社区
VB基础类
帖子详情
关于ADO,begintran的问题
normandj
2005-10-25 03:34:06
我在一个地方使用了 connection.begintrans,但一动行到那句,就会有“Cannot create new transaction because capacity was exceeded.”,请教是什么意思?如何解决?
...全文
113
4
打赏
收藏
关于ADO,begintran的问题
我在一个地方使用了 connection.begintrans,但一动行到那句,就会有“Cannot create new transaction because capacity was exceeded.”,请教是什么意思?如何解决?
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
4 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
fxy_2002
2005-11-16
打赏
举报
回复
可能是游标不对,设置 conn.CursorLocation = adUseClient 试试
当然,这还需要你的数据库支持事务才行。如果 ado 连接的是 excel,事务当然不能启动。
normandj
2005-11-16
打赏
举报
回复
up
normandj
2005-10-25
打赏
举报
回复
还是没看出原因?
事务太长? 是什么概念?只开始就太长?
winehero
2005-10-25
打赏
举报
回复
http://search.csdn.net/Expert/topic/2274/2274273.xml?temp=.8864557
ADO
.NET实用技巧两则
要想充分发挥
ADO
.NET的优势,不仅需要全面、深入理解
ADO
.NET编程模型,及时总结经验、技巧也十分重要。
ADO
已经有多年的实践经验,
ADO
.NET以此为基础,提供了更加丰富、强大的工具;尽管如此,
ADO
.NET的设计目标毕竟不是提供一个即插即用的工具,它不会把所有的编程工作简化到仅靠鼠标点击就可以完成的程度。
ADO
.NET包含了一大堆代表数据访问模型中各种逻辑实体的对象,其中尤以连接、事务这两个对象最为重要。连接的作用是建立一个与后端数据库通信的通道,创建连接对象必须以特定的.NET数据提供者为基础。事务对象可以在已有的连接对象上创建,也可以通过显式地执行一个BE
GIN
TRAN
微软内部资料-SQL性能优化3
Contents Overview 1 Lesson 1: Concepts – Locks and Lock Manager 3 Lesson 2: Concepts – Batch and
Tran
saction 31 Lesson 3: Concepts – Locks and Applications 51 Lesson 4: Information Collection and Analysis 63 Lesson 5: Concepts – Formulating and Implementing Resolution 81 Module 4: Troubleshooting Locking and Blocking Overview At the end of this module, you will be able to: Discuss how lock manager uses lock mode, lock resources, and lock compatibility to achieve
tran
saction isolation. Describe the various
tran
saction types and how
tran
sactions differ from batches. Describe how to troubleshoot blocking and locking issues. Analyze the output of blocking scripts and Microsoft® SQL Server™ Profiler to troubleshoot locking and blocking issues. Formulate hypothesis to resolve locking and blocking issues. Lesson 1: Concepts – Locks and Lock Manager This lesson outlines some of the common causes that contribute to the perception of a slow server. What You Will Learn After completing this lesson, you will be able to: Describe locking architecture used by SQL Server. Identify the various lock modes used by SQL Server. Discuss lock compatibility and concurrent access. Identify different types of lock resources. Discuss dynamic locking and lock escalation. Differentiate locks, latches, and other SQL Server internal “locking” mechanism such as spinlocks and other synchronization objects. Recommended Reading Chapter 14 “Locking”, Inside SQL Server 2000 by Kalen Delaney SOX000821700049 – SQL 7.0 How to interpret lock resource Ids SOX000925700237 – TITLE: Lock escalation in SQL 7.0 SOX001109700040 – INF: Queries with PREFETCH in the plan hold lock until the end of
tran
saction Locking Concepts Delivery Tip Prior to delivering this material, test the class to see if they fully understand the different isolation levels. If the class is not confident in their understanding, review appendix A04_Locking and its accompanying PowerPoint® file.
Tran
sactions in SQL Server provide the ACID properties: Atomicity A
tran
saction either commits or aborts. If a
tran
saction commits, all of its effects remain. If it aborts, all of its effects are undone. It is an “all or nothing” operation. Consistency An application should maintain the consistency of a database. For example, if you defer constraint checking, it is your responsibility to ensure that the database is consistent. Isolation Concurrent
tran
sactions are isolated from the updates of other incomplete
tran
sactions. These updates do not constitute a consistent state. This property is often called serializability. For example, a second
tran
saction traversing the doubly linked list mentioned above would see the list before or after the insert, but it will see only complete changes. Durability After a
tran
saction commits, its effects will persist even if there are system failures. Consistency and isolation are the most important in describing SQL Server’s locking model. It is up to the application to define what consistency means, and isolation in some form is needed to achieve consistent results. SQL Server uses locking to achieve isolation. Definition of Dependency: A set of
tran
sactions can run concurrently if their outputs are disjoint from the union of one another’s input and output sets. For example, if T1 writes some object that is in T2’s input or output set, there is a dependency between T1 and T2. Bad Dependencies These include lost updates, dirty reads, non-repeatable reads, and phantoms. ANSI SQL Isolation Levels An isolation level determines the degree to which data is isolated for use by one process and guarded against interference from other processes. Prior to SQL Server 7.0, REPEATABLE READ and SERIALIZABLE isolation levels were synonymous. There was no way to prevent non-repeatable reads while not preventing phantoms. By default, SQL Server 2000 operates at an isolation level of READ COMMITTED. To make use of either more or less strict isolation levels in applications, locking can be customized for an entire session by setting the isolation level of the session with the SET
TRAN
SACTION ISOLATION LEVEL statement. To determine the
tran
saction isolation level currently set, use the DBCC USEROPTIONS statement, for example: USE pubs GO SET
TRAN
SACTION ISOLATION LEVEL REPEATABLE READ GO DBCC USEROPTIONS GO Multigranular Locking Multigranular Locking In our example, if one
tran
saction (T1) holds an exclusive lock at the table level, and another
tran
saction (T2) holds an exclusive lock at the row level, each of the
tran
sactions believe they have exclusive access to the resource. In this scenario, since T1 believes it locks the entire table, it might inadvertently make changes to the same row that T2 thought it has locked exclusively. In a multigranular locking environment, there must be a way to effectively overcome this scenario. Intent lock is the answer to this problem. Intent Lock Intent Lock is the term used to mean placing a marker in a higher-level lock queue. The type of intent lock can also be called the multigranular lock mode. An intent lock indicates that SQL Server wants to acquire a shared (S) lock or exclusive (X) lock on some of the resources lower down in the hierarchy. For example, a shared intent lock placed at the table level means that a
tran
saction intends on placing shared (S) locks on pages or rows within that table. Setting an intent lock at the table level prevents another
tran
saction from subsequently acquiring an exclusive (X) lock on the table containing that page. Intent locks improve performance because SQL Server examines intent locks only at the table level to determine whether a
tran
saction can safely acquire a lock on that table. This removes the requirement to examine every row or page lock on the table to determine whether a
tran
saction can lock the entire table. Lock Mode The code shown in the slide represents how the lock mode is stored internally. You can see these codes by querying the master.dbo.spt_values table: SELECT * FROM master.dbo.spt_values WHERE type = N'L' However, the req_mode column of master.dbo.syslockinfo has lock mode code that is one less than the code values shown here. For example, value of req_mode = 3 represents the Shared lock mode rather than the Schema Modification lock mode. Lock Compatibility These locks can apply at any coarser level of granularity. If a row is locked, SQL Server will apply intent locks at both the page and the table level. If a page is locked, SQL Server will apply an intent lock at the table level. SIX locks imply that we have shared access to a resource and we have also placed X locks at a lower level in the hierarchy. SQL Server never asks for SIX locks directly, they are always the result of a conversion. For example, suppose a
tran
saction scanned a page using an S lock and then subsequently decided to perform a row level update. The row would obtain an X lock, but now the page would require an IX lock. The resultant mode on the page would be SIX. Another type of table lock is a schema stability lock (Sch-S) and is compatible with all table locks except the schema modification lock (Sch-M). The schema modification lock (Sch-M) is incompatible with all table locks. Locking Resources Delivery Tip Note the differences between Key and Key Range locks. Key Range locks will be covered in a couple of slides. SQL Server can lock these resources: Item Description DB A database. File A database file Index An entire index of a table. Table An entire table, including all data and indexes. Extent A contiguous group of data pages or index pages. Page An 8-KB data page or index page. Key Row lock within an index. Key-range A key-range. Used to lock ranges between records in a table to prevent phantom insertions or deletions into a set of records. Ensures serializable
tran
sactions. RID A Row Identifier. Used to individually lock a single row within a table. Application A lock resource defined by an application. The lock manager knows nothing about the resource format. It simply compares the 'strings' representing the lock resources to determine whether it has found a match. If a match is found, it knows that resource is already locked. Some of the resources have “sub-resources.” The followings are sub-resources displayed by the sp_lock output: Database Lock Sub-Resources: Full Database Lock (default) [BULK-OP-DB] – Bulk Operation Lock for Database [BULK-OP-LOG] – Bulk Operation Lock for Log Table Lock Sub-Resources: Full Table Lock (default) [UPD-STATS] – Update statistics Lock [COMPILE] – Compile Lock Index Lock sub-Resources: Full Index Lock (default) [INDEX_ID] – Index ID Lock [INDEX_NAME] – Index Name Lock [BULK_ALLOC] – Bulk Allocation Lock [DEFRAG] – Defragmentation Lock For more information, see also… SOX000821700049 SQL 7.0 How to interpret lock resource Ids Lock Resource Block The resource type has the following resource block format: Resource Type (Code) Content DB (2) Data 1: sub-resource; Data 2: 0; Data 3: 0 File (3) Data 1: File ID; Data 2: 0; Data 3: 0 Index (4) Data 1: Object ID; Data 2: sub-resource; Data 3: Index ID Table (5) Data 1: Object ID; Data 2: sub-resource; Data 3: 0. Page (6) Data 1: Page Number; Data 3: 0. Key (7) Data 1: Object ID; Data 2: Index ID; Data 3: Hashed Key Extent (8) Data 1: Extent ID; Data 3: 0. RID (9) Data 1: RID; Data 3: 0. Application (10) Data 1: Application resource name The rsc_bin column of master..syslockinfo contains the resource block in hexadecimal format. For an example of how to decode value from this column using the information above, let us assume we have the following value: 0x000705001F83D775010002014F0BEC4E With byte swapping within each field, this can be decoded as: Byte 0: Flag – 0x00 Byte 1: Resource Type – 0x07 (Key) Byte 2-3: DBID – 0x0005 Byte 4-7: ObjectID – 0x 75D7831F (1977058079) Byte 8-9: IndexID – 0x0001 Byte 10-16: Hash Key value – 0x 02014F0BEC4E For more information about how to decode this value, see also… Inside SQL Server 2000, pages 803 and 806. Key Range Locking Key Range Locking To support SERIALIZABLE
tran
saction semantics, SQL Server needs to lock sets of rows specified by a predicate, such as WHERE salary BETWEEN 30000 AND 50000 SQL Server needs to lock data that does not exist! If no rows satisfy the WHERE condition the first time the range is scanned, no rows should be returned on any subsequent scans. Key range locks are similar to row locks on index keys (whether clustered or not). The locks are placed on individual keys rather than at the node level. The hash value consists of all the key components and the locator. So, for a nonclustered index over a heap, where columns c1 and c2 where indexed, the hash would contain contributions from c1, c2 and the RID. A key range lock applied to a particular key means that all keys between the value locked and the next value would be locked for all data modification. Key range locks can lock a slightly larger range than that implied by the WHERE clause. Suppose the following select was executed in a
tran
saction with isolation level SERIALIZABLE: SELECT * FROM members WHERE first_name between ‘Al’ and ‘Carl’ If 'Al', 'Bob', and 'Dave' are index keys in the table, the first two of these would acquire key range locks. Although this would prevent anyone from inserting either 'Alex' or 'Ben', it would also prevent someone from inserting 'Dan', which is not within the range of the WHERE clause. Prior to SQL Server 7.0, page locking was used to prevent phantoms by locking the entire set of pages on which the phantom would exist. This can be too conservative. Key Range locking lets SQL Server lock only a much more restrictive area of the table. Impact Key-range locking ensures that these scenarios are SERIALIZABLE: Range scan query Singleton fetch of nonexistent row Delete operation Insert operation However, the following conditions must be satisfied before key-range locking can occur: The
tran
saction-isolation level must be set to SERIALIZABLE. The operation performed on the data must use an index range access. Range locking is activated only when query processing (such as the optimizer) chooses an index path to access the data. Key Range Lock Mode Again, the req_mode column of master.dbo.syslockinfo has lock mode code that is one less than the code values shown here. Dynamic Locking When modifying individual rows, SQL Server typically would take row locks to maximize concurrency (for example, OLTP, order-entry application). When scanning larger volumes of data, it would be more appropriate to take page or table locks to minimize the cost of acquiring locks (for example, DSS, data warehouse, reporting). Locking Decision The decision about which unit to lock is made dynamically, taking many factors into account, including other activity on the system. For example, if there are multiple
tran
sactions currently accessing a table, SQL Server will tend to favor row locking more so than it otherwise would. It may mean the difference between scanning the table now and paying a bit more in locking cost, or having to wait to acquire a more coarse lock. A preliminary locking decision is made during query optimization, but that decision can be adjusted when the query is actually executed. Lock Escalation When the lock count for the
tran
saction exceeds and is a multiple of ESCALATION_THRESHOLD (1250), the Lock Manager attempts to escalate. For example, when a
tran
saction acquired 1250 locks, lock manager will try to escalate. The number of locks held may continue to increase after the escalation attempt (for example, because new tables are accessed, or the previous lock escalation attempts failed due to incompatible locks held by another spid). If the lock count for this
tran
saction reaches 2500 (1250 * 2), Lock Manager will attempt escalation again. The Lock Manager looks at the lock memory it is using and if it is more than 40 percent of SQL Server’s allocated buffer pool memory, it tries to find a scan (SDES) where no escalation has already been performed. It then repeats the search operation until all scans have been escalated or until the memory used drops under the MEMORY_LOAD_ESCALATION_THRESHOLD (40%) value. If lock escalation is not possible or fails to significantly reduce lock memory footprint, SQL Server can continue to acquire locks until the total lock memory reaches 60 percent of the buffer pool (MAX_LOCK_RESOURCE_MEMORY_PERCENTAGE=60). Lock escalation may be also done when a single scan (SDES) holds more than LOCK_ESCALATION_THRESHOLD (765) locks. There is no lock escalation on temporary tables or system tables. Trace Flag 1211 disables lock escalation. Important Do not relay this to the customer without careful consideration. Lock escalation is a necessary feature, not something to be avoided completely. Trace flags are global and disabling lock escalation could lead to out of memory situations, extremely poor performing queries, or other problems. Lock escalation tracing can be seen using the Profiler or with the general locking trace flag, -T1200. However, Trace Flag 1200 shows all lock activity so it should not be usable on a production system. For more information, see also… SOX000925700237 “TITLE: SQL 7.0 Lock escalation in SQL 7.0” Lock Timeout Application Lock Timeout An application can set lock timeout for a session with the SET option: SET LOCK_TIMEOUT N where N is a number of milliseconds. A value of -1 means that there will be no timeout, which is equivalent to the version 6.5 behavior. A value of 0 means that there will be no waiting; if a process finds a resource locked, it will generate error message 1222 and continue with the next statement. The current value of LOCK_TIMEOUT is stored in the global variable @@lock_timeout. Note After a lock timeout any
tran
saction containing the statement, is rolled back or canceled by SQL Server 2000 (bug#352640 was filed). This behavior is different from that of SQL Server 7.0. With SQL Server 7.0, the application must have an error handler that can trap error 1222 and if an application does not trap the error, it can proceed unaware that an individual statement within a
tran
saction has been canceled, and errors can occur because statements later in the
tran
saction may depend on the statement that was never executed. Bug#352640 is fixed in hotfix build 8.00.266 whereby a lock timeout will only Internal Lock Timeout At time, internal operations within SQL Server will attempt to acquire locks via lock manager. Typically, these lock requests are issued with “no waiting.” For example, the ghost record processing might try to clean up rows on a particular page, and before it can do that, it needs to lock the page. Thus, the ghost record manager will request a page lock with no wait so that if it cannot lock the page, it will just move on to other pages; it can always come back to this page later. If you look at SQL Profiler Lock: Timeout events, internal lock timeout typically have a duration value of zero. Lock Duration Lock Mode and
Tran
saction Isolation Level For REPEATABLE READ
tran
saction isolation level, update locks are held until data is read and processed, unless promoted to exclusive locks. "Data is processed" means that we have decided whether the row in question matched the search criteria; if not then the update lock is released, otherwise, we get an exclusive lock and make the modification. Consider the following query: use northwind go dbcc traceon(3604, 1200, 1211) -- turn on lock tracing -- and disable escalation go set
tran
saction isolation level repeatable read be
gin
tran
update dbo.[order details] set discount = convert (real, discount) where discount = 0.0 exec sp_lock Update locks are promoted to exclusive locks when there is a match; otherwise, the update lock is released. The sp_lock output verifies that the SPID does not hold any update locks or shared locks at the end of the query. Lock escalation is turned off so that exclusive table lock is not held at the end. Warning Do not use trace flag 1200 in a production environment because it produces a lot of output and slows down the server. Trace flag 1211 should not be used unless you have done extensive study to make sure it helps with performance. These trace flags are used here for illustration and learning purposes only. Lock Ownership Most of the locking discussion in this lesson relates to locks owned by “
tran
sactions.” In addition to
tran
saction, cursor and session can be owners of locks and they both affect how long locks are held. For every row that is fetched, when SCROLL_LOCKS option is used, regardless of the state of a
tran
saction, a cursor lock is held until the next row is fetched or when the cursor is closed. Locks owned by session are outside the scope of a
tran
saction. The duration of these locks are bounded by the connection and the process will continue to hold these locks until the process disconnects. A typical lock owned by session is the database (DB) lock. Locking – Read Committed Scan Under read committed isolation level, when database pages are scanned, shared locks are held when the page is read and processed. The shared locks are released “behind” the scan and allow other
tran
sactions to update rows. It is important to note that the shared lock currently acquired will not be released until shared lock for the next page is successfully acquired (this is commonly know as “crabbing”). If the same pages are scanned again, rows may be modified or deleted by other
tran
sactions. Locking – Repeatable Read Scan Under repeatable read isolation level, when database pages are scanned, shared locks are held when the page is read and processed. SQL Server continues to hold these shared locks, thus preventing other
tran
sactions to update rows. If the same pages are scanned again, previously scanned rows will not change but new rows may be added by other
tran
sactions. Locking – Serializable Read Scan Under serializable read isolation level, when database pages are scanned, shared locks are held not only on rows but also on scanned key range. SQL Server continues to hold these shared locks until the end of
tran
saction. Because key range locks are held, not only will this prevent other
tran
sactions from modifying the rows, no new rows can be inserted. Prefetch and Isolation Level Prefetch and Locking Behavior The prefetch feature is available for use with SQL Server 7.0 and SQL Server 2000. When searching for data using a nonclustered index, the index is searched for a particular value. When that value is found, the index points to the disk address. The traditional approach would be to immediately issue an I/O for that row, given the disk address. The result is one synchronous I/O per row and, at most, one disk at a time working to evaluate the query. This does not take advantage of striped disk sets. The prefetch feature takes a different approach. It continues looking for more record pointers in the nonclustered index. When it has collected a number of them, it provides the storage en
gin
e with prefetch hints. These hints tell the storage en
gin
e that the query processor will need these particular records soon. The storage en
gin
e can now issue several I/Os simultaneously, taking advantage of striped disk sets to execute multiple operations simultaneously. For example, if the en
gin
e is scanning a nonclustered index to determine which rows qualify but will eventually need to visit the data page as well to access columns that are not in the index, it may decide to submit asynchronous page read requests for a group of qualifying rows. The prefetch data pages are then revisited later to avoid waiting for each individual page read to complete in a serial fashion. This data access path requires that a lock be held between the prefetch request and the row lookup to stabilize the row on the page so it is not to be moved by a page split or clustered key update. For our example, the isolation level of the query is escalated to REPEATABLE READ, overriding the
tran
saction isolation level. With SQL Server 7.0 and SQL Server 2000, portions of a
tran
saction can execute at a different
tran
saction isolation level than the entire
tran
saction itself. This is implemented as lock classes. Lock classes are used to control lock lifetime when portions of a
tran
saction need to execute at a stricter isolation level than the underlying
tran
saction. Unfortunately, in SQL Server 7.0 and SQL Server 2000, the lock class is created at the topmost operator of the query and hence released only at the end of the query. Currently there is no support to release the lock (lock class) after the row has been discarded or fetched by the filter or join operator. This is because isolation level can be set at the query level via a lock class, but no lower. Because of this, locks acquired during the query will not be released until the query completes. If prefetch is occurring you may see a single SPID that holds hundreds of Shared KEY or PAG locks even though the connection’s isolation level is READ COMMITTED. Isolation level can be determined from DBCC PSS output. For details about this behavior see “SOX001109700040 INF: Queries with PREFETCH in the plan hold lock until the end of
tran
saction”. Other Locking Mechanism Lock manager does not manage latches and spinlocks. Latches Latches are internal mechanisms used to protect pages while doing operations such as placing a row physically on a page, compressing space on a page, or retrieving rows from a page. Latches can roughly be divided into I/O latches and non-I/O latches. If you see a high number of non-I/O related latches, SQL Server is usually doing a large number of hash or sort operations in tempdb. You can monitor latch activities via DBCC SQLPERF(‘WAITSTATS’) command. Spinlock A spinlock is an internal data structure that is used to protect vital information that is shared within SQL Server. On a multi-processor machine, when SQL Server tries to access a particular resource protected by a spinlock, it must first acquire the spinlock. If it fails, it executes a loop that will check to see if the lock is available and if not, decrements a counter. If the counter reaches zero, it yields the processor to another thread and goes into a “sleep” (wait) state for a pre-determined amount of time. When it wakes, hopefully, the lock is free and available. If not, the loop starts again and it is terminated only when the lock is acquired. The reason for implementing a spinlock is that it is probably less costly to “spin” for a short time rather than yielding the processor. Yielding the processor will force an expensive context switch where: The old thread’s state must be saved The new thread’s state must be reloaded The data stored in the L1 and L2 cache are useless to the processor On a single-processor computer, the loop is not useful because no other thread can be running and thus, no one can release the spinlock for the currently executing thread to acquire. In this situation, the thread yields the processor immediately. Lesson 2: Concepts – Batch and
Tran
saction This lesson outlines some of the common causes that contribute to the perception of a slow server. What You Will Learn After completing this lesson, you will be able to: Review batch processing and error checking. Review explicit, implicit and autocommit
tran
sactions and
tran
saction nesting level. Discuss how commit and rollback
tran
saction done in stored procedure and trigger affects
tran
saction nesting level. Discuss various
tran
saction isolation level and their impact on locking. Discuss the difference between aborting a statement, a
tran
saction, and a batch. Describe how @@error, @@
tran
scount, and @@rowcount can be used for error checking and handling. Recommended Reading Charter 12 “
Tran
sactions and Triggers”, Inside SQL Server 2000 by Kalen Delaney Batch Definition SQL Profiler Statements and Batches To help further your understanding of what is a batch and what is a statement, you can use SQL Profiler to study the definition of batch and statement. Try This: Using SQL Profiler to Analyze Batch 1. Log on to a server with Query Analyzer 2. Startup the SQL Profiler against the same server 3. Start a trace using the “StandardSQLProfiler” template 4. Execute the following using Query Analyzer: SELECT @@VERSION SELECT @@SPID The ‘SQL:BatchCompleted’ event is captured by the trace. It shows both the statements as a single batch. 5. Now execute the following using Query Analyzer {call sp_who()} What shows up? The ‘RPC:Completed’ with the sp_who information. RPC is simply another entry point to the SQL Server to call stored procedures with native data types. This allows one to avoid parsing. The ‘RPC:Completed’ event should be considered the same as a batch for the purposes of this discussion. Stop the current trace and start a new trace using the “SQLProfilerTSQL_SPs” template. Issue the same command as outlines in step 5 above. Looking at the output, not only can you see the batch markers but each statement as executed within the batch. Autocommit, Explicit, and Implicit
Tran
saction Autocommit
Tran
saction Mode (Default) Autocommit mode is the default
tran
saction management mode of SQL Server. Every
Tran
sact-SQL statement, whether it is a standalone statement or part of a batch, is committed or rolled back when it completes. If a statement completes successfully, it is committed; if it encounters any error, it is rolled back. A SQL Server connection operates in autocommit mode whenever this default mode has not been overridden by either explicit or implicit
tran
sactions. Autocommit mode is also the default mode for
ADO
, OLE DB, ODBC, and DB-Library. A SQL Server connection operates in autocommit mode until a BE
GIN
TRAN
SACTION statement starts an explicit
tran
saction, or implicit
tran
saction mode is set on. When the explicit
tran
saction is committed or rolled back, or when implicit
tran
saction mode is turned off, SQL Server returns to autocommit mode. Explicit
Tran
saction Mode An explicit
tran
saction is a
tran
saction that starts with a BE
GIN
TRAN
SACTION statement. An explicit
tran
saction can contain one or more statements and must be terminated by either a COMMIT
TRAN
SACTION or a ROLLBACK
TRAN
SACTION statement. Implicit
Tran
saction Mode SQL Server can automatically or, more precisely, implicitly start a
tran
saction for you if a SET IMPLICIT_
TRAN
SACTIONS ON statement is run or if the implicit
tran
saction option is turned on globally by running sp_configure ‘user options’ 2. (Actually, the bit mask 0x2 must be turned on for the user option so you might have to perform an ‘OR’ operation with the existing user option value.) See SQL Server 2000 Books Online on how to turn on implicit
tran
saction under ODBC and OLE DB (acdata.chm::/ac_8_md_06_2g6r.htm).
Tran
saction Nesting Explicit
tran
sactions can be nested. Committing inner
tran
sactions is ignored by SQL Server other than to decrements @@
TRAN
COUNT. The
tran
saction is either committed or rolled back based on the action taken at the end of the outermost
tran
saction. If the outer
tran
saction is committed, the inner nested
tran
sactions are also committed. If the outer
tran
saction is rolled back, then all inner
tran
sactions are also rolled back, regardless of whether the inner
tran
sactions were individually committed. Each call to COMMIT
TRAN
SACTION applies to the last executed BE
GIN
TRAN
SACTION. If the BE
GIN
TRAN
SACTION statements are nested, then a COMMIT statement applies only to the last nested
tran
saction, which is the innermost
tran
saction. Even if a COMMIT
TRAN
SACTION
tran
saction_name statement within a nested
tran
saction refers to the
tran
saction name of the outer
tran
saction, the commit applies only to the innermost
tran
saction. If a ROLLBACK
TRAN
SACTION statement without a
tran
saction_name parameter is executed at any level of a set of nested
tran
saction, it rolls back all the nested
tran
sactions, including the outermost
tran
saction. The @@
TRAN
COUNT function records the current
tran
saction nesting level. Each BE
GIN
TRAN
SACTION statement increments @@
TRAN
COUNT by one. Each COMMIT
TRAN
SACTION statement decrements @@
TRAN
COUNT by one. A ROLLBACK
TRAN
SACTION statement that does not have a
tran
saction name rolls back all nested
tran
sactions and decrements @@
TRAN
COUNT to 0. A ROLLBACK
TRAN
SACTION that uses the
tran
saction name of the outermost
tran
saction in a set of nested
tran
sactions rolls back all the nested
tran
sactions and decrements @@
TRAN
COUNT to 0. When you are unsure if you are already in a
tran
saction, SELECT @@
TRAN
COUNT to determine whether it is 1 or more. If @@
TRAN
COUNT is 0 you are not in a
tran
saction. You can also find the
tran
saction nesting level by checking the sysprocess.open_
tran
column. See SQL Server 2000 Books Online topic “Nesting
Tran
sactions” (acdata.chm::/ac_8_md_06_66nq.htm) for more information. Statement,
Tran
saction, and Batch Abort One batch can have many statements and one
tran
saction can have multiple statements, also. One
tran
saction can span multiple batches and one batch can have multiple
tran
sactions. Statement Abort Currently executing statement is aborted. This can be a bit confusing when you start talking about statements in a trigger or stored procedure. Let us look closely at the following trigger: CREATE TRIGGER TRG8134 ON TBL8134 AFTER INSERT AS BE
GIN
SELECT 1/0 SELECT 'Next command in trigger' END To fire the INSERT trigger, the batch could be as simple as ‘INSERT INTO TBL8134 VALUES(1)’. However, the trigger contains two statements that must be executed as part of the batch to satisfy the clients insert request. When the ‘SELECT 1/0’ causes the divide by zero error, a statement abort is issued for the ‘SELECT 1/0’ statement. Batch and
Tran
saction Abort On SQL Server 2000 (and SQL Server 7.0) whenever a non-informational error is encountered in a trigger, the statement abort is promoted to a batch and
tran
sactional abort. Thus, in the example the statement abort for ‘select 1/0’ promotion results in an entire batch abort. No further statements in the trigger or batch will be executed and a rollback is issued. On SQL Server 6.5, the statement aborts immediately and results in a
tran
saction abort. However, the rest of the statements within the trigger are executed. This trigger could return ‘Next command in trigger’ as a result set. Once the trigger completes the batch abort promotion takes effect. Conversely, submitting a similar set of statements in a standalone batch can result in different behavior. SELECT 1/0 SELECT 'Next command in batch' Not considering the set option possibilities, a divide by zero error generally results in a statement abort. Since it is not in a trigger, the promotion to a batch abort is avoided and subsequent SELECT statement can execute. The programmer should add an “if @@ERROR” check immediately after the ‘select 1/0’ to T-SQL execution to control the flow correctly. Aborting and Set Options ARITHABORT If SET ARITHABORT is ON, these error conditions cause the query or batch to terminate. If the errors occur in a
tran
saction, the
tran
saction is rolled back. If SET ARITHABORT is OFF and one of these errors occurs, a warning message is displayed, and NULL is assigned to the result of the arithmetic operation. When an INSERT, DELETE, or UPDATE statement encounters an arithmetic error (overflow, divide-by-zero, or a domain error) during expression evaluation when SET ARITHABORT is OFF, SQL Server inserts or updates a NULL value. If the target column is not nullable, the insert or update action fails and the user receives an error. XACT_ABORT When SET XACT_ABORT is ON, if a
Tran
sact-SQL statement raises a run-time error, the entire
tran
saction is terminated and rolled back. When OFF, only the
Tran
sact-SQL statement that raised the error is rolled back and the
tran
saction continues processing. Compile errors, such as syntax errors, are not affected by SET XACT_ABORT. For example: CREATE TABLE t1 (a int PRIMARY KEY) CREATE TABLE t2 (a int REFERENCES t1(a)) GO INSERT INTO t1 VALUES (1) INSERT INTO t1 VALUES (3) INSERT INTO t1 VALUES (4) INSERT INTO t1 VALUES (6) GO SET XACT_ABORT OFF GO BE
GIN
TRAN
INSERT INTO t2 VALUES (1) INSERT INTO t2 VALUES (2) /* Foreign key error */ INSERT INTO t2 VALUES (3) COMMIT
TRAN
SELECT 'Continue running batch 1...' GO SET XACT_ABORT ON GO BE
GIN
TRAN
INSERT INTO t2 VALUES (4) INSERT INTO t2 VALUES (5) /* Foreign key error */ INSERT INTO t2 VALUES (6) COMMIT
TRAN
SELECT 'Continue running batch 2...' GO /* Select shows only keys 1 and 3 added. Key 2 insert failed and was rolled back, but XACT_ABORT was OFF and rest of
tran
saction succeeded. Key 5 insert error with XACT_ABORT ON caused all of the second
tran
saction to roll back. Also note that 'Continue running batch 2...' is not Returned to indicate that the batch is aborted. */ SELECT * FROM t2 GO DROP TABLE t2 DROP TABLE t1 GO Compile and Run-time Errors Compile Errors Compile errors are encountered during syntax checks, security checks, and other general operations to prepare the batch for execution. These errors can prevent the optimization of the query and thus lead to immediate abort. The statement is not run and the batch is aborted. The
tran
saction state is generally left untouched. For example, assume there are four statements in a particular batch. If the third statement has a syntax error, none of the statements in the batch is executed. Optimization Errors Optimization errors would include rare situations where the statement encounters a problem when attempting to build an optimal execution plan. Example: “too many tables referenced in the query” error is reported because a “work table” was added to the plan. Runtime Errors Runtime errors are those that are encountered during the execution of the query. Consider the following batch: SELECT * FROM pubs.dbo.titles UPDATE pubs.dbo.authors SET au_lname = au_lname SELECT * FROM foo UPDATE pubs.dbo.authors SET au_lname = au_lname If you run the above statements in a batch, the first two statements will be executed, the third statement will fail because table foo does not exist, and the batch will terminate. Deferred Name Resolution is the feature that allows this batch to start executing before resolving the object foo. This feature allows SQL Server to delay object resolution and place a “placeholder” in the query’s execution. The object referenced by the placeholder is resolved until the query is executed. In our example, the execution of the statement “SELECT * FROM foo” will trigger another compile process to resolve the name again. This time, error message 208 is returned. Error: 208, Level 16, State 1, Line 1 Invalid object name 'foo'. Message 208 can be encountered as a runtime or compile error depending on whether the Deferred Name Resolution feature is available. In SQL Server 6.5 this would be considered a compile error and on SQL Server 2000 (and SQL Server7.0) as a runtime error due to Deferred Name Resolution. In the following example, if a trigger referenced authors2, the error is detected as SQL Server attempts to execute the trigger. However, under SQL Server 6.5 the create trigger statement fails because authors2 does not exist at compile time. When errors are encountered in a trigger, generally, the statement, batch, and
tran
saction are aborted. You should be able to observe this by running the following script in pubs database: Create table tblTest(iID int) go create trigger tr
gIn
sert on tblTest for INSERT as be
gin
select * from authors select * from authors2 select * from titles end go be
gin
tran
select 'Before' insert into tblTest values(1) select 'After' go select @@
TRAN
COUNT go When run in a batch, the statement and the batch are aborted but the
tran
saction remains active. The follow script illustrates this: be
gin
tran
select 'Before' select * from authors2 select 'After' go select @@
TRAN
COUNT go One other factor in a compile versus runtime error is implicit data type conversions. If you were to run the following statements on SQL Server 6.5 and SQL Server 2000 (and SQL Server 7.0): create table tblData(dtData datetime) go select 1 insert into tblData values(12/13/99) go On SQL Server 6.5, you get an error before execution of the batch be
gin
s so no statements are executed and the batch is aborted. Error: 206, Level 16, State 2, Line 2 Operand type clash: int is incompatible with datetime On SQL Server 2000, you get the default value (1900-01-01 00:00:00.000) inserted into the table. SQL Server 2000 implicit data type conversion treats this as integer division. The integer division of 12/13/99 is 0, so the default date and time value is inserted, no error returned. To correct the problem on either version is to wrap the date string with quotes. See Bug #56118 (sqlbug_70) for more details about this situation. Another example of a runtime error is a 605 message. Error: 605 Attempt to fetch logical page %S_PGID in database '%.*ls' belongs to object '%.*ls', not to object '%.*ls'. A 605 error is always a runtime error. However, depending on the
tran
saction isolation level, (e.g. using the NOLOCK lock hint), established by the SPID the handling of the error can vary. Specifically, a 605 error is considered an ACCESS error. Errors associated with buffer and page access are found in the 600 series of errors. When the error is encountered, the isolation level of the SPID is examined to determine proper handling based on information or fatal error level.
Tran
saction Error Checking Not all errors cause
tran
sactions to automatically rollback. Although it is difficult to determine exactly which errors will rollback
tran
sactions and which errors will not, the main idea here is that programmers must perform error checking and handle errors appropriately. Error Handling Raiserror Details Raiserror seems to be a source of confusion but is really rather simple. Raiserror with severity levels of 20 or higher will terminate the connection. Of course, when the connection is terminated a full rollback of any open
tran
saction will immediately be instantiated by the SQL Server (except distributed
tran
saction with DTC involved). Severity levels lower than 20 will simply result in the error message being returned to the client. They do not affect the
tran
saction scope of the connection. Consider the following batch: use pubs be
gin
tran
update authors set au_lname = 'smith' raiserror ('This is bad', 19, 1) with log select @@
tran
count With severity set at 19, the 'select @@
tran
count' will be executed after the raiserror statement and will return a value of 1. If severity is changed to 20, then the select statement will not run and the connection is broken. Important Error handling must occur not only in T-SQL batches and stored procedures, but also in application program code.
Tran
sactions and Triggers (1 of 2) Basic behavior assumes the implicit
tran
sactions setting is set to OFF. This behavior makes it possible to identify business logic errors in a trigger, raise an error, rollback the action, and add an audit table entry. Logically, the insert to the audit table cannot take place before the ROLLBACK action and you would not want to build in the audit table insert into every applications error handler that violated the business rule of the trigger. For more information, see also… SQL Server 2000 Books Online topic “Rollbacks in stored procedure and triggers“ (acdata.chm::/ac_8_md_06_4qcz.htm) IMPLICIT_
TRAN
SACTIONS ON Behavior The behavior of firing other triggers on the same table can be tricky. Say you added a trigger that checks the CODE field. Read only versions of the rows contain the code ‘RO’ and read/write versions use ‘RW.’ Whenever someone tries to delete a row with a code ‘RO’ the trigger issues the rollback and logs an audit table entry. However, you also have a second trigger that is responsible for cascading delete operations. One client could issue the delete without implicit
tran
sactions on and only the current trigger would execute and then terminate the batch. However, a second client with implicit
tran
sactions on could issue the same delete and the secondary trigger would fire. You end up with a situation in which the cascading delete operations can take place (are committed) but the initial row remains in the table because of the rollback operation. None of the delete operations should be allowed but because the
tran
saction scope was restarted because of the implicit
tran
sactions setting, they did.
Tran
sactions and Triggers (2 of 2) It is extremely difficult to determine the execution state of a trigger when using explicit rollback statements in combination with implicit
tran
sactions. The RETURN statement is not allowed to return a value. The only way I have found to set the @@ERROR is using a ‘raiserror’ as the last execution statement in the last trigger to execute. If you modify the example, this following RAISERROR statement will set @@ERROR to 50000: CREATE TRIGGER trgTest on tblTest for INSERT AS BE
GIN
ROLLBACK INSERT INTO tblAudit VALUES (1) RAISERROR('This is bad', 14,1) END However, this value does not carry over to a secondary trigger for the same table. If you raise an error at the end of the first trigger and then look at @@ERROR in the secondary trigger the @@ERROR remains 0. Carrying Forward an Active/Open
Tran
saction It is possible to exit from a trigger and carry forward an open
tran
saction by issuing a BE
GIN
TRAN
or by setting implicit
tran
saction on and doing INSERT, UPDATE, or DELETE. Warning It is never recommended that a trigger call BE
GIN
TRAN
SACTION. By doing this you increment the
tran
saction count. Invalid code logic, not calling commit
tran
saction, can lead to a situation where the
tran
saction count remains elevated upon exit of the trigger.
Tran
saction Count The behavior is better explained by understanding how the server works. It does not matter whether you are in a
tran
saction, when a modification takes place the
tran
saction count is incremented. So, in the simplest form, during the processing of an insert the
tran
saction count is 1. On completion of the insert, the server will commit (and thus decrement the
tran
saction count). If the commit identifies the
tran
saction count has returned to 0, the actual commit processing is completed. Issuing a commit when the
tran
saction count is greater than 1 simply decrements the nested
tran
saction counter. Thus, when we enter a trigger, the
tran
saction count is 1. At the completion of the trigger, the
tran
saction count will be 0 due to the commit issued at the end of the modification statement (insert). In our example, if the connection was already in a
tran
saction and called the second INSERT, since implicit
tran
saction is ON, the
tran
saction count in the trigger will be 2 as long as the ROLLBACK is not executed. At the end of the insert, the commit is again issued to decrement the
tran
saction reference count to 1. However, the value does not return to 0 so the
tran
saction remains open/active. Subsequent triggers are only fired if the
tran
saction count at the end of the trigger remains greater than or equal to 1. The key to continuation of secondary triggers and the batch is the
tran
saction count at the end of a trigger execution. If the trigger that performs a rollback has done an explicit be
gin
tran
saction or uses implicit
tran
sactions, subsequent triggers and the batch will continue. If the
tran
saction count is not 1 or greater, subsequent triggers and the batch will not execute. Warning Forcing the
tran
saction count after issuing a rollback is dangerous because you can easily loose track of your
tran
saction nesting level. When performing an explicit rollback in a trigger, you should immediately issue a return statement to maintain consistent behavior between a connection with and without implicit
tran
saction settings. This will force the trigger(s) and batch to terminate immediately. One of the methods of dealing with this issue is to run ‘SET IMPLICIT_
TRAN
SACTIONS OFF’ as the first statement of any trigger. Other methods may entails checking @@
TRAN
COUNT at the end of the trigger and continue to COMMIT the
tran
saction as long as @@
TRAN
COUNT is greater than 1. Examples The following examples are based on this table: create table tbl50000Insert (iID int NOT NULL) go Note If more than one trigger is used, to guarantee the trigger firing sequence, the sp_settriggerorder command should be used. This command is omitted in these examples to simplify the complexity of the statements. First Example In the first example, the second trigger was never fired and the batch, starting with the insert statement, was aborted. Thus, the print statement was never issued. print('Trigger issues rollback - cancels batch') go create trigger trg50000Insert on tbl50000Insert for INSERT as be
gin
select 'Inserted', * from inserted rollback
tran
select 'End of trigger', @@
TRAN
COUNT as '
TRAN
COUNT' end go create trigger trg50000Insert2 on tbl50000Insert for INSERT as be
gin
select 'In Trigger2' select 'Trigger 2 Inserted', * from inserted end go insert into tbl50000Insert values(1) print('---------------------- In same batch') select * from tbl50000Insert go -- Cleanup drop trigger trg50000Insert drop trigger trg50000Insert2 go delete from tbl50000Insert Second Example The next example shows that since a new
tran
saction is started, the second trigger will be fired and the print statement in the batch will be executed. Note that the insert is rolled back. print('Trigger issues rollback - increases
tran
count to continue batch') go create trigger trg50000Insert on tbl50000Insert for INSERT as be
gin
select 'Inserted', * from inserted rollback
tran
be
gin
tran
end go create trigger trg50000Insert2 on tbl50000Insert for INSERT as be
gin
select 'In Trigger2' select 'Trigger 2 Inserted', * from inserted end go insert into tbl50000Insert values(2) print('---------------------- In same batch') select * from tbl50000Insert go -- Cleanup drop trigger trg50000Insert drop trigger trg50000Insert2 go delete from tbl50000Insert Third Example In the third example, the raiserror statement is used to set the @@ERROR value and the BE
GIN
TRAN
statement is used in the trigger to allow the batch to continue to run. print('Trigger issues rollback - uses raiserror to set @@ERROR') go create trigger trg50000Insert on tbl50000Insert for INSERT as be
gin
select 'Inserted', * from inserted rollback
tran
be
gin
tran
-- Increase @@
tran
count to allow -- batch to continue select @@
tran
count as ‘
Tran
count’ raiserror('This is from the trigger', 14,1) end go insert into tbl50000Insert values(3) select @@ERROR as 'ERROR', @@
TRAN
COUNT as '
Tran
count' go -- Cleanup drop trigger trg50000Insert go delete from tbl50000Insert Fourth Example For the fourth example, a second trigger is added to illustrate the fact that @@ERROR value set in the first trigger will not be seen in the second trigger nor will it show up in the batch after the second trigger is fired. print('Trigger issues rollback - uses raiserror to set @@ERROR, not seen in second trigger and cleared in batch') go create trigger trg50000Insert on tbl50000Insert for INSERT as be
gin
select 'Inserted', * from inserted rollback be
gin
tran
-- Increase @@
tran
count to -- allow batch to continue select @@
TRAN
COUNT as '
Tran
count' raiserror('This is from the trigger', 14,1) end go create trigger trg50000Insert2 on tbl50000Insert for INSERT as be
gin
select @@ERROR as 'ERROR', @@
TRAN
COUNT as '
Tran
count' end go insert into tbl50000Insert values(4) select @@ERROR as 'ERROR', @@
TRAN
COUNT as '
Tran
count' go -- Cleanup drop trigger trg50000Insert drop trigger trg50000Insert2 go delete from tbl50000Insert Lesson 3: Concepts – Locks and Applications This lesson outlines some of the common causes that contribute to the perception of a slow server. What You Will Learn After completing this lesson, you will be able to: Explain how lock hints are used and their impact. Discuss the effect on locking when an application uses Microsoft
Tran
saction Server. Identify the different kinds of deadlocks including distributed deadlock. Recommended Reading Charter 14 “Locking”, Inside SQL Server 2000 by Kalen Delaney Charter 16 “Query Tuning”, Inside SQL Server 2000 by Kalen Delaney Q239753 – Deadlock Situation Not Detected by SQL Server Q288752 – Blocked SPID Not Participating in Deadlock May Incorrectly be Chosen as victim Locking Hints UPDLOCK If update locks are used instead of shared locks while reading a table, the locks are held until the end of the statement or
tran
saction. UPDLOCK has the advantage of allowing you to read data (without blocking other readers) and update it later with the assurance that the data has not changed since you last read it. READPAST READPAST is an optimizer hint for use with SELECT statements. When this hint is used, SQL Server will read past locked rows. For example, assume table T1 contains a single integer column with the values of 1, 2, 3, 4, and 5. If
tran
saction A changes the value of 3 to 8 but has not yet committed, a SELECT * FROM T1 (READPAST) yields values 1, 2, 4, 5. Tip READPAST only applies to
tran
sactions operating at READ COMMITTED isolation and only reads past row-level locks. This lock hint can be used to implement a work queue on a SQL Server table. For example, assume there are many external work requests being thrown into a table and they should be serviced in approximate insertion order but they do not have to be completely FIFO. If you have 4 worker threads consuming work items from the queue they could each pick up a record using read past locking and then delete the entry from the queue and commit when they're done. If they fail, they could rollback, leaving the entry on the queue for the next worker thread to pick up. Caution The READPAST hint is not compatible with HOLDLOCK. Try This: Using Locking Hints 1. Open a Query Window and connect to the pubs database. 2. Execute the following statements (--Conn 1 is optional to help you keep track of each connection): BE
GIN
TRAN
SACTION -- Conn 1 UPDATE titles SET price = price * 0.9 WHERE title_id = 'BU1032' 3. Open a second connection and execute the following statements: SELECT @@lock_timeout -- Conn 2 GO SELECT * FROM titles SELECT * FROM authors 4. Open a third connection and execute the following statements: SET LOCK_TIMEOUT 0 -- Conn 3 SELECT * FROM titles SELECT * FROM authors 5. Open a fourth connection and execute the following statement: SELECT * FROM titles (READPAST) -- Conn 4 WHERE title_ID < 'C' SELECT * FROM authors How many records were returned? 3 6. Open a fifth connection and execute the following statement: SELECT * FROM titles (NOLOCK) -- Conn 5 WHERE title_ID 0 the lock manager also checks for deadlocks every time a SPID gets blocked. So a single deadlock will trigger 20 seconds of more immediate deadlock detection, but if no additional deadlocks occur in that 20 seconds, the lock manager no longer checks for deadlocks at each block and detection again only happens every 5 seconds. Although normally not needed, you may use trace flag -T1205 to trace the deadlock detection process. Note Please note the distinction between application lock and other locks’ deadlock detection. For application lock, we do not rollback the
tran
saction of the deadlock victim but simply return a -3 to sp_getapplock, which the application needs to handle itself. Deadlock Resolution How is a deadlock resolved? SQL Server picks one of the connections as a deadlock victim. The victim is chosen based on either which is the least expensive
tran
saction (calculated using the number and size of the log records) to roll back or in which process “SET DEADLOCK_PRIORITY LOW” is specified. The victim’s
tran
saction is rolled back, held locks are released, and SQL Server sends error 1205 to the victim’s client application to notify it that it was chosen as a victim. The other process can then obtain access to the resource it was waiting on and continue. Error 1205: Your
tran
saction (process ID #%d) was deadlocked with another process and has been chosen as the deadlock victim. Rerun your
tran
saction. Symptoms of deadlocking Error 1205 usually is not written to the SQL Server errorlog. Unfortunately, you cannot use sp_altermessage to cause 1205 to be written to the errorlog. If the client application does not capture and display error 1205, some of the symptoms of deadlock occurring are: Clients complain of mysteriously canceled queries when using certain features of an application. May be accompanied by excessive blocking. Lock contention increases the chances that a deadlock will occur. Triggers and Deadlock Triggers promote the deadlock priority of the SPID for the life of the trigger execution when the DEADLOCK PRIORITY is not set to low. When a statement in a trigger causes a deadlock to occur, the SPID executing the trigger is given preferential treatment and will not become the victim. Warning Bug 235794 is filed against SQL Server 2000 where a blocked SPID that is not a participant of a deadlock may incorrectly be chosen as a deadlock victim if the SPID is blocked by one of the deadlock participants and the SPID has the least amount of
tran
saction log
gin
g. See KB article Q288752: “Blocked Spid Not Participating in Deadlock May Incorrectly be Chosen as victim” for more information. Distributed Deadlock – Scenario 1 Distributed Deadlocks The term distributed deadlock is ambiguous. There are many types of distributed deadlocks. Scenario 1 Client application opens connection A, be
gin
s a
tran
saction, acquires some locks, opens connection B, connection B gets blocked by A but the application is designed to not commit A’s
tran
saction until B completes. Note SQL Server has no way of knowing that connection A is somehow dependent on B – they are two distinct connections with two distinct
tran
sactions. This situation is discussed in scenario #4 in “Q224453 INF: Understanding and Resolving SQL Server 7.0 Blocking Problems”. Distributed Deadlock – Scenario 2 Scenario 2 Distributed deadlock involving bound connections. Two connections can be bound into a single
tran
saction context with sp_getbindtoken/sp_bindsession or via DTC. Spid 60 enlists in a
tran
saction with spid 61. A third spid 62 is blocked by spid 60, but spid 61 is blocked by spid 62. Because they are doing work in the same
tran
saction, spid 60 cannot commit until spid 61 finishes his work, but spid 61 is blocked by 62 who is blocked by 60. This scenario is described in article “Q239753 - Deadlock Situation Not Detected by SQL Server.” Note SQL Server 6.5 and 7.0 do not detect this deadlock. The SQL Server 2000 deadlock detection algorithm has been enhanced to detect this type of distributed deadlock. The diagram in the slide illustrates this situation. Resources locked by a spid are below that spid (in a box). Arrows indicate blocking and are drawn from the blocked spid to the resource that the spid requires. A circle represents a
tran
saction; spids in the same
tran
saction are shown in the same circle. Distributed Deadlock – Scenario 3 Scenario 3 Distributed deadlock involving linked servers or server-to-server RPC. Spid 60 on Server 1 executes a stored procedure on Server 2 via linked server. This stored procedure does a loopback linked server query against a table on Server 1, and this connection is blocked by a lock held by Spid 60. Note No version of SQL Server is currently designed to detect this distributed deadlock. Lesson 4: Information Collection and Analysis This lesson outlines some of the common causes that contribute to the perception of a slow server. What You Will Learn After completing this lesson, you will be able to: Identify specific information needed for troubleshooting issues. Locate and collect information needed for troubleshooting issues. Analyze output of DBCC Inputbuffer, DBCC PSS, and DBCC Page commands. Review information collected from master.dbo.sysprocesses table. Review information collected from master.dbo.syslockinfo table. Review output of sp_who, sp_who2, sp_lock. Analyze Profiler log for query usage pattern. Review output of trace flags to help troubleshoot deadlocks. Recommended Reading Q244455 - INF: Definition of Sysprocesses Waittype and Lastwaittype Fields Q244456 - INF: Description of DBCC PSS Command for SQL Server 7.0 Q271509 - INF: How to Monitor SQL Server 2000 Blocking Q251004 - How to Monitor SQL Server 7.0 Blocking Q224453 - Understanding and Resolving SQL Server 7.0 Blocking Problem Q282749 – BUG: Deadlock information reported with SQL Server 2000 Profiler Locking and Blocking Try This: Examine Blocked Processes 1. Open a Query Window and connect to the pubs database. Execute the following statements: BE
GIN
TRAN
-- connection 1 UPDATE titles SET price = price + 1 2. Open another connection and execute the following statement: SELECT * FROM titles-- connection 2 3. Open a third connection and execute sp_who; note the process id (spid) of the blocked process. (Connection 3) 4. In the same connection, execute the following: SELECT spid, cmd, waittype FROM master..sysprocesses WHERE waittype 0 -- connection 3 5. Do not close any of the connections! What was the wait type of the blocked process? Try This: Look at locks held Assumes all your connections are still open from the previous exercise. • Execute sp_lock -- Connection 3 What locks is the process from the previous example holding? Make sure you run ROLLBACK
TRAN
in Connection 1 to clean up your
tran
saction. Collecting Information See Module 2 for more about how to gather this information using various tools. Recognizing Blocking Problems How to Recognize Blocking Problems Users complain about poor performance at a certain time of day, or after a certain number of users connect. SELECT * FROM sysprocesses or sp_who2 shows non-zero values in the blocked or BlkBy column. More severe blocking incidents will have long blocking chains or large sysprocesses.waittime values for blocked spids. Possibl
winform控件与
ADO
.NET
ADO
.NET的名称起源于
ADO
(ActiveX Data Objects),是一个COM组件库,用于在以往的Microsoft技术中访问数据。之所以使用
ADO
.NET名称,是因为Microsoft希望表明,这是在NET编程环境中优先使用的数据访问接口。
NBEARLISY使用
做数据映射层 NBearLite Version 1.0.0.9 beta ------------------------------- Author: Teddy (shijie.ma@gmail.com) Official Site: http://nbear.org Open Source License: BSD Copyright: 2007-2010 Release Notes ------------- Version 1.0.0.9 beta 1. Fix bug of getting oracle table and view info in QueryColumnsGenerator.exe tool. 2. Change the NBearLite_Documentation format from chm to general HTML to prevent some operation system's could not open it issue. Version 1.0.0.8 beta 1. Fix type cast bug when QueryColumnsGenerator.exe generated out parameter value is dbnull. 2. Enhance QueryColumnsGenerator.exe to generate one more method for each stored procedure with a Db
Tran
saction
tran
parameter. Version 1.0.0.7 beta 1. Fix bug in Aggregation select. 2. Provide Chinese version full documentation of NBearLite in doc folder. Version 1.0.0.6 beta 1. Add ToDbCommand() method to InsertSqlSection/UpdateSqlSection/DeleteSqlSection classes. 2. Add 8 Save() method overridens to Database class to support DataTable/DataRows saving. e.g. Sample Save code: SelectSqlSection selectSection = db.Select(Northwind.Categories) .Where(Northwind.Categories.CategoryID == catID) .OrderBy(Northwind.Categories.CategoryID.Desc) .SetSelec
tRan
ge(1, 0, Northwind.Categories.CategoryID); DataTable dt = selectSection.ToDataSet().Tables[0]; dt.Rows[0]["CategoryName"] = "modified"; //save a modified row db.Save(selectSection.ToDbCommand(), 10, dt); dt.Rows[0]["CategoryName"] = "modified2"; DataRow newRow = dt.NewRow(); newRow["CategoryName"] = "new"; dt.Rows.Add(newRow); //save 1 modified row and insert a new row db.Save(selectSection.ToDbCommand(),
tran
, 0, dt.Rows[0], dt.Rows[1]); Version 1.0.0.5 beta 1. Add ToDbCommand() method to SelectSqlSection class. e.g. We can use database.Select(Northwind.Categories).ToDbCommand(); 2. Enhance strong type query with sub query support. Add ToSubQuery() method to SelectSqlSection class. e.g. Sample strong type query with sub queries: DataSet ds = db.Select(Northwind.Products) .Where(Northwind.Products.CategoryID.In ( db.Select(Northwind.Categories, Northwind.Categories.CategoryID).SetSelec
tRan
ge(10, 0, Northwind.Categories.CategoryID).ToSubQuery()) ) .ToDataSet(); ds = db.Select(Northwind.Products) .Where(Northwind.Products.CategoryID == ( db.Select(Northwind.Categories, Northwind.Categories.CategoryID).SetSelec
tRan
ge(1, 0, Northwind.Categories.CategoryID).ToSubQuery()) ) .ToDataSet(); Version 1.0.0.4 beta 1. Enhanced NBearLite.QueryColumnsGenerator to generate Stored Procedure Wrapper methods for SqlServer, Oracle, MySql and PostgreSql databases. Version 1.0.0.3 beta 1. Fix bug in PostgreSql DbProvider. Version 1.0.0.2 beta 1. Fix bug in preview version. 2. Add PostgreSql DbProvider in NBearLite.AdditionalDbProviders.dll. 3. Release as the first beta version. Version 1.0.0.0 preview 1. Release the initial preview version. Introdution Q & A ----------------- Q: What is NBearLite? A: NBearLite is a .NET 2.0 data access component which supports MsAccess, SqlServer, Oracle, Sqlite, MySql, PostgreSql databases. Q: Is NBearLite an O/R Mapping component? A: No. Q: Then what are the main features of NBearLite? A: With NBearLite, you can
tran
sparently query databases by a strong type query language similar to LINQ. The strong type query language provided by NBearLite supports not only basic CRUD but also complex select queries with ORDER BY, GROUP BY, PA
GIN
G, INNER JOIN, BATCH OPERATION...- Most common database operations we may met in our development life, which significantly simplifies database operations from our .Net code and saves our development time. The select query of NBearLite returns Scalar, DataSet or IDataReader. Q: Is NBearLite easy to use? A: Yes, super easy. You can easily reference NBearLite.dll, use NBearLite.QueryColumnsGenerator.exe tool provided by together with NBearLite.dll to generate QueryColumns code from existing database and then freely query your database through NBearLite's strong type query language. Please check code in NBearLite.Test project for basic usage. NBearLite.QueryColumnsGenerator itself is a sample WinForm application using NBearLite. More tutorials is incoming. Q: What is the relation of NBearLite and NBear? A: NBearLite is maintained by NBear team. It shares the DbProvider and query kernalcode of NBear but provides cleaner namespaces, code structure and more powerful data access fucntions working with
ADO
.NET build-in DataSet instead of Entity classes in NBear. Yes, to be
gin
from NBearLite, there is no need to write any entity classes or entity configurations.
be
gin
tran
s返回值_
ADO
Be
gin
Tran
s, Commit
Tran
以及 Rollback
Tran
s 方法
定义和用法这三个方法与 Connection 对象使用,来保存或取消对数据源所做的更改。注释:并非所有提供者都支持事务。注释:Be
gin
Tran
s、Commit
Tran
s 和 Rollback
Tran
s 方法在客户端 Connection 对象上无效。Be
gin
Tran
sBe
gin
Tran
s 方法可开始一个新事务。Commit
Tran
sCommit
Tran
s 方法可保存自最后一个 Be
gin
Tra...
VB基础类
7,763
社区成员
197,609
社区内容
发帖
与我相关
我的任务
VB基础类
VB 基础类
复制链接
扫一扫
分享
社区描述
VB 基础类
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章