* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Locks and Concurrency
Survey
Document related concepts
Entity–attribute–value model wikipedia , lookup
Clusterpoint wikipedia , lookup
Data analysis wikipedia , lookup
Information privacy law wikipedia , lookup
Commitment ordering wikipedia , lookup
Java ConcurrentMap wikipedia , lookup
Data vault modeling wikipedia , lookup
Business intelligence wikipedia , lookup
Open data in the United Kingdom wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Expense and cost recovery system (ECRS) wikipedia , lookup
Database model wikipedia , lookup
Versant Object Database wikipedia , lookup
File locking wikipedia , lookup
Transcript
SQL Server 2000 Notes Chapter 14 Page 1 of 3 Chapter 14B: Locks and Concurrency Concurrency is when two or more users try to interact with the same object at the same time. Locking is a mechanism for preventing something from being done to an object that conflicts with something already being done to that object. o Locking can be implemented with transaction isolation levels o Locking can be implemented with optimizer hints Five types of concurrency issues: o Dirty reads – when a transaction reads a record that us part of another transaction that isn’t complete yet o Unrepeatable reads – when a transaction reads a record twice in the same transaction, and the data is altered in the interim. o Phantoms – when a transaction makes an update, but another transaction inserts a record at the same time that would meet the WHERE criteria of that update o Lost updates – when one transaction makes a successful update, and then another transaction comes along that undoes that update. o Deadlocks – a situation where two transactions can not proceed because each is holding a lock on the resource the other transaction needs Lockable resources: o Database (can happen during schema changes) o Table – includes all rows, keys, indexes, etc. o Extent – 8 pages… o Page – all data or index on a page o Key – a lock on a particular key o Row Identifier (RID) – used for locking a row Escalation occurs when SQL Server locks more and more resources to conserve overhead – e.g., you might think you are locking a few rows, but they turn out to be so numerous that SQL Server may lock the page, extent, or even table holding them. Lock Modes – i.e., ways to lock resources o Shared Locks – indicates data is being looked at, but is still available – useful for preventing dirty reads o Exclusive Locks – a lock that prevents anyone else from changing locked data or placing another lock on the data o Update Locks – places a shared lock on data until the WHERE clause is evaluated, then places an exclusive lock on the data once the update is to occur – useful for preventing deadlocks o Intent Shared Locks – indicates a shared lock is or will be established at a lower level of the database hierarchy o Intent Exclusive Lock - indicates an exclusive lock is or will be established at a lower level of the database hierarchy o Shared with Intent Exclusive Lock – kind of indicates an update lock will be established at a lower level of the database hierarchy o Schema modification lock – no changes can be made to an object because a schema change is being made o Schema stability lock - ??? o Bulk update lock – locks a table while bulk inserts or bcp operations are being performed SQL Server 2000 Notes Chapter 14 Page 2 of 3 You can specify your own lock type instead of relying on the lock manager…use the optimizer hint in the SELECT statement: o Syntax: SELECT <fields> FROM <table> [AS < alias >] [[WITH] (<hint>)] o SERIALIZABLE / HOLDLOCK – indicates that a lock is not to be released until a transaction is ended (via ROLLBACK or COMMIT) – highest isolation level – guarantees absolute data consistency o READUNCOMITTED / NOLOCK – obtains no lock, and honors no other locks – very fast – can generate dirty reads, etc. … o READCOMMITTED – default hint – honors all locks, but releases all locks as soon as the object in question is no longer needed – same as READ COMMITTED isolation level o REPEATABLEREAD – lock is not released by a statement in a transaction until the transaction is ended – new data can be inserted o READPAST – skip all locked rows when reading o ROWLOCK – sets a row level lock o PAGLOCK – sets a page level lock o TABLOCK – locks a whole table – can speed up table scanning, but also create big concurrency issues o TABLOCKX – creates an exclusive lock on the whole table for duration of statement or transaction (depending on TRANSACTION ISOLATION LEVEL) o UPDLOCK – sets an update lock o XLOCK – specifies an exclusive lock to be held on a table or page o Example: SELECT * FROM Orders as O WITH (PAGLOCK) Isolation level of a transaction: o Syntax: SET TRANSACTION ISOLATION LEVEL <READ COMMITTED | READ UNCOMMITTED | REPEATABLE READ | SERIALIZABLE> o READ COMMITTED - Specifies that shared locks are held while the data is being read to avoid dirty reads, but the data can be changed before the end of the transaction, resulting in nonrepeatable reads or phantom data. This option is the SQL Server default. o READ UNCOMMITTED - Implements dirty read, or isolation level 0 locking, which means that no shared locks are issued and no exclusive locks are honored. When this option is set, it is possible to read uncommitted or dirty data; values in the data can be changed and rows can appear or disappear in the data set before the end of the transaction. This option has the same effect as setting NOLOCK on all tables in all SELECT statements in a transaction. This is the least restrictive of the four isolation levels. o REPEATABLE READ - Locks are placed on all data that is used in a query, preventing other users from updating the data, but new phantom rows can be inserted into the data set by another user and are included in later reads in the current transaction. Because concurrency is lower than the default isolation level, use this option only when necessary. o SERIALIZABLE - Places a range lock on the data set, preventing other users from updating or inserting rows into the data set until the transaction is complete. This is the most restrictive of the four isolation levels. Because concurrency is lower, use this option only when necessary. This option has the same effect as setting HOLDLOCK on all tables in all SELECT statements in a transaction. SQL Server 2000 Notes Chapter 14 Page 3 of 3 Three “styles” of using locks: 1. Very Optimistic – assume everything will be A-okay… Example: select records for updating where the OrderID = 10249 2. Very Pessimistic – lock all records before user even begins to update them Repeat Example: select records for updating where the OrderID = 10249 3. Optimistic with Timestamps – check to see if the row changed while your transaction was working Repeat example again: