Use copies of source database domains to minimize downtime

To keep the earlier portal environment in production and reduce the amount of downtime during migration copy the earlier portal server JCR and Release domains. Connect to the domain copies and then update the new portal server with the domain copies. The process of connecting to the domain copies must be done after you upgrade the ConfigEngine tool but before you upgrade the Portal profile.

Review the following list before you begin.

• Copy the source portal JCR and Release domains is a recommendation but not a requirement. If we point the new portal server to the source portal domains, we cannot use the JCR and Release domains with the earlier portal server.

• During migration, the Community and Customization domains are upgraded to their new definitions required by the new WebSphere Portal release. This migration might break the compatibility with the source portal server. Carefully check the requirements for the source portal server to use the earlier portal server until migration is finished.

• If we are migrating from WebSphere Portal v7 to WebSphere Portal v8.5, be aware there is a major schema change in the JCR database that may cause the JCR database to triple in size. Verify there is enough disk space for the new copies of the database when creating the new copies.

• DB2 only: When we migrate a source portal to a target portal that uses a different driver type, reconnect all of the affected domains. For example, the source portal is using DB2 with Type 2 drivers for all domains. You plan to use a Type 4 driver type for all of the domains in the target portal. In this case, we must reconnect all of the database domains using the connect-database command.

1. Use the Database tools to copy the source portal JCR domain and Release domain.

   If we are using IBM DB2 Universal Database™ for z/OS , review the following considerations:

   • To use the DB2 Administration Tool to copy the database domains, make sure that APAR PM16847 is applied.

   • Make sure that you verify the databases are not in a COPY PENDING state before you connect to the database copies described in the following step.

2. DB2 only: On the database copies, verify the Statement Heap size is set to at least 32k.

   1. List the database manager configuration parameters db2 get db cfg for dbname.

   2. If the Statement Heap size is smaller than 32k, increase it db2 "UPDATE DB CFG FOR dbname USING stmtheap 32768"
   Where dbname is the name of the WebSphere Portal database.

3. On the target portal, update the wkplc_dbdomain.properties file in WP_PROFILE/ConfigEngine/properties.

   1. Update the jcr.* and release.* database properties to point to the JCR and Release domain copies created in the previous step.

   If the source portal uses the default Apache Derby database, the migration tools automatically copy the database for you. However, if you modified or customized the default Derby database, copy the entire Derby directory to a new directory on the target server. Then, update all database properties of the target environment to point to the copy of the Derby database. Ensure that derby.DBLibrary is set to use the derby.jar of the target WebSphere Application Server as the JDBC driver class and includes the directory location of the file. Enter the parameter as derby.DBLibrary=Target_WAS_ROOT\derby\lib\derby.jar.

Parent Set up the target environment