Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
Share Embed Flag
Download ePaper

Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Beginning Microsoft SQL Server 2008 ... - S3 Tech Training Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

cdn.s3techtraining.com
from cdn.s3techtraining.com More from this publisher
17.06.2013 Views

Chapter 14: Transactions and Locks The syntax is simple enough: SAVE TRAN[SACTION] [| ] The thing to remember about save points is that they are cleared on ROLLBACK — that is, even if you save five save points, once you perform one ROLLBACK they are all gone. You can start setting new save points again and rolling back to those, but whatever save points you had when the ROLLBACK was issued are gone. SAVE TRAN can get extremely confusing and I can’t recommend it for the beginning user, but keep it in mind as being there. How the SQL Ser ver Log Works 430 You definitely must have the concept of transactions down before you try to figure out how SQL Server tracks what’s what in your database. You see, what you think of as your database is only rarely a complete version of all the data. Except for rare moments when it happens that everything has been written to disk, the data in your database is made up of not only the data in the physical database file(s), but also any transactions that have been committed to the log since the last checkpoint. In the normal operation of your database, most activities that you perform are logged to the transaction log, rather than written directly to the database. A checkpoint is a periodic operation that forces all dirty pages for the database currently in use to be written to disk. Dirty pages are log or data pages that have been modified after they were read into the cache, but the modifications have not yet been written to disk. Without a checkpoint the log would fill up and/or use all the available disk space. The process works something like the diagram in Figure 14-1. Don’t mistake all this as meaning that you have to do something special to get your data out of the cache. SQL Server handles all of this for you. This information is only provided here to facilitate your understanding of how the log works and, from there, the steps required to handle a transaction. Whether something is in cache or not can make a big difference to performance, so understanding when things are logged and when things go in and out of the cache can be a big deal when you are seeking maximum performance. Note that the need to read data into a cache that is already full is not the only reason that a checkpoint would be issued. Checkpoints can be issued under the following circumstances: ❑ By a manual statement (using the CHECKPOINT command) ❑ At normal shutdown of the server (unless the WITH NOWAIT option is used) ❑ When you change any database option (for example, single user only, dbo only, and so on) ❑ When the Simple Recovery option is used and the log becomes 70 percent full ❑ When the amount of data in the log since the last checkpoint (often called the active portion of the log) exceeds the size that the server could recover in the amount of time specified in the recovery interval option

Figure 14-1 Data needed Data in cache? No Yes Read or modify data in cache Data changed? Yes Write changes to log Failure and Recovery Room in cache for new data? A recovery happens every time that SQL Server starts. SQL Server takes the database file, then applies (by writing them out to the physical database file) any committed changes that are in the log since the last checkpoint. Any changes in the log that do not have a corresponding commit are rolled back — that is, they are essentially forgotten. Let’s take a look at how this works depending on how transactions have occurred in your database. Imagine five transactions that span the log as pictured in Figure 14-2. Yes Read data into cache so placing least recently used data Let’s look at what would happen to these transactions one by one. Chapter 14: Transactions and Locks No Issue checkpoint Write any modified cache pages to disk 431

Figure 14-1<br />

Data needed<br />

Data in cache? No<br />

Yes<br />

Read or modify<br />

data in cache<br />

Data changed?<br />

Yes<br />

Write changes<br />

to log<br />

Failure and Recovery<br />

Room in cache<br />

for new data?<br />

A recovery happens every time that <strong>SQL</strong> <strong>Server</strong> starts. <strong>SQL</strong> <strong>Server</strong> takes the database file, then applies (by<br />

writing them out to the physical database file) any committed changes that are in the log since the last<br />

checkpoint. Any changes in the log that do not have a corresponding commit are rolled back — that is,<br />

they are essentially forgotten.<br />

Let’s take a look at how this works depending on how transactions have occurred in your database.<br />

Imagine five transactions that span the log as pictured in Figure 14-2.<br />

Yes<br />

Read data<br />

into cache so<br />

placing least<br />

recently used<br />

data<br />

Let’s look at what would happen to these transactions one by one.<br />

Chapter 14: Transactions and Locks<br />

No<br />

Issue checkpoint<br />

Write any<br />

modified<br />

cache<br />

pages to disk<br />

431

logo

products

Resources

Company

Terms of service
Privacy policy
Cookie policy
Cookie settings
Imprint
Change language
Made with love in Switzerland
© 2024 Yumpu.com all rights reserved

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!