Post reply

Recovery Model - SIMPLE V/S FULL

  • June 3, 2013 at 2:28 pm

    #273488

    Hi,

    If we having Full backup every night but it's set up FULL Recovery model, I have a question that if we are taking back up every night and looks like it will be ok with this but is it any benefits having Recovery Model leaving as default as FULL instead of SIMPLE as if don't have any Differential or T-Log back up?

    I am just wondering if they are not using any Differential or T-Log back up and only taking daily Full Backup then it should be advisable to set up Recovery Model as Simple instead of default?

    Thanks

  • June 3, 2013 at 2:40 pm

    #1620714

    If you're not doing any T-Log backups and you're not planning on doing them, then you should change to Simple Recovery Model. Otherwise it would be like driving a Camaro at 20km/h all the time.

    Luis C.
    General Disclaimer:
    Are you seriously taking the advice and code from someone from the internet without testing it? Do you at least understand it? Or can it easily kill your server?

    How to post data/code on a forum to get the best help: Option 1 / Option 2

  • June 3, 2013 at 3:20 pm

    #1620727

    Thanks.

    Right not taking any T-Log backups or Differential Backup and not planning to do to change it.

    If we do the Upgrade, do we have any requirements to keep it FULL before upgrade or we can change Recovery Model during upgrade/migration?

  • June 3, 2013 at 3:26 pm

    #1620730

    Which upgrade are you talking about? :blink:

    Luis C.
    General Disclaimer:
    Are you seriously taking the advice and code from someone from the internet without testing it? Do you at least understand it? Or can it easily kill your server?

    How to post data/code on a forum to get the best help: Option 1 / Option 2

  • June 3, 2013 at 3:45 pm

    #1620737

    From 2005 to 2008

  • June 7, 2013 at 7:27 am

    #1622060

    If your recovery model is set to FULL and you are not doing T-log backups your transaction log will continue to grow, until eventually it will become larger than the database itself.

    By all means, if you are only doing database backups set the recovery model to SIMPLE.

    The probability of survival is inversely proportional to the angle of arrival.

  • June 17, 2013 at 5:11 am

    #1624541

    I think the question(s) that you have missed is - Do you require a point in time restore? What is your recovery point objective on that datasbase?

    If you have the need to restore to specific point in time then you need the FULL recovery model; If not then change to SIMPLE.

    You would need to start performing log backups as suggested to stop the log file getting overly large

    SQL DBA
    Every day is a school day, and don't trust anyone who tells you any different.
    http://sqlblogness.blogspot.co.uk

  • June 17, 2013 at 6:27 am

    #1624562

    poratips (6/3/2013)

    Thanks.

    Right not taking any T-Log backups or Differential Backup and not planning to do to change it.

    If we do the Upgrade, do we have any requirements to keep it FULL before upgrade or we can change Recovery Model during upgrade/migration?

    I dont' think it doesn't depend on the recovery model to migrate from version to version and you can change even after the migration has happened.

  • June 17, 2013 at 6:58 am

    #1624574

    gosh. If you have data in a database, it must be important. One of the chief requests for help on this and other forums is to recover the contents of a table that someone accidently truncated, deleted, or dropped and the poster doesn't have backups Unless the database is an archive database that's only update once per month or a "staging" database where the data is only transient at best, I'd make sure that the database was set to the FULL Recovery Model and I'd setup Point-in-Time log backups to occur at least once an hour (10 to 15 minutes is my normal setup, though).

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply