Install > Installing maintenance > ... WebSphere Commerce > Installing WebSphere Commerce fix packs
Migrate the database from DB2 V9.5 Fix Pack 4 to DB2 V9.7 Fix Pack 1 or Fix Pack 2
After installing WebSphere Commerce Version 7 Fix Pack 1, you can upgrade the database from DB2 Version 9.5 Fix Pack 4 to DB2 9.7 Fix Pack 1 or Fix Pack 2.
Before you begin
- You cannot uninstall Websphere Commerce Version 7 Fix Pack 1 after you migrate the database to DB2 V9.7. Websphere Commerce Version 7 does not support DB2 V9.7 Fix Pack 1.
- You cannot migrate the database from DB2 V9.5 Fix Pack 4 to DB2 V9.7 Fix Pack 1 unless WebSphere Commerce Version 7 Fix Pack 1 is installed.
- Install WebSphere Commerce Version 7 Fix Pack 1.
Procedure
This procedure describes migration steps related to WebSphere Commerce and the WebSphere Commerce database. See the DB2 Version 9.7 Information Center for instructions on obtaining the DB2 software upgrade and related documentation.
- Upgrade the DB2 database from Version 9.5.4 to Version 9.7.1, following the steps in the DB2 documentation.
- Optional: Configure the remote server when the DB2 server is installed on a separate machine from the WebSphere Commerce product:
- Manually copy the DB2 bind file db2_adminotm.bnd from the DB2 server to the DB2 client before running the WebSphere Commerce instance creation. The details can be found in DB2 V9.7 APAR IC62106. On Windows: The "bnd" directory is typically located under C:\Program Files\IBM\SQLLIB\bnd in the default install location. On Unix: The "bnd" directory is located under the instance user's home directory of $INSTHOME/sqllib/bnd.
When copying files, ensure the server and client are at the same fix pack level.
- Configure user authority and privilege in the migrated database.
The security model for users was changed in DB2 V9.7. As a result, the migrated database users may not have the proper authority and privileges in the migrated database. This can be resolved by manually granting the authority and privilege to the proper users:
- Connect to the migrated database with the DB2 SYSADMIN user. Depending on the the platform, the DB2 SYSADMIN may refer to one of the following users:
- db2inst1
- db2admin
If necessary, write down the name of the DB2 SYSADMIN user.
- Check the user authority in the migrated database by running the following SQL command:
db2 "select cast(grantee as char(32)) as user, dbadmauth, securityadmauth from syscat.dbauth where granteetype='U'"
This statement checks whether the non-root user (wasuser), and the DB2 SYSADMIN, have DBA authority (DBADMIN) and security administrator authority (SECADM).
Your results may be similar to the following sample results:
USER DBADMAUTH SECURITYADMAUTH -------------------------------- --------- --------------- WASUSER Y N DB2INST1 N Y 2 record(s) selected.
These results indicate that user wasuser does not have the SECADM authority and the user db2inst1 does not have the DBADM authority.
- Grant the DBADM authority to the DB2 SYSADMIN user.
DB2 does not allow users to grant authority to themselves, so in our example, the user db2inst1 can not grant the DBADM authority to itself even though it has the SECADM authority. You need to grant the SECADM authority to another user (wasuser in this example) and then use wasuser to grant DBADM to db2inst1.
Run the following SQL statements:
db2 grant secadm on database to user WC_non_root_user db2 disconnect database_name db2 connect to database_name user WC_non_root_user using db_password db2 grant dbadm on database to user db_schema
- Configure the WebSphere Commerce environment settings.
WebSphere Commerce references the DB2 installation directory in its library path setting and JDBC driver classpath setting.
- Open the following file in a text editor:
- WC_INSTALL/bin/setenv.sh
- WC_INSTALL/bin/setenv.bat
- Change all occurrences of the string /IBM/db2/V9.5 to /IBM/db2/v9.7
For example, if you were making the change on an AIX setenv.sh file, you would find the following line:
AIX_DB2_HOME="/usr/ibm/db2/V9.5"and change that line to:
AIX_DB2_HOME="/usr/ibm/db2/V9.7"
- Update the DBDIR variable in the WC_INSTALL/bin/wcnonroot.sh.
For example, if you were making the change on an AIX wcnonroot.sh file, you would find the following line:
"DBDIR=/opt/ibm/db2/V9.5"and change that line to:
"DBDIR=/opt/ibm/db2/V9.7"
- Update environment variable DB2_JDBC_DRIVER_PATH in WebSphere Administration Console.
- Log on to the WebSphere Administration Console.
- Select Environment > WebSphere Variables > DB2_JDBC_DRIVER_PATH.
- Set the DB2_JDBC_DRIVER_PATH to the DB2v9.7 path.
For example, change the existing value from:
/opt/ibm/db2/V9.5/javato:
/opt/ibm/db2/V9.7/java
- Update the DB2 JDBC native library path.
- The DB2 JDBC library path is set in the non-root user's .profile file. The library path needs to be changed to point to the DB2 V9.7 path.
For example, change the existing value from:
LD_LIBRARY_PATH=/opt/ibm/db2/V9.5/lib32to:
LD_LIBRARY_PATH=/opt/ibm/db2/V9.7/lib32
- The DB2 JDBC library path is set in the Windows system environment variable PATH. The PATH needs to be changed to point to DB2 V9.7 path.
For example, change the existing value from:
PATH=DB2_version_9.5_installdir/BINto:
PATH=DB2_version_9.7_installdir/BIN
- Update the DB2 version information in the WebSphere Commerce product.xml file.
- Open the following file in a text editor:
- WC_INSTALL/xml/product.xml
- Find the following DB2 section in the file:
<database> <name>DB2</name> <edition> <name>UDB Enterprise Edition</name> </edition> <version>9</version> <release>5</release> <modification>0</modification> <fixpak></fixpak> <default>1</default> <install> <date></date> <time></time> <path>/opt/ibm/db2/V9.5</path> </install> <upgraded></upgraded> </database>
- Replace this section with the following XML block:
For a local database:
<database> <name>DB2</name> <edition> <name>UDB Enterprise Edition</name> </edition> <version>9</version> <release>7</release> <modification>0</modification> <fixpak></fixpak> <default>1</default> <install> <date></date> <time></time> <path>/opt/ibm/db2/V9.7</path> </install> <upgraded></upgraded> </database>For a remote database:
<database> <name>DB2</name> <edition> <name>Administration client</name> </edition> <version>9</version> <release>7</release> <modification>0</modification> <fixpak></fixpak> <default>1</default> <install> <date></date> <time></time> <path>/usr/IBM/db2/V9.7</path> </install> <upgraded></upgraded> </database>
- Restart the WebSphere Commerce Server.
- Enable the current committed (cur_commit) feature.
In order to improve database concurrency, WebSphere Commerce enables the DB2 V9.7 current committed feature by default in new instance creation. However, during a database upgrade from Version 9.5 to Version 9.7, the cur_commit configuration parameter is set to DISABLED to maintain consistent behavior with previous releases. To use currently committed on cursor stability scans, set the cur_commit configuration parameter to ON after the upgrade.
To enable the current committed feature:
- Connect to the migrated database with the DB2 SYSADMIN user. Depending on the the platform, the DB2 SYSADMIN may refer to one of the following users:
- db2inst1
- db2admin
- Run the following SQL command:
db2 update database configuration using cur_commit on
- Stop the WebSphere Commerce Server.
- Force all database connections by running the following command:
db2 force applications all
- Start the WebSphere Commerce Server.
Related tasks
Related reference
APARs fixed in WebSphere Commerce