-
Datafile block changes during hot backups and TSM
Here's my problem with traditional hot backups (NOT RMAN) on a certain database. Was just wondering if anyone out there has faced a similar situation..and how they went about addressing it.
I've got a reasonably active database..and it checkpoints often as well. There's a tablespace(called 'JUNK') with say 5 datafiles of 2G each. I issue an "alter tablespace begin backup JUNK". Then start 'copying' the files to tape using TSM (Tivoli Storage manager). Since Oracle continues to write data blocks to files in a backup mode (without updating the file headers obviously), it causes the timestamps of the underlying datafiles to change when there is activity on this tablespace (and when a checkpoint is issued).
TSM is pretty fussy about timestamps. Copying a 2G file to tape takes about 2 minutes. And if the timestamp of a datafile changes during the copy, it will fail and start all over again. It ends up retrying this process 3 times by default. This causes the backup to typically run a lot longer than it really ought to..Also, there are times when the backup fails altogether.
1) Yes, I can copy the datafile to an intermediate "temporary" directory..and then copy the datafile from the temp dir to tape. But restores with such a process will be chaotic.
2) I know I ought to use RMAN. That's WIP.
3) No, I can't recommend any additional hardware purchases.
-
Just configure TSM to ignore changes and copy the file as it is. Don't waste your time teaching it how hot backup works.
An ounce of action is worth a ton of theory.
—Friedrich Engels
-
It's not as easy as that. We use TSM to backup lots of stuff across many different nodes/servers. Asking TSM to "ignore" a timestamp is a "global" change and will affect the way everything else in the environment is backed up. For example, there is no point backing up an archivelog file that is still being written to..
-
OK, then, please describe how you want to ignore certain files where the timestamp changes and include others.
Jeff Hunter
-
Huh..what?!
I simply asked if someone had faced a certain problem..and if they did, what was the solution?
-
Ok, then. If ignoring timestamps on TSM isn't good for you, try backing up to a staging area instead of tape directly. Then, submit another job copying from staging to tape after hot backup finishes.
It'll take more time and resources to backup, but depending on the size of your backup it may be feasible.
An ounce of action is worth a ton of theory.
—Friedrich Engels
-
The "Staging area" idea, has already been addressed in the original post.
"1) Yes, I can copy the datafile to an intermediate "temporary" directory..and then copy the datafile from the temp dir to tape. But restores with such a process will be chaotic."
-
Originally posted by Axr2
It's not as easy as that. We use TSM to backup lots of stuff across many different nodes/servers. Asking TSM to "ignore" a timestamp is a "global" change and will affect the way everything else in the environment is backed up. For example, there is no point backing up an archivelog file that is still being written to..
Not sure what version you are running on, but you can configure TSM to have multiple Policies/management classes. We had to do that even for our RMAN backups to TDP because the Unix level backups didn't meet our needs. Talk to your TSM admin, he/she should be able to help you set your policy for Oracle backups. You then set up the node you use for that policy. (I'm assuming you have a separate node set up for your Oracle backups, separate from your OS level backups... if not, you should)
Hope that helps!
Jodie
-
Jodie,
Thanks. Yes, we do use multiple policies and management classes. However, there doesn't appear to be a way to tell TSM to "ignore" timestamp or block changes (globally or otherwise).
I was infact wrong about the below sentence - "Asking TSM to ignore a timestamp is a "global" change and will affect the way everything else in the environment is backed up. ". From all the TSM documentation that I've read, you simply can't do this. Please let me know if you have information to the contrary.
- Anand
-
Originally posted by Axr2
Jodie,
Thanks. Yes, we do use multiple policies and management classes. However, there doesn't appear to be a way to tell TSM to "ignore" timestamp or block changes (globally or otherwise).
I was infact wrong about the below sentence - "Asking TSM to ignore a timestamp is a "global" change and will affect the way everything else in the environment is backed up. ". From all the TSM documentation that I've read, you simply can't do this. Please let me know if you have information to the contrary.
- Anand
I asked our TSM admin, and she says she doesn't know of a way to ignore the timestamp either. And you can't tell it to do a full every time. Her suggestion was to actually list the files in the .opt file. I know that's not a great option, incase your db changes, but it's an idea.
HTH
Jodie
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|