unixadmin.free.fr Handy Unix Plumbing Tips and Tricks

Drive paths to library client taken offline when server option SANDISCOVERY set to ‘YES’

Technote (troubleshooting)

Problem(Abstract)

This message in the activity log of the library manager appears: ANR1772E The path from source to destination is taken offline.

Symptom

On the library client, these messages are observed in the activity log when a library sharing session is opened to the library manager:

On the library manager, you can see this corresponding message showing the path to the drive being taken offline:

Cause

The SAN discovery's query of the HBA has timed out, and the path is taken offline. This can occur in SAN environments with a large number of devices.
Diagnosing the problem

Verify that there is not an underlying hardware problem causing the drives paths to go offline.

Check the value of the SANDISCOVERYTIMEOUT option on the library clients and the library manager. The default value is 15 seconds:

Resolving the problem

If the value of the option is at or near the default value of 15 seconds, increase to a greater number. For example:

Why Are Tapes with PRIVATE Status Not Found in QUERY VOLUME Output?

Technote (FAQ)

Question

QUERY LIBVOLUME shows tape volumes with status of PRIVATE, but the same volumes do not show up with the command: Q VOL

Why are these tapes PRIVATE?

Answer

QUERY VOLUME will only return information about volumes that belong to stgpools, but there are other types of volumes that can have valid data on them: DB backups, exports, backupsets and remote volumes that belong to a Library Client server.

The volume history will keep a record of all volumes and you can display these other types of non-stgpool volumes with the following commands:

If a PRIVATE volume is not part of a stgpool and does not display in any of the above Q VOLH commands then you can set it to scratch using the command:

If you do have a library sharing environment it is recommended to run an AUDIT LIBRARY on the Library Client servers prior to changing the status of a volume to scratch on the Library Manager server.

Using ‘dd’ to verify Tivoli Storage Manager tape volume labels

Question
How can I use the Unix 'dd' command to verify a tape volume label?

Answer
The first step that may be necessary to verify a tape volume label is to find out the block size in use on that tape volume. This parameter is typically set on the physical tape library console interface and will vary between manufacturers so the ideal place to search is on the manufacturer website.
There is a method to manually find out the block size as follows:

On most Unix systems, the 'dd' command will output a message indicating a read failed from a tape drive (and corresponding tape volume) along with insufficient memory message. For example on AIX:

The 'if' parameter must reference a valid path to a drive that contains the volume you are seeking information about. This volume may be loaded using a utility such as tapeutil or directly from the physical library's console management. The drive should not be in use by Tivoli Storage Manager at the time the command is run and it is recommended to take the drive offline to Tivoli Storage Manager.

The 'ibs' parameter indicates the block size to use in bytes unless a 'k' is specific, in which case the parameter is read as kilobytes. A value of 32 bytes, as in the example above, is a good starting value. If this command returns a memory related error message then the value can be doubled.

The value specified for the block size is still smaller than what is actually on the volume so another error is generated. The value must be increased (each time doubling it) until no error message is reported:

Once the correct block size has been discovered, the 'dd' command should not generate a memory error when reading from the volume.
Now that the block size is known, the data on the first block of the tape can be dumped to a file:
dd bs= conv=ascii if= of=/tmp/.out

For example:

Once the file is file '/tmp/block1.out' is written, the file may be viewed in any text editor or the cat command can be used:

In this case the 'VOL1200312' is the label of the tape volume residing in the drive /dev/rmt1.

Source: IBM Technote

IBM Spectrum Protect formerly Tivoli Storage Manager

Beginning with Version 7.1.3, IBM Tivoli Storage Manager is now IBM Spectrum Protect™.
Beginning with Version 4.1.3, IBM Tivoli Storage FlashCopy® Manager is now IBM Spectrum Protect™ Snapshot.

Product name cross reference

Source:  IBM Technote

Scheduled « Backup VM » processes more virtual machines than expected.

Technote (troubleshooting)

TSM – Installation Manager fails to complete prereq check

Problem

The on screen message reports:
Exception caught while evaluating expression in bundle "com.tivoli.dsm.prereq.oscheck".

Symptom

Within the Installation Manager logs, the following messages are logged in the .xml log:

Cause

Incorrect user being used during installation/upgrade.

Resolving the problem

Review the following requirements for the user ID performing the installation/upgrade here:

Windows: Installing Tivoli Storage Manager by using the installation wizard

Ensure that the user ID that you plan to use during the installation is a user with local Administrator authority.

Installing the V7.1.1 server and verifying the upgrade

You must be logged on to the system with the administrative user ID that was used to install the V6.2 or V6.3 server.

SLOW STARTUP PERFORMANCE OF THE 7.1 SERVER ON WINDOWS

Abstract

The default value for the DB2 database parameter DB_MEM_THRESH changed in DB2 version 10.5 and can lead to slow startup performance of the 7.1 server on Windows.

Content

ERROR DESCRIPTION:
It is possible to see the server startup take significantly longer to start up than is expected. The delay is experienced when the DB2 DB_MEM_THRESH value is set to 100 and there are large bufferpools.

The delay affects either, newly installed Tivoli Storage Manager Version 7.1.x, or upgrades from Tivoli Storage Manager V5.x to 7.1.x on Windows systems.

Upgrades from V6.x to 7.1.0.00 or higher do not show this behavior, since the DB_MEM_THRESH value is not changed to 100. The delay does not affect normal server operations, only server startup.

Tivoli Storage Manager Versions Affected: 7.1

Customer/L2 Diagnostics: The following commands can be run on a
DB2 command line to verify the setting for DB_MEM_THRESH.

db2 connect to TSMDB1
db2 get db cfg for TSMDB1 | find "DB_MEM_THRESH"

Output should be similar to the following.

C:\Program Files\Tivoli\TSM\db2\BIN>db2 get db cfg for TSMDB1 |
find
"DB_MEM_THRESH"
Database memory threshold               (DB_MEM_THRESH) = 100

If you see DB_MEM_THRESH set to 100 and are running server version 7.1 on Windows then this APAR applies.

Initial Impact: Medium

Additional Keywords: startup start mem perf slow start up
performance

LOCAL FIX:
The following steps can be done while the TSM server is running and does not require that the TSM server be restarted.

The DB_MEM_THRESH value can be changed to the previous default
of 10 by issuing the following DB2 commands.

db2 connect to TSMDB1
db2 update db cfg for TSMDB1 using DB_MEM_THRESH 10

The output should look similar to the following.

C:\Program Files\Tivoli\TSM\db2\BIN>db2 update db cfg for TSMDB1
using
DB_MEM_THRESH 10
DB20000I  The UPDATE DATABASE CONFIGURATION command completed
successfully.

BACKUP VM uses NBD over SAN transport

Technote (troubleshooting)

Problem(Abstract)

Although "VMVSTORTRANSPORT SAN" is set in the datamovers options file, the backup uses NBD.
Symptom

Backup uses NBD transport

Cause

VMware vCenter 'SSL.VERSION' setting is set to TLSv1.

This option can be found in the VMware vSphere client -> Administration -> vCenter Server Settings -> Advanced Settings.

Environment

Windows/Linux datamover.

vCenter 5.1 or 5.5.

Diagnosing the problem

A Tivoli Storage Manager client trace will show the following:

Resolving the problem

The SSL.VERSION parameter needs to either be set to 'ALL', or if TLS is a requirement, then the Tivoli Storage Manager client (datamover) must be upgraded to version 7.1.2.x. This version of client includes VDDK version 6.0 which has added support for TLS.

https://www.vmware.com/support/developer/vddk/vddk-600-releasenotes.html#whatsnew

Tivoli Storage Manager: Understanding the DB2 instance and database dirs

Question

In a Tivoli Storage Manager server environment, what is the purpose of the DB2 instance directory, and the local and system database directories?

Cause

When the TSMDB1 database is created in a Tivoli Storage Manager server environment, information about the database is written to both the DB2 local and system database directories. Understanding the purpose and locations of these directories, and the DB2 instance directory, can be beneficial during problem determination.

Answer

DB2 instance directory
The DB2 instance directory contains all information that pertains to a specific database instance. The instance directory contains the following data:
the database manager configuration file
the system database directory
the node directory
the node configuration file (db2nodes.cfg)
other files that contain debugging information (eg. db2diag.log)

By default, the DB2 instance directory is created in the home directory for the DB2 instance owner. The DB2 instance directory can typically be identified by the presence of the sqllib directory. If necessary, the 'db2greg -dump' command can be issued, as the DB2 instance owner, to determine the appropriate instance directory. The output from the 'db2greg -dump' command will resemble the following:

In the output above we are only concerned with the line that begins with "I" as this is the line that contains information about the instance. The value in the fourth comma-delimited field should be the name of the DB2 instance owner (tsminst1) and the value in the fifth field is the location where the sqllib directory was created. Being as the sqllib directory is only created in the instance directory, we are able to determine that /home/tsminst1 is the instance directory. Keep in mind that if multiple instances are defined on this host, information about each of these instances will be displayed in the 'db2greg -dump' output.

DB2 system database directory
The system database directory is where DB2 records information about all of the local and remote databases that are cataloged to this specific DB2 instance. In a Tivoli Storage Manager server environment, only information about the local TSMDB1 database is recorded in the system database directory. Entries for the TSMDB1 database are created in the system database directory when the database is cataloged; either implicitly via the CREATE DATABASE command (eg. dsmserv format) or explicitly via the CATALOG DATABASE command.

The system database directory is created in a subdirectory beneath the DB2 instance directory and can be identified by the following path:

//sqllib/sqldbdir

DB2 local database directory
The local database directory is where DB2 records information about all of the databases that are defined on the local host. In a Tivoli Storage Manager server environment, the local database directory will only contain information about the TSMDB1 database that is defined on that host. Entries for the TSMDB1 database are created in the local database directory only when the database is defined.

The DB2 local database directory is also often defined in, or a subdirectory of, the DB2 instance directory. The local database directory is created in the location specified by the default database path (DFTDBPATH) configuration parameter at the time that the database is defined. The current value for the DFTDBPATH configuration parameter can be determined by issuing the 'db2 get dbm cfg' command, as seen below:

$ db2 get dbm cfg |grep -i dftdbpath
Default database path (DFTDBPATH) = /tsminst1
In the event that no value is defined for the DFTDBPATH parameter, then the local database directory is, by default, created in the home directory for the DB2 instance owner. The local database directory can also be identified by the following directory structure:

////sqldbdir
For example, assuming a DB2 instance name of 'tsminst1' and a local database directory of '/home/tsminst1', we would expect to see the existence of the following directory path:

/home/tsminst1/tsminst1/NODE0000/sqldbdir