Shocking tales of lost integrity Brace yourself: You’re about to read several ways that your information can lose its integrity. Fortunately, you can avoid each of these unpleasant scenar- ios by simply employing a combination of referential integrity (primary and foreign keys) and transactions. ߜ Parent and child differences: Imagine that your database includes data stored in parent (header) and child (detail) tables. Furthermore, suppose that you keep a running total of information in the parent table about records in the child table. A good example is customer details (name, address, financial summary) in the parent table, and customer transac- tions (transaction date, amount, and so on) in the child table. If you’re not careful, these two tables can get out of sync, which might lead to someone looking at data in the parent table to make an incorrect assumption. ߜ Orphans: Continuing with the preceding example, what happens if you intentionally delete a parent record but somehow overlook deleting its related children? You’re left with the sad prospect of orphaned child records forever doomed to a lonely existence in your database. ߜ Partial updates: A partial update can happen when all the tables that are supposed to be updated at one time don’t actually successfully com- plete their modifications. The classic example of this problem is a failure when transferring money between savings and checking tables. If the application only reduces the savings balance but does not increase the checking balance, the customer is quite unhappy, and the data’s integrity (and possibly the bank manager’s office) is damaged. ߜ Business rule violations: Although rules are generally meant to be broken from time to time, this is not true with information carefully entrusted to your SQL Server Express database. For example, you might be building an application to track credit ratings for your customers. Valid values for the credit score range between 0 and 100. If a rogue person or program places a value of –291 or 1,259 in this column, your data’s integrity is no longer intact. Passing the ACID test SQL Server 2005 Express is a robust, industrial-strength database server. One hurdle that any database server must pass to belong to this club is known as the ACID test. It does not refer to the database’s propensity to ingest psyche- delic drugs, nor does it have anything to do with its ability to withstand cor- rosive liquids. Instead, passing this test means that the database server 194 Part IV: Keeping Your Data Safe from Harm 19_599275 ch12.qxp 6/1/06 8:45 PM Page 194 supports a minimum level of transaction integrity. ACID is an acronym that stands for Atomicity, Consistency, Integrity, and Durability. I describe each of these components in the following list: ߜ Atomicity: This doesn’t refer to the radioactivity of your database. Instead, you can consider a transaction to be atomic if all its steps happen as a group, or none of them do. For example, a transaction may update four tables at one time. Atomicity means that either all four tables receive their updates correctly, or all of them are restored to their initial state. Without this trait, your database could easily become inconsistent. ߜ Consistency: Part of your job as a database designer or administrator is to set up referential integrity and other business rules. The database engine’s job is to take these rules into consideration when processing a transaction. If the transaction attempts to violate even one rule, the database server must abort the transaction and roll the database back to its original state. For example, if you specify that a column can only contain a numeric value between 1 and 5, and a transaction attempts to place a 6 into that column, SQL Server 2005 Express rolls the whole transaction back, even for any other tables or columns that were not violated. ߜ Integrity: In the context of a SQL Server 2005 Express transaction, integrity has nothing to do with paying debts, obeying the speed limit, or helping old ladies across the street. Instead, it means that while a trans- action is underway, no other processes other than the transaction itself can see the database in an intermediate state. For example, suppose that your transaction is processing an order, which involves decrementing inventory while updating a customer’s shopping cart. The integrity trait means that any other process sees both the inventory and shopping cart data structures in their original states while the transaction is running. Of course, after you finish the transaction both these results are available at the same time. ߜ Durability: A durable database server transaction does not refer to its ability to withstand heat and cold, or resist thermal viscosity break- down. Rather, it means that after you state that the transaction is fin- ished, and the database reports this to be true, SQL Server 2005 Express doesn’t suddenly develop amnesia and disregard your work. It’s true that another user or process may come along and make changes to your data, but this is not the same as the database itself casually forgetting what you did. 195 Chapter 12: Keeping It Together: Using Transactions to Maintain Data Integrity 19_599275 ch12.qxp 6/1/06 8:45 PM Page 195 Key Transaction Structures To make transactions possible, SQL Server 2005 Express uses a sophisticated set of technologies all working together to help ensure that things go smoothly. At the beginning of a transaction, SQL Server 2005 Express uses the set of internal structures that I describe here to record the details about the transaction, as well as coordinate interaction between your transaction and other database users and processes. Some of these key components include ߜ Log cache: SQL Server 2005 Express uses this memory-based structure as a temporary storage buffer for details about a transaction. Because it’s based in memory, and separate from the standard buffer cache used for data, it’s very fast and efficient. ߜ Transaction log: This file, or group of files, is a journal that contains information about your transactions. It works in conjunction with the log cache. If you need to roll back your transaction, or restore from a backup, this journal is vital to setting things right with your database. It also serves as a source of guidance for database replication and standby servers. Administrators typically back up their transaction logs as part of normal maintenance. ߜ Locks: Because SQL Server 2005 Express supports multiple concurrent users and processes, a series of locking mechanisms must coordinate access to information. A lock’s scope can be very granular — such as at the data page level — or very wide — such as at the table or even data- base level. ߜ Checkpoints: As you might guess from its name, a checkpoint is an intri- cate, internal SQL Server 2005 Express event that serves to synchronize all the other internal transaction structures so that everything is consistent. Isolation Levels Each SQL Server 2005 Express transaction has an isolation level. This term describes how the transaction interacts with other database users and processes. To make transaction isolation levels work, SQL Server 2005 Express employs a variety of locks on data and indexes, as well as other internal controls. Locks may be at the row, page, or table level, and they may be exclusive (completely restricting access to data) or shared (which allows other transactions to access information). 196 Part IV: Keeping Your Data Safe from Harm 19_599275 ch12.qxp 6/1/06 8:45 PM Page 196 SQL Server 2005 Express offers a series of increasingly stringent isolation levels: ߜ READ UNCOMMITTED: Also described as dirty read, this isolation level is the most permissive. It lets other users and processes see your transac- tion’s work even if it hasn’t yet been formally committed to the SQL Server 2005 Express database. For example, you may insert a row into a particu- lar table. Other users see that row even before the transaction is finished. If you then roll back the transaction, the row never truly existed; yet other users saw it. This is known as phantom data, and can lead others to make scarily incorrect decisions. ߜ READ COMMITTED: As the default for SQL Server 2005 Express, this isola- tion level prevents other users or processes from seeing your transac- tion’s work until it’s finished. However, these outside parties can make alterations to any of the data that your transaction has read. For exam- ple, suppose that your transaction reads 100 rows from a given table and then takes action based on what it read. Another program can modify any of those 100 rows even while your transaction is active. This may be a problem if your transaction needs those rows to remain in their origi- nal condition. Fortunately, the next isolation level addresses that kind of potential issue. ߜ REPEATABLE READ: This level is just like the READ COMMITTED isola- tion level, except that REPEATABLE READ prevents other transactions from modifying any rows that were consulted by your transaction. To continue the READ COMMITTED example, this isolation level means that no other transactions could change any of the 100 rows that your trans- action has read until your transaction has finished. ߜ SNAPSHOT: By requesting this isolation level, you can be assured that all the data that your transaction reads or modifies remains in that state until you complete your work. It uses versioning to achieve this high degree of interoperability, which comes at a much lower overhead cost than other isolation levels, such as REPEATABLE READ. Of course, others may come along after you finish your transaction and make their own changes, but this isolation level does at least keep things consistent until your work is done. ߜ SERIALIZABLE: This isolation level is by far the most restrictive. Not only does it block other transactions from seeing any changes that your active transaction has made, and changing any data that you’ve read, it also prevents outside transactions from inserting any new rows if the index values for those rows would fall in the range of data that you’ve read. For example, suppose that your transaction has read rows with an index value between 0 and 100. With this setting, no other transactions could insert a new row with an index value anywhere between 0 and 100. 197 Chapter 12: Keeping It Together: Using Transactions to Maintain Data Integrity 19_599275 ch12.qxp 6/1/06 8:45 PM Page 197 Be careful when using the more restrictive isolation levels. Although they do a great job of preserving data integrity, the cost can be significantly reduced system speed and throughput. Using Transactions In the previous sections of this chapter, I tell you all about transactions. So now you’re probably wondering how you can put these powerful features to work. Fortunately, despite their rich capabilities, transactions are quite simple to use. In a nutshell, just follow these steps: 1. Determine the isolation level that you need to do your work. In the preceding section of this chapter, I show you that SQL Server 2005 Express offers five different transaction isolation levels. Your job as a developer is to pick the right one. Pick the least restrictive transaction isolation level that your application can afford. In other words, don’t use the more draconian isolation levels (such as SERIALIZABLE) unless your transaction demands the control and restrictions provided by this isolation level. As a matter of fact, in most cases, you’ll probably find that the default isolation level will suffice. 2. Set the isolation level. Because SQL Server Express supports numerous development languages and technologies, I use straight SQL transaction invocations for the bal- ance of this section. To specify your choice of isolation level, just use the SET TRANSACTION ISOLATION LEVEL statement: SET TRANSACTION ISOLATION LEVEL REPEATABLE READ Your chosen isolation level remains in effect until you explicitly change it, or your session closes. 3. Start the transaction. Use the BEGIN TRANSACTION statement to indicate that your transac- tion is now underway: BEGIN TRANSACTION You may also specify a name for your transaction, but a name is optional. In any case, after you invoke this statement, you are now in an active transaction. 198 Part IV: Keeping Your Data Safe from Harm 19_599275 ch12.qxp 6/1/06 8:45 PM Page 198 4. Make your data alterations. You can use whatever SQL or other database access language you’re accustomed to. The fact that you’re in a transaction doesn’t change your syntax at all. 5. Check for any errors. Carefully monitoring each statement to make sure that it works as you expected is important. These facts are very important when deciding whether you want to make your work permanent. 6. Finalize the transaction. By now you’re ready to finish your work. Assuming that everything has gone well, you can tell SQL Server 2005 Express that you want your changes to be made permanent: COMMIT TRANSACTION If you have given your transaction a name as part of the BEGIN TRANS- ACTION statement, you need to include it here. If things didn’t go well with your transaction, don’t despair. You can tell SQL Server 2005 Express to forget the whole thing, and return your data- base to its pristine, original state: ROLLBACK TRANSACTION Remember that if you gave your transaction a name, you need to include it here: ROLLBACK TRANSACTION transaction name Here, written in basic Transact-SQL, is a simple banking transaction that adds $5.00 into the balance of every customer who has been with the bank since before January 1, 2004: DECLARE @ERROR_STATE INT; SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; BEGIN TRANSACTION; UPDATE Accounts SET Balance = Balance + 5 WHERE DateJoined < ‘1/1/2004’; SELECT @ERROR_STATE = @@ERROR; IF (@ERROR_STATE <> 0) ROLLBACK TRANSACTION; ELSE COMMIT TRANSACTION; The @@ERROR function tells you if anything has gone wrong with your trans- action, which gives you the chance to roll it back in time. To find out more about handling errors, take a look at Chapter 17. 199 Chapter 12: Keeping It Together: Using Transactions to Maintain Data Integrity 19_599275 ch12.qxp 6/1/06 8:45 PM Page 199 200 Part IV: Keeping Your Data Safe from Harm 19_599275 ch12.qxp 6/1/06 8:45 PM Page 200 Chapter 13 Preventing Data Loss In This Chapter ᮣ Using transactions to safeguard your data ᮣ Keeping memory and disk in sync ᮣ Backing up vital database information ᮣ Restoring database archives W aking up one morning to find some or all your precious data lost for- ever ranks with some of life’s great moments — like root canals, tax audits, or endless flight delays. However, in this chapter, I show you that unlike death and taxes, you can avoid losing data. To begin, I show you why using transactions can be one of the smartest things a software developer can do. Next, I expound on ways to keep your database server’s memory consistent with the permanent information stored on disk. Finally, you see how to use the sophisticated backup and recovery features built into SQL Server 2005 Express to help safeguard your data. Transactions: Your Data’s Best Friend Because relational database applications typically divide their information among multiple tables, things can go horribly wrong if one or more tables have a problem with a particular database operation. For example, suppose that you write a program that updates rows in tables A, B, and C as part of the same unit of work. Furthermore, imagine that tables A and C happily accept your changes, but something is wrong with the modi- fication that you want to apply to table B’s data. If you’re not careful, you could easily end up in a state where tables A and C think everything was fine, and table B does not. This translates into a corrupted and out-of-sync database. Months may go by before anyone notices, but rest assured: Your data has been damaged. 20_599275 ch13.qxp 6/1/06 8:46 PM Page 201 This situation is where transactions come in. By grouping all your data updates into one batch, you can definitively tell SQL Server 2005 Express to either keep or reject all your changes. In the preceding example, you could have put tables A, B, and C back to their original states if even one of them had a prob- lem with your change. Your data remains in sync, and is safely preserved. What are transactions? In a nutshell, a transaction is a unit of work that you launch with a BEGIN TRANSACTION statement. You then proceed to issue one or more database operation requests, which SQL Server 2005 Express dutifully processes. Then, after all your work is finished, you complete the transaction with a COMMIT TRANSACTION statement. SQL Server 2005 Express then makes all your changes permanent: Everything that happened between BEGIN TRANS- ACTION and COMMIT TRANSACTION is now enshrined in your database for- ever (or at least until you change it later). But wait a minute. What if something went wrong during all these operations? Fear not, because transactions let you change your mind. For example, sup- pose that you start a transaction, issue a bunch of statements, and then change your mind and want to go back to the way things were before? Luckily, you have the ROLLBACK TRANSACTION statement waiting in the wings. If you issue this statement instead of COMMIT TRANSACTION, SQL Server can rollback all your modifications, putting the database back into the state that it was just prior to the BEGIN TRANSACTION statement. How do transactions work? To make sure that your transactions work as advertised, SQL Server 2005 Express performs a sophisticated juggling act among a number of internal technologies. When you start a transaction, the database server records this event in a memory structure known as the log cache. In addition, all your changes are also written into the log cache. This cache is then periodically written to the log cache’s disk-based counterpart, which is known as the transaction log. If the server were to crash in the middle of a transaction, SQL Server 2005 Express would use the transaction log as a guide to determine which transac- tions to rollback. On the other hand, if you simply change your mind, SQL Server 2005 Express can use the transaction log as a guide to reinstating your data to the way it was prior to the start of the transaction. If this rollback 202 Part IV: Keeping Your Data Safe from Harm 20_599275 ch13.qxp 6/1/06 8:46 PM Page 202 wasn’t helpful enough, the transaction log is also useful when you need to restore from a backup. In any case, when the transaction completes, SQL Server 2005 Express also records this event in the log cache and transaction log. Synchronizing Memory and Disk Storage Most modern relational database systems are built to take advantage of the lightning speed of memory-based processing. SQL Server 2005 Express is no exception. To cut down on the number of performance-degrading disk accesses, it uses a sophisticated set of internal memory structures to buffer information. Because processing in memory is at least ten times faster than doing the same work on disk, these speed enhancements can really help your application hum along. However, eventually all this fun has to come to an end, even if temporarily. Sooner or later, SQL Server 2005 Express must write the contents of its memory to disk, as part of an event known as a checkpoint. Otherwise, what would happen if the computer suddenly lost power? All your changes would be lost forever, vanishing into the ether before SQL Server 2005 Express could get the chance to commit them onto disk. Try explaining that to a user looking for last month’s sales figures. As you work with database information, SQL Server 2005 Express accumu- lates data on pages within a section of server memory known as the buffer cache. When you create, modify, or remove data, SQL Server 2005 Express records these alterations in the buffer cache on what are known as dirty pages. These pages are then synchronized to disk during a checkpoint. In addition to keeping memory and disk in sync, checkpoints also serve to help SQL Server 2005 Express recover from an unanticipated shutdown or failure. A successful checkpoint acts as an anchor in time, letting SQL Server 2005 Express recover from that point forward. Checkpoints happen all the time, not just during transactions. Here are just a few events that trigger a checkpoint: ߜ Prior to backing up your database ߜ Stopping your database server ߜ The transaction log fills up to a preset threshold Now that you know how checkpoints work, what do you have to do to make sure that your own checkpoints get run correctly? The good news here is that SQL Server 2005 Express handles all these chores automatically: You don’t have to do anything. 203 Chapter 13: Preventing Data Loss 20_599275 ch13.qxp 6/1/06 8:46 PM Page 203 [...]... trigger is disabled For each trigger that you create, SQL Server 2005 Express also writes detail entries in the sys .sql_ modules and sys.trigger_events tables These tables hold additional information about the trigger: ߜ The actual SQL text for the trigger ߜ Which type of SQL statement invokes the trigger ߜ Other trigger properties When the trigger is in place, the SQL Server 2005 Express engine consults... installed on your server, as well as go through some examples of some particularly appealing components 219 220 Part V: Putting the Tools to Work: Programming with SQL Server 2005 Express Getting a list of stored procedures and functions Using SQL Server Management Studio Express (which you can download free from Microsoft) , you can figure out what you have available on your SQL Server 2005 Express system,... Transact -SQL, or if you’re using SQLCLR (the Microsoft NET Framework Common Language Runtime) Using Transact -SQL As it turns out, in most cases Transact -SQL can meet your processing needs If you’re unsure about whether to use Transact -SQL or SQLCLR, see the next section for more about when SQLCLR is the right choice 223 224 Part V: Putting the Tools to Work: Programming with SQL Server 2005 Express. .. Putting the Tools to Work: Programming with SQL Server 2005 Express Y In this part ou’ll primarily use SQL Server 2005 Express as a data repository in conjunction with packaged, pre-built tools and applications However, you may use it as the foundation of a new application If you’re building a new solution that relies on SQL Server 2005 Express, this part is for you Initially, I show you how to extend... you can also take advantage of the many built-in stored procedures and functions offered by SQL Server 2005 Express If you write your own, you can use Transact -SQL or another Microsoft NET programming language if you have enabled SQLCLR 2 16 Part V: Putting the Tools to Work: Programming with SQL Server 2005 Express These helpful objects offer a number of marvelous benefits: ߜ Better accuracy: In any... (less than 60 seconds), the database server shuffles its resources to dedicate more to the job of getting your checkpoint done quickly Conversely, a high value lets SQL Server 2005 Express make its own decisions about how to allocate resources to get checkpoints done as quickly as possible Unless you’re really worried about squeezing the last bit of performance out of your SQL Server 2005 Express system,... a password for a SQL Server 2005 Express login • sp_defaultdb: You can use this procedure to change the default database for a given SQL Server 2005 Express login Figure 14-2: Output from the sp_ helpdb and sp_ depends system stored procedures Chapter 14: Using Stored Procedures and Functions Figure 14-3: Output from the sp_data type_info and sp_ columns system stored procedures If you forget to include... objects: 221 222 Part V: Putting the Tools to Work: Programming with SQL Server 2005 Express ߜ Administrative: These types of procedures enable SQL Server 2005 Express administrators to configure, manage, and monitor their own unique database server Figure 14-2 shows the output of two procedures The sp_helpdb procedure returns high-level information about your database, while the sp_depends procedure cites... backup utility is built into SQL Server 2005 Express Numerous third-party applications also handle database backups; you might want to use one of these tools instead However, for this chapter, I assume that you’re using built-in backup capabilities in SQL Server Management Studio Express, available via a free download from Microsoft 2 Connect to the right instance of your database server 3 Expand the Databases... dynamic information coupled with intolerance for data loss or system outages is one that needs a robust backup strategy, perhaps even one that is not provided by a product such as SQL Server 2005 Express On the other hand, if you have relatively static data or have deployed alternative redundancy measures, you may not need a very strict data archiving regimen Recovery models The full SQL Server 2005 product . a 6 into that column, SQL Server 2005 Express rolls the whole transaction back, even for any other tables or columns that were not violated. ߜ Integrity: In the context of a SQL Server 2005 Express. database information, SQL Server 2005 Express accumu- lates data on pages within a section of server memory known as the buffer cache. When you create, modify, or remove data, SQL Server 2005 Express records. Safe from Harm 20_599275 ch13.qxp 6/ 1/ 06 8: 46 PM Page 212 Part V Putting the Tools to Work: Programming with SQL Server 2005 Express 21_599275 pt05.qxp 6/ 1/ 06 8: 46 PM Page 213