successful data migration

PTC Channel ServicesOliver Droop

Successful Data MigrationFrom Pro/INTRALINK 3.x to Windchill PDMLink 9.x or Pro/INTRALINK 9.x

PTC Channel Services

Agenda

Why should I migrate to the new Architecture?

How Does Data Migration Fit into the Deployment Pro cess?

Migration Roadmap: the Path to a Successful Migrati on

“Patterns” of Migration

Considerations: What Matters Most?

PTC/User 2009 Eindhoven2 © 2009 PTC


Compatibility Requirements

Pro/INTRALINK Data Migrator 9.x Software Overview

Migration Process Step by Step

Tips and Tricks



Tighter Pro/ENGINEER integration

Less clicks, usage from model tree, great “SimpRep” support

Stay on supported platform

Continue to receive bug fixes and release updates

Take advantage of using Wildfire 5 and beyond


New features available like shape indexing against the database

Improved WAN performance and visualization for distr ibuted groups

Smart replication and caching mechanisms

Enables enhanced collaboration in-house or with customers, improving design productivity and reducing time to market

Consolidates data from multiple Pro/INTRALINK systems

Improved search and reuse capabilities



Establish a platform for growth beyond CAD data man agement and into more advanced business processes

Advanced Change and Configuration Management

Integral Collaborative Project Management with Windchill ProjectLink

Streamline Release to Manufacturing with Windchill MPMLink

Integrate with other Enterprise Systems


Integrate with other Enterprise Systems

Multiple options to connect to ERP Systems

Integration with Sharepoint via Webparts


Agenda











Tips and Tricks


How Does Data Migration Fit into the 9.x Deployment Process?

A successful Pro/INTRALINK 9.x deployment meets cer tain requirements.

Those requirements mean something in the deployment plan.

Requirement

System set up and configured to meet business needs .

Implication

Need time for system configuration and use case validation.


to meet business needs .

System performance meets needs of business and users.

Legacy data in the system.

Users productive on the system.

Project completed on time and on budget .

and use case validation.

Need to validate performance, tune if necessary.

Need to include data migration activities.

Need to include training and adoption.

Project Management is important.


Project Management

The Typical Pro/INTRALINK 9.x or PDMLink 9.x Deploy ment Process

Training

Target System Design,

9.x Admin Training

User Training


Target System Design,Install, Setup, & Configuration

Data Migration

Performance Tuning

Go Live

System Validation/Use-Case Testing


Agenda











Tips and Tricks



Customer Training & Prerequisites

Planning

Conflict Identification

This methodology is based on PTC’s years of experience in all types and sizes of migrations.

In particular…

P

CI

Metadata M

igration



Conflict Resolution & Data Cleansing

Rehearsal Migration

Production Migration

� Pro/PDM to Pro/INTRALINK 3.x.

� Pro/INTRALINK 3.x to PDMLink 8.0/9.x.

PTC Global Services and Certified Migration Partners will follow this methodology

CR

RM

PM

Metadata M

igration



Details:

� Attend Administrator training.

� Attend migration training (if necessary).


Planning



� Provision hardware.

� Complete Install and Setup of target system.



Rehearsal Migration




Details:

� Create Project Plan.

� Document Data Migration Requirements (Data Mappings).


Planning



• Example: attributes, version scheme, folders, phases, …

� Develop Migration Procedure and Checklist

� Create Migration Validation Plan.



Rehearsal Migration




Details:

� Install Pro/INTRALINK Data Migrator.

� Run Pro/INTRALINK Data Migrator on Metadata only, using Data Mappings from


Planning



using Data Mappings from Migration Requirements Document.

� Pro/INTRALINK Data Migrator will identify conflicts and generate Conflict Report Logs.



Rehearsal Migration





Planning


Details:

� Review Conflict Report Logs.

� Determine and apply appropriate resolutions.




Rehearsal Migration


� Update Migration Requirements, Procedures, and Migration Validation Plan, if necessary.



Details:

� Perform full migration

� Validate results using Migration Validation Plan.

� Review validation results.


Planning



� Review validation results. Update Requirements, Procedures and Validation Plan, if necessary.

� Perform additional Conflict Resolution or Data Cleansing, as necessary.

� Capture duration



Rehearsal Migration




Details:

� Execute Production Migration.

� Validate results using Validation Plan.


Planning



� Review validation results.

� Make Go-Live decision.



Rehearsal Migration



Agenda











Tips and Tricks



There are three basic “patterns” of migration

Single-Source

Migration from a single Pro/INTRALINK 3.x system to a single Pro/INTRALINK or PDMLink system.

Can be considered to be the “basic” or the “unit” case.


Pro/I 3.4 Pro/I 9.x or PDMLink 9.x

P CI CR RM PM��

��= Project Review Checkpoint


Multi-Source Migration: Serial Migration Pattern

Serial Migration Pattern

Series of single-source migrations with multiple go-live events.

Good way to combine 3.x databases over time and “grow” the system.


Pro/I 3.x#2

Pro/I 3.x#1

P CI CR RM PM

P CI CR RM PM

��

��Pro/I 9.x or PDMLink 9.x

(Go Live)

1st Go Live on Pro/I 9.x or PDMLink 9.x after DB #1 production migration

2nd Go Live on Pro/I 9.x or PDMLink 9.x after DB #2 production migration

Possible Time Gap



Multi-Source Migration: Stepped Migration Pattern

Stepped Migration Pattern

Repeated migration subtasks with single go-live event.

Good way to focus on migration over a limited period and get it out of the way.

Go Live on Pro/I 9.x or PDMLink 9.x after completion


Pro/I 9.x or PDMLink 9.x

P CI CR RM PM

P CI CR RM PM��

��

��

��

PDMLink 9.x after completion of all production migrations

��

Metadata Migration

Pro/I 3.x#2

Pro/I 3.x#1



Agenda











Tips and Tricks



What are the leading drivers in overall project com plexity?

Current CAD data management processes and security.

– Impact System Design/Configuration of 9.x system

– Note: the # and naming of existing groups is a good indicator how complex your access requirements are – e.g. 20 xxx_designer groups maybe 20 products with a designer team role


Quantity and distribution of users.

– Impact Training efforts and Support Needs.

– Impact 9.x System Configuration and Architecture.

Quantity, distribution, and complexity of data.

– Impact Migration Strategy and Scheduling Activities.


Factors related to 3.x data quantity and distributi on


� Number of source databases.• Two databases more difficult than one

vs.vs.

� Number of Product Item Versions• Affects duration of migration

Pro/I 3.x DB #1


vs.

US FVUS FV UK FV

vs.Small

FV

vs.

Pro/INTRALINK 3.x

Pro/I 3.x DB#2

Pro/INTRALINK 3.x

Pro/INTRALINK 3.x

Small Pro/INTRALINK

3.x DB

LargePro/INTRALINK

3.x DB

Pro/INTRALINK 3.x

Pro/INTRALINK 3.x

� Volume of file vaults (GB)

• 500 more “cumbersome” than 50GB� Location of source vaults

• Distributed more difficult than centralized

LargeFV



Factors related to 3.x system configuration

� Inconsistencies among Pro/INTRALINK 3.x databases

• Impacts system design and conflict resolution.

Example: Revision sequence.

� Usage of 3.x package replication

• Affects complexity of creating test environments.

3.x 3.x


3.xDB1

3.xDB2

1 , 2, 3, …, -, A, B, C, …

-, A, B, C, …

Example: Revision sequence.

3.xDB

PDMLink8.0Gateway

3.xDB1

3.xDB2

Package Replication

� Usage of 3.x INTRALINK Gateway

• Affects complexity of creating test environments. (Gateway not supported with PDMLink 9.x.)



Factors related to target system

� State of the Pro/INTRALINK 9.x system.

• Populated database causes more conflicts than empty database.

. � Migration with WTParts

• PDMLink 9.x has concept of WTParts and Product Structure. Part & Product Structure creation is optional.

• WTParts and structure can be created during migration, causing migration to take longer.


vs.

Pro/INTRALINK 3.x

Pro/INTRALINK 3.x

WindchillPDMLink 9.x

Pro/INTRALINK9.x

vs.

Pre-Existing Data

Pro/INTRALINK 3.x

Pro/INTRALINK 3.x

Windchill PDMLink 9.x

WindchillPDMLink 9.x

longer.


Agenda











Tips and Tricks


Software: Compatibility Requirements

Pro/INTRALINK Data Migrator 9.x Compatibility Matri ces


*The Pro/INTRALINK Data Migration only supports mig rations to a target system running with Oracle. It does not support migrations directly to Windchill systems co nfigured to use Microsoft SQL Server as its databas e.


Software: Compatibility Requirements

Certified Platform Support



Software: Are you not on the latest release?


Reference Documents:

Technical Support Suggested Technique for migration from Release 3.2 or 3.3 to Release 3.4. Link

Technical Support Suggested Technique for migrating from Release 2.0 to Release 3.0 or 3.2. Link

Release Notes for Pro/INTRALINK 2.0, see section "Updating to Pro/INTRALINK Release 2.0" for description of steps. Link


Agenda











Tips and Tricks


Pro/INTRALINK Data Migrator 9.x Software: Overview

Enables migration from Pro/INTRALINK 3.4 to the 9.x architecture

Pro/INTRALINK Data Migrator 9.x is available to all Pro/INTRALINK Maintenance-Paying Customers

Conflict Resolution Capability enables Migration of multiple Pro/INTRALINK 3.4

Windchill PDMLink 9.x orPro/INTRALINK 9.x


Migration of multiple Pro/INTRALINK 3.4 databases to one Pro/INTRALINK 9.x or PDMLink 9.x Database (One at a time).

Key capabilities:• Out of the box support for all Pro/ENGINEER file types

• Migration of non-Pro/ENGINEER data currently managed in Pro/INTRALINK 3.x

• Preservation of the Revision History of migrated data

• Works with a pre-populated target system

• Optional WTpart and Product Structure creation

Pro/INTRALINK Data Migrator

Pro/INTRALINK 3.x

Pro/INTRALINK 3.x

Pro/INTRALINK 3.x


SQL Server

The Pro/INTRALINK Data Migrator will not support mi grations from Intralink Oracle to MS SQL Server (PDMLink or Pro/IN TRALINK 9.x). But there is a tool available that moves an Oracle to a SQL Server Windchill database.

What does this mean for Pro/INTRALINK 3.x customers looking to go to a SQL*Server based system?


SQL*Server based system?

It means that they would migrate to SQL Server in 2 steps:

– Migrate their Pro/INTRALINK 3.x to 9.x running Oracle

– Use 9.1 tools to move this database to SQL Server

Guidelines and Documentation available

– http://www.ptc.com/WCMS/files/84371/en/WCOracleToSQLSvrMigGuide.pdf

– http://www.microsoft.com/sqlserver/2005/en/us/migration-oracle.aspx


Software: Supported Data

All Objects, All Versions

Main branch data only

Maintain revision/version history

Broad file type support

– Pro/ENGINEER (CAD Docs)

Relationships

Pro/ENGINEER

User Defined and BOM

– Secondary content

– BOM migrated as WTPart relationship


– Non-CAD data (WTDoc)

Document types configurable

– Pro/ENGINEER file types required as CAD Document

– Some file types hard-coded as secondary content

• Note – for secondary content not all versions may be migrated

– Others – configurable

Support for soft types

Release Levels

Mapping of RS/RL to Life Cycle(s) and State(s).

– Manual definition of PDMLink lifecycles required prior to mapping

Attributes

Versioned, including Lifecycle attributes

Non-versioned

Dependency


Software: Supported Data (Continued)

Configurations

Named and as-stored baselines

Package Replication recognition

Object Maturity / Lifecycle History / Rename Histor y

Forms


Completed RTP Forms

Check-In Form Comments

File vault content

WTParts and Product Structure

Post migration scripts provided

Configuration language provided to specify which objects require WTParts

Support Pro/ENGINEER and non-Pro/ENGINEER data

Visualization Data


Software: Features

Conflict Resolution capabilities

Conflict Reporting

Prescribe Bulk Rename Resolutions

– Bulk Rename in Pro/INTRALINK 3.x

– Bulk Rename in Pro/INTRALINK 9.x or PDMLink 9.x


Duplicate Object Manager

– Use Existing Object (Merge)

– Replace Existing Object

Facilitate support of following use cases:

– Pre-existing data in target system, including gateway data

– Support merge of multiple Pro/INTRALINK common spaces


Software: Features (Continued)

Error Logging and Status monitoring

Track progression of migration processes

Record un-migrated data

– Particular PIs and PIVs

– Dependencies


Administrative Data Loading

Users

Attributes

Folder Structure


Agenda











Tips and Tricks



1. Preparation

1. Review Data Migrator Documentation

– http://www.ptc.com/WCMS/files/89201/en/ProIDataMigAdminGuide_X-12_M010.pdf

2. Clone Intralink to Migration Environment

3. Copy and run Healing Scripts on IL


4. Set Intralink into restricted mode

5. Prepare PDMLink Server Business Configuration

6. Backup PDMLink



2. Migration

1. Download Admin Data from IL– User, Folder, Attributes, Vaults

2. Edit property/mapping files– Above plus Types, Part Rules

3. Reconcile


3. Reconcile

4. Load Admin Data to PDML

5. Map Admin Data

6. Doc Resume

7. Execute Loader threads (see picture)

8. Migration Status

9. Post Migration Data Check

10. Unhide



3. Post Migration

1. Run check epmfilesize (see Tips section for details)

2. Delete unneeded users and cabinets

3. Backup PDMLink

4. Run Windu Tool (see Tips section for details)


5. Reset tuning settings


1. One-time Pre-migration Completed 3. Migration Completed

Intralink Installation Lock intralinkInstall 3.4 M040 dataserver and client ildataloader MappingPatch TCL libraries Clean up mapping

PDMLink DownloadIncrease Data Migrator, Tomcat, Method Server memory ReconcilePDMLink site.xconf configuration Create user and group scripts, user preference scriptPDMLink Business Config loadFiles (users, groups, lc, wf, attibutes, container, templates) Create users, assign to groups, user preferencesVault reconfiguration (delete default cache vault, set master to cache, autocreate folder) Load Admindata,Type Manager, add Logical Identifier MappingCreate EPMDOCUMENT_ATTRIBUTES Attribute Organizer (can be loaded) ildataloader DocResumeDisable site-level library and product templates Resolve naming conflictsCreate custom table views ildataloader MassRename WTDOCLoad or set Preferences ildataloader MassRename CADsetup content cache sites delete from Intralinksetup cad workers pibatchrenameFull backup Re-Run update common name script

Install migration tool ildataloader DocResume

Production Migration Checklist


Install migration tool ildataloader DocResumeInstall migration tool on PDMLink clone Run migration ant script for remaining stepsCopy scripts to Intralink server ildataloader UnHideConfigure migration.properties (attribute organizers)

2. Pre-migration Post-MigrationIntralink Production PDMLink

Disable ALL replication Delete orphaned users from PDMLinkShut down server, take ilink_export cleanup cabinets of deleted users

Intralink Clone Set state-based go-forward version seriesAdjust system time SQL patch for family table issueImport Intralink DB run windu famtbl validatorUpgrade Intralink schema (ilink_patches SCHEMA) check for empfilesize = 1Run healing scripts on Intralink database BackupChange vault pointers to new file vault location Rehosting to production (recompile packages, update stats)Move/validate replicated objects into separate folder Finalize local replication processCreate orphaned users Convert replica vault to use auto-folder creationDelete unwanted attributesRun update common name scriptData clean-upBackup Intralink

PDMLinkSet file-based versioning series to be used for migrationCopy over Intralink vaultsAdd custom statistics gathering job


Agenda











Tips and Tricks


Content of the Tips and Tricks section

Migration into clustered environments

Using legacy flag for new version scheme

Check for orphan users in INTRALINK 3.x

Check for double usernames in INTRALINK 3.x

Check for missing objects

Check for orphan files

FT Loader issue

Post Migration Check

Tuning loader performance


Check for 0-bytes Objects

Creating precopy area and configure vaulting

Check for WTDocuments with long filenames

Setting timezones for migration

Creating „Quick backup and restore“ of PDMLink

Fix Time Stamp of „PImerge“ objects

Best practice for delimeter settings

Check for double names in INTRALINK

Check for empty folders in INTRALINK


Migration into clustered environments

The dataloader allows easily to migrate into an acti ve Windchill cluster

Install an ORACLE client on your fastest foreground methodserver (migration server)

Install Intralink Data Migrator on the same migration server

You mustn‘t propagate any xconf changes to the other nodes

If you have the chance, add a fast multicore box to you cluster to improve performance. All loaders will only run on the migration server – it is NOT supported/reliable to execute threads on second node!


supported/reliable to execute threads on second node!

If working with a multicore CPU using 5 worker threads will work very well. On single core CPU 2-3 workers are most time OK

Using an Oracle RAC needs minor reconfiguration

An active RAC works but slows down migration time due to synchronization

Shutdown second instance and connect the migration server to the active instance– Service during migration: <Property name="wt.pom.serviceName" overridable="true" targetFile="db/db.properties"

value=“hostname1:1521:inst1"/>

– After migration reset:<Property name="wt.pom.serviceName" overridable="true" targetFile="db/db.properties" value="(DESCRIPTION = (LOAD_BALANCE=yes)(FAILOVER=yes)(ADDRESS = (PROTOCOL = TCP)(HOST = hostname1)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = hostname2)(PORT = 1521))(CONNECT_DATA=(SERVICE_NAME = inst )))"/>


Using legacy flag for new version scheme

Many customers have an old version scheme which mig ht not be appropriate after migration. E.g. numeric scheme wa s used in the past and later on switched to alphanumeric.

Old: 01,02,03,…,-,A,B,C,….

New: -,A,B,C

During migration the version scheme must be identic al to the complete


During migration the version scheme must be identic al to the complete old scheme to assure a correct data. After the migr ation you can disable the invalid values by adding a legacy flag to the s eries.

Use windchill wt.series.LoadFileBasedSeries loadFiles\mySeries.xml -load/-read

• migration series:<series name=“mySeries">

<value>00</value><value>01</value><value>02</value><value>03</value>….<value>-</value><value>A</value><value>B</value><value>C</value>…

• post migration series:<series name=“mySeries">

<value legacy="true">00</value><value legacy="true">01</value><value legacy="true">02</value><value legacy="true">03</value>….<value>-</value><value>A</value><value>B</value><value>C</value>…


Best practice for delimeter settings

By default the dataloader uses a „.“ as a delimeter.

This will get you into trouble if you have products with a „.“ or Release scheme names with a „.“

The documentation allows to change the delimeter to any ASCII value. I foundout, that „|“ is a very good one because never ever user for products and so on.

Change the migration.properties and add the following line. Restart you


Change the migration.properties and add the following line. Restart youmigration methodserver und any instance on the dataloader to make thechanges happen.

– migration.admin.contextDelimeter |


Setting timezones for migration

Pro/INTRALINK does not care about time zones. You al ways see the dataserver time if you take a look at the „CreatedOn “ or similar.

PDMLink does care and adapt time zones. That's great ! To avoid that files from an asian INTRALINK have wrong CreatedOn an d ModifiedOnvalues after importing into a European PDMLink syst em you must adapt the time zones.


The local migration clone of the INTRALINK dataserver machine must have the time zone from the original location (e.g. Asia)

The PDMLink server must have the time zone of the location it is located:


Check for orphan users in Pro/INTRALINK 3.x

All objects created by users that don‘t exist in Pro/INTRA LINK 3.x anymore will be mapped to the site administrator „wtadmin“ d uringmigration. You can change this upfront by

Create a list of all orphan users: sqlplus system/manager@INTRALINK

• select createdby from pdm.pdm_productitemversion p where (select count (*) frompdm.pdm_user u where u.username=p.createdby) = 0 group by createdby;

Add all listed users again to Pro/INTRALINK 3.x. If having a larger number of


Add all listed users again to Pro/INTRALINK 3.x. If having a larger number ofusers you should use INTRALINK JAVA Script to automatically add the users. (add_user.java)

If you map one ore more users to a „migration user“, the old INTRALINK accounts will not be created in PDMlink!

– as3423=as3423 (user will be created)– dk3233=migration (user migrate must exist, dk3244 will not be created)– lk4533=lk4533 (user will be created)– fg2223=win111 (user win111 must exist in PDMLink, fg2223 will not be created)


Check for double usernames in INTRALINK 3.x

INTRALINK 3.4 makes case sensitive differences betw een „User123“ and „user123“. PDMLink does not. Therefore check for „doub le“ usernames and make changes to your usermap.properties to avoid unexpected mappings.

1.) Create a list of „double“ usernames: sqlplus system/manager@INTRALINK

• select lower(username) from pdm.pdm_user group by lower(username) having count(*) > 1;


2.) Do an approciate mapping in the usermap.properties file– ER3423=er3423– er3423=er3423– Kr3455=tr4432 (user has been married and got a new name ☺ )– kr3455=kr3455


Check for missing objects

An „must have“ is a „missing object report“. Use the text bas e sciptedinstead of the ProIMgr user interface to get maximum perform ance.

<dataserver loadpoint>\intralink\objects\tclsh ilink_missing_object_report.tcl

If there is any missing item try to restore it!!!

If you can‘t find the file anymore delete the version of the o bject in Pro/INTRALINK.


Pro/INTRALINK.


Check for orphan objects

If you work with the precopy option it is a very goo d advise to create a „orphan object report“ and remove all these objects.

<dataserver loadpoint>\intralink\objects\tclsh ilink_orphan_file_report.tcl

There is a Tcl/TK Script that can move automaticall y all files from the „orphan files report“ into a subdirectory „/orphan“ on the fileservers. You have to configure the fileservers port and pass word inside the cleanup_orphan_files.tcl.


cleanup_orphan_files.tcl.

Having a orphan free pre-copy area makes it easy to check, that all files have been transferred. And if not: You can see, wha t is missing. Most times an issue of a wrong: pitdmapping.properties


Check for 0-bytes Objects

In certain cases Backup and Restore does not work as desir ed andobjects get destroyed. Also after creating the pre-copy area you shouldtake care that there are no 0-Byte objects. These objects do not containany valid data.

Search for these objects in the filesystem and verify your copy.

– WINDOWS: change to fileserver directory


– dir /o:-s /a:-d *

You get a sorted list of all files. The 0-byte files are l isted at the end.


Check for „double“ names in INTRALINK

INTRALINK 3.4 makes case sensitive differences betw een object named “abc.doc” and “Abc.doc”. These objects will create some trouble if mapping the name to NUMBER. It will create a duplic ate number

Create a list of „double“ objectname: sqlplus system/manager@INTRALINK

select lower(piname) from pdm.pdm_productitem group bylower(piname) having count(*) > 1


Rename the objects inside Pro/INTRALINK


Check for empty folders

Search for potential empty Pro/e folders to delete them. This script will report all folders without any objects inside. Neve rtheless it could be that subfolders contain objects. The delete JAVA Script will take care that ony folders got deleted than are really empty.

select folpath from pdm.pdm_folder f where (select count(*) from pdm.pdm_productitem p where f.folid=p.folid) = 0 group by folpath


group by folpath

Sort the list descending!

Use a java macro to run a delete job to get rid of your empty folders.


Check for WTDocuments with long filenames

For many migrations it is a very common option to m ap filenames to PDMLink „Number“.

Long filenames are no problem for all EPMDocuments b ut WTDocumentsare forced to have filenames with less than 32 char acters including the extension and the „.“

Check in the “WTDocument Section” inside pitdmapping.properties can cause this issue.


Check in the “WTDocument Section” inside pitdmapping.properties can cause this issue.

Create a list of all long filenames: sqlplus system/manager@INTRALINK

• select piname from pdm.pdm_productitem where length(piname) > 32 and (not piname like‘%.prt‘) and (not piname like ‘%.asm‘) .....drw,igs,dxf, stp,frm,sec,gph...

Take a look at the results you get and decide if th ere are additional types you have to exclude.


TAN 132021 – Populate a string value to PTC_COMMON_N AME

PTC_COMMON_NAME was introduced in past to Pro/Intra link but it might

It is highly desirable to populate the value of PTC _COMMON_NAME with that of an existing attribute in Pro/INTRALINK

Contact Technical Support for a script and instructions included in the zipfile that will populate the value of PTC_COMMON_NAME with that of an existing attribute in Pro/INTRALINK.


Creating pre-copy area and configure vaulting

You should ALWAYS work with the pre-copy option to minimize t ime forthe data. For general Information take a look at the manua l.

Pre-copy areay should be on the same partition as the PDMLink filevaults. Pre-copy use the operation system „move“ and „rename“ command. This only worksfast if data is on the same partition.

One mastervault is recommended. Many customers use multip le vaultsin Intralink to separate data, mostly to be able to messure the consumed


in Intralink to separate data, mostly to be able to messure the consumedspace by department. In PDMLink the size can be easily quer ied via a report or sql and multiple vaults shouldn‘t be needed.

For best performance and administration:

<Property name="wt.fv.forceContentToVault" overridable="true" targetFile="codebase/wt.properties" value="true"/><Property name="wt.fv.useVaultsForAllContent" overridable="true" targetFile="codebase/wt.properties" value="true"/>

<Property name="wt.fv.useFvFileThreshold" overridable="true" targetFile="codebase/wt.properties" value="true"/><Property name="wt.fv.fvFileThreshold" overridable="true" targetFile="codebase/wt.properties" value="50000"/>

<Property name="wt.fv.replicationFileSizeThreshold" overridable="true" targetFile="codebase/wt.properties" value="0"/><Property name="wt.fv.purgeUnreferencedFvItemsOlderThan" overridable="true" targetFile="codebase/wt.properties" value="2"/><Property name="wt.fv.revaulting.NumOfQueues" overridable="true" targetFile="codebase/wt.properties" value="3"/>


Creating pre-copy area and configure vaulting

Your PDMLink vaults must be „Enabled“

Read/Write Access will be checked during verififaction of vault/folder and is strongly advised.

IF your PDMLink vaulting needs to be similar to the INTRALINK vaulting you should not use the „defaultcachevault“ as target. Use the real vault of the product. This saves time for revaulting after migration


The Data Migrator does not take care about any vaultingrules you have defined in your products. It only uses the „vaultingrules“ from the filevaults.properties file

– FILEVAULT.server:|vault|00=defaultcachevaultLOCAL_PRECOPY_PATH.server|vault|01=/precopy/vault/01

– FILEVAULT.server:|vault|00=Product01VaultLOCAL_PRECOPY_PATH.server|vault|01=/precopy/vault/01

IF you have differences between your INTRALINK and your PDMLink vaulting scheme create revaulting jobs to solve the location discrepancy. But again, one vault with many folders is in most c ases the best solution!


Creating „Quick backup and restore“ of PDMLink

It is a good practice to create several snapshots t o which you can rollback in cases of errors or to start a rehearsal migration.

Snapshots should be taken from:

PDMLink empty

PDMLink after business configuration is loaded

PDMLink after migration Mapping and DocResume is completed


PDMLink after migration Mapping and DocResume is completed

Intralink once after cloning, healing and migration scripts are completed

Backup PDMLINK: LDAP and ORACLE is all you need– /usr/sbin/lde/export -c "" -o /wt9_backup/PDS_PreMig.ldif -f /usr/var/lde/PTCLdap/PTCLdap_lde.conf– exp pds/pds@pds file=/wt9_backup/PDS_PreMig.dmp grants=y statistics=none consistent=Y

On INTRALINK export ORACLE Dump– ilink_export.bat

Assumptions: Vaults are empty, Software restore not needed, no active load


Fix creator of „PImerge“ objects

Some costumers have merged their databases with PIm erge from SF before doing a migration to PDMLink. These objects most ti mes have „wrong“ system attributes. They belong all to one user. PIm erge store the old attributes into 2 versioned attributes. Most times SRC_CREATED_ON and SRC_CREATED_BY

To get a „nice looking“ PDMLink you have to map these values back to the INTRALINK system attributes createdon, createdby, m odifiedon and modifiedby .


modifiedby .

Further you might want to check for invalid date va lues like 21.04.0004 instead of 21.04.2009.

• select to_char(piv.createdon, 'YYYY-MM-DD HH:MI:SS'), pivid from pdm.pdm_productitemversion pivwhere piv.createdon < to_date('01.01.1970','dd.mm.yyyy');

Ask your Reseller or PTC global services for help i f needed.


Fix creator of „PImerge“ objects cont‘

First changing the creator:

Get the table name and table column of the attribute. If you got more than one result be careful and stop. There is something special!!

sqlplus system/manager@INTRALINK• Select d.dbaattrtable as attrtable, d.dbaattrcol as a ttrcol from

pdm.pdm_dbattrdef d, pdm.pdm_classattr c where c.clai d=d.claid and c.claname=' Src_Created_By ';


• Select d.dbaattrtable as attrtable, d.dbaattrcol as a ttrcol from pdm.pdm_dbattrdef d, pdm.pdm_classattr c where c.clai d=d.claid and c.claname=' Src_Modified_By ';

Copy the values to the system attributes. Replace t he green marked variables with the results you find in the sql befor e:

• update pdm.pdm_productitemversion p set createdby =(select $$attrcolfrom pdm. $$attrtable a where p.pivid=a.pivid) where (select $$attrcolfrom pdm. $$attrtable a where p.pivid=a.pivid) IS NOT NULL

• update pdm.pdm_productitemversion p set modifiedby =(select $$attrcolfrom pdm. $$attrtable a where p.pivid=a.pivid) where (select $$attrcolfrom pdm. $$attrtable a where p.pivid=a.pivid) IS NOT NULL


Fix time stamp of „PImerge“ objects cont‘

Get the table name and table column of the attribute. If you got more than one result be careful and stop. There is something special!!

sqlplus system/manager@INTRALINK

• Select d.dbaattrtable as attrtable2, d.dbaattrcol as attrcol2 from pdm.pdm_dbattrdef d, pdm.pdm_classattr c where c.clai d=d.claid and c.claname=' Src_Created_On ';

• Select d.dbaattrtable as attrtable2, d.dbaattrcol as attrcol2 from


• Select d.dbaattrtable as attrtable2, d.dbaattrcol as attrcol2 from pdm.pdm_dbattrdef d, pdm.pdm_classattr c where c.clai d=d.claid and c.claname=' Src_Modified_On ';

Copy the values to the system attributes. Replace t he marked variables with the results you find in the sql before:

• update pdm.pdm_productitemversion p set createdon =to_date( (select $$attrcol2from pdm. $$attrtable2 a where p.pivid=a.pivid and $$attrcol2 IS NOT NULL), 'YYYY.MM.DD HH24:MI:SS') where (select $$attrcol2 from pdm. $$attrtable2 a where p.pivid=a.pivid) IS NOT NULL;

• update pdm.pdm_productitemversion p set modifiedon =to_date( (select $$attrcol2 from pdm. $$attrtable2 a where p.pivid=a.pivid and $$attrcol2 IS NOT NULL), 'YYYY.MM.DD HH24:MI:SS') where (select $$attrcol2 from pdm. $$attrtable2 a where p.pivid=a.pivid) IS NOT NULL;


FT Loader issue

Often Problems with Memory overflow on large Famtab s and/or famtabswith many iteration

First shot: 4 Threads Loadersize=100

SecondShot: 1 Thread Loadersize=1 (To avoid Java Out of Memory)



Postmigration - EPM File Size Validation

In the past of Intralink it might have been occurred that values for the filesize stored in the database are not in synch with the physical filesizeon disk. This causes issues during download and rep lication and should be fixed upfront.

Check if this is relevant for you

– sqls can be found in the note section


You can check and repair the file size with an available tool from TS

– windchill wt.fv.FVCheckEVFSize


Postmigration - WinDU Validation for Pro/INTRALINK Mig rations

Running the Winchill Diagnostic Utility (WinDU) is highly recommended as a post migration step on all projects going forw ard. This utility will generate a report of possible inconsistencies that need to be investigated before a production use.

For more information on the WinDU utility see TPI 137420.

The WinDU reports should be run after each Rehearsal migration pass and after the Production migration pass. The log files will need to be reviewed for data


the Production migration pass. The log files will need to be reviewed for data issues that must be resolved. Working through issues during the rehearsals will help eliminate problems during the production pass.

Process Steps

• Note: If the target Windchill system already has data in it, then the WinDU Diagnostic Tasks should be run before the migration begins as well as after the migration pass.

• Run all the required WinDU Tasks listed on next page

• Review the log files generated.

• Open one Technical Support call to report all Task errors. Technical Support will then determine if separate calls need to be created for different types of Task errors.

• Follow recommendations provided by Technical Support and R&D to correct the Task errors.


Postmigration - WinDU Validation for Pro/INTRALINK Mig rations

This is the list of required WinDU Tasks:– ValidateFamilyTableData– NullContainerReferencesCheck– MissingMaster– DanglingReferences– DomainAdministeredObjectsDomainReferenceCheck– NullDerivedFromDiagnosticTask


– NullDerivedFromDiagnosticTask– UpdateCountA2DT– VersionAttributeAlignmentDT– DeleteDuplicateFt (only needed when Ilink Gateway published data exists TAN143328)

Resources:

• Windchill Diagnostic Utility Guide link


Tuning to improve loader performance

There are several things you can change to improve performance

1. Switch off „achive log“ mode in ORACLE

2. Switch off „redo logs“ for the tables USER and IN DEX

3. Separate USER and INDEX files to different volume groups even if you have a SAN!

4. Adjust Table size and change AUTOEXTENT to reason able values (e.g. 1GB)

5. Set gather statistic job from 10g from 1h to 15 m in

6. Set undo_retention =0 for IL and PDML Oracle


6. Set undo_retention =0 for IL and PDML Oracle

7. Increase the redo log file size and number depend ing on transfer speed (e.g. 4x 100Mb)

8. Switch off PDMLink Indexing queue or don‘t use in dexing at all if you have only CAD data

9. Adjust memory management of ildataloader.bat (set Xms=1024MB and Xmx=1024MB)

10. Avoid Explicit Garbage collection (modify ildata loader.bat set –XX:+DisableExplicitGC)

11. Analyse all tables in PRO/INTRALINK 3.x after dum p import. dbms_stats.gather_schema_stats(ownname=> 'PDM' , ca scade=> TRUE);

12. Turn of the second instance of a RAC to avoid sy nchronization overhead

13. Run multiple loader threads in parallel


Tuning to improve loader performance

Don’t run same loader from different shells!

Run for e.g. Link in one shell and Baseline in anot her

Server needs to be capable of handling the load

Rule of thumb: # threads is (# of cores - 1)
