|
Re: Backup reporting: SUMMARY TABLE ISSUE IS FOUND
2002-09-20 10:47:15
The fix for this is at these levels (per apar doc):
Apply patch 4.2.2.5, 5.1.1.1 or higher, available through
Tivoli Web Page to resolve this problem, or fixing
PTF when available.
Here's a blerb from my etr/pmr (problem ticket):
The APAR you are referring to is IC34462. This issue is specific to
the summary table not being updated when client sessions are severed and
the session has to be re-established. This APAR is currently open, but
I have added you to the interested parties list for this APAR. There
was also another APAR (IC33455) which addressed an issue with the
summary table simply not being updated properly during client backups.
Here's the actual 2 apars...the doc on the problem/issue:
FYI Thanks Tim
APAR Identifier ...... IC34462 Last Changed..02/09/19
BYTES FIELD IN SUMMARY TABLE SHOWS VALUE 0 IF THE BACKUP SESSION
IS LOST AND THEN REOPENED AGAIN (I.E. MSG ANS1809E)
Symptom ...... IN INCORROUT Status ........... OPEN
Severity ................... 2 Date Closed .........
Component .......... 5698ISMSV Duplicate of ........
Reported Release ......... 51A Fixed Release ............
Component Name TSM SERVER 510 Special Notice
Current Target Date .. Flags
SCP ................... AIXRSC
Platform ............ AIX
Status Detail: Not Available
PE PTF List:
PTF List:
Parent APAR:
Child APAR list:
ERROR DESCRIPTION:
When a backup session is lost and then reopened again
successfully (e.g. MSG ANS1809E can be seen in the
dsmsched.log), not all values in the SUMMARY TABLE of the TSM
server will show the correct backup statistics. The BYTES field
shows in that case a value of 0, while e.g the fields EXAMINED
and AFFECTED show correct values.
.
Example:
========
1.) select * from summary where activity='BACKUP':
START_TIME: 2002-08-28 19:32:06.000000
END_TIME: 2002-08-28 19:54:17.000000
ACTIVITY: BACKUP
NUMBER: 366
ENTITY: LWLSAP2
COMMMETH: Tcp/Ip
ADDRESS: 172.20.13.42:33133
SCHEDULE_NAME: MO-FR-1800
EXAMINED: 71137
AFFECTED: 251
FAILED: 0
BYTES: 0 <= |
IDLE: 0
MEDIAW: 0
PROCESSES: 1
SUCCESSFUL: YES
VOLUME_NAME:
DRIVE_NAME:
LIBRARY_NAME:
LAST_USE:
.
2.) dsmsched.log:
08/28/02 18:01:25 Scheduler has been started by Dsmcad.
08/28/02 18:01:25 Querying server for next scheduled event.
08/28/02 18:01:25 Node Name: LWLSAP2
...
08/28/02 18:59:19 ANS1898I ***** Processed 66,000 files
*****
08/28/02 19:31:50 Normal File--> 2,048,008,192
/oracle/09p2/daten6/TBS_APOLLO4_IMG_TBS_2.ora Sent
08/28/02 19:31:50 ANS1809E Session is lost; initializing
session reopen procedure.
08/28/02 19:32:06 ... successful
08/28/02 19:32:09 ANS1898I ***** Processed 66,500 files
*****
...
08/28/02 19:54:16 Total number of objects inspected: 71,137
08/28/02 19:54:16 Total number of objects backed up: 251
08/28/02 19:54:16 Total number of objects updated: 0
08/28/02 19:54:16 Total number of objects rebound: 0
08/28/02 19:54:16 Total number of objects deleted: 0
08/28/02 19:54:16 Total number of objects expired: 63
08/28/02 19:54:16 Total number of objects failed: 0
08/28/02 19:54:16 Total number of bytes transferred: 6.46 GB
08/28/02 19:54:16 Data transfer time: 1,868.07 sec
08/28/02 19:54:16 Network data transfer rate: 3,629.75 KB/sec
08/28/02 19:54:16 Aggregate data transfer rate:1,001.56 KB/sec
08/28/02 19:54:16 Objects compressed by: 19%
08/28/02 19:54:16 Elapsed processing time: 01:52:50
################################################################
It seems that when a session is lost and then reopened again,
the new session descriptor does not hold the value for the bytes
transfered so far anymore.
.
This problem was seen on a TSM AIX and NT 5.1.1.4 server, but
maybe all TSM server levels will be affected which inlcude the
fix for APAR IC33455.
.
Recreation:
Unplug the network cable during a backup session => session lost
Plug the network cable in again => backup session restarts
Then check the SUMMARY TABLE for the BYTES field
LOCAL FIX:
Do not believe the values reported in the SUMMARY TABLE. Check
the DSMSCHED.LOG or the ACTLOG for the correct backup
statistics.
APAR Identifier ...... IC33455 Last Changed..02/07/19
SUMMARY TABLE NOT BEING FULLY UPDATED
Symptom ...... IN INCORROUT Status ........... CLOSED PER
Severity ................... 2 Date Closed ......... 02/06/07
Component .......... 5698TSMAX Duplicate of ........
Reported Release ......... 420 Fixed Release ............ 999
Component Name TSM AIX SERVER Special Notice
Current Target Date .. Flags
SCP ................... AIXRSC
Platform ............ AIX
Status Detail: Not Available
PE PTF List:
PTF List:
Release 420 : PTF not available yet
Parent APAR:
Child APAR list: PQ62875 IC34044 IC34045 IC34046 PQ62876 IC34047
ERROR DESCRIPTION:
Found on TSM Version 4.2.2.0
Other Versions Affected TSM Server V5.1
OSs Effected All (recreated on WIN, AIX, Solaris)
Happens with all TSM Client levels (tested 4.x thru 5.1 clients
Impact: medium
When backing up to a V4.2..2.0 or V5.1.0 TSM server the
summary table is not being updated to show the correct amount
of bytes received. In the older versions of the server the
bytes would display the amount of data received,however with
versions 5.1.0 and 4.2.2.0 the bytes received is
reflecting 0 bytes. This is a problem for customers that
verify backups with scripts querying the SUMMARY table:
..
"select * from SUMMARY where ACTIVITY = 'BACKUP' "
..
Examples:
Server Version 4, Release 2, Level 1.11
Total number of bytes transferred: 8.55 MB
tsm: SOCRATES>select * from SUMMARY where ACTIVITY = 'BACKUP'
START_TIME: 2002-04-29 14:42:49.000000
END_TIME: 2002-04-29 14:44:06.000000
ACTIVITY: BACKUP
NUMBER: 3
ENTITY: CHIPSHOT
COMMMETH: Tcp/Ip
SCHEDULE_NAME:
EXAMINED: 54
AFFECTED: 54
FAILED: 0
BYTES: 0
IDLE: 76
MEDIAW: 0
PROCESSES: 1
SUCCESSFUL: YES
VOLUME_NAME:
DRIVE_NAME:
LIBRARY_NAME:
LAST_USE:
Server Version 4, Release 2, Level 2.0
Total number of bytes transferred: 6.73 MB
tsm: DUMPTRUCK>select * from SUMMARY where ACTIVITY='BACKUP'
*** Older Backup when TSM server was at V4.2.1.0 **
START_TIME: 2002-04-15 15:18:57.000000
END_TIME: 2002-04-15 15:20:55.000000
ACTIVITY: BACKUP
NUMBER: 5
ENTITY: COSMO
COMMMETH: Tcp/Ip
SCHEDULE_NAME:
EXAMINED: 459
AFFECTED: 459
FAILED: 0
BYTES: 10195527
IDLE: 0
MEDIAW: 0
PROCESSES: 1
SUCCESSFUL: YES
VOLUME_NAME:
DRIVE_NAME:
LIBRARY_NAME:
LAST_USE:
*********After Upgrade to V4.2.2***************
START_TIME: 2002-04-29 14:59:42.000000
END_TIME: 2002-04-29 15:03:25.000000
ACTIVITY: BACKUP
NUMBER: 2
ENTITY: CHIPSHOT
COMMMETH: Tcp/Ip
SCHEDULE_NAME:
EXAMINED: 74
AFFECTED: 74
FAILED: 0
BYTES: 0
IDLE: 222
MEDIAW: 0
PROCESSES: 1
SUCCESSFUL: YES
VOLUME_NAME:
DRIVE_NAME:
LIBRARY_NAME:
LAST_USE:
LOCAL FIX:
Keywords: ADAS_BYTES_AFFECTED multi-threaded client
This also effects statistics of "ARCHIVE"
sessions.
.
Apply patch 4.2.2.5, 5.1.1.1 or higher, available through
Tivoli Web Page to resolve this problem, or fixing
PTF when available.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: All Platforms of TSM Server version 4.2.2.X *
* All Platforms of TSM Server version 5.1.0.X *
* All Platforms of TSM Server version 5.1.1.0 *
****************************************************************
* PROBLEM DESCRIPTION: When backing up to a V4.2.2.0 or *
* V5.1.0 TSM server the *
* summary table is not being updated to *
* show the correct amount *
* of bytes received. *
****************************************************************
* RECOMMENDATION: Apply fixing PTF or Patch. *
****************************************************************
This is a problem for customers that
verify backups with scripts querying
the SUMMARY table:
..
"select * from SUMMARY where ACTIVITY
= 'BACKUP' "
PROBLEM CONCLUSION:
Server has been modified. Summary table is not being updated
to show the correct amount of bytes received.
TEMPORARY FIX:
COMMENTS:
MODULES/MACROS: NONE
SRLS: NONE
RTN CODES:
CIRCUMVENTION:
MESSAGE TO SUBMITTER:
|
|
|
