11:25
Archive log files are not deleted after Tivoli Storage Manager server Version 7.1.1 database backup.
Content
Releases Affected:
Tivoli Storage Manager Version 7.1.1 for all platforms.
Required Conditions:
Archive logs will not be deleted if an incremental database backup was run or if a full backup was run and did not complete until after midnight local Tivoli Storage Manager server time. This issue is related to APAR IT02910.
Problem Resolution:
Apply the fixing level when available. This problem is currently projected to be fixed in Tivoli Storage Manager server levels 7.1.1.1, and 7.1.2 and later for all server platforms. Note that this is subject to change at the discretion of IBM.
Circumvention:
Do not perform incremental Tivoli Storage Manager server database backups. Ensure that full backup processing completes before midnight local server time. For example, if a full backup begins at 11 PM and ends at 1 AM, this issue will occur. If a full backup starts at 11 AM and ends at 1 PM on the same day, this issue will not occur.
Manually delete orphaned archive log files as follows:
Listing the directory might show a gap in the log sequence numbers as well as a date disparity.
For example, a listing of the Archive log directory might show something similar to the following output:
# ls -l /mttsm23/archlog/archmeth1/mttsm23/TSMDB1/NODE0000/C0000000
total 181552736
-rw-r----- 1 mttsm23 tsmadmin 536879104 May 17 16:49 S0000815.LOG
-rw-r----- 1 mttsm23 tsmadmin 536879104 May 17 17:03 S0000816.LOG
-rw-r----- 1 mttsm23 tsmadmin 536879104 May 17 17:04 S0000817.LOG
(snipped more than 100 lines for brevity)
-rw-r----- 1 mttsm23 tsmadmin 536879104 May 18 01:32 S0000985.LOG
-rw-r----- 1 mttsm23 tsmadmin 536879104 May 18 11:12 S0000986.LOG
-rw-r----- 1 mttsm23 tsmadmin 536879104 May 24 05:41 S0001258.LOG
-rw-r----- 1 mttsm23 tsmadmin 74915840 May 24 08:55 S0001259.LOG
root@aratsminp04 [/home_local/root]
In this example, logs S0000815.LOG through S0000986.LOG have a date of 5/17-18 and logs S0001258.LOG through the end have a date of 5/24.
To determine whether the earlier logs are orphaned, you can find the "First active log file" from DB2. Logs before the "First active log file" are not needed. In the following example, the command was issued a day later. Therefore, the log sequence number is greater than if the command was issued immediately after the directory listing in the previous example. Each subsequent day you can expect this log sequence number to increment while the older "orphaned" logs would remain the same.
# db2 connect to tsmdb1
Database Connection Information
Database server = DB2/AIX64 9.7.5
SQL authorization ID = MDTSM23
Local database alias = TSMDB1
mdtsm@mjdtsminp02 [/mdtsm23/config]
# db2 get db cfg | grep -i "first active log file"
First active log file = S0001349.LOG
mdtsm@mjdtsminp02 [/mttsm23/config]
To resolve this issue, temporarily move or copy the orphaned archive logs (for example, S0000815.LOG through S0000986.LOG)to a temporary location outside the archive log directory. After the next successful full Tivoli Storage Manager server database backup, delete the orphaned logs that you placed in the temporary location.
Content
Releases Affected:
Tivoli Storage Manager Version 7.1.1 for all platforms.
Required Conditions:
Archive logs will not be deleted if an incremental database backup was run or if a full backup was run and did not complete until after midnight local Tivoli Storage Manager server time. This issue is related to APAR IT02910.
Problem Resolution:
Apply the fixing level when available. This problem is currently projected to be fixed in Tivoli Storage Manager server levels 7.1.1.1, and 7.1.2 and later for all server platforms. Note that this is subject to change at the discretion of IBM.
Circumvention:
Do not perform incremental Tivoli Storage Manager server database backups. Ensure that full backup processing completes before midnight local server time. For example, if a full backup begins at 11 PM and ends at 1 AM, this issue will occur. If a full backup starts at 11 AM and ends at 1 PM on the same day, this issue will not occur.
Manually delete orphaned archive log files as follows:
Listing the directory might show a gap in the log sequence numbers as well as a date disparity.
For example, a listing of the Archive log directory might show something similar to the following output:
# ls -l /mttsm23/archlog/archmeth1/mttsm23/TSMDB1/NODE0000/C0000000
total 181552736
-rw-r----- 1 mttsm23 tsmadmin 536879104 May 17 16:49 S0000815.LOG
-rw-r----- 1 mttsm23 tsmadmin 536879104 May 17 17:03 S0000816.LOG
-rw-r----- 1 mttsm23 tsmadmin 536879104 May 17 17:04 S0000817.LOG
(snipped more than 100 lines for brevity)
-rw-r----- 1 mttsm23 tsmadmin 536879104 May 18 01:32 S0000985.LOG
-rw-r----- 1 mttsm23 tsmadmin 536879104 May 18 11:12 S0000986.LOG
-rw-r----- 1 mttsm23 tsmadmin 536879104 May 24 05:41 S0001258.LOG
-rw-r----- 1 mttsm23 tsmadmin 74915840 May 24 08:55 S0001259.LOG
root@aratsminp04 [/home_local/root]
In this example, logs S0000815.LOG through S0000986.LOG have a date of 5/17-18 and logs S0001258.LOG through the end have a date of 5/24.
To determine whether the earlier logs are orphaned, you can find the "First active log file" from DB2. Logs before the "First active log file" are not needed. In the following example, the command was issued a day later. Therefore, the log sequence number is greater than if the command was issued immediately after the directory listing in the previous example. Each subsequent day you can expect this log sequence number to increment while the older "orphaned" logs would remain the same.
# db2 connect to tsmdb1
Database Connection Information
Database server = DB2/AIX64 9.7.5
SQL authorization ID = MDTSM23
Local database alias = TSMDB1
mdtsm@mjdtsminp02 [/mdtsm23/config]
# db2 get db cfg | grep -i "first active log file"
First active log file = S0001349.LOG
mdtsm@mjdtsminp02 [/mttsm23/config]
To resolve this issue, temporarily move or copy the orphaned archive logs (for example, S0000815.LOG through S0000986.LOG)to a temporary location outside the archive log directory. After the next successful full Tivoli Storage Manager server database backup, delete the orphaned logs that you placed in the temporary location.
No comments
Post a Comment