Flylib.com

Books Software

 
 
 

Suggested Practices


Suggested Practices

Objective 4.2: Design the Locking Granularity Level

  • Practice 1 Create a simple table with one column and no primary key. Insert two rows into the table. Start a transaction (without committing it), and update one of the rows in the table. In another connection, try to read the unaffected row, both rows, and the affected row, and watch the result. Do this for all different isolation levels (including read committed snapshot), and observe the differences in behavior.

Objective 4.4: Design Code that Uses Transactions

  • Practice 1 Create a simple table with one integer column, and declare it as the table's primary key. Within a user -defined transaction, insert the values 1, 1, and 2 into the table. Check whether any rows were persisted into the table (or if they were rolled back). Experiment with using the SET XACT_ABORT ON setting as well as using a try/catch block around the transaction. Also, always issue a SELECT XACT_STATE(); query at the end of each batch to see the state of the transaction.



References

  • Lock Compatibility

    http://msdn2.microsoft.com/en-us/library/aa213041(SQL.80).aspx.

  • Locking Hints

    http://msdn2.microsoft.com/en-us/library/ms189857.aspx

  • Table Hint (Transact-SQL)

    http://msdn2.microsoft.com/en-us/library/ms187373.aspx.

  • Using Snapshot Isolation

    http://msdn2.microsoft.com/en-us/library/tcbchxcb.aspx

  • "The Rational Guide to SQL Server 2005 Service Broker" by Roger Wolter (Rational Press, 2006)



Chapter Summary

  • The choice of transaction isolation level affects both query results and performance because of blocking and row versioning.

  • Use the least restrictive transaction isolation level.

  • When a more restrictive transaction isolation level is required, consider applying table locking hints rather than specifying transaction isolation level on the session level using the SET TRANSACTION ISOLATION LEVEL statement.

  • Keep transactions short. Open the transaction as late as possible, and close it as early as possible.

  • Design transactions to minimize deadlocks.

  • Consider alternate solutions to locking by using the @@ROWCOUNT function and the OUTPUT clause.

  • When not rolling back a transaction in a try/catch block, always verify that the transaction is not uncommittable by querying the XACT_STATE() function.



Chapter 7: Optimizing SQL Server 2005 Performance

Overview

Database optimization is a compelling part of the database developer's job role. The difference in performance between a well-optimized database and a non-optimized database can be enormous . Working with optimization demands a keen eye for details and an interest in understanding how the database engine works. The more you learn about what Microsoft SQL Server actually needs to do to complete a task, the greater your chance will be to successfully optimize the database. In a sense, you must try to "become" SQL Server.

The task of optimizing a database can be broken down into subtasks , including: optimizing queries and database routines, creating appropriate indexes, and normalizing and de-normalizing the database. (Database normalization is beyond the scope of this training kit.)

Exam objectives in this chapter:

  • Optimize and tune queries for performance.

    • Evaluate query performance.

  • Analyze query plans.

  • Modify queries to improve performance.

  • Test queries for improved performance.

    • Detect locking problems.

    • Modify queries to optimize client and server performance.

    • Rewrite subqueries to joins.

    • Design queries that have search arguments (SARGs).

    • Convert single-row statements into set-based queries.

  • Optimize indexing strategies.

    • Design an index strategy.

    • Analyze index use across an application.

    • Add, remove, or redesign indexes.

    • Optimize index-to-table- size ratio.

  • Optimize data storage.

    • Choose column data types to reduce storage requirements across the enterprise.

    • Design appropriate use of varchar across the enterprise.

    • Denormalize entities to minimize page reads per query.

    • Optimize table width.