Full Recovery Model

  • Comments posted to this topic are about the item Full Recovery Model

  • Thank you for the simple question. + 1 added.

  • EZ PZ

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • Good one.

    M&M

  • <cough>referense</cough>

    /T

  • Nice back to basics question. Very thorough reference though, took me hours to wield through 😀

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • easy and basic but i love it !!!!!!!!! :hehe:

  • Wasn't the "explanation" more or less a repeat of the question? It really felt like "Is X true? Yes it is, because X is true!". Needed a reference at the very least.

  • This was removed by the editor as SPAM

  • What do you mean for "created and loaded database"?

  • Stewart "Arturius" Campbell (3/7/2012)


    Nice, simple back-to-basics question, thanks, Peter

    For the explanation, refer to Working with Transaction Log Backups, specifically the third paragraph

    +1

    😎


    [font="Times New Roman"]rfr.ferrari[/font]
    DBA - SQL Server 2008
    MCITP | MCTS

    remember is live or suffer twice!
    the period you fastest growing is the most difficult period of your life!
  • Stewart "Arturius" Campbell (3/7/2012)


    Nice, simple back-to-basics question, thanks, Peter

    For the explanation, refer to Working with Transaction Log Backups, specifically the third paragraph

    And to add to that reference, the reason for this is that a restore always has to start with the restore of a full backup. A full backup contains the information in the database at a given point; a log backup contains a list of changes. When you need to restore to a point in time, you HAVE to restore to the complete content of a previous point in time first, then reapply the changes by following the chain of log backups.

    Without a starting point to base the changes on, a set of changes is useless. That's why SQL Server refuses to let you save such a set of changes. (In fact, when setting a database to FULL or BULK_LOGGED recovery, the actual running mode always remains SIMPLE until you take a full backup. And the same is true for newly created databases.)


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • Good question. Got me thinking a little since I never tried this before.

    @hugo: Thanks for the explanation. That rationalization of the restore process is what led me to the right answer.

    ---------------
    Mel. 😎

  • Hugo Kornelis (3/7/2012)


    (In fact, when setting a database to FULL or BULK_LOGGED recovery, the actual running mode always remains SIMPLE until you take a full backup. And the same is true for newly created databases.)

    Ooohh... did not know that, never thought about it since I start backups immediately, but that is good to know. This implies that therefore should a backup be forgotten, the changes are immediately lost even to a log reader should a transaction log backup be taken later on after the full backup. Good to know indeed.

  • Nice and easy, but still got me thinking a little bit 🙂

    @hugo, thank you for the explanation, clear and concise.

    "El" Jerry.

    "El" Jerry.

    "A watt of Ottawa" - Gerardo Galvan

    To better understand your help request, please follow these best practices.[/url]

Viewing 15 posts - 1 through 15 (of 29 total)

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