Trying to understand the Consistency of a TSM DBB

[StuartMcCall]

Hi.
I was wondering if any more experienced TSMers' could answer a question on the "consistency" of a TSM Full Database Backup?
My question - I suppose - boils down to "What TSM Server activity is recorded and stored in a TSM DBB whilst it's running?"
I know this seems a bit simplistic - but I have a real-world problem which I feel may be explained by asking the question above.
I’ll explain my problem - and perhaps give some context.
We run a TSM Server (AIX V6, TSM V6.2) with a reasonable number of clients - but of particular concern are our Oracle (TDP) clients.
We also have a similar AIX based TSM server (V6.2) for backups of our remote systems and occasional Oracle Restores.
It's our Oracle restores (known as "Refreshes" internally.) which create some issues.
We run TDPO backups of our Primary DB's and when we have a need to “refresh” our DR copy we do the following:-
1. Identify all the TSM Volumes used by the TDP specific node for the relevant time-frame
2. Check these volumes out of the TSM Library (IBM 3584 – LTO3 Media)
3. Run a TSM DBB to LTO3 tape.
4. Ship the tapes to the Offsite TSM system and associated Library.
5. Restore the DBB at the remote site into a pre-prepared TSM Instance for this purpose.
6. Let the DBA’s loose with their RMAN/BRARCHIVE restore scripts.
7. Job done.
However, we’ve come across some discrepancies during a few recent attempts at the restore process . In some cases – when the DBA starts an RMAN restore – the selected Oracle control-file or Archive log is sometimes actually found to be on a TSM volume which hadn’t actually been used when the other Volumes were checked out.
This “missing” volume can be found in the original TSM Server Library.
We are therefore wondering if the TSM Database backup is still recording “normal” TSM server activity during subsequent TDPO Client backups – hence the question at the beginning of my post.

Any insight or suggestions would be welcomed.

Stuart.

 

[moon-buddy]

Simple answer to your dilemma - timing!!

I have seen this - so to say been there done that! You have to be certain of your RTO - Recovery Time Objective - and for which determines how you sync data. In other words, be very precise with your cut-off times.

 

[StuartMcCall]

Hi Moon-Buddy, Thanks for the quick reply.

It's an issue we've come across more lately - especially since our DBB backups are now taking longer with V6 - we used to be able to get one done in 25 minutes - now it can be up to twice the time.

With regards to the specific question - Is it fair to say that the DBB reflects all activity on the TSM server up to it's completion time? Looking at the times reported from both "query drmedia" and "query volhist type=dbb" - it now seems clear that it's the end time which is recorded - so I suppose it would make sense that the activity on the server would be captured to that point.

I will have to think about how I can modify the normal behaviour of our Oracle Archive Log backups - and maybe get them suspended before and after a DBB/Checkout for an Oracle restore offsite.

 

[moon-buddy]

The TSM DB is truly just meta data - and yes, you should have a complete DB backup that you will need to restore to your 'other' site.

The simple sequence should be like this:

1. defined cut-off time: EX: 0800H

This means that all Oracle DB - FULL and LOGARC have been 'backed' up: Primary pools have been copied to offsite pools

2. Full DB backup starts and completes

3. Checkout DB and Oracle Offsite backup tapes

4. Restore to DR site - using DB backup and Offsite tapes

You should be in-sync as of 0800H.

Addendum:

The cut-off time should be - more or less - reflect the last FULL DB backup FOR ALL databases if you want the RTO to be exact. If you have FULL backups for some DB happening, say at 0500H, earlier than others, then your RTO is really the FULL backup at 0500H and NOT the full backup at 0800H.