Download Performance Extracts from Books Online

Performance Extracts from Books Online
Online Transaction Processing Design Considerations
Transaction processing system databases should be designed to promote:

Good data placement.
I/O bottlenecks are a big concern for OLTP systems due to the number of users
modifying data all over the database. Determine the likely access patterns of the
data and place frequently accessed data together. Use filegroups and RAID
(redundant array of independent disks) systems to assist in this.

Short transactions to minimize long-term locks and improve concurrency.
Avoid user interaction during transactions. Whenever possible, execute a single
stored procedure to process the entire transaction. The order in which you
reference tables within your transactions can affect concurrency. Place references
to frequently accessed tables at the end of the transaction to minimize the duration
that locks are held.

Online backup.
OLTP systems are often characterized by continuous operations (24 hours a day,
7 days a week) for which downtime is kept to an absolute minimum. Although
Microsoft® SQL Server™ 2000 can back up a database while it is being used,
schedule the backup process to occur during times of low activity to minimize
effects on users.

High normalization of the database.
Reduce redundant information as much as possible to increase the speed of
updates and hence improve concurrency. Reducing data also improves the speed
of backups because less data needs to be backed up.

Little or no historical or aggregated data.
Data that is rarely referenced can be archived into separate databases, or moved
out of the heavily updated tables into tables containing only historical data. This
keeps tables as small as possible, improving backup times and query performance.

Careful use of indexes.
Indexes must be updated each time a row is added or modified. To avoid overindexing heavily updated tables, keep indexes narrow. Use the Index Tuning
Wizard to design your indexes.

Optimum hardware configuration to handle the large numbers of concurrent users
and quick response times required by an OLTP system.
Locking
Microsoft® SQL Server™ 2000 uses locking to ensure transactional integrity and
database consistency. Locking prevents users from reading data being changed by other
users, and prevents multiple users from changing the same data at the same time. If
locking is not used, data within the database may become logically incorrect, and queries
executed against that data may produce unexpected results.
Although SQL Server enforces locking automatically, you can design applications that
are more efficient by understanding and customizing locking in your applications.
Locking Architecture
A lock is an object used by software to indicate that a user has some dependency on a
resource. The software does not allow other users to perform operations on the resource
that would adversely affect the dependencies of the user owning the lock. Locks are
managed internally by system software and are acquired and released based on actions
taken by the user.
Microsoft® SQL Server™ 2000 uses locks to implement pessimistic concurrency control
among multiple users performing modifications in a database at the same time. By
default, SQL Server manages both transactions and locks on a per connection basis. For
example, if an application opens two SQL Server connections, locks acquired by one
connection cannot be shared with the other connection. Neither connection can acquire
locks that would conflict with locks held by the other connection. Only bound
connections are not affected by this rule. For more information, see Using Bound
Connections.
SQL Server locks are applied at various levels of granularity in the database. Locks can
be acquired on rows, pages, keys, ranges of keys, indexes, tables, or databases. SQL
Server dynamically determines the appropriate level at which to place locks for each
Transact-SQL statement. The level at which locks are acquired can vary for different
objects referenced by the same query; for example one table may be very small and have
a table lock applied, while another, larger table may have row locks applied. The level at
which locks are applied does not have to be specified by users and needs no configuration
by administrators. Each instance of SQL Server ensures that locks granted at one level of
granularity respect locks granted at another level. For example, if UserA attempts to
acquire a share lock on a row, the instance of SQL Server also attempts to acquire intent
share locks on the page and the table. If UserB has an exclusive lock at the page or table
level, UserA is blocked from acquiring locks until the lock held by UserB is freed.
There are several lock modes: shared, update, exclusive, intent, and schema. The lock
mode indicates the level of dependency the connection has on the locked object. SQL
Server controls how the lock modes interact. For example, an exclusive lock cannot be
obtained if other connections hold shared locks on the resource.
Locks are held for the length of time needed to protect the resource at the level requested:

The duration of share locks used to protect reads depends on the transaction
isolation levels. At the default transaction isolation level of READ
COMMITTED, a share lock is held only as long as it takes to read a page. In
scans, the lock is held until a lock is acquired on the next page in a scan. If the
HOLDLOCK hint is specified, or the transaction isolation level is set to either
REPEATABLE READ or SERIALIZABLE, the locks are held to the end of the
transaction.

Depending on the concurrency options set for a cursor, the cursor may acquire
shared-mode, scroll locks to protect fetches. When scroll locks are needed, they
are held until the next fetch or the closing of the cursor, whichever happens first.
If HOLDLOCK is specified, however, the scroll locks are held until the end of the
transaction.

Exclusive locks used to protect updates are held until the end of the transaction.
If a connection attempts to acquire a lock that conflicts with a lock held by another
connection, the connection attempting to acquire the lock is blocked until:

The conflicting lock is freed and the connection acquires the lock it requested.

The time-out interval for the connection expires. By default, there is no time-out
interval, but some applications set a time-out interval to prevent an indefinite
wait.
If several connections become blocked waiting for conflicting locks on a single resource,
the locks are granted on a first-come, first-serve basis as the preceding connections free
their locks.
SQL Server has an algorithm to detect deadlocks, a condition where two connections
have blocked each other. If an instance of SQL Server detects a deadlock, it will
terminate one transaction, allowing the other to continue. For more information, see
Deadlocking.
SQL Server may dynamically escalate or deescalate the granularity or type of locks. For
example, if an update acquires a large number of row locks and has locked a significant
percentage of a table, the row locks are escalated to a table lock. If a table lock is
acquired, the row locks are released. SQL Server 2000 rarely needs to escalate locks; the
query optimizer usually chooses the correct lock granularity at the time the execution
plan is compiled.