Migrating IBM Cloudscape or Apache Derby databases

The migration tools migrate any IBM® Cloudscape® database instances to Apache Derby instances in the new configuration, and they copy any Apache Derby instances that are stored in the previous release's WebSphere® Application Server configuration tree to the new release's configuration tree. After you use the migration tools, you should verify the results of the database migration and manually migrate any Cloudscape database instances or copy any Derby database instances that are not automatically migrated or copied by the tools.

Before you begin

Supported configurations Supported configurations:

This topic is about configuration migration, such as migrating deployment managers and federated nodes in a network deployment environment. The Application Migration Toolkit for WebSphere Application Server provides support for migrating applications from previous versions of WebSphere Application Server to the latest product version. For information about migrating applications, read more about the Application Migration Toolkit.

sptcfg

Read Overview of migration, coexistence, and interoperability and Premigration considerations. For resources to help you plan and perform your migration, visit Knowledge Collection: Migration planning for WebSphere Application Server.

Tips:
  • Before you run the migration tools, ensure that any application servers hosting applications that are using a Cloudscape or a Derby database are closed.

    Otherwise, the database migration will fail.

  • Before you run the migration tools, ensure that the debug migration trace is active.
    By default, this trace function is enabled. To reactivate the debug migration trace if it is disabled, set one of the following trace options:
    • all traces*=all
    • com.ibm.ws.migration.WASUpgrade=all

About this task

WebSphere Application Server Version 8.0 requires Apache Derby Version 10.3 or later. Apache Derby Version 10.3 is a pure Java database server that combines the Derby runtime with the opportunity to use the full services of IBM Software Support. For comprehensive information about Apache Derby Version 10.3, read the Apache Derby website.

For help, read Troubleshooting migration.

Important: Derby-to-Derby migration performs a file-system copy of the data at a given point in time. This snapshot will not remain in sync with the database in the previous installation. If you roll back to the previous release, any updates to the database that you made after migration will not be reflected in the previous installation.

Procedure

  1. Migrate the configuration to Version 8.0.
  2. Verify the automatic migration of Cloudscape database instances or copying of Derby database instances.

    When you migrate from WebSphere Application Server Version 6.x to Version 8.0, the migration tools automatically upgrade Cloudscape or Derby database instances that are accessed through the embedded framework by some internal components such as the UDDI registry. The tools also attempt to upgrade Cloudscape or Derby instances that your applications access through the embedded framework. You must verify these migration results after running the migration tools.

    • To distinguish between a partially and a completely successful Cloudscape-to-Derby migration, verify the automatic-migration results by performing the following tasks:
      1. Check the general migration post-upgrade log for database error messages.

        These exceptions indicate database migration failures. The migration tool references all database exceptions with the prefix DSRA.

      2. Check the individual database migration logs.

        These logs have the same timestamp as that of the general migration post-upgrade log. The individual logs display more detail about errors that are listed in the general post-upgrade log as well as expose errors that are not documented by the general log.

        The path name of each database log is app_server_root/profiles/profileName/logs/myFulldbPathName_migrationLogtimestamp.log.

      3. Look at the debug log that corresponds with the database migration log.

        The WebSphere Application Server migration utility triggers a debug migration trace by default; this trace function generates the database debug logs.

        The full path name of each debug log is app_server_root/profiles/profileName/logs/myFulldbPathName_migrationDebugtimestamp.log.

      Performing these tasks gives you vital diagnostic data to troubleshoot the partially migrated databases as well as those that fail automatic migration completely. Ultimately, you must migrate databases that were not completely migrated automatically through a manual process. The log messages contain the exact old and new database path names that you must use to run the manual migration. Note these new path names precisely.

      Read the "Verifying the Cloudscape automatic migration" article in the information center for more information.

    • Verify that any Derby database instances that are stored in the previous release's WebSphere Application Server configuration tree were copied to the new release's configuration tree

      Check the general migration post-upgrade log for database error messages. These exceptions indicate database migration failures. The migration tool references all database exceptions with the prefix DSRA.

      .
  3. Manually migrate Cloudscape database instances or copy Derby database instances where necessary.
    • The Version 8.0 migration tools do not attempt to migrate database instances that transact with applications through the Cloudscape Network Server or the Apache Derby Network Server framework. This exclusion eliminates the risk of corrupting third-party applications that access the same database instances as those accessed by WebSphere Application Server.

      To minimize the risk of migration errors for databases that were only partially upgraded during the automatic migration process, delete the new database. Troubleshoot the original database according to the log diagnostic data, then perform manual migration of the original database.

      Read the "Upgrading Cloudscape manually" article in the information center for more information.

    • The Version 8.0 migration tools do not copy any Derby database instances outside the WebSphere Application Server configuration tree.

      If migration does not copy a Derby database instance automatically, copy the database instance manually.

  4. Manually migrate your UDDI registry if it uses a database on the Cloudscape Network Server or the Apache Derby Network Server framework.

    Read the "Migrating the UDDI registry" article in the information center for more information.

What to do next

Service integration bus-enabled web services use a Service Data Objects (SDO) repository for storing and serving WSDL definitions. If you migrate a configuration that uses a Cloudscape database as the SDO repository, the SDO application will still be configured to use Cloudscape in the new configuration. Migration converts the Cloudscape database to Derby, but you must still update any SDO application's backend ID to use the new database. After you migrate all of the nodes on a server with an SDO repository application that uses Cloudscape, perform the following actions to reset the database type used by the SDO application on the new configuration to Derby:
  1. Read about the basic usage for the installSdoRepository.jacl script inside the script file.
  2. Run the installSdoRepository.jacl script by changing to the app_server_root/bin/ directory and running the following command:
    wsadmin.extension -f app_server_root/bin/installSdoRepository.jacl -editBackendId DERBY_V10

Read the "Installing and configuring the SDO repository" article in the information center for more information on upgrading the SDO repository application to Version 8.0 .

Task topic Task topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Feb 6, 2014 11:54:51 PM CST
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=matt&product=was-nd-zos&topic=tmig_derby
File name: tmig_derby.html