Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12345»»»

Full backup Scenario Expand / Collapse
Author
Message
Posted Monday, March 15, 2010 8:54 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, September 2, 2014 10:45 PM
Points: 37, Visits: 54
Comments posted to this topic are about the item Full backup Scenario
Post #883499
Posted Monday, March 15, 2010 9:09 PM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Monday, November 24, 2014 8:33 AM
Points: 1,676, Visits: 1,760
This is a very good question, which definitely required some thinking to answer. Thank you.

It looks like I am the first one who answered this one correctly . The full backup is designed to restore the database to the state in which it was at the moment the backup has finished, so the answer makes perfect sense.

Oleg
Post #883508
Posted Monday, March 15, 2010 11:20 PM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Today @ 12:41 AM
Points: 4,151, Visits: 5,545
Tricky.
good question


____________________________________________
Space, the final frontier? not any more...
All limits henceforth are self-imposed.
“libera tute vulgaris ex”
Post #883556
Posted Tuesday, March 16, 2010 1:39 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 3:46 PM
Points: 6,128, Visits: 8,392
Great question!

One additional comment that was missing from the question and description, is how pending transactions are handled.

IF the session inserting the 10000 rows does so within a transaction, and the transaction is not yet committed when the backup finishes, then a restore from this backup will contain none of those rows.
IF the session inserting the 10000 rows does not use an explicit transaction (making each individual insert statement an implied transaction of its own), then a restore from this backup will contain all the rows that were inserted before the backup finished, and none of the rows inserted after the backup finished.

Even though the portion of the transaction log that is added to the backup will include modifications by uncommitted transactions, the restore process will not restore those changes (or even undo them if they were already made in the data page when it was copied) because the transaction is still uncommitted at the end of the backup.



Hugo Kornelis, SQL Server MVP
Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
Post #883582
Posted Tuesday, March 16, 2010 2:58 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, May 10, 2010 11:23 PM
Points: 262, Visits: 53
Thank you for your question.It's a good point that I had never attended.It's obvious in question that 10000 rows are inserted without transaction because the records are inserting through a loop and any records that insert until the completion time of full backup will be included.
Post #883604
Posted Tuesday, March 16, 2010 5:30 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, July 28, 2011 2:11 PM
Points: 7, Visits: 39
I'm not sure I understand the explanation though:
Whenever a full backup is initiated it will place a pointer in the transaction log in order to understand from where the backup started. So any transaction happening,after the pointer, will be included in the backup.


Is this saying that a full backup backs up everything fully before the pointer, and then pulls the data after the pointer? Otherwise, what is the point of the pointer?

If it doesn't mean that, what does it mean? Why would a pointer be placed in the transaction log on the initiation of a full backup if it is going to backup the data before AND after the pointer?
Post #883667
Posted Tuesday, March 16, 2010 5:57 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 3:46 PM
Points: 6,128, Visits: 8,392
vogelz (3/16/2010)
I'm not sure I understand the explanation though:
Whenever a full backup is initiated it will place a pointer in the transaction log in order to understand from where the backup started. So any transaction happening,after the pointer, will be included in the backup.


Is this saying that a full backup backs up everything fully before the pointer, and then pulls the data after the pointer? Otherwise, what is the point of the pointer?

If it doesn't mean that, what does it mean? Why would a pointer be placed in the transaction log on the initiation of a full backup if it is going to backup the data before AND after the pointer?

I'm not sure if the explanation is 100% technically accurate. My understanding (which might be wrong as well) is that the backup first copies all the data pages, then adds all the log pages starting from the start of the oldest uncommitted transaction right up until the time the backup ends.

On a restore, first all data pages are restored; then the log entries included in the backup are used to
a) roll forward any transactions that were committed while the backup was running, and
b) roll back any changes from transactions that were not yet commited when the backup finished.
The latter is required because the backed up data pages may already have been modified by those transactions.

As I said, the exact implementation might be slightly different. But the main point to remember is that the backup/restore process ensures that the restored database includes the changes from all the transactions that were finished when the backup ended, and no changes at all from any transactions that were still running at that time.



Hugo Kornelis, SQL Server MVP
Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
Post #883682
Posted Tuesday, March 16, 2010 6:04 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, July 28, 2011 2:11 PM
Points: 7, Visits: 39
Thanks Hugo, that does make much more sense.

Andrew
Post #883685
Posted Tuesday, March 16, 2010 7:00 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Wednesday, December 3, 2014 8:17 AM
Points: 2,917, Visits: 2,537
Hugo, after getting the questin wrong and re-reading a few times in disbelief I found on <http://msdn.microsoft.com/en-us/library/ms175477.aspx> - Each data backup includes part of the transaction log so that the backup can be recovered to the end of that backup.

So, in a full backup, all completed transactions will be added to the full dump. everything else will be added to the transaction log dumps if being performed.


Steve Jimmo
Sr DBA
“If we ever forget that we are One Nation Under God, then we will be a Nation gone under." - Ronald Reagan
Post #883734
Posted Tuesday, March 16, 2010 9:37 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Monday, November 10, 2014 12:05 PM
Points: 3,969, Visits: 3,648
This was a good question. And thanks Hugo for the explanation.
Post #883913
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse