DB2 backup always requesting scratch tape volume

[Harold]

Hi friends,

I have one question: I am backing up a db2 database directly through the TSM API, but always that the backup session begins, I can see on the tsm console the following message:

ANR1405W Scratch volume mount request denied - no scratch volume available.

I have no scratch volumes in the library. and this message appears even though there is plenty of space on other volumes in the library, and those are in a READWRITE state. Can be modified this behavior of always trying to mount a new scratch volume rather than using up a volume with some data on it?

Thanks.

 

[marclant]

It's like that by design. Database backups always go to a scratch tape, you cannot write it on an existing data tape. There's a couple of reasons for that. First, the type of data is not the same, a storage pool volume is of type DATA, while a database backup is of type DBBACKUP. It's not possible to mix the two types. The second reason is that database backup tapes are normally sent offsite, so in the event that you need to restore the DB, it's clear from the volume history which tapes are database backups.

You can do a move data of one or many of the filling tapes to get some scratch tapes. Also run reclamation more aggressively (lower threshold), but you will need at least one scratch tape to run reclamation.

 

[Harold]

Thanks for your reply. I was talking about backing up any DB2 database in general, not the TSM DB backup itself. I think the same situation does not apply, because the backup after trying to mount a scratch volume without success finally sends data to another tape that is in a READWRITE state, my question is if this behavior of always requesting the scratch volume first can be overriden.

 

[marclant]

Sorry, I wrongfully assumed you were talking about the TSM DB, disregard my previous post.

From the documentation:

When storing client files in a sequential-access storage pool where collocation is disabled, the server selects a volume using the following selection order:

1. A previously used sequential volume with available space (a volume with the most amount of data is selected first)
2. An empty volume

When the server needs to continue to store data on a second volume, it attempts to select an empty volume. If none exists, the server attempts to select any remaining available volume in the storage pool.

source: http://www-01.ibm.com/support/knowl...m.itsm.srv.doc/c_colloc_disabled.html?lang=en

Is that what you are seeing?