backup stgpool broken

[purdon]

Hi,

Please examine the two sessions below and weep. The stgpool ctc0147_2 is being backed up to stgpool whs2418_1 with a process count higher than 1 and now two processes are after the same volume CE00IQ. This sort of defeats the reason for having ,ultiple processes in the first place....


tsm: CTCTSM001>select * from processes where status like '%CE00IQ%'

PROCESS_NUM: 1686
PROCESS: Backup Storage Pool
START_TIME: 2007-11-02 11:56:55.000000
FILES_PROCESSED: 17648
BYTES_PROCESSED: 30297437605
STATUS: Primary Pool CTC0147_2, Copy Pool WHS2418_1, Files Backed Up:
17648, Bytes Backed Up: 30,297,437,605, Unreadable Files: 0,
Unreadable Bytes: 0. Current Physical File (bytes):
454,868,724 Waiting for access to input volume CE00IQ (771
seconds). Current output volume: WZ0201L3.

PROCESS_NUM: 1690
PROCESS: Backup Storage Pool
START_TIME: 2007-11-02 11:56:56.000000
FILES_PROCESSED: 6610
BYTES_PROCESSED: 21078436579
STATUS: Primary Pool CTC0147_2, Copy Pool WHS2418_1, Files Backed Up:
6610, Bytes Backed Up: 21,078,436,579, Unreadable Files: 0,
Unreadable Bytes: 0. Current Physical File (bytes):
14,765,481,581 Current input volume: CE00IQ. Current output
volume: WZ0386L3.

 

[BBB]

Might be that one of the processes is in particular backing up CE00IQ, and the other process is backing up a different tape XXX, but just needs to grab the 2nd half of a file stored on CE00IQ, triggered by backing up the first half of the file on vol XXX? (ie. files that span volumes).

Just a guess though.

 

[JohanW]

I don't see the problem. Process 1690 has the tape, will do its thing, and will surrender the tape to process 1686 later. They are not necessarily after the same file on tape.

Am I missing something?

 

[BBB]

No there is no problem. I didn't say they are after the same file on the tape by the way.

I think purdon just thought it was wierd they were both after the same tape. It doesn't usually happen this way so the above was one possible explanation.

 

[markul]

How about collocation settings?
Maybe you have no collocation on primary pool and collocation=node or group (default) on copy stg? It would justify that backing up stg is copying files from one tape to a two different copy volumes.

Regards,
Markul

 

[spiffy]

Man i am glad i am not the only one that sees this issue too, i do not have collocation set up, and i see this quite frequently, where 1 backup storage pool process is running and the second process is running, but in a waiting for access to media xxx mode.
I have seen one of the processes sit and wait for more than an hour to get access to the tape, it only gets it after the other BSP process is done with it....

do you think IBM will address this? if the BSP sees the tape is in use, to just skip it and load another tape? it does cause the BSP to run extra long when this happens..