oracle -- separate storage pool ?

td3201

ADSM.ORG Member
Joined
May 24, 2007
Messages
28
Reaction score
0
Points
0
I am new to TSM. I inherited a 5.3 TSM with an Oracle DB. I have a primary tape pool called LTOPOOL1 where all the 'other backups' go and another called ORACLE_TAPE where the oracle rman backups go. Is there any reason to have a separate storage pool like this? They have different management classes and policy domains and such, but why cant they all be stored in teh same volumes? They end up in the same copy pool anyways.
 
There's no crushing reason why you should go either way, but what you have is reasonably common practice. It can be advantageous in that your tape utilization can be improved, and the amount of reclamation reduced. It may also improve restore times, depending on your environment.

Generally by storing big DB backups in your oracle_tape pool, almost all of these will expire after a certain period and the tape will rapidly drop to a low utilization to be reclaimed ... and the reclamation will be reasonably fast because there's not many small files to skip over which is the slowest part of reclamation.

Whereas the tapes in your other pool will probably have lots of small files that are still active - these will have to be read and moved by reclamation, and all the expired small files on the tape skipped over. These tapes probably won't have to be reclaimed as often under your current system because they don't have big DB backups filling them up and then expiring quickly afterwards.
 
There's no crushing reason why you should go either way, but what you have is reasonably common practice. It can be advantageous in that your tape utilization can be improved, and the amount of reclamation reduced. It may also improve restore times, depending on your environment.

Generally by storing big DB backups in your oracle_tape pool, almost all of these will expire after a certain period and the tape will rapidly drop to a low utilization to be reclaimed ... and the reclamation will be reasonably fast because there's not many small files to skip over which is the slowest part of reclamation.

Whereas the tapes in your other pool will probably have lots of small files that are still active - these will have to be read and moved by reclamation, and all the expired small files on the tape skipped over. These tapes probably won't have to be reclaimed as often under your current system because they don't have big DB backups filling them up and then expiring quickly afterwards.


That's the reason why we've also got oracle seperated from the rest. :)
 
Should I have a separate copypool for the oracle_tape primary pool too or can I simply use an existing copypool? I can't think of any harm in having another copypool for oracle_tape.
 
If you can afford it, it may reduce reclamation for the same reasons as above, but on the other hand as its an offsite pool it may actually increase reclamation, I'm not sure .. you could try it and see. Note you may send more tapes offsite each day though - at least one tape for each of the 2 copypools plus your db backup.

One of my servers has a separate copypool for each of about 5 primary pools, and it works very nicely. Although we have one of those nice situations where the copypools are "online" in a san attached library that is offsite. If it wasn't for this, we'd be sending at least 5 copypool tapes offsite per day.
 
We have seperate prim., sec. and copypools for all platforms......
 
I am reviewing our entire TSM environment, not only for my benefit since I am new to TSM, but also because everything else I have ran into with this company has been poor practice, etc. We have a diskpool that migrates to an Ltopool for our filesystem backups. It also writes to a copypool for offsite. Our Oracle backups, utilizing RMAN/TDP, write out to a separate disk via NFS as operation #1, then to TSM as operation #2. Operation #2 writes to ORACLE_TAPE, which is a primary pool, but thats it. No copypool, no diskpool first, etc.

1) Any benefit to writing to diskpool first, then migrating to ORACLE_TAPE similar to our filesystem backups?
2) Can the above be done in conjunction with the other backups utilizing the diskpool at the same time?
3) Why in the world would they not utlize the copypool for offsite stuff for Oracle? I am about to set copypool as the copy pool, but wanted to check here first. :)

Thanks again!
 
1) Diskpool would be way faster
2) Diskpools are sequential access
If you want to do it this way, you would create a diskpool specifically for Oracle so it can migrate to ORACLE_TAPE
3) Maybe it didn't occur to them at the time - hehe :)
 
Thanks for the reply. Our current situation won't allow for another diskpool I will just keep it going directly to tape but will have it copy to the copypool for offsite rotation love. :)
 
keep in mind that when you go to tape, you will certainly experience speed issues as well as possible contention for tape drives.
 
Back
Top