Results 1 to 15 of 15
  1. #1
    Join Date
    Dec 2003
    Posts
    1,074

    Unanswered: Hot Backup vs Cold

    I think I've been thinking about this too much, and I'm getting lines crossed.

    A cold backup occurs when the database is down. To recover, you restore to a cold backup and apply archived redo logs.

    A hot backup occurs when the database is up. To recover, do you restore to the hot backup and apply archived redo logs?

    I know this is a low-level question, but for some reason it's getting me.

    Thanks
    -cf

  2. #2
    Join Date
    Aug 2003
    Location
    Where the Surf Meets the Turf @Del Mar, CA
    Posts
    7,776
    Provided Answers: 1
    > A cold backup occurs when the database is down.
    >To recover, you restore to a cold backup and apply archived redo logs.
    One does not normally apply archived redo logfiles to a DB where a cold backup is done.
    First, a consistant cold backup requires a "clean" SHUTDOWN or SHUTDOWN IMMEDIATE.
    A DB restored from a consistant cold backup won't look for or require any redo logfiles to open.
    The proof is in the pudding.
    Create a small test DB & experiment with it.
    You can lead some folks to knowledge, but you can not make them think.
    The average person thinks he's above average!
    For most folks, they don't know, what they don't know.
    Good judgement comes from experience. Experience comes from bad judgement.

  3. #3
    Join Date
    Jul 2003
    Posts
    2,296
    are we assuming you are not referring to RMAN at all and only talking about
    a command-line cold or hot backup?
    - The_Duck
    you can lead someone to something but they will never learn anything ...

  4. #4
    Join Date
    Dec 2003
    Posts
    1,074
    A couple more questions, if you don't mind:

    1) Can you apply redo logs to a Cold Backup, and essentially roll it forward?
    2) Would you ever perform 1)?

    I'm in the midst of helping consider our backup plan (using RMAN), and other plans I have seen involve taking a cold level 0 backup Sundays and then performing incremental backups across the week.

    Another DBA put forward the idea of a Cold Backup Sundays, with hot backups every evening after production. The extreme case argument was that if something ever happened with the daily RMAN backupsets, we could use the Cold Backup and apply archive logs to revive the database (hence question 1) above). Under less extreme circumstances, the hot backups would make sure we never lost more than a days worth of data, if something happened to the archive logs for a day.

    In writing this, I'm feeling like I am slightly off conceptually on how I've learned that backup & recovery actually works. Is a weekly cold backup and nightly hot backups the right combination?

    -Thanks,
    Chuck

  5. #5
    Join Date
    Aug 2003
    Location
    Where the Surf Meets the Turf @Del Mar, CA
    Posts
    7,776
    Provided Answers: 1
    >1) Can you apply redo logs to a Cold Backup, and essentially roll it forward?
    AFAIK, NO.
    >2) Would you ever perform 1)?
    If you can convince Oracle to apply the redo logfiles, you are essentially doing an incomplete PITR, so the answer would be YES.

    >Is a weekly cold backup and nightly hot backups the right combination?
    Define "RIGHT".
    The business needs to decide a couple of parameters which will be the driving factors to an acceptable backup & recovery procedures.
    How much data can be lost and still be acceptable from a business standpoint?
    Assume a catestrophic failure of the database server.
    How much down time (recovery time) is acceptable to be able to restore data
    that meets or exceeds the answer to the 1st question?
    How much money is the business willing to spend to achieve both goals above?

    You can have it good, fast, or cheap.
    Pick any TWO & be willing to pay the piper in the criteria not selected.
    You can lead some folks to knowledge, but you can not make them think.
    The average person thinks he's above average!
    For most folks, they don't know, what they don't know.
    Good judgement comes from experience. Experience comes from bad judgement.

  6. #6
    Join Date
    Dec 2003
    Posts
    1,074
    Thanks Anacedent,

    then back to cold & hot RMAN backups, what the real difference between the two? In the above scenario, what would the Sunday Cold backup provide if taken once a week, besides serving as a starting point for recovery if the db crashes on a Monday before the hot backup?

    I'm having a tough time figuring out the utility in a cold backup, when a hot backup seems to do everything a cold backup performs, but with the added benefit of allowing users to interact with the database. A cold backup has been stressed in the texts I've read as a solid, reliable, consistent version of the database. But unless you want to return to Sundays database state, seeing as it may not be possible to use archive logs to roll forward...

    -cf

  7. #7
    Join Date
    Aug 2003
    Location
    Where the Surf Meets the Turf @Del Mar, CA
    Posts
    7,776
    Provided Answers: 1
    > what the real difference between the two?
    Trade-offs.
    Assume you want a copy of your production DB to be available for developers.
    The easiest way is to shutdown the production DB, copy all the file to a new system & then simply startup both DBs.
    I suspect that you NEVER have actually restored a DB from a hot backup.
    It is more than just issuing the STARTUP command.
    Even tho it is V8, the content is still valid. Invest in a copy of
    "Oracle 8 Backup & Recovery Handbook" ISBN - 0-07-882389-7

    Keep in mind that doing backups is only HALF of the solution.
    If you can't actually restore a functioning DB, you've FAILED; BIG TIME!

    Again, create a small test DB & practice backup & recovery scenarios.
    How do you recover from a lost controlfile, redo logfile, datafile, RBS?
    Each requires a unique solution, because they are different problems.
    You can lead some folks to knowledge, but you can not make them think.
    The average person thinks he's above average!
    For most folks, they don't know, what they don't know.
    Good judgement comes from experience. Experience comes from bad judgement.

  8. #8
    Join Date
    Apr 2003
    Location
    Jagdishpur
    Posts
    146
    Hi anacedent,
    Seems u r boss in backup & recovery scene. Good..I think i liked it. I have seen so many posts of yours regarding backup & recovery and tried to understand them to the bset of my capacity. But, i have so many confusions regarding setting up backup strategy here.

    I feel that first i should undertsand the complete possibility of backup before i ask anything. So, i request you for following:
    1. Please tell me some good book on backup & recovery on oracle9i. I need to really understand it to depth. And the publication..?
    2. Which oracle documentation i should go for.?
    3. Any note on OTN.

    I will go through chapter-by-chapter and try to get the information and understand it. And then i feel i can better visualize it and mark difference between hot & cold backups.

    Thanks. I wait for ur answer please.

    regads,
    kamesh Rastogi
    - KR

  9. #9
    Join Date
    Jul 2003
    Posts
    2,296
    when using RMAN in archive log mode you are only referring to either:
    1. FULL hot backup (there really is no cold backup since you don't need to shutdown the db to make a FULL backup in archivelog mode)
    2. Incremental hot backup (either cumulative or differential)

    Then all you need to worry about it backing up your archive-redo logs.

    When doing recovery, RMAN alerady knows where all the files are located in order to recover the DB to a specific point in time and it will automatically use the proper archive logs to do so.

    BTW - Be sure to use a catalog db (not on the same server as the one you are backing up)
    - The_Duck
    you can lead someone to something but they will never learn anything ...

  10. #10
    Join Date
    Dec 2003
    Posts
    1,074
    The instuctions I was looking at for incremental backups showed an example where the database was in MOUNT mode during a LEVEL 0 backup. So, is that not a necessary step when you are in ARCHIVELOG mode?

    And can you clarify the necessity for the RMAN repository? From what I've been reading, it doesn't look like it is an important feature, unless you want to restore your database using a full backup, when that backup is not the most recent full backup. (Apologies for extending this discussion to a controlfile/repository discussion, but this has been another slow spot for me.)

    Thanks,
    Chuck

  11. #11
    Join Date
    Jul 2003
    Posts
    2,296
    You don't have to ever take the DB down to do any level backup
    if you are using RMAN and you are in archivelogmode.


    from the Docs:
    Benefits of Using the Recovery Catalog as the RMAN Repository
    When you use a recovery catalog, RMAN can perform a wider variety of automated backup and recovery functions than when you use the control file in the target database as the sole repository of metadata. The following features are available only with a catalog:

    You can store metadata about multiple target databases in a single catalog.
    You can store metadata about multiple incarnations of a single target database in the catalog. Hence, you can restore backups from any incarnation.
    Resynchronizing the recovery catalog at intervals less than the CONTROL_FILE_RECORD_KEEP_TIME setting, you can keep historical metadata.
    You can report the target database schema at a noncurrent time.
    You can store RMAN scripts in the recovery catalog.
    When restoring and recovering to a time when the database files that exist in the database are different from the files recorded in the mounted control file, the recovery catalog specifies which files that are needed. Without a catalog, you must first restore a control file backup that lists the correct set of database files.
    If the control file is lost and must be restored from backup, and if persistent configurations have been made to automate the tape channel allocation, these configurations are still available when the database is not mounted.
    Costs of Using the Recovery Catalog as the RMAN Repository
    The main cost of using a catalog is the maintenance overhead required for this additional database. For example, you have to:

    Find a database other than the target database to store the recovery catalog (otherwise, the benefits of maintaining the catalog are lost), or create a new database
    Create enough space on the database for the RMAN metadata (as described in "Configuring the Recovery Catalog Database")
    Back up the recovery catalog metadata
    Upgrade the recovery catalog when necessary
    Hence, unless you manage a network of databases, you may choose to avoid the overhead and use the control file as the exclusive repository of metadata. When you use a control file as the RMAN repository, RMAN still functions effectively. If you do not use a catalog, read the section "Managing the RMAN Repository Without a Recovery Catalog". Specifically, make sure you:

    Consider the costs of not using a recovery catalog, as described in "Understanding Catalog-Only Command Restrictions"
    Develop a strategy for backing up the repository, as described in "Backing Up and Restoring the Control File"
    Last edited by The_Duck; 08-06-04 at 12:05.
    - The_Duck
    you can lead someone to something but they will never learn anything ...

  12. #12
    Join Date
    Dec 2003
    Posts
    1,074
    I read this part of the documentation, and the piece that drew me to the Repository was:

    "You can store metadata about multiple incarnations of a single target database in the catalog. Hence, you can restore backups from any incarnation."

    Does this mean that:

    Jan 1 Jan 8 Jan 15 Jan 17(Today)
    full full full

    Can I perform a PITR (more likely TPITR) for, say, Jan 7, several days beyond the older, full backup on Jan 1? Or does it mean I'd restore to Jan 1, 7, or 15 only, as an 'incarnation' of the target database.

    -Chuck

  13. #13
    Join Date
    Aug 2003
    Location
    Where the Surf Meets the Turf @Del Mar, CA
    Posts
    7,776
    Provided Answers: 1
    "Oracle 8 Backup & Recovery Handbook" ISBN - 0-07-882389-7

    "Oracle 9i RMAN Backup & Recovery: ISBN - 0-07-222622-5
    You can lead some folks to knowledge, but you can not make them think.
    The average person thinks he's above average!
    For most folks, they don't know, what they don't know.
    Good judgement comes from experience. Experience comes from bad judgement.

  14. #14
    Join Date
    Jul 2003
    Posts
    2,296
    he is saying go read about it.

    I thought this book was very easy to understand:
    Oracle9i RMAN Backup & Recovery
    Amazon is selling it for $34

    9i RMAN users manual:
    Code:
     http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96566.pdf
    9i RMAN reference manual:
    Code:
    http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96565.pdf
    - The_Duck
    you can lead someone to something but they will never learn anything ...

  15. #15
    Join Date
    Dec 2003
    Posts
    1,074
    I just sent off the request to have it rush-ordered. I would have bought it already, but we're on 10g, and I was trying to hold out for the new release.

    -cf

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •