Oct 22

System State Backups May Fail On Certain Windows Operating Systems

Windows VSS Comments Off on System State Backups May Fail On Certain Windows Operating Systems

Problem(Abstract)

TSM Client system state backups sometimes fail on Windows 2008 R2, Windows 7, Windows 8, or Windows 2012 operating systems. These backups are performed using Volume Shadow Copy Service, which may fail during this operation. During the operating system installation, a 100 MB System Reserved Partition is typically created, however the VSS operation will fail if this volume is not online. This leads to the system state backup failure.

Symptom

When this problem is encountered the following will appear after the system state backup is invoked:

Backup System State using shadow copy…
ANS1468E Backing up Automated System Recovery (ASR) files failed. No files will be backed up.

System State Backup finished with failures.

ANS1468E Backing up Automated System Recovery (ASR) files failed. No files will be backed up.

After the failure, vssadmin reports that the ASR writer has timed out.

********

In addition to the above error, the error log will contain entries similar to the following:

05/13/2011 11:18:39 ANS5250E An unexpected error was encountered.
TSM function name : BackupComplete()
TSM function : ‘BackupComplete() failed with error VSS_E_BAD_STATE. -2147212543’
TSM return code : -2147212543
TSM file : asrutil.cpp (2416)
05/13/2011 11:18:39 ANS1468E Backing up Automated System Recovery (ASR) files failed. No files will be backed up.

05/13/2011 11:18:40 ANS1468E Backing up Automated System Recovery (ASR) files failed. No files will be backed up.

********

In addition to the errors listed above, the Windows Event Viewer will contain:

Volume Shadow Copy Service error: Error calling a routine on a Shadow Copy Provider {b5946137-7b9f-4925-af80-51abd60b20d5}.
Routine details EndPrepareSnapshots({4fe8f016-cc83-4541-acb1-106e36caba72}) [hr = 0x80070015, The device is not ready.].

Operation:
Executing Asynchronous Operation

Context:
Current State: DoSnapshotSet

 

Cause

TSM uses VSS to back up system state, but VSS runs into errors if the 100 MB System Reserved Partition is offline.

One cause for the 100 MB System Reserved Partition to be offline is having the Windows automount capability disabled. There are circumstances where the automount capability must be disabled, but it has been observed that this can result in the partition being offline after the reboot.

 

Environment

Windows Server 2008 R2

Windows 7
Windows Server 2012
Windows 8

 

Diagnosing the problem

To determine if this problem has been encountered during a TSM Client system state backup, perform the following:

  1. Confirm that the operating system is Windows 2008 R2, Windows 7, Windows 8, or Windows 2012.
  2. Check for the errors listed in the Symptoms section above.
  3. Run ‘DISKPART LIST VOLUME’ from a Command Prompt to determine if there is a 100 MB volume that is offline.

Resolving the problem

As mentioned in the Abstract section, this problem occurs because the 100 MB System Reserved Partition is offline. This issue can be resolved by enabling automount and rebooting, which will bring this volume online and keep it online through subsequent reboots. Enabling automount can be done by opening a Command Prompt window and invoking DISKPART:

DISKPART -> automount enable -> exit

Before making this change to enable automount, care should be taken to determine that it was not disabled intentionally. For example, systems acting as VMware vStorage backup servers are required to have automount disabled. If automount needs to stay disabled, a work-around would be to go into DISKPART and set the 100 MB volume online:

DISKPART -> list volume -> select volume 1 -> online volume -> exit

The volume selected should be the 100 MB volume. In the above example it was assumed that ‘list volume’ showed the 100 MB volume to be volume 1. It is important to note that with automount disabled, this will only keep the volume online until the next system reboot.

written by Bosse

Sep 15

New Data Protection for Microsoft SQL Server Version 7.1.1

SQL Comments Off on New Data Protection for Microsoft SQL Server Version 7.1.1
Support for Microsoft SQL Server 2014
You can now use Data Protection for SQL Server to manage SQL Server 2014 in stand-alone and failover cluster environments, and to protect your SQL Server 2014 databases.
Backup processing efficiencies and improvements
During backup processing, Data Protection for SQL Server bypasses database snapshots and databases that are in offline, mirroring, and restoring states. With this release, the databases that are bypassed during backup processing are indicated in the console output and in the tdpsql.log.
AES 256-bit encryption added as an available data encryption type
AES 256-bit encryption is available as a data encryption type with this release. AES-256 provides the most secure algorithm to encrypt data that is sent to the Tivoli Storage Manager server. Previously supported AES-128 and DES-56 encryption remain as supported encryption types.
Checksum processing is available for legacy database backups
In the Microsoft Management Console (MMC), you can specify integrity checking for legacy database backups. On the command-line interface, you can set the SQLCHECKSum parameter with the set command to specify integrity checking for all legacy backups. You can override the global setting by issuing the SQLCHECKSum parameter on the backup command.
VERIFYOnly option is available for legacy database restore operations
You can verify whether a legacy database backup is valid without physically restoring the backup. Before you restore the legacy database backup, you can run the restore operation with the Verify Only option in the MMC. Alternatively, you can use the /VERIFYOnly option with the restore command on the command-line interface.

written by Bosse

Sep 15

News in TDM Exchange 7.1.1

Exchange Comments Off on News in TDM Exchange 7.1.1

New for Data Protection for Microsoft Exchange Server Version 7.1.1

Data Protection for Microsoft Exchange Server includes several new features and changes.

The required authority to perform mailbox restore operations is reduced
In previous releases, only members of the Exchange Organization Management role group had the required administrative permissions to complete mailbox restore operations. With this release, it is no longer necessary for Exchange backup and restore operators to be in the Organization Management role group and have full administrative authority. You can use Exchange Role Based Access Control (RBAC) to limit users to specific operations, for example, view-only access to a mailbox list or individual mailbox restore operations. With RBAC management role scope, you can further limit the scope of restore operations, for example, to users in a single Active Directory domain.
Capacity to keep a recovery database for mailbox restore operations
With this release, you can retain a recovery database for reuse in mailbox restore operations. Alternatively, you can ensure that the recovery database is removed after a mailbox restore operation is complete. You can use the /KEEPRDB option with the restoremailbox command on the command-line interface, or specify the option in the Microsoft Management Console (MMC).
Capacity to use or remove an existing recovery database during mailbox restore operations
You can restore mailboxes from an existing recovery database, or you can automatically remove an existing recovery database during mailbox restore operations. You can choose whether to use a recovery database for mailbox restore operations in the MMC, or by using the /USEEXISTINGRDB option with the restoremailbox command on the command-line interface.
Performance enhancements in Mailbox Restore Browser functionality
Performance is significantly improved when the Mailbox Restore Browser feature restores whole mailboxes, mailbox folders, and selected mail messages.
Usability enhancements in the Mailbox Restore Browser interface
When you use the Mailbox Restore Browser interface to restore a mailbox, you can identify which backup version to restore from a list of available backups. Right-click menus are available for mailbox restore tasks.
AES 256-bit encryption added as an available data encryption type
AES 256-bit encryption is available as a data encryption type with this Data Protection for Exchange release. AES-256 provides the most secure algorithm to encrypt data that is sent to the Tivoli Storage Manager server. AES-128 and DES-56 encryption remains as encryption types that you can use.
Options to bypass integrity checking in a Database Availability Group environment
If at least two healthy copies of a database (one active and one passive copy) exist in a Database Availability Group (DAG) environment, it might not be necessary to verify the consistency of the database and log files. To expedite backup processing, you can bypass integrity checking of database and log files. You can use the /SKIPINTEGRITYCHECK options with the backup command on the command-line interface, or in the MMC.

written by Bosse

Jun 24

Backup of VMware Windows MS SQL guest fails

VE Comments Off on Backup of VMware Windows MS SQL guest fails

Problem(Abstract)

Tivoli Storage Manager for Virtual Environments is used to back up a Windows guest that runs Microsoft SQL. The backup of the VM fails with the ANS9365E and ANS5250E errors.

Symptom

The following errors are logged during the backup :


04/30/2014 23:18:46 ANS9365E VMware vStorage API error for virtual machine 'myguest'.
TSM function name : visdkCreateVmSnapshotMoRef
TSM file : vmvisdk.cpp (5416)
API return code : 67
API error message : An error occurred while quiescing the virtual machine. See the virtual machine's event log for details.
04/30/2014 23:18:46 ANS5250E An unexpected error was encountered.
TSM function name : vmVddkFullVMPrePareToOpenVMDKs
TSM function : snapshot targetMoRefP is null
TSM return code : 115
TSM file : ..\..\common\vm\vmbackvddk.cpp (12439)
04/30/2014 23:18:46 ANS1228E Sending of object 'myguest' failed.

 

Diagnosing the problem

Examine the vmware.log of the virtual machine, located in the folder of the virtual machine in the datastore. The following errors are logged :

2014-05-05T02:32:18.259Z| vcpu-1| I120: [msg.snapshot.quiesce.vmerr] The guest OS has reported an error during quiescing.
2014-05-05T02:32:18.259Z| vcpu-1| I120+ The error code was: 5
2014-05-05T02:32:18.259Z| vcpu-1| I120+ The error message was: 'VssSyncStart' operation failed: IDispatch error #8449 (0x80042301)

Examine the Windows event log of the Windows guest. The following errors are logged :

4/30/2014 11:18:30 PM VSS Error None 6008 N/A MYGUEST
Sqllib error: Failed to create VDS object. hr = 0x80040154.
4/30/2014 11:18:30 PM VSS Error None 20 N/A MYGUEST
Volume Shadow Copy Service error: A critical component required by the Volume Shadow Copy service is not registered. This might happened if an error occurred during Windows setup or during
installation of a Shadow Copy provider. The error returned from CoCreateInstance on class with CLSID
{40700425-0080-11d2-851f-00c04fc21759} and Name MSSQL_ClientVirtualDeviceSet is [0x80040154].

 

Resolving the problem

In this case, the backup fails is caused by a VSS problem on the Windows guest. Follow the steps below to resolve the error :

  1. Stop SQL Server.
  2. Click Start/Run and enter the following command in the Open box, and then click OK.

    Regsvr32 Path\SQLVDI.DLL

    The default path of the Sqlvdi.dll file is C:\Program Files\Microsoft SQL Server\80\COM.
  3. Restart SQL Server.
  4. Run the backup of the VM

Refer to the following Microsoft article for more information about the VSS SQL error.
http://support.microsoft.com/kb/830575

written by Bosse

May 07

Considerations when upgrading to Tivoli Storage Manager v7

Upgrade Comments Off on Considerations when upgrading to Tivoli Storage Manager v7

Question

What are the known issues you need to be aware of before upgrading to version 7.1 of the Tivoli Storage Manager?

Cause

There are two potential DB2 APARs that you may encounter during your upgrade from v6 to v7.
APAR Numbers:

Note that the underlying sub-directory structure of DB2’s active, active mirror, archive, and archive overflow locations have been changed. As a result, at upgrade time, DB2 attempts to copy the log files from the old sub-directory structure into a new sub-directory structure.

If DB2 is unable to successfully move the log files, the following errors may be seen:

Tivoli Storage Manager Installation/Upgrade Results:

      When running the upgrade of the server, the following warning message is encountered:

ANRI1017W WARNING:   The upgrade command for database TSMDB1 failed. To complete the upgrade of this instance, correct the error and reissue the following command as user <Instance User>:

db2 upgrade database TSMDB1.

      Next, trying to start DB2 and run the upgrade command results in the following:

$ db2start
04/14/2014 16:17:58     0   0   SQL1063N  DB2START processing was successful.
SQL1063N  DB2START processing was successful.

$ db2 upgrade database TSMDB1
SQL1762N  Unable to connect to database because there is not enough space to allocate active log files.  SQLSTATE=08004
db2diag.log File Results:2014-04-08-10.04.20.104213-300 I63592A829           LEVEL: Error
PID     : 14811534             TID : 2058           PROC : db2sysc 0
INSTANCE: prd04                NODE : 000           DB   : TSMDB1
APPHDL  : 0-7                  APPID: *LOCAL.tsmprd04.140408150419
AUTHID  : PRD04                HOSTNAME: prd004
EDUID   : 2058                 EDUNAME: db2agent (TSMDB1) 0
FUNCTION: DB2 UDB, data protection services, sqlpgReallocLogs, probe:970
MESSAGE : ZRC=0x85100084=-2062548860=SQLP_NO_SPACE_FOR_LOG
          "Not enough space to create primary logs"
DATA #1 : String, 59 bytes
Log path / Free space (bytes) / Log space required (bytes):
DATA #2 : String, 52 bytes
/prd04/db2actlog/prd04/NODE0000/LOGSTREAM0000/
DATA #3 : unsigned integer, 8 bytes
16079912960
DATA #4 : unsigned integer, 8 bytes
137441050624

2014-04-08-10.04.20.161956-300 I71011A511           LEVEL: Warning
PID     : 10944702             TID : 1              PROC : db2bp
INSTANCE: prd04                NODE : 000
HOSTNAME: prd004
EDUID   : 1
FUNCTION: DB2 UDB, base sys utilities, sqlemgdb, probe:365
MESSAGE : ZRC=0xFFFFF91E=-1762
          SQL1762N  Unable to connect to database because there is not
          enough space to allocate active log files.

 

Answer

For APAR IC99700, there are two possible solutions you can do before attempting your upgrade.

    1. Double the size of the file system where your active log resides. All this space will be needed because the log files are copied from the old location to the new location (refer to APAR IC97073).
    2. Change the size of your active log by updating the ACTIVELOGSIZE in your dsmserv.opt file. Once you update this option, restart your Tivoli Storage Manage server, prior to your upgrade, to allow the new size to take effect. If this is the option you select, ensure you have double the space in your active log file system. After you complete the upgrade, start your server and go through your verification steps. Halt your Tivoli Storage Manager server and reset your ACTIVELOGSIZE option to your desired size and then start your server.

For APAR IC97073, there is no work around. Following a successful v7 upgrade, be aware that there is a chance the old log files will not be removed. These old files may need to be manually removed. Before removal, verification of the configuration from both the Tivoli Storage Manager and DB2 perspectives should be completed. Contact Support for assistance.

Related information

IBM Tivoli Storage Manager Upgrade and Migration Proces

written by Bosse

May 07

Archive and active log directories are full and server will not start

ActiveLog ArchiveLog Comments Off on Archive and active log directories are full and server will not start

Question

If a FULL database backup is not taken in time to prune the archive logs before the directory becomes full. Either the active log becomes full, or the active directory becomes full of the logs that could not be archived. The result is that the Tivoli Storage Manager server shuts down.

Cause

Tivoli Storage Manager server shuts down and archive log directory and active log directory are full. The server cannot be started again.

Answer

When the archive log directory or active log directory fills up, or when the pre-allocated active logs fill up, the Tivoli Storage Manager shuts down. In order to get the Tivoli Storage Manager server up and running, you must update the DB2 configuration to change the location of the active log directory to a new location. This will allow to active logs to free up space and then the Tivoli Storage Manager server can start. You can then clear the archive log directory by issuing database backups. Complete the following procedure:

1. Create a temporary directory large enough to place the active logs.
See dsmserv.opt for value of ACTIVELOGSIZE.

2. Open a DB2 command prompt:
Windows:
Go to Start > All Programs > IBM DB2 > DB2COPY1 > Command Line Tools > Command Window – Administrator.

AIX/Linux/Unix:
1. Open a terminal session.
2. Log in as the Tivoli Storage Manager instance user.

3. Update the DB2 configuration to specify the new location for active log directory that you just created. From the DB2 command prompt, issue the following commands:
set db2instance=SERVER1
db2start
db2 update db cfg for tsmdb1 using newlogpath <path_from_step1>
db2 connect to tsmdb1

4. The active log files will not be removed until the following ‘activate’ command is issued.
First perform a deactivation to ensure that the database is not already activated:
db2 deactivate db tsmdb1
Then run the activate command:
db2 activate db tsmdb1

Note: The active logs will be COPIED and RENAMED (not moved) to the new temporary directory that you specified in step 1.

5. You have 2 options to prune the archive logs to get the Tivoli Storage Manager sever back up and running:

Hide details for Option A: Have Tivoli Storage Manager prune the archive logsOption A: Have Tivoli Storage Manager prune the archive logs
You can have Tivoli Storage Manager prune the archive logs by issuing database backups. You will need to update the DB2 configuration to point the active log direction location back to the original location, and then issue the activate command to copy over the log files to the original location. Since these newly created active log files have space to write transactions, the Tivoli Storage Manager server can start, and you can initiate DB backups to prune the archive logs. Complete the following steps:

A.5.1. Update the DB2 parameter to point the location of the active log back to the original location.
See ACTIVELOGDIRECTORY value in dsmserv.opt.
db2 UPDATE DATABASE CONFIG FOR TSMDB1 USING NEWLOGPATH <path_to_activelogdir>

A.5.2. Issue the activate command to copy the logs to the original location:
db2 activate db tsmdb1

A.5.3. Start the Tivoli Storage Manager server in the foreground.
Open a command terminal and navigate to the server directory and issue the dsmserv command to start the correct instance. Refer to the command here:
http://publib.boulder.ibm.com/infocenter/tsminfo/v6r2/topic/com.ibm.itsm.srv.ref.doc/r_cmd_dsmserv_start.html

A.5.4. Run a database backup to prune some of the archive logs.
dsmserv backup db type=full dev=<your device class>

A.5.5. Review the archive log directory. Is the drive/volume free space still low? You will have to decide if you need to run a second database backup to avoid having the archive logs fill up again before the next scheduled database backup. This depends on the average growth of archive logs per day. Review the timestamps on the archive log.

Hide details for Option B: Have DB2 prune the archive logsOption B: Have DB2 prune the archive logs
You can have DB2 prune the archive logs by running a DB2 database backup.

B.5.1. Create a directory on a drive/volume with enough space to hold a full DB2 database backup.

B.5.2. From the DB2 command prompt, issue the following commands:
db2 deactivate db tsmdb1
db2 backup db tsmdb1 to <path_to_database_directory>

Examples:
Windows: db2 backup db tsmdb1 to C:\dbbackup
AIX/Linux: db2 backup db tsmdb1 to /tmp/dbbackup

The following message will appear once the backup is complete:
Backup successful. The timestamp for this backup image is: 20090721130818
At the end of this backup, archive logs will start pruning.
Note: depending on the size of the database and archive logs, this could take a while to complete the backup.

B.5.3 Review the archive log directory. Is the drive/volume free space still low? You will have to decide if you need to run a second DB2 database backup to avoid having the archive logs fill up again before the next scheduled Tivoli Storage Manager database backup. This depends on the average growth of archive logs per day. Review the timestamps on the archive log.
If need, issue another DB2 database backup.

B.5.4. Delete any DB2 database backups as follows:
db2stop
db2start
db2 connect to tsmdb1
db2 PRUNE HISTORY <timestamp> WITH FORCE OPTION AND DELETE

where <timestamp> is the timestamp that was displayed after the DB2 database backup completed. See step B.5.2, where the timestamp is: 20090721130818.

B.5.5. Update the DB2 parameter to point the location of the active log back to the original location.
Ssee ACTIVELOGDIRECTORY value in dsmserv.opt.
db2 UPDATE DATABASE CONFIG FOR TSMDB1 USING NEWLOGPATH <path_to_activelogdir>

B.5.6. Connect to the database to start automatic moving of active logs from the temporary location to original active log location.
db2 force application all
db2stop
db2start
db2 connect to tsmdb1

The connect command will trigger DB2 to move (not copy) the active logs to the original directory.
Note: depending on the size of the active logs, this process can take a long time.

B.5.7. Start Tivoli Storage Manager server in foreground.
Open a command terminal and navigate to the server directory and issue the dsmserv command to start the correct instance. Refer to the command here:
http://publib.boulder.ibm.com/infocenter/tsminfo/v6r2/topic/com.ibm.itsm.srv.ref.doc/r_cmd_dsmserv_start.html

B.5.8. Take a full database backup by issuing the following commands:
disable sessions
backup db type=full dev=<your device class>
enable sessions

Now that the Tivoli Storage Manager server is up and running, attention should be paid to see how often FULL Tivoli Storage Manager database backups are needed in order to prune the archive log directory.

written by Bosse

May 07

Configuring DB2 log archives to Tivoli Storage Manager

TSM 7.1 Comments Off on Configuring DB2 log archives to Tivoli Storage Manager

Question

Configuration steps required to send DB2 archive log data to the Tivoli Storage Manager Server

Cause

Technotes 1391970 (Configuring DB2 and Tivoli Storage Manager in Windows) and 1635414 (Configuring DB2 and Tivoli Storage Manager in Unix / Linux) describe configuring the DB2 DB backups to Tivoli Storage Manager, but additional steps are required in order to send log archives.

Answer

This document presumes that you have already configured the DB2 backups to Tivoli Storage Manager, so the steps for registering a nodename, configuring dsm.opt/dsm.sys, etc., are not included here. Reference the links to the above technotes for more information on that aspect of the configuration.

To ensure the DB2 archive log data can be successfully stored on the Tivoli Storage Manager Server, perform the following steps:

1) Define an archive copygroup for the default management class within the active policyset of the domain in which the node resides.

    DEFINE COPYGROUP domain_name policyset_name mgmtclass_name TYPE=ARCHIVE DESTINATION=archive_stgpool_name RETVER=NOLIMIT

Note: It is recommended to specify a different storage pool hierarchy for the archive logs than the DB2 database backups, especially if the backups are including the DB2 archive logs (which is the default behavior for a full DB2 backup). If the DB2 archive data is in the same storage pool as the DB2 backup data, you can run into the scenario where a DB2 archive log retrieve (which occurs during a DB2 backup) will preempt access to a volume that a DB2 backup session has mounted. This will cause the backup to fail.

2) If the archive logs will be stored using a different management class other than the default, create the additional Archive copygroup for that management class using the syntax in step 1. It is recommended to define an archive copygroup for the default Mgmt Class even if you plan to use a different management class than the default, since this will be checked during the session initialization.

3) Validate and activate the policyset to enable the changes made in the previous steps.

      VALIDATE POLICYSET domain_name policyset_name

ACTIVATE POLICYSET domain_name policyset_name

On the Tivoli Storage Manager client where DB2 resides:

4) Update the database configuration in DB2 to save the log archive data using the Tivoli Storage Manager API interface. Log in as the instance owner (for Windows, also open a ‘db2cmd’ window) and update the db cfg for the databases in question:

      db2 update db cfg for

db_name

    using logarchmeth1 TSM

If you’re specifying a different management class than the default, include the Mgmt Class specification as follows:

      db2 update db cfg for

db_name

      using logarchmeth1 TSM:

mgmtclass_name
5) Restart DB2 to pick up the changes to the DB CFG.

Related information

Configuring DB2 and Tivoli Storage Manager in Unix / Li
Configuring DB2 and Tivoli Storage Manager in Windows

written by Bosse

May 07

Tivoli Storage Manager server upgrade from V6 to V7 fails with ANRI1043E

TSM 7.1 Comments Off on Tivoli Storage Manager server upgrade from V6 to V7 fails with ANRI1043E

Problem(Abstract)

A Tivoli Storage Manager server is upgraded from V6 to V7. The upgrade fails with the following error :
ANRI1043E: An error occurred while dropping the DB2 instances.

Symptom

The following errors are logged :


=====> IBM Installation Manager> Error

ERROR: Error during “install” phase:

Details:
ANRI1043E: An error occurred while dropping the DB2 instances. To review errors and correct any issues, review the log files in /var/ibm/InstallationManager/logs/native.

 

Cause

Orphaned DB2 instance causing the db2idrop command to fail during upgrade

 

Environment

Tivoli Storage Manager Server on Unix/Linux

Diagnosing the problem

1. Run the db2ilist command to verify the DB2 instances that are configured on the system. For example :

# /opt/tivoli/tsm/db2/instance/db2ilist

tsmi
tsmiold

In this case, it shows two instances, tsmi and tsmiold. The tsmiold instance is an instance that is no longer in use.

2. Run the db2greg command to verify the DB2 registry. For example :

/opt/tivoli/tsm/db2/bin/db2greg -dump show
V,DB2GPRF,DB2SYSTEM,xvotsmsrv01,/opt/tivoli/tsm/db2,
I,DB2,9.7.0.6,tsmi,/home/tsmi/sqllib,,1,0,/opt/tivoli/tsm/db2,,
V,DB2GPRF,DB2INSTDEF,tsmi,/opt/tivoli/tsm/db2,
I,DB2,9.7.0.4,tsmiold,/home/tsmiv/sqllib,,1,0,/opt/tivoli/tsm/db2,,
V,DB2GPRF,DB2FCMCOMM,TCPIP4,/opt/tivoli/tsm/db2,
S,DB2,9.7.0.6,/opt/tivoli/tsm/db2,,,6,0,,1359560348,0

Again, in this case, the registry shows references to the tsmi and tsmiold instances

3. Run the db2idrop command to remove the old instance (tsmiold). The command fails with the following error :

DBI1081E The file or directory /home/tsmiold/sqllib/bin is missing.

 

Resolving the problem

Remove the orphaned DB2 registry reference to the old instance (tsmiold) with the following command :


/opt/tivoli/tsm/db2/bin/db2greg -delinstrec instancename=tsmiold

Retry the upgrade once the orphaned instance is removed

written by Bosse

May 07

Server failed to start after upgrade SQL5035N

TSM 7.1 Comments Off on Server failed to start after upgrade SQL5035N

Problem(Abstract)

After a server upgrade, it fails to start with the follwing error:

SQL5035N The database must be upgraded to the current release.

Symptom

When trying to start the Tivoli Storage Manager server after an upgrade and you receive the following error:

ANR9999D_3831306406 ReportSQLDiagInfo(dbieval.c:1568) Thread (5): Missing sqlState=55001, sqlCode=-5035 from table. Returning rc = 9994. SQL5035N The database must be upgraded to the current release. SQLSTATE=55001

 

Cause

The database instance did not upgrade properly during the upgrade process.

 

Diagnosing the problem

Run the following DB2 commands as the Tivoli Storage Manager instance user (default: tsminst1):

db2start
db2 connect to tsmdb1

You will get:
SQL5035N The database must be upgraded to the current release.
SQLSTATE=55001

 

Resolving the problem

You will need to manually complete the upgrade of the database instance using the commands below:

db2start
db2 upgrade database TSMDB1
Note: The upgrade command will take time, depending on how big the database is. There will be no progress messages given. You can monitor the CPU/Memory usage to verify the process is running.

After the upgrade completes, try the DB2 connect commands again and it should be successful.
db2start
db2 connect to tsmdb1
Now you can start your Tivoli Storage Manager server.

written by Bosse

Apr 16

Troubleshooting Volume Shadow Copy (VSS) quiesce related issues

VE Comments Off on Troubleshooting Volume Shadow Copy (VSS) quiesce related issues

Details

•When quiescing a guest operating system using the Microsoft Volume Shadow Copy Service (VSS) prior to a snapshot, the operation fails.

•You see one of these errors:

Cannot create a quiesced snapshot because the snapshot operation exceeded the time limit for holding off I/O in the frozen virtual machine

An error occurred while quiescing the virtual machine. The error code was: 4 The error was: Quiesce aborted

•In the Event Viewer Application logs of the Windows Virtual Machine, you see errors similar to this:

◦Event ID 11
◦Event ID 12292
◦Event ID 12032
◦Event ID 12298

•The Event ID errors contain descriptions similar to this:

Volume Shadow Copy Service information: The COM Server with CLSID {} and name cannot be started. [].

Solution

Background Information

VMware products may require file systems within a guest operating system to be quiesced prior to a snapshot operation for the purposes of backup and data integrity.

VMware products which use quiesced snapshots include, but are not limited to, VMware Consolidated Backup and VMware Data Recovery.

As of ESX 3.5 Update 2, quiescing can be done by Microsoft Volume Shadow Copy Service (VSS), which is available in Windows Server 2003.

Operating systems which do not have VSS make use of the SYNC driver for quiescing operations. When VSS is invoked, all VSS providers must be running. If there is an issue with any third-party providers or the VSS service itself, the snapshot operation may fail.

 

Before verifying a VSS quiescing issue, ensure that you are able to create a manual non-quiesced snapshot using the vSphere Snapshot Manager. For more information see Troubleshooting issues when creating or committing snapshots in ESX/ESXi (1038963).

 

Troubleshooting Steps

Note: These steps may vary depending on the operating system.
  1. Ensure that you meet all of the prerequisites of VSS when quiescing guest operating systems:
    • Verify that you are running ESX 3.5.0 Update 2 or higher.
    • Verify that the latest version of VMware Tools is installed on the virtual machine. VSS components must be explicitly specified during the VMware Tools upgrade process. VSS is not installed in non-interactive mode. For more information, see Verifying a VMware Tools build version (1003947).
    • Ensure that you are using Windows Server 2003 or higher. Previous versions of Windows, such as Windows XP and Windows 2000, do not include VSS and rely on the SYNC driver.
  2. Ensure that all the appropriate services are running and the startup types are listed correctly:
    Note: With the exception of the VMware Snapshot Provider service, all services listed below are Microsoft services bundled with the operating system. If you are having difficulty starting these services, consult Microsoft support before proceeding with the troubleshooting steps.

    • During the installation of VMware Tools (this is required to install the VMware Snapshot Provider Service):
      • Ensure that the COM+ System Application service is listed as Started and that the startup type is listed as Manual.
      • Ensure that the COM+ Event System service is listed as Started and that the startup type is listed as Automatic.
    • While Idle:
      • Ensure that the COM+ System Application is listed as Started and that the startup type is listed as Manual.
      • Ensure that the COM+ Event System service is listed as Started and that the startup type is listed as Automatic.
      • Ensure that the Volume Shadow Copy service is not running and the startup type is listed as Manual.
      • The Microsoft Software Shadow Copy Provider service may or may not be started. Ensure that the startup type is listed as Manual.
      • Ensure that the VMware Snapshot Provider is not running and that the startup type is listed as Manual.
    • During the backup:
      • Ensure that the COM+ System Application is listed as Started and that the startup type is listed as Manual.
      • Ensure that the COM+ Event System service is listed as Started and that the startup type is listed as Automatic.
      • The Volume Shadow Copy service may or may not be started. Ensure that the startup type is listed as Manual.
      • Ensure that the Microsoft Software Shadow Copy Provider service startup type is listed as Manual.
      • Ensure that the VMware Snapshot Provider is listed as Started and that the startup type is listed as Manual.
      • Ensure that the Virtual Disk is listed as Started and that the startup type is listed as Manual.
  3. Make sure that you are using the Microsoft Software Shadow Copy provider:
    1. Click Start > Run.
    2. Type cmd and press Enter to open a command prompt.
      Note: You may need to run this as administrator.
    3. Check the VSS Providers with this command:
      C:\Users\Workstation> vssadmin list providers
      The output appears similar to this:
      Provider name: ‘Microsoft Software Shadow Copy provider 1.0’
      Provider type: System
      Provider Id: {b5946137-7b9f-4925-af80-51abd60b20d5}
      Version: 1.0.0.7

      Check the permissions on the VSS and on any third party VSS providers and ensure that the account is valid. For more information, see the Microsoft Knowledge Base article 259733.
      If you have a third-party provider, it may interfere with the quiescing operation. Try uninstalling any third-party VSS providers.
      Note: The vssadmin utility and VSS are bundled with the Microsoft operating system. If the vssadmin utility is reporting errors, this may indicate that you may have a pre-existing issue with the VSS. Consult Microsoft support before proceeding with the next troubleshooting steps.
  4. Ensure that all of the VSS writers are stable and that they are not reporting an error. Run this command:
    C:\Users\Workstation> vssadmin list writers
    The output for each writer appears similar to this:
    Writer name: ‘VSS Metadata Store Writer’
    Writer Id: {75dfb225-e2e4-4d39-9ac9-ffaff65ddf06}
    Writer Instance Id: {088e7a7d-09a8-4cc6-a609-ad90e75ddc93}
    State: [1] Stable
    Last error: No error

    Ensure that the State is Stable and that the last line of the output is Last error: No error.
  5. If the issue persists, perform these troubleshooting steps:
    1. Run NTBackup and see if there are VSS errors when NTBackup attempts to run. For more information, see the Windows NT Backup – Restore Utility page.
    2. Try reinstalling VMware Tools to re-register VSS.
    3. If you are having difficulty backing up information from specific applications such as Microsoft Exchange, Microsoft SQL, and Active Directory, ensure that all necessary VSS writers are also installed with these components.
    4. Engage Microsoft support to ensure that there are no known issues with VSS. Visit http://support.microsoft.com/ to see if there are any patches and updates for VSS.
    5. If errors such as Error: 0x8000FFFF or Event ID 12302 persist, see the Microsoft Knowledge Base article 940184.
    6. Ensure that the time is accurate in the guest operating system and validate that it is being synchronized via NTP or VMware Tools. Please see Timekeeping in VMware Virtual Machines for more information.

Notes:

  • In Windows 2000, XP, and 2003, you can reinstall VMware Tools in custom mode and choose not to install VSS. This results in the SYNC driver being used.
  • The Distributed Transaction Coordinator service must be running while installing VMware Tools. Otherwise, VSS fails to quiesce Windows 2008 R2.

written by Bosse