Need a little clarification here....
Are your clients backups going to a disk pool first or directly to
SQL_TAPEPOOL?
Is SQL_TAPEPOOL your primary tape pool, or a copy pool?
The "normal" sequence of events if you're backing up to disk is something
like this:
- Clients backup to the disk pool throughout the day.
- Sometime later, you do a "backup stgpool" to backup the disk pool to the
tape COPY pool.
- Then you do a migration of the disk pool to the tape PRIMARY pool
(SQL_TAPEPOOL in your case?) (this could also happen throughout the day
based on threshold value)
- Then you do "backup stgpool" of the tape PRIMARY pool to the tape COPY
pool.
- Then you send the copy pool volumes offsite.
If your problem is occurring during the migration, check the DISK pool
definition and see if "migration processes" is set greater than 1. If so,
TSM will need that many tapes to write to.
Robin Sharpe
Berlex Labs
|---------+--------------------------->
| | ML_SPAM |
| | <spam.admin@AVIV|
| | A.COM> |
| | Sent by: "ADSM: |
| | Dist Stor |
| | Manager" |
| | <[email protected]|
| | T.EDU> |
| | |
| | |
| | 08/03/2005 07:09|
| | AM |
| | Please respond |
| | to "ADSM: Dist |
| | Stor Manager" |
| | |
|---------+--------------------------->
>----------------------------------------------------------------------------------------------------------------------|
|
|
|
|
|To: ADSM-L AT VM.MARIST DOT EDU
|
|cc:
|
|Subject:
|
| More tapes used than necessary
|
>----------------------------------------------------------------------------------------------------------------------|
Hi *SMers,
TSM 5.2.1 server
W2K sp4
3583 L72
I can't get my head around why this is happening...
A number of SQL clients back up to the SQL_TAPEPOOL, with collocation
turned off. However, we are only storing 68 MB from all the sql clients
so I would expect all that data to fit on one tape, which it does. But for
some reason TSM wants to pick up two scratch volumes everyday to backup
the SQL diskpool to - not the already defined volume.
Eachmorning I find myself performing a 'move data' on the two newly
defined vols just to move the data back to the slowly accumilating volume.
One thing that occured to me was that the volume had about 37% reclaimable
space - and if the files which had expired were at the end of the volume,
would TSM be able to locate the correct position to start writing from?
That's the only reason I can think why this is happening. Can any one else
shine a bit of light on this problem?
Many Thanks,
Matthew
Aviva plc
Registered Office: St. Helen's, 1 Undershaft, London EC3P 3DQ
Registered in England Number 02468686
www.aviva.com
This message and any attachments are confidential.
If you are not the intended recipient, please telephone
or e-mail the sender and delete this message and any
attachment from your system. Also, if you are not the
intended recipient you must not copy this message or
attachment or disclose the contents to any other person.
|
