PROBLEM:
Project Object Relation (POR) proliferation Issue
For objects created prior to Tc 11.2.2 which have security attributes assigned, the following undesired data conditions can exist after upgrading to 11.2.2 or 11.2.3
- Unnecessary ProjectObjectRelation (POR) objects are created during various actions which trigger propagation
Impact:
- Proliferation of superfluous POR objects
- Performance and lock issues with objects having legacy PORs when the data with security attribute assigned is used
- Propagation functionality is unaffected
REMEDY:
• The underlying issue is resolved in the following Teamcenter releases and later releases in the patch and minor release series. These release streams contain the server code changes to address the proliferation issue.
• Tc11.2.2.1_a01_4
• Tc11.2.2.1_b01_4
• Tc 11.2.3.1_a01_1
• Tc 11.2.3_c01_1
• Tc 11.3
• A “one time use” utility is posted on GTAC site for 11.2.2.x and 11.2.3.x. These are posted under Product Updates for Teamcenter in the Tools/MigratePropagation directory
• Utilize this utility to address superfluous data situation in 11.2.2+ and 11.2.3+ environments.
• For customers using Oracle database: Customers who upgrade from a Teamcenter release earlier than Tc 11.2.2 directly to any release listed in the series above will not have superfluous POR issue and do not need to use the utility for data clean up
• For customers using SQL Server database: Customers who upgrade from a Teamcenter release earlier than Tc 11.2.2 directly to 11.2.3.x or 11.3 release listed in the series above will not have superfluous POR issue and do not need to use the utility for data clean up
• The utility also supports migration of legacy PORs to new PORs. See Details and Utility sections that follow
• For customers who are at release level 11.2.2.x or 11.2.3.x not in release listed in the series above should migrate the POR data to prevent POR proliferation issue. See Details and Utility sections that follow.
• Migrating POR data is also beneficial where customers desire to have more granular control over propagation i.e. propagating to different destination objects per Security Group as an effect of removing some OOTB rule(s) or adding custom propagation rule(s) with specific Security Group.
Details:
Important Note: This utility cannot be run concurrently with any other Teamcenter processes accessing the same database. Specifically, multiple instances of this utility cannot be run in parallel. This limitation is due to the high-speed, low level nature of the codes used in the utility.
• Clean up PORs using migrate_propagation_data utility This is only needed for releases where superfluous PORs issue exists i.e. Release >=11.2.2 and <11.3
Performance Expectations : query and fix of superfluous POR has been seen to execute efficiently and for reasonable number of such POR (less than 1000) requiring fixes as outlined above,we can expect no more than a few minutes (~5-10 minutes) for any such operation including querying and reporting.
Please use the utility in advance with the option, -mode=dryRunMode, to determine the data size and estimate execution time.
Actual clean up must be done during downtime with no other active Teamcenter usage.
Multi-site implications:
-If the customer has a federation of sites connected via Multi-site, the clean-up and migration of PORs needs to be done at each site separately
*All clean-up code is agnostic to the replica state of any affected objects, the master and replica objects can be processed in the same way.
*If all affected objects at all sites have been processed along these lines, no additional data-share/data-sync process is required to re-sync the data.
*Clean-Up of any such objects does not trigger additional multi-site operations (since it does not update “last modified date” of the affected objects)
•Next, need to accomplish migration of legacy PORs to new PORs. Multi-site implications for migration:
-If the customer has federation of sites connected via Multi-site, the clean-up and migration of PORs needs to be done at each site separately
*All migration code is agnostic to the replica state of any affected objects, the master and replica objects can be processed in the same way.
*If all affected objects at all sites have been processed along these lines, no additional data-share/data-sync process is required to re- sync the data.
*Migration of any such objects does not trigger additional multi-site operations (since it does not update “last modified date” of the affected objects)
Based on customer data size and need for migration recommend one of the following options.
Run the utility with the option, -mode=dryRunMode, to determine the size.
Performance Expectations: The current rate of conversion is observed to be ~6 Million PORs/hour (For this and other timing information in the document we have used the following reference hardware/software configuration:
VMWare node, Windows Server 2008 R2 Enterprise Pack, 64bit, 92G RAM, MySQL 11.0)
-Option1: Complete total migration in one activity
Steps:
1.Ensure that clean-up of superfluous PORs has been done
2.Migrate Legacy POR objects using migrate_propagation_data utility Reference the utility for detailed instructions
We recommend to run migration processes sequentially with as many as 500k object UIDs per input file.
-Option2: Phased migration
Migration of the legacy PORs can be done as per customer convenience/schedule.
Steps:
1.Ensure that clean-up of superfluous PORs has been done
2.Using BMIDE, add custom propagation rules with “No Group” propagation group:
For any custom propagation rule (defined via BMIDE in Tc 11.2 and above OR added as a project preference in pre-Tc 11.2),
•Generate a new rule with same parameters but change the PropagationGroup entry to “No Group”
•Deploy these changes into the database
3.Migrate Legacy POR objects in a phased manner as convenient using migrate_propagation_data utility (Reference the utility for detailed instructions)
Recommendations:
*Prioritize the migration of business critical data (generally active engineering data)
*Business critical data (UIDs) can be identified by running SQLs and migrate option can be used with UIDs as input.
*Migration must be done during downtime Migrate in phases in chunks of data that fits the downtime window. We recommend to run migration processes sequentially with as many as 500k object UIDs per input file.
Utility:
migrate_propagation_data utility to clean-up superfluous PORs and migrate PORs will be available for download at GTAC site.
Syntax
migrate_propagation_data [-u= user-id {-p= password | -pf= password-file }
-g= group ] [-h ]
[-mode=dryRunMode|fixMode]
[-migrate=1]
[-deleteSuperfluous=1]
[-deletePORWithAllNullAttr=1]
[-toplevelObjOutputFile=]
[-filePath= file path]
[-noGroupCount=1]
Arguments
-u
Specifies the user ID.
This is generally infodba or another user with administration privileges. If this argument is used without a value, the operating system user name is used.
Note: If Security Services single sign-on (SSO) is enabled for your server, the -u and -p arguments are authenticated externally through SSO rather than being authenticated against the Teamcenter database. If you do not supply these arguments, the utility attempts to join an existing SSO session. If no session is found, you are prompted to enter a user ID and password.
-p
Specifies the clear text password.
This argument is mutually exclusive with the -pf argument.
-pf
Specifies the encrypted password file.
For more information about managing password files, see Manage password
files.
This argument is mutually exclusive with the -p argument.
-g
Specifies the group associated with the user.
If used without a value, the user’s default group is assumed.
-h
Displays help for this utility.
-mode=
Different modes for running the utility. Report is written to syslog.
Set “TC_KEEP_SYSTEM_LOG” to true to keep the syslog file.
dryRunMode This is dry run mode. No modification will be made to the data
in this mode. The Utility will report in the syslog the list of objects for
which duplicate ProjectObjectRelation (POR) exist and the number of
duplicate POR objects.
fixMode This is fix mode. In this mode, duplicate
ProjectObjectRelation (POR) associated with the objects are deleted. The
Utility will report the objects for which PORs are deleted in the syslog
file.
-filePath
An input File containing UIDs of objects which needs to be processed. Each
UID should be specified in a separate line
-migrate=1
Perform migration of objects provided in the UID list in input file
specified by “-filePath”
– deleteSuperfluous=1
Perform cleanup of superfluous POR in the database (no input file of UIDs
required) as follows:
o Clean all POR with “”/empty group and convert to “No Group” (this data
condition may occur for MS SQL Server platform only for releases >=11.2.2
and <11.2.3). a list of UIDs can be specified optionally.
o For POR with “No Group”, find and remove any other POR associated to
the same top-level objects
o For POR with duplicate groups, find and remove all such duplicate PORs.
Note: both –migrate and –deleteSuperfluous can be run in dry Run mode as
well (see usage below)
-deletePORWithAllNullAttr=1
Deletion of POR having “No Group” and all null security attributes
These POR cannot be migrated and they are not required for re-propagation.
However be advised that this code will not scrutinize any additional custom
security attributes.
If such custom security attributes are used, it is advised not to invoke
fixMode for this use case and leave these in the system.
-toplevelObjOutputFile=
If this option is specified, a query is run against the entire database to
find all UID of top-level objects with “No Group” POR. This file can then be
used as input for the “-filePath” option to migrate such objects.
-noGroupCount=1
If this option is specified, the utility will display the total number of
POR with “No Group” in the database
Important Note: The example list of usage commands shown below does not
correspond to the desirable sequence of execution for successful cleanup and
migration of the database. We recommend the following sequence of command
execution:
a) find relevant counts of POR objects
b) generate input file and chunk into a set of input lists each no greater
than 500k
c) execute dry run for cleanup of superfluous POR
d) execute fix mode for cleanup of superfluous POR (as needed)
e) execute dry run for migration
f) execute fix mode for migration
Important Note: This utility must not be run concurrently with any other
Teamcenter processes accessing the same database. Specifically, multiple
instances of this utility must not be run in parallel.
Usage
Usage 1. migrate_propagation_data -u=userid -p=password -g=group
-mode=dryRunMode -migrate=1 -filePath=
Usage 2. migrate_propagation_data -u=userid -p=password -g=group
-mode=fixMode -migrate=1 -filePath=
Usage 3. migrate_propagation_data -u=userid -p=password -g=group
-mode=dryRunMode -deleteSuperfluous=1
Usage 4. migrate_propagation_data -u=userid -p=password -g=group
-mode=fixMode -deleteSuperfluous=1
Usage 3a. migrate_propagation_data -u=userid -p=password -g=group
-mode=dryRunMode -deleteSuperfluous=1 -filePath=
Usage 4a. migrate_propagation_data -u=userid -p=password -g=group
-mode=fixMode -deleteSuperfluous=1 -filePath=
Usage 5. migrate_propagation_data -u=userid -p=password -g=group
-mode=dryRunMode -deletePORWithAllNullAttr=1
Usage 6. migrate_propagation_data -u=userid -p=password -g=group
-mode=fixMode -deletePORWithAllNullAttr=1
Usage 7. migrate_propagation_data -u=userid -p=password -g=group
-toplevelObjOutputFile=
Usage 8. migrate_propagation_data -u=userid -p=password -g=group
-noGroupCount=1