Issue 1:
The Tivoli Storage Manager V6.1 server might run out of space in the active log when one or more transactions are open for a long period of time. The server shuts down because all available active log space is exhausted.
The Tivoli Storage Manager V6.1 server might run out of space in the active log when one or more transactions are open for a long period of time. The server shuts down because all available active log space is exhausted.
Solution
There are two possible solutions for this issue:
Solution #1: Increase the active log size to allow for enough log space to handle transactions that are open for a long period of time in conjunction with table reorganization activities that drive the active log use as a consequence of the reorganization operation.
Solution #2: An undocumented server option is available that disables the server from performing automatic table reorganization. To disable automatic table reorganization, add the following line to the server options file and then restart the server:
ALLOWREORGTABLE NO
Also Read: Take TSM DB backup immediately if you notice these messages
Issue 2:
When using certain IBM Tivoli Storage Manager (TSM) Windows and NetWare backup-archive client versions, scheduled operations might not run if the Client Acceptor Daemon (CAD) manages the schedule in prompted mode. The TSM server QUERY EVENT command will show that the scheduled events are missed.
Issue 2:
When using certain IBM Tivoli Storage Manager (TSM) Windows and NetWare backup-archive client versions, scheduled operations might not run if the Client Acceptor Daemon (CAD) manages the schedule in prompted mode. The TSM server QUERY EVENT command will show that the scheduled events are missed.
Content
Schedule client operations can be missed if all of the required conditions below are met. The client schedule log and client error log will have no messages, but the TSM server QUERY EVENT command will show that the schedule was missed.
REQUIRED CONDITIONS:
All of the following conditions are required:
Version 6.1' 6.1.0.2 or 6.1.0.3
Version 5.5, 5.5.2.2, 5.5.2.3, 5.5.2.4 or 5.5.2.5
Version 5.4, 5.4.3.0, 5.4.3.1 or 5.4.3.2
Note: the NetWare client included in V6.1 is at the V5.5-functional level
Note: the NetWare client included in V6.1 is at the V5.5-functional level
2. The Client Acceptor Daemon (CAD) manages the client schedules. The default scheduler is traditional scheduling for Windows and NetWare. The CAD manages the schedule only when the MANAGEDSERVICES option is defined with a value of SCHEDULE.
3. The NODENAME option is not specified in the client options file
4. The SCHEDMODE option is set to a value of PROMPTED. Note that the default value for SCHEDMODE is POLLING.
Implement any one of the following to prevent the problem:
- Define the NODENAME option in the client options file. This will prevent the issue, even if the value for NODENAME is defined as the default value of the hostname or clustername.
- Set the SCHEDMODE option to POLLING
- Ensure the MANAGEDSERVICES option does not have a value of SCHEDULE
Issue 3:
Tivoli Storage Manager version 6.1 servers that have deduplicated storage pools might encounter data corruption, and possible data loss, if the data is moved using the MOVE DATA or MOVE NODEDATA commands with the RECONSTRUCT parameter explicitly set to NO. Data corruption might occur if these commands are used to move data to another storage pool, however data loss might occur if the data being moved was not previously backed up to a copy storage pool.
Tivoli Storage Manager version 6.1 servers that have deduplicated storage pools might encounter data corruption, and possible data loss, if the data is moved using the MOVE DATA or MOVE NODEDATA commands with the RECONSTRUCT parameter explicitly set to NO. Data corruption might occur if these commands are used to move data to another storage pool, however data loss might occur if the data being moved was not previously backed up to a copy storage pool.
PROBLEM RESOLUTION:
When the 6.1.2.1 patch is applied, the Tivoli Storage Manager V6.1 server will reconstruct deduplicated data regardless of whether or not the RECONSTRUCT parameter is set to NO for the MOVE DATA and MOVE NODEDATA commands.
Solution:
Do not move data from a deduplicated storage pool with the MOVE DATA or MOVE NODEDATA commands with the RECONSTRUCT parameter set to NO. Additionally, ensure that all data is backed up to a copy storage pool before reclamation processes the data stored in a deduplicated storage pool.
0 Comment to "Problem and Solutions for commonly seen TSM Server DB related issues"
Post a Comment