Portal V6.1.x on application server V6.1 stand-alone: Use copies of source database domains to minimize downtime
The recommended way to keep the earlier portal environment in production and reduce the amount of downtime during migration is to copy the earlier portal server JCR and Release domains. Then update the new portal server using 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.
- (Important): Copying the source portal JCR and Release domains is recommended but not required. However, if you choose to have the new portal server point directly to the source portal domains (instead of to copies of the domains), you will not be able to continue using 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 could sometimes break the compatibility with the source portal server. You should carefully check the requirements for the source portal server if you plan to use the earlier portal server until migration is finished.
- (DB2 only): When we are migrating a source portal to a target portal that uses a different driver type, you must reconnect all of the domains that are affected by changing the driver type.
For example, the source portal is using DB2 with Type 2 drivers for all domains and you plan to use a Type 4 driver type for all of the domains in the target portal. In this case, you must reconnect all of the database domains using the connect-database command.
- Use the Database tools to copy the source portal JCR domain and Release domain.
For IBM DB2 Universal Database™ for z/OS:
- To use the DB2 Administration Tool to copy the database domains, make sure 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.
- DB2 only: On the database copies, verify the Statement Heap size is set to at least 32k.
- List the database manager configuration parameters by running the following command db2 get db cfg for dbname.
- If the Statement Heap size is smaller than 32k, increase it by running the following commanddb2 "UPDATE DB CFG FOR dbname USING stmtheap 32768"
- On the target portal, update wkplc_dbdomain.properties located in...
WP_PROFILE/ConfigEngine/properties
- Update the jcr.* and release.* database properties to point to the JCR and Release domain copies that you 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 have modified or customized the default Derby database, you must copy the entire Derby directory to a new directory. Then update all database properties to point to the copy of the Derby database. Ensure that derby.DBLibrary is set to use the WAS v7 derby.jar as the JDBC driver class and includes the directory location of the file.
For example: derby.DBLibrary=WAS7_root\derby\lib\derby.jar
- When migrating with coexistence, that is both source and target environments are running on the same machine, change the WAS and WebSphere Portal port numbers. You must change ports before connecting to the domain copies. For details on changing ports, see the Related section for performing platform-specific, post-installation steps.
Parent: Portal V6.1.x on application server V6.1 stand-alone: Migrating databases
Related:
Standalone: Post-installation tasks
Standalone: Perform post-installation tasks on IBM i
Standalone: Perform post-installation tasks on Linux
Standalone: Perform post-installation tasks on Solaris
Standalone: Perform post-installation tasks on Windows