DBAsupport.com Forums - Powered by vBulletin
Results 1 to 10 of 10

Thread: Datafile block changes during hot backups and TSM

  1. #1
    Join Date
    Oct 2002
    Posts
    807

    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.

  2. #2
    Join Date
    Feb 2001
    Posts
    295

    Talking

    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

  3. #3
    Join Date
    Oct 2002
    Posts
    807
    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..

  4. #4
    Join Date
    Nov 2000
    Location
    greenwich.ct.us
    Posts
    9,092
    OK, then, please describe how you want to ignore certain files where the timestamp changes and include others.
    Jeff Hunter

  5. #5
    Join Date
    Oct 2002
    Posts
    807
    Huh..what?!

    I simply asked if someone had faced a certain problem..and if they did, what was the solution?

  6. #6
    Join Date
    Feb 2001
    Posts
    295
    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

  7. #7
    Join Date
    Oct 2002
    Posts
    807
    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."

  8. #8
    Join Date
    Sep 2001
    Location
    Ohio
    Posts
    334
    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

  9. #9
    Join Date
    Oct 2002
    Posts
    807
    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

  10. #10
    Join Date
    Sep 2001
    Location
    Ohio
    Posts
    334
    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
  •  


Click Here to Expand Forum to Full Width