About this task
Before migrating
your data, it is recommended that you make a backup of the custom
files in the your current installation, such as:
- Extended API templates
- Customized screens
- Localized bundle files
- Custom themes
Next, ensure that
you complete the following sequence of tasks:
- Before upgrading
from Release 9.2.1 to Release 9.3, compare the entity extension files
in <INSTALL_DIR_OLD>/repository/entity/extensions with
the entity extension files in <INSTALL_DIR_OLD>/extensions/global/entities.
If extension files with matching file names exist, consolidate these
files into one file in <INSTALL_DIR_OLD>/repository/entity/extensions.
- For purposes of
upgrade, Apache Ant is being shipped as part of the migration kit
directory. Set the ANT_HOME environment variable to <INSTALL_DIR>/Migration/apache-ant-1.7.1.
- Go to the <INSTALL_DIR>/Migration directory
and execute the chmod -R 755 apache-ant-1.7.1 command.
- Ensure that the <JAVA_HOME> environment
variable points to the folder in which the JDK is installed.
- Shut down your
production system. The application is unavailable when database backup
takes place.
- Back up the database
server.
Note: This
backup pertains to premigrated data. If you want this data to be available
for use with Release 9.3, you must migrate the data before putting
your system into production.
- For multihop upgrade,
two separate log4jconfig.xml files are used. One
file is located in the <INSTALL_DIR>/resources folder
and the other is copied from the <runtime.old>/resources folder
and placed in the <INSTALL_DIR>/Migration/resources folder.
During the upgrade process logging will be done in the log files mentioned
in both these log4jconfig.xml files.
- If you have functional
indexes, they must be dropped before migration, and re-created after
migration is completed. If you are upgrading in sharded mode, functional
indexes for all colonies must be dropped before migration, and recreated
after migration.
- If you upgraded
from an earlier version to Release 8.0 or 8.2, you must apply 8.0-HF51
(or later) or 8.2-HF18 (or later) before upgrading to Release 9.3.
- In nonsharded
upgrade mode, you have the option of reducing the size of some database
tables by converting CHAR/NOT NULL columns to VARCHAR/NULL columns.
Whether or not you plan to convert these columns, you must extend
the following files and edit the corresponding XML files:
- SMCF_85_attribute_default_extn.xml.sample
- SMCF_920_attribute_default_extn.xml.sample
- YCD_920_tables_modifications.xml.sample
You cannot convert these columns in a sharded environment. Thus,
if you want these columns converted and plan to move to a sharded
environment in the future, you should perform this conversion as part
of the nonsharded migration to Release 9.3.To convert columns on DB2®, perform the DB2: Reducing Table
and Index Size migration strategy. However, if you are migrating from
8.0 (or later) to 9.3 on Oracle, perform the following migration:
Note: If
you upgraded to 8.5 (or later) and are now migrating to 9.3, the SMCF_85_attribute_default_extn.xml.sample file
has already been extended and the corresponding XML file modified.
To maintain these changes, use the earlier release’s extended
file. However, if you want to make additional changes, such as converting
CHAR columns that were not converted earlier, re-extend the SMCF_85_attribute_default_extn.xml.sample file,
as described in this step.
- In the <INSTALL_DIR>/repository/entity/extensions directory,
perform the following file updates:
- copy the SMCF_85_attribute_default_extn.xml.sample file
and save the file as SMCF_85_attribute_default_extn.xml.
- copy the SMCF_920_attribute_default_extn.xml.sample file
and save the file as SMCF_920_attribute_default_extn.xml.
- copy the YCD_920_tables_modifications.xml.sample file
and save the file as YCD_920_tables_modifications.xml.
- To convert
NOT NULL columns to NULL, remove the Nullable attribute
and the DefaultValue attribute from the SMCF_85_attribute_default_extn.xml file,
the SMCF_920_attribute_default_extn.xml file, and
the YCD_920_tables_modifications.xml file. Do not
remove the VirtualDefaultValue attribute from the
XML files.
Note: All NOT NULL columns specified in the
sample files must be converted to NULL. You cannot convert only some
of the NOT NULL columns in these files to NULL.
- Optional. To convert CHAR columns to VARCHAR, remove
the DataType attributes from the SMCF_85_attribute_default_extn.xml file.
If you want to maintain CHAR columns, do not remove the DataType attributes
from the SMCF_85_attribute_default_extn.xml file.
Note: If converting
to VARCHAR, follow these guidelines:
- Convert NOT NULL columns to NULL before converting CHAR columns
to VARCHAR.
- Convert all columns in the SMCF_85_attribute_default_extn.xml.sample file
to VARCHAR. You cannot convert only some of the CHAR columns in this
file to VARCHAR.
- When upgrading
to Release 9.3, if the DB_SCHEMA_OWNER property is not set in the <INSTALL_DIR>/properties/sandbox.cfg file,
perform the following steps:
- Set the DB_SCHEMA_OWNER
property to your database shard owner.
- Run
the <INSTALL_DIR>\bin\setupfiles.cmd script
if you are using the Windows environment,
and <INSTALL_DIR>/bin/setupfiles.sh if you
are using either the Linux or
the UNIX environment.
- When upgrading
to Release 9.3 in sharded mode, if the multischema.enabled property
is not set in the <INSTALL_DIR>/properties/sandbox.cfg file,
perform the following steps:
- Set the multischema.enabled
property to True.
- Run
the <INSTALL_DIR>\bin\setupfiles.cmd script
if you are using the Windows environment,
and <INSTALL_DIR>/bin/setupfiles.sh if you
are using either the Linux or
the UNIX environment.
- When upgrading
to Release 9.3 and Change Project Management is enabled, if the OVERRIDE_LOAD_DEFAULTS_PK_GEN
property is not set in the <INSTALL_DIR>/properties/sandbox.cfg file,
perform the following steps:
- Set the OVERRIDE_LOAD_DEFAULTS_PK_GEN
property to True.
- Run the <INSTALL_DIR>\bin\setupfiles.cmd script
if you are using the Windows environment,
and <INSTALL_DIR>/bin/setupfiles.sh if you
are using either the Linux or
the UNIX environment.
- When upgrading
to Release 9.3, do not use property encryption. You must override
encrypted properties in your old runtime before upgrading to Release
9.3.
- If custom entities
are defined, TableTypes for custom entities must be specified in the
entity definitions.
- If you are using DB2 and want to drop nullability
constraints for the columns that are made nullable, use the <INSTALL_DIR>/Migration/9.2.0/buildmigration.properties file
to set the following properties to Y:
- db2.allow.required.reorg.stmts
This property allows the generation of the DROP NOT
NULL alters, which drops the null constraints. You must then perform
a manual reorg of the tables.
- db2.allow.reorg.stmts
If the null constraints are being dropped, set this
property to Y to generate REORG TABLE statements for tables that require
a reorg. You must manually execute these statements, and then remove
the statements from the alter scripts that get generated.
If you are dropping nullability
constraints, it is recommended that you set both these properties
to Y.
- Exclude configuration tables from synchronization.
Before upgrade, a complete export and import cycle is run
between the staging and production servers. Running an export/import
cycle ensures that the changes in the YFS_ENTITY_CHANGE table do not
disrupt a change project that is in progress.
A new section, ExcludeFromSync is
included in the changeDataManagementRules.xml file
that allows explicit exclusion of configuration tables from the export
process. Any section of the config-db.xml file
to be excluded from synchronization is specified in the ExcludeFromSync section.
Note: Warehouse
Management System segments are included by default and are not removed
from the config-db.xml file.
<Rule
Name="ExcludeFromSync" Value="">
<ExcludeList>
<Exclude
Name="YFS_SYNC_SUBSCRIPTION"/>
<Exclude
Name="YFS_CHANGE_PROJECT"/>
</ExcludeList>
</Rule>
- Prevent change tracking for records in certain tables.
A new section, DisableChangeTracking, is
included in the changeDataManagementRules.xml file
that prevents change tracking for records in certain tables. Set this
rule to "Y" to prevent change tracking for the tables specified under
this rule.
The tables included in DisableChangeTracking are
tables that should not be exported by the Data Sync Delta or Change
Project Management export processes. When included, entity tracking
is disabled for these tables, and associated records are not tracked
in the YFS_ENTITY_CHANGE table.
<Rule Name="DisableChangeTracking"
Value="Y">
<TableList>
<Table
Name="YFS_CUSTOMER"/>
<Table Name="YFS_CUSTOMER_GRADE"/>
<Table
Name="YFS_CUSTOMER_ASSIGNMENT"/>
<Table
Name="YFS_CONSUMER"/>
<Table Name="YFS_CUSTOMER_ADDNL_ADDRESS"/>
<Table
Name="YFS_CUSTOMER_ANALYTICS"/>
<Table
Name="YFS_CUSTOMER_CONTACT"/>
<Table
Name="YFS_CUSTOMER_CURRENCY"/>
<Table
Name="YFS_CUSTOMER_PAYMENT_METHOD"/>
<Table
Name="YFS_CUSTOMER_SCH_PREFERENCE"/>
<Table
Name="YFS_CUSTOMER_SLOT_PREFERENCE"/>
<Table
Name="YFS_PARTICIPANT_NOTE"/>
</TableList>
</Rule>
- To manually run DDLs for the following targets, use the <INSTALL_DIR>/Migration/9.2.0/buildmigration.properties file
to set the yfs.apply.sql.manually property to Y:
- alter-history-tables
- install-history-indexes
- run-history-drop
- alter-transaction-tables
- install-transaction-indexes
- run-transaction-drop
If you want to manually run the DDLs, ensure that you apply the
DDLs before running the corresponding targets. When you run the target,
the upgrade process does not apply the SQLs but creates the required .done files.
- If upgrading from Release 9.0 (or earlier), enclose the
entry, GraphUI element containing GraphUIKey="20050711140704272558",
within comments in <INSTALL_DIR>/COM/Migration/9.0/COM_Add-in/database/FactorySetup/ycd/changed/YFS_Graph_UIList.xml.