Updates to DB2 Recovery Expert Version 3.1 for Linux, UNIX, and Windows User's Guide

Content

The most recent update is listed first.


________________________________________
Update 1
Date of change: February 6, 2012
Topic: DB2 Recovery Expert overview

Change description: New and revised information

- HP-UX 11iv2 (11.23.0505) and 11iv3 (11.31) are now supported
- Backups created by DB2 Merge Backup for Linux UNIX and Windows now supported
- Repositories and security

Backup images created by the DB2 Merge Backup for Linux UNIX and Windows are now supported.

Merged backups can be specified as the source backup for creating the SLR or used for supplying data during Log Analysis or Recovery operations.

Repositories and security

DB2® Recovery Expert stores data in one or more datastore repository databases, authentication repository databases, and Derby repository databases.

To use DB2 Recovery Expert with a specific DB2 instance, the product administrator must create a datastore repository database and define a datastore connection so that DB2 Recovery Expert knows how to access it. The datastore repository database contains the Schema Level Repository (SLR) information for each database in the instance that the user works with. The SLR information is used by Log Analysis and Recovery. The datastore is also used to store Log Analysis reports, including generated SQL.

An authentication database repository is used to provide application authentication if the security configuration is changed to DB2 authentication. Only one authentication database repository is needed, even if multiple instances exist.

The Derby repository database is stored on the DB2 Recovery Expert server, which may be a different machine than the DB2 server. DB2 Recovery Expert ships with a single Derby database that will record the application security model that is being used. The Derby database also stores the DB2 Recovery Expert database server component locations.

DB2 Recovery Expert provides application security, datastore security, and user database security.

Application security provides Administrator and User levels, and includes the following modes: No application mode, Container based mode, and DB2 authentication mode. The initial application security mode is Container based, with the installation user name and password. DB2 Recovery Expert does not provide a method to add users to the Container based security. Therefore, users who want more than one login should change to DB2 authentication mode.

The DB2 Recovery Expert application login protects the database server components and datastore configurations. Note: The DB2 Recovery Expert server configuration file dswebserver.properties should be protected. It is possible to disable the DB2 Recovery Expert server security by editing the configuration file.

Datastores can be configured with a saved password, which enables all users to access the datastore. Alternatively, datastores can be configured to require that users enter a password that has privileges on the datastore as an additional layer of security. Use of Change Authorities on the Datastore step of the Admin perspective allows the administrator to configure which users have access to the datastore, and requires a DB2 username and password on the datastore.

Access to the user database can be protected by requiring a password for the application, a password for the datastore, and a password for the database.

________________________________________


Update 2
Date of change: February 6, 2012
Topic: Preparing to install and configure DB2 Recovery Expert
Change description: New and revised information in the following sections:

- Hardware prerequisites
- Software prerequisites
- Installation requirements and recommendations
- Operational prerequisites
- Configuring Linux and UNIX systems to run the DB2 Recovery Expert Server

Hardware prerequisites

- DB2 Recovery Expert Database Server Components
- Operating system platform: The DB2 Recovery Expert Database Server Components must be installed on any supported Linux, UNIX, or Windows operating system platform where the user wants to use DB2 Recovery Expert to access DB2 databases.

- Storage requirements:

- A minimum of 1 GB of disk space should be available on the filesystem where the DB2 Recovery Expert Database Server components will be installed.

- Additional space will be required for storing intermediate working data while the product is running, and for storing result data into the product datastore database. For more information about disk space requirements, see Operational prerequisites.

- Memory requirements:

- A minimum of 1 GB of memory should be available for running DB2 Recovery Expert processes on the DB2 database server systems.
DB2 Recovery Expert Database Command Line Processor Client

- Operating system platform: The DB2 Recovery Expert Command Line Processor Client can be installed on any supported Linux, UNIX, or Windows operating system platform where the user wants to use the command line feature.

- Storage requirements:
- A minimum of 500 MB of disk space should be available on the filesystem where the DB2 Recovery Expert Command Line Processor Client components will be installed.

- At least 500 MB of temporary space should be available during the installation on the system temporary filesystem (the /tmp filesystem on Linux/UNIX systems, or the location specified by the TEMP variable on Windows systems).

- Memory requirements: A minimum of 1 GB of available memory is recommended.



Software prerequisites

The software prerequisites for running the DB2 Recovery Expert Server and the DB2 Recovery Expert Database Server Components vary depending on the type of operating system that you are using and other environmental considerations.

UNIX Operating Systems

•AIX® 5.3 64-bit

•AIX 6.1 64-bit

•AIX 7.1 64-bit

•Solaris 10 (SPARC) 64-bit

•HP-UX 11iv2 (11.23.0505) with

- May 2005 Base Quality (QPKBASE) bundle

- May 2005 Applications Quality (QPKAPPS) bundle

- PHCO_38637

- libc cumulative patch

•HP-UX 11iv3 (11.31) with

- PHCO_38658

- libc cumulative patch

Note: DB2 Recovery Expert supports only the Itanium-based HP Integrity Series Systems hardware for HP-UX.

Linux on xSeries®
•Red Hat Enterprise Linux 6.0 AS/ES x86-32
•Red Hat Enterprise Linux 6.0 AS/ES x86-64
•Red Hat Enterprise Linux 5.0 AS/ES x86-32
•Red Hat Enterprise Linux 5.0 AS/ES x86-32
•SUSE Linux Enterprise Server 10 x86-32
•SUSE Linux Enterprise Server 10 x86-64
•SUSE Linux Enterprise Server 11 x86-32
•SUSE Linux Enterprise Server 11 x86-64


Supported DB2 versions
•DB2 Workgroup Server Edition 9.5, Fix Pack 2 and later
•DB2 Workgroup Server Edition 9.7, Fix Pack 3a and later

Supported storage management software
•DB2 Recovery Expert supports Symantec NetBackup versions 6.5 and 7.0


Installation requirements and recommendations


Datastore repository database STMTHEAP requirement

The datastore repository database must have a minimum statement heap size (STMTHEAP parameter) of 4096 4-KB pages. If the datastore repository database is created in a database with a smaller statement heap size, creation of the Schema Level Repository (SLR) will fail. The default STMTHEAP value for 32-bit instances is 2048, and must be increased.


Recommendations for installing on an IBM Smart Analytics System

If you are installing DB2 Recovery Expert in an IBM Smart Analytics System environment, review the following recommendations:

- Install the DB2 Recovery Expert Server on the management node to provide access to the internal application network. This step allows the server to support installation of the database server components directly in the browser client. If the DB2 Recovery Expert Server is installed outside of the IBM Smart Analytics System, the database server components will require manual installation.

- The DB2 Recovery Expert datastore must exist within the DB2 instance in which the managed databases exist. To minimize administration, create the datastore within the core warehouse database. Alternatively, you can create a separate database in the IBM Smart Analytics System DB2 instance.

- DB2 Recovery Expert supports shared and non-shared installations of the database server components. For performance reasons, install the components locally on each database partition. In a high availability (HA) configuration, install the DB2 Recovery Expert database server components locally on the administration, data, and standby nodes.

- In an HA configuration, the DB2 Recovery Expert working storage must be configured so that it is accessible on the standby administration node if a fail-over occurs. The DB2 Recovery Expert working storage contains cached information required for processing. When a fail-over occurs, this information must be accessible for DB2 Recovery Expert to continue processing. The DB2 Recovery Expert working storage location is configured by setting the DATA_DIR property on the Admin perspective.


Operational prerequisites

Database backups must be recorded in the Recovery History File

DB2 Recovery Expert locates backup images using information recorded by DB2 in the Recovery History File (RHF). If a backup does not currently exist in the original location that was recorded in the RHF, the user can either update the history file entry to specify the new location, or they can specify the current location of the files using options in the browser client application or in the command line client.

Use host name when installing Recovery Expert database server components in IPv6 environments

When using the DB2 Recovery Expert browser client application to install the product database server components onto DB2 server systems in an IPv6 environment, you must identify the target system using a host name. The installation will not work if you specify an IPv6 address.


Selecting schema or mixed object types only recovers DDL definitions

When using the DB2 Recovery Expert browser client application, you can select different types of database objects to be recovered using the Objects step on the Recovery perspective. By choosing to recover tables or table spaces, you can recover object definitions and the associated table data. Selecting any of the other types of object only allows recovery of the object definitions.

It is currently only supported to choose objects of the same type. For example, choose one or more tables, or one or more SQL procedures, but don't choose both tables and procedures. The application UI does not prevent choosing more than one type of object.

One exception is that it is supported to select a combination of tables and table spaces, but in this case, only the DDL definitions will be recovered. If you want to recover table or table space data, choose a set of the same type of objects (tables, or table spaces, but not both).

Also, selecting the schema object type allows you to recover the object definitions (DDL) for the various objects that are defined with the selected schema names. You can also use a pattern expression to match multiple schema names. When recovering using the schema object, only the DDL definitions are recovered for the selected schema contents. Table data and index data is not recovered. In this case, the generated recovery plan is named "Recreate object definitions from SLR (DDL only; no data will be restored)". The recovery will drop existing objects, including the current table data, before recreating the objects associated with the selected schema as they existed at the specified recovery Point In Time (PIT). Tables and associated indexes will be empty after the recovery.

To recover a set of tables (including both definitions and table data) that are defined within the same schema, choose the table object type on the Objects step. You can select one or more table names from the expanded list of tables, or you can use the pattern object to match multiple tables. To match a set of tables that exist within the same schema, specify a pattern of the form "schema.expression", where the expression uses the DB2 pattern matching characters "%" or "?". For example, to match all tables in the schema ORANGE, enter the pattern: ORANGE.% You can add more than one pattern expression to the "Selected objects" list, to simplify the pattern expressions or to allow recovering tables from different schemas during the same recovery.


SLR pruning is recommended when pruning the DB2 history file and using the AUTO_DEL_REC_OBJ configuration setting

When the DB2 recovery history file is pruned and the AUTO_DEL_REC_OBJ configuration setting is in effect, DB2 recovery log files, backup images and load copy files can be automatically deleted. This may cause problems for DB2 Recovery Expert if the Schema Level Repository (SLR) references resources that no longer exist. In this case, the SLR should also be pruned to stay synchronized with the DB2 recovery history.



DB2_LOGGING_DETAIL registry variable value

Set the variable to APPLINFO to capture AUTHID, application name and ID information. Setting this registry variable causes DB2 to write an additional informational log record for each transaction. Authorization ID information is also recorded in the logs when using the DATA CAPTURE CHANGES option, but setting the DB2_LOGGING_DETAIL variable (db2set DB2_LOGGING_DETAIL=APPLINFO) is the preferred method because it covers all tables in the database and it has minimal logging overhead.

In a partitioned database environment, the DB2_LOGGING_DETAIL registry variable must be set for all database partitions. For this registry variable setting to take effect, restart the instance.


DB2 Version 9.7 consideration

The DB2 Recovery Expert table space ARYSPACE, located in the datastore database, might be taken offline unexpectedly by DB2 when using DB2 Recovery Expert with DB2 9.7 Versions earlier than Fix Pack 3a. DB2 will log message ECF_FAILED for buffer pool services in the db2diag.log when this issue is encountered. To avoid this problem, apply DB2 Version 9.7 Fix Pack 3a or later. If you encounter this problem, connect to the datastore database and issue command ALTER TABLESPACE ARYSPACE SWTICH ONLINE. Then, apply DB2 Version 9.7 Fix Pack 3a or later.


Configuring Linux and UNIX systems to run the DB2 Recovery Expert Server

It is necessary to set the data segment size and the number of open files from the operating system defaults for AIX®, HP-UX, Linux, and Solaris.

About this task

The default and recommended minimum values of these files might need to be higher, depending on usage. Note: The recommended limit for data is unlimited.

Procedure 1.For all UNIX systems, the data segment size limit must be not less than 1024 MB. This is the data or data seg size parameter in ulimit -a output. To set this limit to 1024 MB for the KornShell shell (ksh), issue the ulimit -d 1048576 command.

2.Set the number of open files from the operating system defaults for AIX, HP-UX, Linux, and Solaris:

AIX file descriptors (ulimit) Description: Specifies the various restrictions on resource usage on the user account. The ulimit -a command displays all of the ulimit limits. The ulimit -n command specifies only the number of open files that are permitted. The default number of open files setting (2000) is typically sufficient for most applications. If the value set for this parameter is too low, errors might occur when opening files or establishing connections. Because this value limits the number of file descriptors that a server process might open, a value that is too low prevents optimum performance.

How to view or set:

Perform the following steps to change the open file
limit to 10,000 files:

a.Open the command window.

b.Edit the /etc/security/limits file by adding the following lines to the user account that the DB2® Recovery Expert Server process runs on:

nofiles = 10000 nofiles_hard = 100002.

c.Save the changes.

d.Restart your AIX system.

e.To verify the result, type the ulimit -a command on the command line. For example, type # ulimit -a.

Default value: For the AIX operating system, the default setting is 2000.

Recommended minimum value: At least 10000


HP-UX file descriptors (ulimit)

Description:

Specifies the number of open files that are supported. The default setting is typically sufficient for most applications. If the value set for this parameter is too low, a file open error, memory allocation failure, or connection establishment error might be displayed.

How to view or set:

Check the reference pages on the ulimit command for the syntax of different shells. To set the ulimit command to 8000 for the KornShell shell (ksh), issue the ulimit -n 8000 command. Use the ulimit -a command to display the current values for all limitations on system resources.

Default value: For HP-UX 11iv2 and HP-UX 11iv3 the default is 2048.

Recommended minimum value: At least 8000

Linux file descriptors (ulimit)

Description:

Specifies the number of open files that are supported. The default setting is typically sufficient for most applications. If the value set for this parameter is too low, a file open error, memory allocation failure, or connection establishment error might be displayed.

How to view or set:

Check the UNIX reference pages on the ulimit command for the syntax of different shells. To set the ulimit command to 8000 for the KornShell shell (ksh), issue the ulimit -n 8000 command. Use the ulimit -a command to display the current values for all limitations on system resources.

Default value: For SUSE Linux Enterprise Server 9 (SLES 9), the default is 1024.

Recommended minimum value: At least 8000


Solaris

Description:

Specifies the maximum number of open files supported. If the value of this parameter is too low, a Too many files open error is displayed in the DB2 Recovery Expert Server stderr.log file.

How to view or set:

Check the UNIX reference pages on the file descriptor limits for parameters and commands used. For the KornShell (ksh), the ulimit -n command can be used to set the desired file descriptor value and the ulimit -a command to display all current ulimit settings in place.
Default value: 1024

Recommended minimum value: 10000


________________________________________


Update 3
Date of change: February 6, 2012
Topic: Installing DB2 Recovery Expert
Change description:

New and revised information in the following sections:

- Installing or upgrading DB2 Recovery Expert by using the installation wizard or the console mode

- Installing or upgrading DB2 Recovery Expert using the non-interactive (silent) mode

- Installing or upgrading the Command Line Processor (CLP) client by using the installation wizard or the console mode

- Installing a permanent license with IBM DB2 Recovery Expert for LUW Activation Kit

- Configuring remote access to database server machines


Installing or upgrading DB2 Recovery Expert by using the installation wizard or the console mode

DB2® Recovery Expert provides an installation wizard to install or upgrade the product. If you want to install or upgrade the product on a computer that does not have a graphical user interface, you can perform the installation by using the console mode.

Before you begin

•Ensure that your environment meets the prerequisites described in Preparing to install and configure DB2 Recovery Expert.

•Review considerations and restrictions for installing, configuring, and using DB2 Recovery Expert in Considerations and restrictions.

About this task

During the installation, you specify the product installation location, authentication details, and the HTTP and HTTPS port numbers to be used by the server. You can also choose to start the server, and display the product readme file upon completion. If DB2 Recovery Expert is currently installed, an upgrade installation will be performed.

Note: Do not make changes to your computer environment while the installation program is running. Examples of changes include changes to users or user groups or to DB2. If you make any of these changes while the installation program is running, you must end the installation program and restart it so that the installation program will recognize the changes.


Procedure

Install or upgrade DB2 Recovery Expert by using the installation wizard or the console mode:

1.To start the installation program, from the directory of the installation image for DB2 Recovery Expert, run one of the following commands, depending on your operating system environment:

Installation program start commands

Installation wizard, Linux/UNIX

Command: ./DB2RecoveryExpertLUW.bin

Installation wizard, Windows

Command: DB2RecoveryExpertLUW.exe

Console mode, Linux/UNIX

Command: ./DB2RecoveryExpertLUW.bin -i console

Console mode, Windows

Command: DB2RecoveryExpertLUW.exe -i console

2.Complete the pages of the wizard or the questions of the console. The wizard or console indicates whether the installation was successful.

3.If the installation failed, look for details in the installation log file, correct the problem, and then try again. The installation log file, DB2_Recovery_Expert_LUW_InstallLog.txt, is located in the product installation directory.



Installing or upgrading DB2 Recovery Expert using the non-interactive (silent) mode

DB2® Recovery Expert can be installed or upgraded by using the
non-interactive (silent) mode to support remote or unattended
installations.

Before you begin

•Ensure that your environment meets the prerequisites described in Preparing to install and configure DB2 Recovery Expert.

•Review considerations and restrictions for installing, configuring, and using DB2 Recovery Expert in Considerations and restrictions.

About this task

Note: Do not make changes to your computer environment while the installation program is running. Examples of changes include changes to users or user groups or to DB2. If you make any of these changes while the installation program is running, you must end the installation program and restart it so that the installation program will recognize the changes.

Procedure

1.Locate an installation properties response file to copy or edit, and then use as input for a non-interactive installation. A sample installation properties file named re.properties is provided in the directory of the installation image. Alternatively, you can use an installation properties file from a previously installed copy of the product.

2.In the installation properties file, set the installation directory location by entering one of the commands below. When you enter the commands, the directory will be created if it does not exist. If the directory already exists, it must be empty when the installation is performed. On Linux/UNIX systems, use a forward slash character as the path separator. On Windows systems, use two backslash characters as the path separator.

Commands to set the installation directory location:

Linux/UNIX command: USER_INSTALL_DIR=/opt/IBM/DB2RELUW

Windows command: USER_INSTALL_DIR=C:\\IBM\\DB2RELUW


3.Choose the components to be installed. To include the component, set the value to 1. To exclude the component, set the value to 0. If you do not intend to use DB2 Recovery Expert with certain platforms, you can skip installing those components to save space. For example:

BACKEND_AIX=1

BACKEND_LINUX=1

BACKEND_HPUX=1

BACKEND_SOLARIS=1

BACKEND_WINDOWS=1

4.Specify the user authentication information for the DB2 Recovery Expert Server.

5.Enter the user name in clear text, and enter the password in encrypted form.

a.To generate the encrypted password, run the installation program with one of the following arguments:

Commands to generate encrypted passwords during the installation procedure

Linux/UNIX command: ./DB2RecoveryExpertLUW.bin -i console -Dencryptedpassword=true

Windows command: DB2RecoveryExpertLUW.exe -i console -Dencryptedpassword=true

b.Enter the password in the console dialog and press Enter.

c.Copy the encrypted password string that is displayed into the response file.

For example: SERVER_USERNAME=admin SERVER_PASSWORD=8BA4C0A899B49FAB

d.Press Enter to terminate the program.

6.Specify the port numbers to be used by the DB2 Recovery Expert Server. Ensure that the selected port numbers do not conflict with other ports in use by the system. For example: SERVER_HTTP_PORT=13080 SERVER_HTTPS_PORT=13081

7.Choose whether to start the server automatically after installation. To start the server automatically, set the value to 1. To leave the server inactive, set the value to 0. For example: START_SERVER=1 You can also choose to start the server manually after the installation is complete.

8.After the installation properties response file is ready, run the installation program and specify the path name to the response file by using one of the following commands:

Commands to specify the path to the installation properties response file

Linux/UNIX command: ./DB2RecoveryExpertLUW.bin -f <response-file-path>

Windows command: DB2RecoveryExpertLUW.exe -f <response-file-path>

For example:./DB2RecoveryExpertLUW.bin -f re.properties

9.Check the results of the installation.

- If the installation is successful, the installation log file is copied to the installation directory and is named DB2_Recovery_Expert_LUW_InstallLog.txt.

- If the installation fails, the installation log file is written to the system temporary directory and is named DB2_Recovery_Expert_LUW_InstallLog_<user>.txt, where <user> is the user name that performed the installation. The system temporary directory is set to /tmp for Linux and UNIX systems, or to the value of the %TEMP% variable on Windows systems.

10.If the installation failed, correct the problem, and then try again.



Installing or upgrading the Command Line Processor (CLP) client by using the installation wizard or the console mode

DB2® Recovery Expert provides an installation wizard to install or upgrade the product. If you want to install or upgrade the CLP on a computer that does not have a graphical user interface, you can perform the task by using the console mode.

Before you begin

•Ensure that your environment meets the prerequisites described in Preparing to install and configure DB2 Recovery Expert.

•Review considerations and restrictions for installing, configuring, and using DB2 Recovery Expert in Considerations and restrictions.

Procedure

Install or upgrade the Command Line Processor (CLP) client by using the installation wizard or the console mode.

1.To start the CLP installation program, run one of the following commands, depending on your operating system environment:

Commands to start the CLP installation program

Installation wizard, AIX command: ./install.clp.aix.bin

Installation wizard, HP-UX command: ./install.clp.hpux.bin

Installation wizard, Linux/UNIX command: ./install.clp.linux.bin

Installation wizard, Solaris command: ./install.clp.solaris.bin

Installation wizard, Windows command: install.clp.windows.exe

Console mode, AIX command: ./install.clp.aix.bin -i console

Console mode, HP-UX command: ./install.clp.hpux.bin -i console

Console mode, Linux/UNIX command: ./install.clp.linux.bin -i console

Console mode, Solaris command: ./install.clp.solaris.bin -i console

Console mode, Windows command: install.clp.windows.exe -i console


2.Complete the pages of the wizard or the questions of the console. The wizard or console indicates whether the installation is successful.


Installing a permanent license with IBM DB2 Recovery Expert for LUW

Activation Kit Commands for installing a permanent license on HP-UX:

Installation wizard, HP-UX command: ./install.license.hpux.bin

Console mode, HP-UX command: ./install.license.hpux.bin -i console



Configuring remote access to database server machines

The location of the sftp-server is operating system-dependent. It is typically found in the following location for HP-UX: /opt/ssh/libexec/sftp-server

________________________________________

Update 4
Date of change: February 6, 2012
Topic: Configuring DB2 Recovery Expert information
Change description: New and revised information in the following sections:

- Installing or upgrading database server components from a browser client
- Installing or upgrading database server components from the command line
- Uninstalling database server components - Verifying the installation of the database server components
- Editing the configuration of the database server components
- Creating or upgrading a datastore repository database from the browser client
- Setting datastore options (new option)

Installing or upgrading database server components from a browser client

The Install step enables the administrator to install, upgrade, uninstall, verify, and configure the database server software components on the database server systems where you want to run DB2® Recovery Expert.

Before you begin

- Ensure that your environment meets the prerequisites described in Preparing to install and configure DB2 Recovery Expert.

- Review considerations and restrictions for installing, configuring, and using DB2 Recovery Expert in Considerations and restrictions.

- Review configuration requirements in Configuring DB2 Recovery Expert.

Procedure

To install or upgrade database server components from a browser client:

1.In your browser window, type the URL of the DB2 Recovery Expert application and log in with an administrator user name and password.

2.From the Task Manager, navigate to the Admin perspective.

3.On the Administration window, click Install.

4.Choose the task to perform:

- To install a new set of database server components, click Install new. Proceed with the Database selection step.

- To upgrade existing components, click an installed version in the list, and then click Upgrade. Proceed with the Version to upgrade step.

5.For a new installation, on the Database selection step, enter the following information:

- Hostname: The host name of the database server system where the components will be installed.

- Database name: The name of any database that exists in the DB2 instance for which the components are being installed. The user must be able to connect to the database and have the SELECT privilege on the administrative views. This allows DB2 Recovery Expert to determine whether additional hosts exist that are part of a DPF configuration. No data in the database will be modified. It is possible to create a database that is only for this purpose that contains no data.

- Database port: DB2 Connection port number for the DB2 instance.

- Username: The username for the connection user. You can connect to the database in the specified DB2 instance by entering this username.

- Password: The password for the connection user. You can connect to the database in the specified DB2 instance by entering this password.

Click Next. Continue with the Version to install step.

6.On the Version to install or Version to upgrade step:

- Version to install: When installing a new version, you can use an existing installation to install for a new instance, or to reinstall on the same instance.

a.In the Existing installations section, choose the installation from the list, and then click Install.

b.Proceed to the Status step.

- Version to install: When installing a new version, you can specify a new installation.

a.In the New installations section, enter the path name or browse to a directory that contains one or more server components. The path name must be visible to the DB2 Recovery Expert server where the browser client application is deployed. It can either be local to that system, or a shared location that is visible to many systems.

b.Click Retrieve list.

Listed are server components found at that location that can be installed on the specified database server system. The list might show more than one version if the directory contains multiple files.

c.Choose a version from the list, and then click Next.

Continue on the Credentials step.

- Version to upgrade:

a. Enter the path name, or browse to a directory that contains the server components to be upgraded.

b. Click Retrieve list. Listed are the server components found at the specified location on the specified database server system that can be upgraded to a newer version.

c. Choose a version from the list and click Next. Continue on the Credentials step.

7. On the Credentials step, review the credentials.

a.If necessary, specify authentication information:

i.Click Set credentials.

ii.On the Authentication window, specify user credentials:

- Host: The host name or IP address to which the connection is made. For DPF systems, the other systems involved are located using the db2nodes.cfg file. Authentication method This is the operating system user authentication method. The choices are:

- Password authentication (the default)

- Secure shell (SSH)

Note: The Secure shell (SSH) option is only available on Linux and UNIX operating systems. This option is not available on Windows operating systems. Windows operating systems support local connections or network connections using the SMB/CIFS protocol over TCP/IP.

- Username: The authorized username to log in to the target host. This username is requested regardless of the authentication method.

- Password: The password for the authorized user to log in to the target host. This password is requested only if Password authentication is selected.

- Additional security privileges for UNIX/Linux systems On UNIX and Linux systems, DB2 Recovery Expert requires additional privileges to install the database server components, and to create or modify databases.

If you did not log in initially as root or as an instance user with authority to run the sudo or su command, then you must complete a two-part authentication process to switch the current user to an authorized user.

Select this check box, and from the Command type dropdown list, select sudo or su.

- sudo user: This is the sudo command that is used to provide super user privileges to users.

- Sudo user's password: The sudo user's password.

Note: If the /etc/sudoers file contains the line Defaults requiretty then you must run the sudo command from a terminal. Setting this requirement prevents DB2 Recovery Expert from working with sudo for database server component installations, datastore creation, and other related operations.

To enable these functions, remove the Defaults requiretty line from the /etc/sudoers file. For more information, see the sudo manual.

- su user: This is the standard su command. This is root for most UNIX systems. su user's password The root user's password.

iii. To save the credentials, click Apply.

b. Optional. To establish a connection, click Test connections to all specified hosts.

c. Click Next. Continue on the Install options or Upgrade options step.


8. On the Install options or Upgrade options step, review directory information: Install directory The path name where the components are installed on the database server. This path name must be either a local file system or a shared file system that is visible and writable from the system host name that was specified in the earlier step. Only one path name can be specified. If a DPF installation is performed using non-shared directories, the components are copied to the same path name on each system.

Temporary directory Temporary files that are used during the installation are created in the default system temporary directory. If necessary, enter a temporary directory path.

Click Install to perform the installation or upgrade. 9.The Status step displays the database server components that are copied from the DB2 Recovery Expert server. Note that it can take some time to unpack the necessary files and copy them to the database server. Errors counts indicate the number of partitions or nodes that encountered an error during the installation. For a single partition installation, the count is either 0 or 1. For a partitioned installation, the count could be 0 up to the total number of partitions, if all failed. The count does not represent the number of individual error messages that were reported during the installation. That is, a given partition installation might encounter three errors, but the error count on the Status step would be 1, because the overall installation for that partition encountered a problem.



Installing or upgrading database server components from the command line

Install or upgrade database server components on Linux, UNIX, and Windows
systems.

About this task

If you install the database server components manually, no entry is created in the browser client for the host. Without the host entry, you cannot use the browser client to edit the DB2® Recovery Expert configuration for the host. To edit the configuration, you must manually edit the configuration file (conf/recex.properties) using a native operating system editor.

Procedure

Install or upgrade database server components on Linux, UNIX, and Windows systems: 1.Open the DB2 Recovery Expert installation package that you have received and copy the appropriate zip files for the desired operating system platform (AIX®, HP-UX, Linux, Sun, or Windows) to the machine where the product will be installed.

2. Create a temporary directory on a filesystem on the host where you want to install the components.

3. Unzip the server components into the temporary directory that you have created.

4. On UNIX or Linux operating systems, set execute access on the scripts in the install subdirectory by entering the following command: chmod a+x install/*.sh

5. If the components are being installed to work with a DPF instance, the user must either install them onto a shared filesystem that is visible to all of the cooperating systems, or they must install them separately onto each host to a local filesystem using the same path for all of the hosts. For example, install to /opt/re3100 on each host computer.

6. If you are performing a separate installation, you must run the script once for each host where you want to copy the components.

7. If you are performing a shared installation, you can just perform the installation once onto a shared filesystem that is accessible to all.

8. Run the installation script to create a target installation directory and copy the files into it: ./installPkg.sh -c <targetdir> For example:./installPkg.sh -c /opt/re3100 Note: On Windows, the script is named installPkg.bat.

9. Create a datastore repository database to be used with a specific DB2 instance. If you are installing more than one instance, create a datastore for each instance. Use the script installDS.sh (or installDS.bat on Windows) to create the datastore repository database. For more information, refer to Creating the datastore repository database manually.

10. On the Admin perspective of the DB2 Recovery Expert browser client, you can define a datastore connection that refers to the datastore that you created and the installation path where the database server components were installed. For more information about the Admin perspective, see Configuring DB2 Recovery Expert.



Uninstalling database server components

This section describes how to uninstall database server components that were previously installed.

About this task

On the Admin perspective on the Install step, you can review all of the installations that have been previously installed on the Installed components panel. The install entry contains the following options:Install host The hostname that was specified for the installation. Path The local database server path for the database server components. Hostname The name of the host machine where the database server components were installed. Installation date The date when the installation was performed. Type of install DPF or single system installs. Installed version The version that was installed. OS type The operating system of the machine where the database server components were installed.

Note: For DPF installs, you can expand the component to see on which DB2® partitions the installation was performed.

Procedure

Uninstall the database server components: 1.To uninstall an entry, select the item in the Installed components table and click Uninstall. The Uninstallation window opens on the Credentials step.

2. Select the Host from the Hosts table and click Set credentials. The Authentication view opens.

3. In the Authentication view, specify information in the following fields: - Host: The host name or IP address to which the connection is made. For DPF systems, the other systems involved are located using the db2nodes.cfg file. Authentication method This is the operating system user authentication method. The choices are:•Password authentication (the default)

- Secure shell (SSH) Note: The Secure shell (SSH) option is only available on Linux and UNIX operating systems. This option is not available on Windows operating systems. Windows operating systems support local connections or network connections using the SMB/CIFS protocol over TCP/IP.

- Username: The authorized username to log in to the target host. This username is requested regardless of the authentication method.

- Password: The password for the authorized user to log in to the target host. This password is requested only if Password authentication is selected.

- Private key: A file containing the private key is requested. The private key is only requested if Secure shell (SSH) is selected in the Authentication method menu. Click Upload to browse for a private key that is associated with a public key in the ~/.ssh/authorized_keys file which is located on the target system. The private key must have a public key already setup on the server to which it is connecting.

Note: When working with DB2 Recovery Expert using a secure https connection, uploading files from the client using the Firefox, Safari or Chrome web browser is restricted. Microsoft Internet Explorer is supported and is recommended for these situations. If you prefer, you can also use an http connection for performing this task only.

If a local file is uploaded to the DB2 Recovery Expert Server on the Admin perspective during the installation of the DB2 Recovery Expert Database Server Components, the authentication type is set to using SSH (on UNIX systems) and a private key needs to be used for the installation. If one of the unsupported web browsers is used with an https connection for uploading the private key, an error message will be displayed and the private key will not be uploaded.

- Passphrase: This is the secure shell passphrase. Passphrase is only requested if Secure shell (SSH) is selected in the Authentication method menu. You can optionally select the Alternate security privileges check box, if you did not login with root privileges.

Specify the following options:

sudo user: This is the sudo command that is used to provide super user privileges to users.

su user: This is the standard su command. This is root for most UNIX systems.

4. Click Apply when all of the required information is entered in the Authentication window. The Status step opens and displays information about the uninstallation process.




Verifying the installation of the database server components

This section describes how to verify the database server components installation.

About this task

On the Admin perspective on the Install step, you can review all of the installations that are listed in the table in the Installed components panel. The install entry contains the following options:Install host The hostname that was specified for the installation. Path The local database server path for the database server components. Hostname The name of the host machine where the database server components were installed. Installation date The date when the installation was performed. Type of install DPF or single system installs. Installed version The version that was installed. OS type The operating system of the machine where the database server components were installed.

Procedure

Verify the installation of the database server components:

1. To verify the installation, select an item in the table and click Verify install. The Verify install window opens on the Credentials step.

2. Select the Host from the Hosts table and click Set credentials. The Authentication window opens.

3. On the Authentication window, specify information for the following fields:

- Host: The host name or IP address to which the connection is made. For DPF systems, the other systems involved are located using the db2nodes.cfg file. Authentication method This is the operating system user authentication method.

The choices are:

- Password authentication (the default)

- Secure shell (SSH) Note: The Secure shell (SSH) option is only available on Linux and UNIX operating systems. This option is not available on Windows operating systems. Windows operating systems support local connections or network connections using the SMB/CIFS protocol over TCP/IP.

- Username: The authorized username to log in to the target host. This username is requested regardless of the authentication method.

- Password: The password for the authorized user to log in to the target host. This password is requested only if Password authentication is selected.

- Private key: A file containing the private key is requested. The private key is only requested if Secure shell (SSH) is selected in the Authentication method menu. Click Upload to browse for a private key that is associated with a public key in the ~/.ssh/authorized_keys file which is located on the target system. The private key must have a public key already setup on the server to which it is connecting.

Note: When working with DB2® Recovery Expert using a secure https connection, uploading files from the client using the Firefox, Safari or Chrome web browser is restricted. Microsoft Internet Explorer is supported and is recommended for these situations. If you prefer, you can also use an http connection for performing this task only.

If a local file is uploaded to the DB2 Recovery Expert Server on the Admin perspective during the installation of the DB2 Recovery Expert Database Server Components, the authentication type is set to using SSH (on UNIX systems) and a private key needs to be used for the installation. If one of the unsupported web browsers is used with an https connection for uploading the private key, an error message will be displayed and the private key will not be uploaded.

- Passphrase: This is the secure shell passphrase. Passphrase is only requested if Secure shell (SSH) is selected in the Authentication method menu.

You can optionally select the Alternate security privileges check box, if you did not login with root privileges. Specify the following options:

- sudo user: This is the sudo command that is used to provide super user privileges to users.

- su user: This is the standard su command. This is root for most UNIX systems.

Note: If the /etc/sudoers file contains the line Defaults requiretty then sudo requires that the command be run from a terminal. Setting this requirement prevents DB2 Recovery Expert from working with sudo for Database Server component installations, data store creation and other related operations.

To enable these functions, remove the Defaults requiretty line from the /etc/sudoers file. Consult the sudo manual for more information.

4. Click Apply when all of the required information is entered in the Authentication window. The Status step opens and displays information about the verification process.



Editing the configuration of the database server components

This section describes how to edit the database server components of an installation.

About this task

On the Admin perspective on the Install step, you can review all of the installations that are listed in the table in the Installed components panel. The install entry contains the following options.

Note: If you install the database server components manually, no entry is created in the browser client for the host. Without the host entry, you cannot use the browser client to edit the DB2 Recovery Expert configuration for the host. To edit the configuration, you must manually edit the configuration file (conf/recex.properties) using a native operating system editor.

- Install host: The hostname that was specified for the installation.

- Path: The local database server path for the database server components.

- Hostname: The name of the host machine where the database server components were installed.

- Installation date: The date when the installation was performed.

- Type of install: DPF or single system installs.

- Installed version: The version that was installed.

- OS type: The operating system of the machine where the database server components were installed.


Procedure

Edit the configuration of the database server components:

1. To edit the configuration settings, select an item in the table and click Edit configuration. The Credentials window opens.

2. Select the Host from the Hosts table and click Set credentials. The Authentication window opens.

3. On the Authentication window, specify the following information:

- Host: The host name or IP address to which the connection is made. For DPF systems, the other systems involved are located using the db2nodes.cfg file.

- Authentication method: This is the operating system user authentication method. The choices are:

- Password authentication (the default)

- Secure shell (SSH)

Note: The Secure shell (SSH) option is only available on Linux and UNIX operating systems. This option is not available on Windows operating systems. Windows operating systems support local connections or network connections using the SMB/CIFS protocol over TCP/IP.

- Username: The authorized username to log in to the target host. This username is requested regardless of the authentication method.

- Password: The password for the authorized user to log in to the target host. This password is requested only if Password authentication is selected.

- Private key: A file containing the private key is requested. The private key is only requested if Secure shell (SSH) is selected in the Authentication method menu. Click Upload to browse for a private key that is associated with a public key in the ~/.ssh/authorized_keys file which is located on the target system. The private key must have a public key already setup on the server to which it is connecting.

Note: When working with DB2 Recovery Expert using a secure https connection, uploading files from the client using the Firefox, Safari or Chrome web browser is restricted. Microsoft Internet Explorer is supported and is recommended for these situations. If you prefer, you can also use an http connection for performing this task only. If a local file is uploaded to the DB2 Recovery Expert Server on the Admin perspective during the installation of the DB2 Recovery Expert Database Server Components, the authentication type is set to using SSH (on UNIX systems) and a private key needs to be used for the installation. If one of the unsupported web browsers is used with an https connection for uploading the private key, an error message will be displayed and the private key will not be uploaded.

- Passphrase: This is the secure shell passphrase. Passphrase is only requested if Secure shell (SSH) is selected in the Authentication method menu.

You can optionally select the Alternate security privileges check box, if you did not login with root privileges. Specify the following options:

- sudo user: This is the sudo command that is used to provide super user privileges to users.

- su user: This is the standard su command. This is root for most UNIX systems.

4. Click Apply. The Credentials window opens.

5. Click Edit configuration when all of the required information is entered in the Credentials window. The edits that you have specified are made to the installed components and the Edit Configuration screen opens with the following message:

DB2 Recovery Expert configuration file

This file is intended to specify DATA_DIR variable only. If not specified, the DATA_DIR is set to {/}/var{INSTALL_DIR} on UNIX and {INSTALL_DIR}/data on Windows. To set DATA_DIR for specific instance use DATA_DIR.<instance> syntax. Examples for Unix/Linux platforms are shown below:

DATA_DIR={/}var{INSTALL_DIR}

DATA_DIR.db2inst1={/}var{INSTALL_DIR}

Note: If this option is not set, the data will be added to the default location and the volume of data can become very large over time.


Creating or upgrading a datastore repository database from the browser client

Create or upgrade a datastore repository database from the browser client When upgrading an existing datastore repository database, repository data is migrated to the new repository.


Before you begin

- Ensure that your environment meets the prerequisites described in Preparing to install and configure DB2 Recovery Expert. - Review considerations and restrictions for installing, configuring, and using DB2 Recovery Expert in Considerations and restrictions.

- Review configuration requirements in Configuring DB2 Recovery Expert.

For more information about this step, click the ? icon in the upper right corner of the main DB2 Recovery Expert window to access the online Help. For a description of a field, hover your mouse pointer over the field.
Procedure

Create or upgrade a datastore repository database:

1. Navigate to the Admin perspective as an administrator user, and click Datastores.

2. On the Datastores databases window, make one of the following choices:

- To create a new datastore repository database, click Create.

- To upgrade an existing database, click Upgrade.

The Datastore creation or Datastore upgrade window opens on the Select installation step.

3. From the List of installations, select an installed database server component where the datastore repository database is to be created, and then click Next. Continue with the Credentials step.

4. On the Credentials step, select a host from the Hosts list, and then click Set credentials. On the Authentication window, set the following fields, and then click Apply to save the credentials.

- Host: The host name or IP address to which the connection is made. For DPF systems, the other systems involved are located using the db2nodes.cfg file. Authentication method This is the operating system user authentication method.

The choices are:

- Password authentication (the default)

- Secure shell (SSH)

Note: The Secure shell (SSH) option is only available on Linux and UNIX operating systems. This option is not available on Windows operating systems. Windows operating systems support local connections or network connections using the SMB/CIFS protocol over TCP/IP.

- Username: The authorized username to log in to the target host. This username is requested regardless of the authentication method.

- Password: The password for the authorized user to log in to the target host. This password is requested only if Password authentication is selected.

- Additional security privileges for UNIX/Linux systems: On UNIX and Linux systems, DB2 Recovery Expert requires additional privileges to install the database server components, and to create or modify databases. If you did not log in initially as root or as an instance user with authority to run the sudo or su command, then you must complete a two-part authentication process to switch the current user to an authorized user.

Select this check box, and from the Command type dropdown list, select sudo or su.

- sudo user: This is the sudo command that is used to provide super user privileges to users.

- Sudo user's password: The sudo user's password.

Note: If the /etc/sudoers file contains the line Defaults requiretty then you must run the sudo command from a terminal. Setting this requirement prevents DB2 Recovery Expert from working with sudo for database server component installations, datastore creation, and other related operations. To enable these functions, remove the Defaults requiretty line from the /etc/sudoers file. For more information, see the sudo manual.

- su user: This is the standard su command. This is root for most UNIX systems.

- su user's password: The root user's password. - Use supplied credentials for all hosts: You can click this check box to apply the credentials to all hosts. Click Next to continue to the Instance information step.

5. On the Instance information step, review the instance name value (instance on which the installation occurred), and enter the user name and password of the user with SYSADM or SYSCTRL authorities. Click Next to continue to the Database step.

Note: For more information about setting SYSADM or SYSCTRL in DB2, see the DB2 documentation: http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm .db2.udb.admin.doc/doc/t0005804.htm

6. On the Database step, perform steps for the operation that you are performing:

- If you are performing an upgrade, accept the datastore repository database name, or enter a name, and click then Upgrade. Proceed to Status step.

- To use an existing datastore repository database, click Use existing database, enter the name of the database, and then click Next. Continue with the Datastore authorities step.

- To create a new datastore repository database, click Create new database. If necessary, specify the following information, and then click Next to continue with the Datastore authorities step.

- Database name: Enter the name of the database.

- Log primary: Enter the primary log file.

- Log secondary: Enter the secondary log file.

- Log size: Enter the size of the log.

- Drop existing database If you want to drop an existing database, click this check box.

7. For a new installation, on the Datastore authorities step, you can grant users or groups access to the datastore repository database in order to get access to the DB2 Recovery Expert main functionality. List of users to grant access (separated by spaces) Enter a list of users who need access to the main DB2 Recovery Expert functionality. List of groups to grant access (separated by spaces) Enter a list of groups who need access to the main DB2 Recovery Expert functionality.
8. Click Install. Proceed to Status step.

9. On the Status step, you can view the installation progress. If the installation fails, you can review error messages that provide an explanation about why the installation failed.

Errors counts indicate the number of partitions or nodes that encountered an error during the installation. For a single partition installation, the count is either 0 or 1. For a partitioned installation, the count could be 0 up to the total number of partitions, if all failed. The count does not represent the number of individual error messages that were reported during the installation. That is, a given partition installation might encounter three errors, but the error count on the Status step would be 1, because the overall installation for that partition encountered a problem.

If you are upgrading, the existing repository data will be migrated to the new repository by defining the new tables, copying the data from the existing tables to the new tables, and then dropping the old tables.


Setting datastore options New option:

Install path The installation directory path of the DB2 Recovery Expert datastore database.

________________________________________


Update 5
Date of change: February 6, 2012
Topic: Object History and the SLR

Revised note about archive logging to read as follows:

Note: Archive logging must be enabled to use DB2 Recovery Expert. If archive logging is disabled in DB2 and then re-enabled, before you run Log Analysis, you must re-create the SLR from a new starting point that is after the most-recent enabling of logging.

________________________________________


Update 6
Date of change: February 6, 2012
Topic: Log Analysis information
Change description: New and revised information in the following sections:

- Configuring DB2 Recovery Expert for Log Analysis and remote database processing
- Providing filters for Log Analysis - Working with Log Analysis results


Configuring DB2 Recovery Expert for Log Analysis and remote database processing

Review how to set up and use DB2® Recovery Expert for Log Analysis and remote database processing

Before you begin Be aware of the following prerequisites and requirements:

- Remote database processing is only available for non-DPF databases.

- The remote and local systems must run on the same operating system and type (32 or 64 bit), and run the same version and fix pack levels of DB2.

- The database name must be cataloged under the same name so that DB2 Recovery Expert can find the backups.

- The username and password that are required for SLR and Log Analysis are for the remote database (not the local databases, and not the datastore). You can provide datastore credentials by issuing the set current connection command, if required.

- You must specify fully qualified paths for the location of log files. When locating log files, DB2 Recovery Expert does not added the instance name, database name, database partition, or log chain to the path.

- For more information about issuing the CLP commands in this procedure, see Command Line Processor (CLP) interface.

Procedure

1. Catalog a remote database on a DB2 system (called a local system) where the DB2 Recovery Expert database server components are installed. You can complete this step using the DB2 Configuration Assistant or the DB2 Command Line Processor (CLP).

2. Copy the archived log files and backups from the remote host to the local system that you created, or make them available on the local system (via shared NFS, for example).

3. Launch the DB2 Recovery Expert CLP.

4. Add and activate a datastore connection (issue the add datastore connection command, and then the set current connection command).

5. To create the Schema Level Repository (SLR), issue the following command: run slr for database <database> perform <create | update | ...> [user <remote_user>] [password <remote_password>] from <backup-image-TS> backups <local_backups_path> logs <local_logs_path>

6. To run Log Analysis, issue the following command: run la for database <database> report <summary | full> [user <remote_user>] [password <remote_password>] backups <local_backups_path> logs <local_logs_path>



Providing filters for Log Analysis

Transaction ID: Filter by Transaction IDs set. Specify a transaction ID or range of transaction IDs using the format ID1..ID2. A transaction ID is a hexadecimal value, as follows:

- Local Transaction IDs have a length between 1 and 12 hexadecimal characters (0-9, A-F).

- Global Transaction IDs have a length between 13 and 40 hexadecimal characters.

- XA Transaction IDs have a length between 41 and 140 hexadecimal characters.



Working with Log Analysis results

The Log Analysis Report view:

Comments in the report provide the following information:

- Connection information that was specified in the Location step (see Connecting to a database to run Log Analysis):

- DATABASE: Database on which the report was performed

- USER: Database user ID

- DATASTORE DATABASE: Name of the datastore database

- PARTITION LIST: Partitions on which the analysis was performed

- Report range options that were specified in the Report step (see Providing report type and mode):

- MRT: Displayed if Report Mode was Minimum Recovery Timestamp activity

- REDO DIRECTION: SQL or UNDO DIRECTION SQL Type of generated SQL (Redo or Undo)

- START TIMESTAMP: Start time of the report range, as specified in Start point

- END TIMESTAMP: End time of the report range, as specified in End point

- START LSN: Starting log sequence number (LSN) of the report range, if specified

- END LSN: Ending log sequence number (LSN) of the report range, if specified

- LOGBOUNDS: Starting and ending log numbers, if specified in Log files range

- PARTITION GROUPS: Partitions groups, if specified in Partitions to launch Log Analysis on

- Objects and filters that were specified in the Objects step and the Filters step (see Selecting objects for Log Analysis to report on and Providing filters for Log Analysis):

- TABLE SPACES: List of table spaces that were used to generate the report

- TABLE LIST: List of tables that were used to generate the report

- AUTHID LIST: List of authorization IDs that were used for report filtering

- APPNAME LIST: List of application names that were used for report filtering

- APPID LIST: List of application IDs that were used for report filtering

- TID FID MAP: List of table space ID (TID) values or table space and table ID (TID:FID) paired values that were used for report filtering

- TRANSACTIONS IDs: List of transactions IDs that were used for report filtering

- ACTION: Indicates the specified operations (I = insert, D = delete, U = update) •Additional options that were specified in the Options step (see Specifying additional options for Log Analysis processing):

- BACKUP DIRECTORY: List of additional backup directories that were specified

- LOG DIRECTORY: List of additional log directories that were specified

- TRANSACTION STATE: Types of transactions that are included in the report (C = committed, U = uncommitted, R = rolled back, P = partial)

- NOBACKUP: Displayed if Don't access backups when processing masked updates was selected

- NOLONG: Displayed if Skip processing for LONG and LOB column data was selected

- NOPAGE: Displayed if Don't access current database when processing masked updates was selected



________________________________________

Update 7
Date of change: February 6, 2012
Topic: Recovery information
Change description: New and revised information in the following sections:

- Viewing dependent objects and specifying related tables for recovery
- Selecting a plan to perform the recovery of database objects


Viewing dependent objects and specifying related tables for recovery

On the Dependencies step, you can ensure that the SLR exists and is up to date.

About this task

You can update the SLR from this step, if necessary. However, if the SLR does not exist, you must create the SLR in the Object History perspective. When you are creating the SLR, you must specify the base backup and the end point. If the SLR does not exist, you cannot perform a recovery on any objects. The SLR must include the Point in Time (PIT) in order to perform a recovery.

You can also review dependent objects and exclude related tables from the recovery on the Dependencies step. After checking the SLR, DB2® Recovery Expert generates the list of dependent objects, which are related to the objects selected on the Objects step. The amount of time required to generate a list of dependent objects is based on the number of objects selected for recovery and the number of dependencies that they have. If many dependencies exit, generating the list might require a significant amount of time. Tabs on the Dependencies step of the Recovery perspective show relationships to the selected objects, as follows:

- The Related tables tab displays all tables that are directly or indirectly related. You can use action buttons as follows:

- Click Include to include the selected table in the recovery plan.

- Click Include tree to include the selected table and all of its children tables in the recovery plan.

- Click Exclude to exclude the selected table from the recovery plan.

- Click Exclude tree to exclude the selected table and all of its children tables from the recovery plan. An icon beside a table in the tree indicates that table's relationship to its adjoining tables, and whether that table is to be included or excluded from the recovery plan, as follows:

Figure 1. Related tables icons [graphic showing the icons]

- The Dependencies tab displays all other objects (aliases, foreign keys, indexes, table spaces, views) that are directly related. By default, all dependent objects are recovered along with objects that you have selected. If you do not want to recover some of the related tables, you can exclude them from the recovery.

Note: Only tables can be excluded. If there are no related tables, only the Dependencies option is enabled and the Related tables option is disabled.

The Recovery plan generation is executed as a Session. You can save the Session by clicking Save, and open the saved Session later. User selection of related tables, and the event presence of them, is not known at the moment of dependencies generation. Therefore, this information is not recorded within the Session. If you want to save this, you must generate the Recovery plan and then save the Session. Note: If a Session was saved on the Dependencies step and this step contains related table information, then any changes made to the related tables will not be saved.

When you click Refresh, the state of the SLR is checked. If the state of the SLR is stable, then it reloads the dependencies; however, the Session is not regenerated. To regenerate the dependencies, you can change the PIT or select different objects.

Note: The Update SLR button is displayed when the SLR is obsolete. For example, Update SLR appears if the selected Point in Time is less than the SLR end point. If this occurs, you must perform an update SLR operation.

Procedure

View dependent objects and specify related tables for recovery:

1. If the SLR is not up to date, click Update SLR. The Status area displays the Time, Partition, and Message of the operation.

2. On the Status pane, specify the type of messages to be displayed by selecting All messages, Warnings and errors, or Errors only from the menu. You can click the Copy status messages to clipboard icon to copy the messages that you have specified in the menu to a clipboard and paste the error messages into a text editor. You can also click the Download status messages icon to download a zip file that contains the specified messages and either view the zip file directly, or save the zip file to a local directory.

3. Click Continue. The Dependencies perspective displays the dependencies and the related tables that have been selected.

4. On the Dependencies tab, you can review a list of all of the dependent objects.

5. On the Related tables tab, you can

- move tables from the Excluded related tables pane to the Selected related tables pane by selecting the table and clicking Include or Include all

- (if related tables exist), select related tables to include or exclude for the recovery

- drag tables to the appropriate pane as necessary

- remove tables from the Selected related tables pane (click the Remove icon to remove an individual table; click the Remove all icon to remove all tables)


Selecting a plan to perform the recovery of database objects

The following steps are available on the Scenario steps panel:

- Drop existing objects: This step removes objects, which are listed in the Selected step details panel, from the recovery object list, including tables (except in UNDO scenarios), table spaces, indexes, aliases, views, monitors, triggers, procedures, functions, modules, and sequences. When no objects must be dropped, you can exclude this step.

- Create objects: This step creates objects that are absent in the database but must be recovered, and that were removed in the Drop objects step. Tables will be created without check constraints and foreign keys. When no objects must be created, you can exclude this step.

The Selected step details panel shows

- the list of objects (not mutable) that will be created

- whether to prepare database objects to apply SQL

- table space type (AUTO or DMS)

For DMS table spaces, you can

- add or change the table space location container (the location type can be file or device)

- set the number of pages for the table space container

Click Resize parameters to access the following additional options:

- Autoresize: Choose whether to enable the auto-resize capability of a DMS or AUTO table space. Auto-resizable table spaces automatically increase in size when they become full.

- Initial size: This option is only valid for AUTO table spaces. Specify the initial size, per database partition, of an automatic storage table space. Specify an integer value followed by K (for kilobytes), M (for megabytes), or G (for gigabytes). The value must be at least 48 K.

Note: The actual value that is used might be slightly smaller than that specified because the database manager strives to maintain a consistent size across containers in the table space. Also, if the table space is auto-resizable and the initial size is not large enough to contain meta data that must be added to the new table space, the database manager will continue to extend the table space until there is enough space. If an initial size is not specified, the database manager determines an appropriate value.

- Increment by: Specify the amount, per database partition, by which a table space that is enabled for auto-resize will automatically be increased when the table space is full and a request for space has been made. Specify an integer value followed by K (for kilobytes), M (for megabytes), or G (for gigabytes).

Note: The actual value that is used might be slightly different than that specified because the database manager strives to maintain consistent growth across containers in the table space. If the table space is auto-resizable, but the amount by which to increment is not specified, the database manager determines an appropriate value.

- Maximum size: Specify the maximum size, per database partition, to which auto-resizable table spaces can automatically be increased. If the table space is auto-resizable, but the maximum size is not specified, the default is None. Specify an integer followed by K (for kilobytes), M (for megabytes), or G (for gigabytes). Specify None to indicate that the table space is to be allowed to grow to file system capacity, or to the maximum table space size.

Note: The actual value that is used might be slightly smaller than that specified because the database manager strives to maintain consistent growth across containers in the table space.

- Caching: Specify whether I/O operations are to be cached at the file system level. If no value is specified, the default is

- File system caching for JFS on AIX®, Linux System z®, all non-VxFS file systems on Solaris, HP-UX, SMS temporary table space files on all platforms, and all LOB and large data objects. File system caching specifies that all I/O operations in the target table space are to be cached at the file system level.

- No file system caching on all other platforms and file system types. No file system caching specifies that all I/O operations are to bypass the file system level cache.

- Run recovery components: This step runs the recovery components. When running on an instance with a single partition, this step has no options. When running on an instance with multiple partitions, the Selected step details panel shows the following option:

- Partition: The partition number (node) on which the recovery will be run.

- Validate data: This step validates options that were specified in the Options step for a specific partition. The Selected step details panel shows the following options:

- Backup locations: The specified backup.

- Database: The specified target database name.

- Log locations: The path to the specified log file.

- Synchronize recovery plan results: This step is required for multiple-partition databases to make sure that tasks are completed on all partitions. This step has no options.

- Extract: This step extracts table data from a backup. The Selected step details panel shows the following options:

- Backup timestamp: Timestamp of the backup from which data is extracted.

- Database: The target database name.

- Extract map: The TID:FID for tables.

- Keep export file: Whether the export file is saved to the session directory (Yes) or the temporary directory (No).

Load: This step loads table data into the database. The Selected step details panel shows the following options:

- Save mode: Choose Save load copy to copy the loading data. Choose Make backup to perform a backup of the table spaces and the tables that are loaded by the backup step.

- Table: The name of the DEL file with data.

- Backup: This step performs a table space backup if, in the Load step, the value of Save mode is Make backup. The Selected step details panel shows the following options:

- Buffer size: The size, in 4 KB pages, of the buffer that is used when building the backup image. If this option has no value, then DB2 will automatically choose an optimal value.

- Media header timestamp

- Number of buffers to be used for the backup.

- Online: Whether to perform an online backup. Online backups are only available for databases configured with logretain or userexit enabled. During an online backup, DB2 obtains IN (Intent None) locks on all tables existing in SMS table spaces as they are processed. S (share locks) are no longer held on LOB data in SMS table spaces during online backup.

- Parallelism: Determines the number of table spaces that the backup utility can read in parallel. If no value is provided, DB2 will automatically choose an optimal value in the range 0 through 999999.

- Table spaces: (not mutable) The table spaces to be backed up.

- Backups: (mutable) The type of backup, as follows:

- Disk location: You can add, edit, or delete backup locations.

- TSM: You can set the number of I/O sessions (1 through 1000) to be created between DB2 and the backup product. When the number of sessions is also specified, choose the path to the backup product library.

- Vendor (to specify another backup vendor's product): You can set the number of I/O sessions (1 through 1000) to be created between DB2 and the backup product.

- Translate table space: This step re-creates the specified table space from a backup. The Selected step details panel shows the backup timestamp (not mutable), the name of the database that contains the table space to be translated (not mutable), and the translation map.

- Rollforward: This step performs a roll forward action for the specified table space of a given database. The Selected step details panel shows the caller action, the database, and the table space for which the action applies.

- Generate redo SQL: This step generates redo SQL for the specified database and TID:FID filter from begin to end time.

- Generate undo SQL: This step generates undo SQL for the specified database and TID:FID filter from begin to end time.

- Apply SQL: This step applies generated SQL to the target database. The Selected step details panel shows the following options:

- Commit scope: (mutable) The number of rows (0 through 999999) that are grouped together in a commit scope.

- Direction: (not mutable) The type of the applied SQL, either redoslq or undosql.

- Stop on error: (mutable) Specifies whether the action stops when an error occurs.

- Update SLR history: This step executes SLR update. It is inserted at the end of the scenario if the scenario includes the Create objects step. It is inserted at the beginning of the Generate Undo SQL from current state recovery scenario.

If no data was entered on the Options step, the Selected step details panel shows no options. Otherwise, the Selected step details panel shows the following options:

- Backup locations: The path to the backup that was specified in the Options step.

- Log locations: The path to the log file that was specified in the Options step.




________________________________________

Update 8
Date of change: February 6, 2012
Topic: Considerations and restrictions information
Change description: New and revised information:

- Considerations for HADR
- Effects of changing the system clock
- Processing of SET INTEGRITY statements during recovery
- RENAME of table space, table, index, and column objects is limited
- DDL activity immediately before an offline backup can affect table space recovery
- MQTs are not refreshed during recovery
- DDL restrictions
- Log chain restrictions and considerations


Considerations for HADR

If your site uses DB2® high availability disaster recovery (HADR), review the HADR considerations for DB2 Recovery Expert processing. The datastore is created as a separate database within the same instance as the user database. High availability disaster recovery (HADR) configuration is performed at the database level, and is separate between the datastore and user databases. To survive a machine failure, the datastore repository database must be configured for HADR, along with the user database. The datastore database may exist within the user database and assume its HADR setup.

Considerations for Schema Level Repository (SLR) operations:

- Normally, the SLR minimizes the logging impact of processing by turning off LOB and table operation logging when updating. When BLOCKNONLOGGED is enabled in a HADR environment, increased logging will occur because all operations will be logged.

- SLR Update processing uses a cache of system catalog row images for log reconstruction. This information is stored on disk in the DATA_DIR path. For future SLR updates to succeed, the DB2 Recovery Expert database server components and working directory DATA_DIR must be located on a shared file system that is accessible on the standby server when a failover occurs.


Considerations for Recovery processing:

- During Recovery processing, the original NOT LOGGED clause for LOB columns will not be included in generated DDL if BLOCKNONLOGGED is currently enabled. Including the NOT LOGGED clause would cause the recovery to fail. As a consequence, if BLOCKNONLOGGED is disabled in the future, the LOB column will still be logged.

- DDL that is generated by using Log Analysis or the command-line DDL generator will include the NOT LOGGED clause, regardless of the BLOCKNONLOGGED setting. Running this DDL would fail if the database has BLOCKNONLOGGED enabled. DB2 Recovery Expert generates DDL in several places. DB2 will change all current NOT LOGGED columns, such as LOB columns, to LOGGED if BLOCKNONLOGGED is enabled after the columns are defined.

- Recovery processing uses the LOAD utility when recovering dropped tables and recovering a table back to a prior definition that requires dropping the current table. In HADR, when LOAD is used, the load file must be available on the secondary server. When BLOCKNONLOGGED is enabled, LOAD utility operations must include the COPY clause. In this configuration DB2 Recovery Expert will use the COPY YES clause of the LOAD utility. The copy location will be the same location as the backup from which the table data was exported.


Effects of changing the system clock

DB2® Recovery Expert for Linux, UNIX, and Windows relies on DB2 changes to the system clock. When major time shifts occur, such as the change to or from Daylight Saving Time (DST), you should be aware of the following situations:

- If you execute point-in-time recovery, you must be aware of any significant time shifts.

- Function definitions include the time and date that they were created in the form of a timestamp. At function invocation, DB2 attempts to resolve the function definition. As part of the function resolution, the timestamp value that was logged in the function definition at create-time is checked. If you move the system clock back to a time before the functions were created, DB2 will not resolve references to those functions. In DB2 Recovery Expert for Linux, UNIX, and Windows this could result in the inability to run tasks and in receiving error SQL0440N.

For more information, see http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=%2Fcom .ibm.db2.luw.admin.ha.doc%2Fdoc%2Ft0054835.html.


SET INTEGRITY considerations for table recovery

- Processing of SET INTEGRITY statements during recovery

During recovery, the processing of SET INTEGRITY statements might require the creation of exception tables. DB2® Recovery Expert for Linux, UNIX, and Windows defines these tables using the original table name. The table name format is <schema>.ARY<timestamp><counter><table_name>, where variables are defined as follows:

<schema> is the original table schema

<timestamp> is the original transaction timestamp

<counter> is a sequential value to ensure a unique table name

<table_name> is the original table name


- RENAME of table space, table, index, and column objects is limited

A recovery plan will not be generated when a rename of a table space, table, index, or column that is part of the recovery is encountered during the recovery time frame. If the recovery point in time is before the rename, the only available recovery plan will be to recreate the object using the original name. When the recovery point in time is after the rename, only the Undo SQL from current state is available.


- DDL activity immediately before an offline backup can affect table space recovery

When performing a table space recovery using the translated table space restore method, a problem might occur if DDL activity that affects tables that are being recovered occurs during the same second as the starting time of the backup. In this case, DB2® Recovery Expert might be unable to determine whether the DDL activity was performed before or after the backup, resulting in incorrect recovery execution with unpredictable results.


Materialized query table restrictions and considerations

- MQTs are not refreshed during recovery

When performing a recovery that involves a materialized query table (MQT), complete the following tasks: 1. Alter the table to drop the MQT. 2. Recover the base table. 3. Add the MQT and refresh the data.



DDL restrictions

Review the DDL restrictions for DB2 Recovery Expert.

DB2 Recovery Expert does not support DDL statements as described in this topic.

- CREATE INDEX statements with the following clauses:
- XMLPATTERN
- INDEX EXTENSION
- CREATE/ALTER TABLE statements for the following objects:
- staging tables
- materialized query tables (MQTs)
- user defined structured types (UDST)
- With the following clauses:
- ORGANIZE BY KEY SEQUENCE
- DISTRIBUTE BY REPLICATION
- SECURITY POLICY
- OPTIONS
- NOT LOGGED INITIALLY
- ALTER TABLE statements with the following clauses:
- PCTFREE
- LOCKSIZE
- APPEND ON/OFF
- VOLATILE/NOT VOLATILE
- LOG INDEX BUILD
- ADD/DROP SECURITY POLICY
- CREATE/ALTER/DROP statements with the following clauses:
- FUNCTION MAPPING
- SERVER
- TYPE MAPPING
- USER MAPPING
- WRAPPER
- AUDIT POLICY
- CREATE TYPE statements for types array, cursor, structured.
- Label Based Access Control (LBAC) statements
- Workload manager statements


Log chain restrictions and considerations

DB2 Recovery Expert cannot process logs across log chain boundaries. Review the following considerations that are associated with this restriction.

- In a high availability disaster recovery (HADR) environment, when a takeover occurs, a new log chain is started on the new primary system. DB2 Recovery Expert cannot process new log chains so that the information from previous chains is preserved for use with the new chains. See also Considerations for HADR.

- DB2 Recovery Expert cannot use the same backup image to create the Schema Level Repository (SLR) as was used for a database recovery.

- DB2 Recovery Expert cannot create the SLR from any backup before the restore point, and cannot update the SLR to a point that is not in the current log chain.

- An existing SLR cannot be retained for a database that was restored. After restoring the database, the SLR must be re-created.



________________________________________


Update 9
Date of change: February 6, 2012
Topic: Messages and codes information
Change description: New and revised messages

ARY0071W NOT LOGGED INITIALLY encountered in transaction {0} for table {1}.{2} TID/FID {3}.

Explanation: The table was created or altered with the NOT LOGGED INITIALLY clause, and therefore, table activity information is missing. Because information is missing, the result of log analysis or extraction from an online backup might be wrong. Correct results cannot be obtained from old logs.

Response: None. To avoid this problem in the future, do not use the NOT LOGGED INITIALLY clause.


ARY0175E Tablespace recovery: The source and target backup images are not compatible
Explanation: For one or more of the following parameters, the source backup image is not the same as the target backup image: - buffer size - session count - compress
Response: Verify that the parameters for the source and target backup images are the same, and then retry.

ARY0224I Cannot recover the table: {0} that is not accessible by Recovery from current table method.
Explanation: Informational error message that is displayed during Recovery generation that signifies that the specified table is contained in the table space that is in rollforward or backup pending state.
Response: Verify that the table space is accessible, and then regenerate the Recovery plan.


ARY0233I Restore of table space: {0} is not supported with HADR.
Explanation: In a high availability disaster recovery (HADR) environment, table space RESTORE is restricted by DB2. Recoveries that use table space RESTORE are not valid recovery paths.
Response: None.


ARY0252E Tablespace recovery: Indexes of source table (tid={0}, fid={1}) are not compatible with indexes of target table (tid={2}, fid={3}).
Explanation: This error message is displayed during recovery generation before translation, and signifies that the index sets of the source and template backup images are different. Translation does not occur and execution of the recovery scenario stops.
Response: Try recovering this database using a different recovery scenario.


ARY0302I Accessing backup image taken at {0} to obtain row images for logged operation reconstruction.
Explanation: Incomplete information was logged for one or more DML operations. Some operations that log incomplete information are UPDATE, MDC Block Delete, and LOB delete. To reconstruct the complete operation details, DB2 Recovery Expert for Linux, UNIX, and Windows will read a row image, LOB data, or both from a backup image. Reading a backup image will affect processing time.
Response: None.
Note: To improve Log Analysis detail processing performance for future logged operations, complete the following tasks:
- Enable DATA CAPTURE CHANGES for tables that are being processed.
- In DB2 version 9.7 and later, use currently committed semantics for cursor stability transaction isolation.
For more information, see the topics about updating the SLR from logs and considerations and restrictions.


ARY0303I Accessing containers for table space {0} to obtain row images for logged operation reconstruction.
Explanation: Incomplete information was logged for one or more DML operations. Some operations that log incomplete information are UPDATE, MDC Block Delete, and LOB delete. To reconstruct the complete operation details, DB2 Recovery Expert for Linux, UNIX, and Windows will read a row image from the current database table space containers. Reading the current database requires that each table space read be quiesced in share mode.
Response: None.
Note: To improve Log Analysis detail processing performance for future logged operations, complete the following tasks:
- Enable DATA CAPTURE CHANGES for tables that are being processed.
- In DB2 version 9.7 and later, use currently committed semantics for cursor stability transaction isolation.
For more information, see the topics about updating the SLR from logs and considerations and restrictions.


ARY0305I Minimum Recovery Timestamp unknown.
Explanation: The database was made recoverable after a table space was created, and no database activity has updated the minimum recovery timestamp (MRT) or LSN values. In this case, the MRT and LSN are zero. Log Analysis will starting reading logs from log extent zero when the database was first made recoverable.
Response: Provide a value for the begin timestamp of the report.


ARY0306I Begin LSN for partition {0} unknown.
Explanation: The database was made recoverable after a table space was created, and no database activity has updated the minimum recovery timestamp (MRT) or LSN values. In this case, the MRT and LSN are zero. Log Analysis will starting reading logs from log extent zero when the database was first made recoverable.
Response: Provide a value for the begin timestamp of the report.


ARY0738E The timestamp value provided for the prune operation is outside of
the SLR range.
Explanation: The product cannot perform the prune operation with the
timestamp value provided; however, SLR status is not affected.
Response: Specify a timestamp value that is between the SLR start and end
timestamps.


ARY4046E Unable to retrieve report details for transaction ID {transaction ID} LSN {LSN value} and partition number {partition}.
Explanation: This error message signifies that Log Analysis report details are not recovered and not available for specified transaction and LSN. It is displayed when a blocking activity is detected (such as LOAD or REORG operations). The blocking activity prevented the Log Analysis tool from accessing a backup image or current database to reconstruct the details of an operation.
Response: If a backup image is available for the specified partition for the time frame of the transaction, then specify the location for this backup. If accessing backups or reading database pages is prohibited, then allow the Log Analysis tool to use backups and access the current database, and repeat the command. It is also possible that no backup image is available between two REORGs or LOADs. In this case, Log Analysis cannot recover some details for the time frame between these two blocking activities.


ARY4241E Unsupported codepage "{0}".
Explanation: This error message signifies that an unsupported character code page was set.
Response: Modify the character code page and repeat the command.


ARY5029E A connection to the target host "{0}" could not be established. Would you like to retry testing the connections to all specified hosts?
Explanation: Whether to perform the connectivity check on all hosts is determined by the Test connections to all specified hosts check box on the Credentials step. DB2 Recovery Expert attempted to perform RXA connections to all hosts, and at least one connection failed.
Response: Click Yes to attempt connection testing again.


ARY5030E The selected installation is determined to be invalid. If you want to use this particular installation, you will need to reinstall it.
Explanation: During the Verify install step, DB2 Recovery Expert determined that the selected installation did not complete properly.
Response: If you want to use this particular installation, reinstall it to correct the problem.



ARY5031E A connection to the target host {0} could not be established due to invalid user credentials.
Explanation: DB2 Recovery Expert performed a connections test before uninstalling the database server components. The connection failed because the user credentials that were entered are not valid.
Response: Retry the uninstallation using authorized credentials.


ARY5032E The upgrade for the specified database server components is not viable because the selected version is older than the currently installed version.
Explanation: DB2 Recovery Expert does not allow the installation of database server components that are older than the currently installed version.
Response: To continue with the upgrade, select a newer version of the database server components.


ARY6018W Closing the current dialog will not result in termination of the process that is currently running in the background. By closing the dialog, any informational or warning messages resulting from the background process will not be displayed. Are you sure you want to close the dialog?
Explanation: Closing the wizard during the installation, uninstallation, upgrade, or installation verification process will not end the actual process. The process will continue to run in the background.
Response: Click Yes to close the wizard, or No to leave it open.


ARY6019W The installation you have selected already exists on the specified instance. Are you sure you want to continue and overwrite the existing installation with this new one?
Explanation: DB2 Recovery Expert does not allow two identical installations on the same instance.
Response: To overwrite the existing installation, click Yes. To close the dialog without overwriting the existing installation, click No.


ARY8006W The configured active log size of "{0}" 4-KB units is less than the recommended default setting of "{1}" 4-KB units.
Explanation: The log size may not be sufficient to perform some operations on the datastore database.
Response: You can adjust the log configuration parameters LOGPRIMARY, LOGSECOND, and LOGFILSIZ to increase the size of the active log.


ARY8007W The database configuration parameter "{0}" is set to "{1}", which is less than the recommended value of "{2}".
Explanation: The specified database configuration parameter value is less than the indicated recommended value. This may affect product operation.
Response: Increase the configuration parameter to a value equal to or greater than the recommended value.


ARY8008W Installation location is empty or corrupted. Check it manually.
Explanation: The database server files cannot be uninstalled using the standard uninstall procedure because the installation location is empty or missing expected files.
Response: Delete the product files manually on any host computers where they were installed.


ARY8009W Datastore database "{0}" is defined using codeset "{1}". DB2 Recovery Expert can only process user databases that match this codeset definition.
Explanation: The specified datastore database is defined using the indicated codeset. This means that DB2 Recovery Expert can only process user databases that match the specified codeset. Users cannot connect to other databases.
Response: To work with databases that are defined with a different codeset, create the datastore in a new UTF-8 database or in an existing database that is defined to use the UTF-8 codeset.


ARY8031E Unable to create the datastore database. The DB2_COMPATIBILITY_VECTOR registry definition "{0}" is not compatible with the database. The "{1}" setting causes a conflict. To avoid this problem, you can temporarily remove the conflicting definition or reset the value to 0, restart the DB2 instance, and repeat the request to create the datastore database. You can restore the original DB2_COMPATIBILITY_VECTOR definition after the database has been created.
Explanation: The current DB2_COMPATIBILITY_VECTOR settings are not compatible with the datastore database. One or more of the option settings may cause a problem when the database is created.
Response: Follow the directions specified in the error message. You can remove the conflicting settings from the vector to avoid the problem, and restore the original settings after the database is created.


ARY8105E Unable to create the datastore in existing database "{0}" that has configuration parameter "{1}" set to "{2}". The parameter must be set to "{3}".
Explanation: The datastore cannot be created in the specified database that has the indicated configuration parameter setting.
Response: Change the configuration parameter or create the datastore in a different database.


ARY8106E Invalid argument combination: "{1}" may only be specified with "{2}".
Explanation: The specified command argument can only be used with one of the listed command arguments.
Response: Correct the command line.


ARY8107E A problem was detected while upgrading the datastore definitions in database "{0}". It is necessary to recreate the datastore. If the problem persists, contact Customer Support for assistance.
Explanation: The datastore definitions in the specified database cannot be upgraded.
Response: Reinitialize the datastore. Previous product data that is stored in the datastore tables will be lost.




________________________________________

Update 10
Date of change: February 6, 2012
Topic: Troubleshooting information
Change description: New troubleshooting topics that are designed to provide you with information about DB2® Recovery Expert errors and issues. They also describe documentation that you might need to provide to IBM® Software Support for assistance.


Gathering diagnostic information for errors

Before you report a problem with DB2® Recovery Expert for Linux, UNIX, and Windows to IBM® Software Support, you need to gather the appropriate diagnostic information.

Information for all errors

Provide the following information for all DB2 Recovery Expert for Linux, UNIX, and Windows errors:

- A clear description of the problem and the steps that are required to re-create the problem
- All messages that were issued as a result of the problem
- Screen captures of pertinent windows
- The name and version of your browser
- The operating system of the client, the DB2 Recovery Expert for Linux, UNIX, and Windows server, and the DB2 server
- The version of DB2 and the type and version of the operating system that you are using

Additional information for specific errors

You might need to provide additional information based on the error message that you received or if requested by Support, as follows:

Messages ARY0000E through ARY2000E

Database server components produce messages in this range, usually during Log Analysis, Recovery, and creating or updating SLR.

Gather the following additional information:

- initial trace results (click Get trace), including all tables that are selected by default

Note: If Get trace is not displayed, see Preferences.

- (if requested) generated database server components trace files.

Note: For instructions, see How to activate tracing for database server components and access trace files.


Messages ARY4000E through ARY4999E

Java/DB2 Recovery Expert server components produce messages in this range. These errors usually occur when

- JDBC connectivity issues exist between the DB2 Recovery Expert server and DB2
- Database server components and the datastore database installation are incorrect, incomplete, or out-of-sync
- Incorrect information was specified by a user (for example, an invalid user ID or password for connecting to DB2)
- DB2 Recovery Expert files and repository were improperly configured or configuration was corrupted
- System errors occur due to lack of space or memory
- RXA component or network issues occur
- A product code problem exists

Gather the following additional information:
- ARYMP log file
- DS_System (WTI) log file
- hostlogs log files

Note: For instructions, see
- How to access log files on the DB2 Recovery Expert server
- How to access log files in a browser window


Messages ARY5000 through ARY8000

The Flex GUI produces messages in this range. These errors usually occur when a user enters incorrect information (such as a value that is out of range), when the network connection between the browser and the DB2 Recovery Expert server is interrupted, or when a product code problem exists. No additional information is required for messages in this range.

Messages ARY8000E through ARY8999

Product scripts produce messages in this range. These errors usually occur during installation, uninstallation, or verification of the database server components, or during datastore creation, and occur because

- Incorrect information was provided by the user (such as an invalid user name or password).
- The user does not have the privileges required to perform the operation.
- Insufficient disk space was available or system errors occurred on one of the DB2 systems.
- RXA/network related issues occurred.
- A product code problem exists.

Gather the following additional information:
- ARY-MP log file from the DB2 Recovery Expert server
Note: For instructions, see How to access log files on the DB2 Recovery Expert server.

- screen capture showing the error message
- printed output from the process

How to activate tracing for database server components and access trace files

1. In the product user interface, click Task Manager > Admin > Datastores.

2. Select the datastore connection that you were using when the problem occurred, and then click Settings.

3. From the Log Level dropdown menu, choose Debug and note the DATA_DIR property setting, and then click Apply.

4. Navigate to the perspective where the error occurred (such as Object history, Log Analysis, or Recovery), and then retry the actions that led to the error.

Note: Make note of the session ID that is used.

5. When the error occurs, navigate to the DATA_DIR location on the DB2 server where you performed the action.

6. In the DATA_DIR location, navigate to the following subdirectory: a. DB2 instance name (for example, db2inst1)

b. partition (for example, NODE0000)

c. database (for example, SATURN)

d. sessions

e. numerical session ID (for example, if your session ID is 5, there will be directory "5")

For example: /var/opt/IBM/DB2RELUW/db2inst1/NODE0000/SATURN/sessions/5/

7.Zip the entire directory to send to Support.

8. If your database is in a DPF environment, zip the directory for each partition (that is, navigate to all partitions NODExxxx). The database and session ID must be the same.

9. From the Log Level dropdown menu, choose Error, and then click Apply.


How to access log files on the DB2 Recovery Expert server

1. Log in to your DB2 Recovery Expert server system directly (via ssh, ftp, telnet, or Windows log in).

2. Change your current directory to the location where the product DB2 Recovery Expert server components are installed.

This is the location that was specified during the installation of the components; default locations are as follows:

- on UNIX: /opt/IBM/DB2RELUW

- on Windows: C:\Program Files\IBM\DB2RELUW

3. Locate the logs directory, which contains the ARY-MP and DS_System log files and the ARY/hostlogs directory.

4. Zip the entire logs directory and send the zip file to Support.


How to access log files in a browser window

To access the ARYMP and DS_ System log files from the product user
interface:

1. Click Task Manager > Logs.

2. Select ARY-MP and then click View log.

3. Click View in browser.

4. Save the contents of the displayed file.

5. Repeat for the DS_System log file.


Gathering diagnostic information

When DB2® Recovery Expert for Linux, UNIX, and Windows tasks such as SLR operations, Log Analysis, or Recovery take longer to complete than expected, IBM® Software Support might require information to analyze the cause of the issue.

Information required

IBM Software Support might request the following information:

- Output from the db2support utility: The db2support utility is a DB2 tool that collects information about a specified user database. To collect the information, run the db2support command as follows:

db2support –d <database alias> -cl 0 .

- ARY-MP log file: This log file contains information about the task that was submitted for execution and its parameters.

Note: For instructions, see "How to access log files on the DB2 Recovery Expert server" and "How to access log files in a browser window."

- Screen captures: Include the Status step with the most recent status messages.

SLR issues

When an issue occurs during SLR operations such as create, rebuild, or update, the issue probably occurred while the product was reading a backup image or DB2 logs. Support will need the following information:

- size and location of the backup that was specified for the SLR operation
- archived log file information as follows:
- log file location
- whether the log files are located on disk or TSM
- total size of archived log files that were to be processed, starting from the first log file that corresponds to the end log file of the specified backup image
- If the SLR was previously built, then a screen capture of SLR Info step is required.

Log Analysis issues

When an issue occurs during Log Analysis operation, Support will need the following information:

- If Log Analysis was launched in MRT mode, an output of the following command for the specified database, which will print MRT timestamp values for all table spaces in your database: db2 list tablespaces show detail
- If Log Analysis was launched in regular mode, a screen capture of the SLR range (This information is available in the Object History perspective on the SLR Info step for the selected database).
- Archived log file information as follows:
- log file location
- whether the log files are located on disk or TSM
- total size of archived log files that were to be processed, starting from the first log file that corresponds to the end log file of the specified backup image


Recovery issues

When an issue occurs during Recovery operation, Support will need the following information:

- trace output from the Recovery plan

Note: For instructions, see How to activate tracing for database server components and access trace files.

- size and location of the backup that was used for the recovery

- if the recovery involves Log Analysis, archived log file information as follows:

- log file location

- whether the log files are located on disk or TSM

- total size of archived log files that were to be processed, starting from the first log file that corresponds to the end log file of the specified backup image