WASPreUpgrade command

The WASPreUpgrade command for WebSphere® Application Server Version 7.0 saves the configuration of a previously installed version of WebSphere Application Server into a migration-specific backup directory.

Location

The command file is located in and must be run from the Version 7.0 app_server_root/bin directory.

Syntax

[AIX] [HP-UX] [Linux] [Solaris]
WASPreUpgrade.sh backupDirectory 
                 currentWebSphereDirectory
                 [-traceString trace_spec [-traceFile file_name ]]
                 [-machineChange true | false]
                 [-oldProfile profile_name]
                 [-workspaceRoot profile1=user_workspace_folder_name_1;profile2=user_workspace_folder_name_2]
                 [-requireEmbeddedDBMigration true | false]
[Windows]
WASPreUpgrade.bat backupDirectory 
                  currentWebSphereDirectory
                  [-traceString trace_spec [-traceFile file_name ]]
                  [-machineChange true | false]
                  [-oldProfile profile_name]
                  [-workspaceRoot profile1=user_workspace_folder_name_1;profile2=user_workspace_folder_name_2]
                  [-requireEmbeddedDBMigration true | false]

Parameters

The command has the following parameters:

backupDirectory
This is a required parameter and must be the first parameter that you specify. The value backupDirectory specifies the name of the directory where the command script stores the saved configuration.

This is also the directory from which the WASPostUpgrade command reads the configuration.

If the directory does not exist, the WASPreUpgrade command script creates it.

currentWebSphereDirectory
This is a required parameter and must be the second parameter that you specify. This can be any edition of WebSphere Application Server Version 5.1.x or Version 6.x for which migration is supported.

The value currentWebSphereDirectory specifies the name of the installation root directory for the current WebSphere Application Server Version 5.1.x or Version 6.x installation.

-traceString
This is an optional parameter. The value trace_spec specifies the trace information that you want to collect.

To gather all trace information, specify "*=all=enabled" (with quotation marks).

If you do not specify the -traceString or -traceFile parameter, the command creates a trace file by default and places it in the backupDirectory/logs directory.

If you specify this parameter, you must also specify the -traceFile parameter.

-traceFile
This is an optional parameter. The value file_name specifies the name of the output file for trace information.

If you do not specify the -traceString or -traceFile parameter, the command creates a trace file by default and places it in the backupDirectory/logs directory.

If you specify the -traceString parameter but do not specify the -traceFile parameter, the script does not generate a trace file.

-machineChange
This is an optional parameter used for a migration involving cross operating-system and machine boundaries. If specified as true, this parameter provides support for changing physical hardware when migrating by backing up items that are stored outside the WebSphere Application Server installation or profile folder hierarchy. If specified as false, only files stored under the WebSphere Application Server installation folder or profile folders are copied to the backup directory during migration.

The default is false.

When this value is false, migration assumes that the new and old WebSphere Application Server installations are on the same physical machine with shared access to the file system. Therefore, any files located outside the WebSphere directories are communal and can be shared. Migration does not copy files outside the WebSphere Application Server tree into the backup directory when -machineChange is false. False is the only option when you use the Migration wizard. If you select -machineChange=false, you must run the WASPostUpgrade command on the same physical hardware.

If you intend to run the WASPostUpgrade command on a different machine or file system, you should run the WASPreUpgrade command with -machineChange=true. If you select -machineChange=true, migration creates an additional subdirectory (/migrated/) in the migration backup directory that contains any files referenced by the WebSphere Application Server configuration that reside outside the product or profile directories. When you run the WASPostUpgrade command, these files are returned to their original paths on the new machine.

Performance considerations:

If you migrate with Service Integration Bus (SIB) busses configured with file-system file-store repositories, you might require additional space in your migration heap and migration backup directory. Each bus has three file-store values—a log, a tempspace, and a repository. These three files vary in size, but they can be as much as 100-500 MB each. When migration is running, it backs up any file stores that are in the WebSphere Application Server tree during the pre-upgrade process. There needs to be sufficient space on the file system to permit this. If file stores exist at the destination location already during the post-upgrade process, migration backs up the file stores in memory to support rollback.

If you run the WASPreUpgrade command with -machineChange=true, resulting in a backup directory that contains shared file-store objects, you might find that the post-upgrade process suffers from out-of-memory exceptions because the default maximum heap is too small to contain the file-store backups in support of rollback. To resolve this issue, perform one of the following three tasks:
  • If the file stores at the system location are valid, delete the copies from the backup directory before running the WASPostUpgrade command.

    By deleting the entire /migrated/ subdirectory from the migration backup directory before running the WASPostUpgrade command, you essentially convert your pre-upgrade backup from -machineChange=true to -machineChange=false.

  • If the copies of the file stores in the backup directory are valid, delete the versions at the destination location.

    This changes the rollback support so that the destination files do not exist and will not occupy space in memory during the migration.

  • If you require rollback support and you need both the files in the backup directory as well as the files on the file system, increase your maximum heap size for the post-upgrade process to some value great enough to support all of the SIB files that conflict.
-oldProfile
This is an optional parameter used for migrating a specific instance or profile from a previous version of WebSphere Application Server.

In WebSphere Application Server Version 5.1.x, unique instance names were defined by the concatenation of -instanceName and -hostName. This concatenation forms the profile_name that you need to use with the -oldprofile parameter to migrate a specific WebSphere Application Server Version 5.1.x instance.

-workspaceRoot
This is an optional parameter. The value user_workspace_folder_name_x specifies the location of the administrative console customized "My tasks" settings for one or more profiles.
-requireEmbeddedDBMigration [Fix Pack 7 or later]
This is an optional parameter used for a migration that involves embedded databases.

The default is true.

If the value is specified as true, any exception that occurs when you migrate the embedded databases will cause the WASPreUpgrade command to fail. If the value is specified as false, any exception that occurs when you migrate the embedded databases will be logged in the trace file, and the WASPreUpgrade command will continue.

Stop all databases before running WASPreUpgrade. In order to ensure data integrity, WASPreUpgrade gets a connection to each database and locks it before taking a snapshot (copy) of the database. If the database is in use and -requireEmbeddedDBMigration is true ("true" is the default setting), then WASPreUpgrade will fail. Also, if authentication or encryption is enabled on the database, and -requireEmbeddedDBMigration is true, then WASPreUpgrade will fail.

If WASPreUpgrade fails because of a database exception, you have two options:

  • Stop the server or restart the server in a way that releases the database lock. Then, run the WASPreUpgrade command again with -requireEmbeddedDBMigration set to true.
  • Run the WASPreUpgrade command again with the -requireEmbeddedDBMigration parameter set to false, which causes the command to skip the database backup if exceptions occur.

Logging

The WASPreUpgrade tool displays status to the screen while it runs. The tool also saves a more extensive set of logging information in the WASPreUpgrade.time_stamp.log file written to the backupDirectory directory, where backupDirectory is the value specified for the backupDirectory parameter. You can view the WASPreUpgrade.time_stamp.log file with a text editor.

Migrated resources

WASPreUpgrade saves all of your resources, but it does not migrate entities in your classes directory.

Migration saves the following files in the backupDirectory directory.
  • classes
  • config
  • properties

The WASPreUpgrade command also saves all instances created in the Version 5.1.x environment.




Related tasks
Migrating product configurations
Migrating product configurations with migration tools
Related reference
WASPostUpgrade command
Reference topic    

Terms of Use | Feedback

Last updated: Oct 21, 2010 12:47:02 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-express-dist&topic=rmig_WASPreUpgrade
File name: rmig_WASPreUpgrade.html