社区
疑难问题
帖子详情
thread was being aborted 问题
envykok
2010-08-13 12:47:52
在执行SQL 语句时候,为什么会抛出这样的错误:thread was being aborted
如何察看是什么错误?
...全文
298
6
打赏
收藏
thread was being aborted 问题
在执行SQL 语句时候,为什么会抛出这样的错误:thread was being aborted 如何察看是什么错误?
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
6 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
hao1hao2hao3
2010-08-13
打赏
举报
回复
哎!问得好累啊!怎么不说开发语言等的相关信息,这个应该不是SQL的问题。
envykok
2010-08-13
打赏
举报
回复
[Quote=引用 1 楼 hao1hao2hao3 的回复:]
在程序中执行?还是在查询分析器中?
[/Quote]
在程序中执行
hao1hao2hao3
2010-08-13
打赏
举报
回复
在程序中执行?还是在查询分析器中?
envykok
2010-08-13
打赏
举报
回复
--- Error Message ---
Thread was being aborted.|System.Data| at SNIReadSync(SNI_Conn* , SNI_Packet** , Int32 )
at SNINativeMethodWrapper.SNIReadSync(SafeHandle pConn, IntPtr& packet, Int32 timeout)
at System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParserStateObject.ReadNetworkPacket()
at System.Data.SqlClient.TdsParserStateObject.ReadBuffer()
at System.Data.SqlClient.TdsParserStateObject.ReadByte()
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteXmlReader()
at Listings.Listings1.GetListings(String methodName)
王向飞
2010-08-13
打赏
举报
回复
语句贴出来看看
envykok
2010-08-13
打赏
举报
回复
[Quote=引用 3 楼 hao1hao2hao3 的回复:]
哎!问得好累啊!怎么不说开发语言等的相关信息,这个应该不是SQL的问题。
[/Quote]
大哥,是SQL 问题,我用的是C#
因为抛出这条错误信息是SQLCommand.EXECUTEQUERY()...
我目前有3000多个用户,我想是不是我的SQL SERVER不够强大
微软内部资料-SQL性能优化3
Contents Overview 1 Lesson 1: Concepts – Locks and Lock Manager 3 Lesson 2: Concepts – Batch and Transaction 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 transaction isolation. Describe the various transaction types and how transactions 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 us
ed
by SQL Server. Identify the various lock modes us
ed
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. Recommend
ed
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 transaction 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. Transactions in SQL Server provide the ACID properties: Atomicity A transaction either commits or
abort
s. If a transaction commits, all of its effects remain. If it
abort
s, 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 transactions are isolat
ed
from the updates of other incomplete transactions. These updates do not constitute a consistent state. This property is often call
ed
serializability. For example, a second transaction traversing the doubly link
ed
list mention
ed
above would see the list before or after the insert, but it will see only complete changes. Durability After a transaction 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 ne
ed
ed
to achieve consistent results. SQL Server uses locking to achieve isolation. Definition of Dependency: A set of transactions 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 isolat
ed
for use by one process and guard
ed
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 COMMITT
ED
. To make use of either more or less strict isolation levels in applications, locking can be customiz
ed
for an entire session by setting the isolation level of the session with the SET TRANSACTION ISOLATION LEVEL statement. To determine the transaction isolation level currently set, use the DBCC USEROPTIONS statement, for example: USE pubs GO SET TRANSACTION ISOLATION LEVEL REPEATABLE READ GO DBCC USEROPTIONS GO Multigranular Locking Multigranular Locking In our example, if one transaction (T1) holds an exclusive lock at the table level, and another transaction (T2) holds an exclusive lock at the row level, each of the transactions 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 lock
ed
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 us
ed
to mean placing a marker in a higher-level lock queue. The type of intent lock can also be call
ed
the multigranular lock mode. An intent lock indicates that SQL Server wants to acquire a shar
ed
(S) lock or exclusive (X) lock on some of the resources lower down in the hierarchy. For example, a shar
ed
intent lock plac
ed
at the table level means that a transaction intends on placing shar
ed
(S) locks on pages or rows within that table. Setting an intent lock at the table level prevents another transaction 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 transaction 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 transaction can lock the entire table. Lock Mode The code shown in the slide represents how the lock mode is stor
ed
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 Shar
ed
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 lock
ed
, SQL Server will apply intent locks at both the page and the table level. If a page is lock
ed
, SQL Server will apply an intent lock at the table level. SIX locks imply that we have shar
ed
access to a resource and we have also plac
ed
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 transaction scann
ed
a page using an S lock and then subsequently decid
ed
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 cover
ed
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. Us
ed
to lock ranges between records in a table to prevent phantom insertions or deletions into a set of records. Ensures serializable transactions. RID A Row Identifier. Us
ed
to individually lock a single row within a table. Application A lock resource defin
ed
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 lock
ed
. Some of the resources have “sub-resources.” The followings are sub-resources display
ed
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: Hash
ed
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 decod
ed
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 transaction semantics, SQL Server ne
ed
s to lock sets of rows specifi
ed
by a pr
ed
icate, such as WHERE salary BETWEEN 30000 AND 50000 SQL Server ne
ed
s to lock data that does not exist! If no rows satisfy the WHERE condition the first time the range is scann
ed
, no rows should be return
ed
on any subsequent scans. Key range locks are similar to row locks on index keys (whether cluster
ed
or not). The locks are plac
ed
on individual keys rather than at the node level. The hash value consists of all the key components and the locator. So, for a noncluster
ed
index over a heap, where columns c1 and c2 where index
ed
, the hash would contain contributions from c1, c2 and the RID. A key range lock appli
ed
to a particular key means that all keys between the value lock
ed
and the next value would be lock
ed
for all data modification. Key range locks can lock a slightly larger range than that impli
ed
by the WHERE clause. Suppose the following select was execut
ed
in a transaction 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 us
ed
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 satisfi
ed
before key-range locking can occur: The transaction-isolation level must be set to SERIALIZABLE. The operation perform
ed
on the data must use an index range access. Range locking is activat
ed
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 transactions 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 adjust
ed
when the query is actually execut
ed
. Lock Escalation When the lock count for the transaction exce
ed
s and is a multiple of ESCALATION_THRESHOLD (1250), the Lock Manager attempts to escalate. For example, when a transaction acquir
ed
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 access
ed
, or the previous lock escalation attempts fail
ed
due to incompatible locks held by another spid). If the lock count for this transaction 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 allocat
ed
buffer pool memory, it tries to find a scan (SDES) where no escalation has already been perform
ed
. It then repeats the search operation until all scans have been escalat
ed
or until the memory us
ed
drops under the MEMORY_LOAD_ESCALATION_THRESHOLD (40%) value. If lock escalation is not possible or fails to significantly r
ed
uce 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 avoid
ed
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 lock
ed
, it will generate error message 1222 and continue with the next statement. The current value of LOCK_TIMEOUT is stor
ed
in the global variable @@lock_timeout. Note After a lock timeout any transaction containing the statement, is roll
ed
back or cancel
ed
by SQL Server 2000 (bug#352640 was fil
ed
). 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 proce
ed
unaware that an individual statement within a transaction has been cancel
ed
, and errors can occur because statements later in the transaction may depend on the statement that was never execut
ed
. Bug#352640 is fix
ed
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 issu
ed
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 ne
ed
s 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 Transaction Isolation Level For REPEATABLE READ transaction isolation level, update locks are held until data is read and process
ed
, unless promot
ed
to exclusive locks. "Data is process
ed
" means that we have decid
ed
whether the row in question match
ed
the search criteria; if not then the update lock is releas
ed
, 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 transaction isolation level repeatable read begin tran update dbo.[order details] set discount = convert (real, discount) where discount = 0.0 exec sp_lock Update locks are promot
ed
to exclusive locks when there is a match; otherwise, the update lock is releas
ed
. The sp_lock output verifies that the SPID does not hold any update locks or shar
ed
locks at the end of the query. Lock escalation is turn
ed
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 us
ed
unless you have done extensive study to make sure it helps with performance. These trace flags are us
ed
here for illustration and learning purposes only. Lock Ownership Most of the locking discussion in this lesson relates to locks own
ed
by “transactions.” In addition to transaction, cursor and session can be owners of locks and they both affect how long locks are held. For every row that is fetch
ed
, when SCROLL_LOCKS option is us
ed
, regardless of the state of a transaction, a cursor lock is held until the next row is fetch
ed
or when the cursor is clos
ed
. Locks own
ed
by session are outside the scope of a transaction. The duration of these locks are bound
ed
by the connection and the process will continue to hold these locks until the process disconnects. A typical lock own
ed
by session is the database (DB) lock. Locking – Read Committ
ed
Scan Under read committ
ed
isolation level, when database pages are scann
ed
, shar
ed
locks are held when the page is read and process
ed
. The shar
ed
locks are releas
ed
“behind” the scan and allow other transactions to update rows. It is important to note that the shar
ed
lock currently acquir
ed
will not be releas
ed
until shar
ed
lock for the next page is successfully acquir
ed
(this is commonly know as “crabbing”). If the same pages are scann
ed
again, rows may be modifi
ed
or delet
ed
by other transactions. Locking – Repeatable Read Scan Under repeatable read isolation level, when database pages are scann
ed
, shar
ed
locks are held when the page is read and process
ed
. SQL Server continues to hold these shar
ed
locks, thus preventing other transactions to update rows. If the same pages are scann
ed
again, previously scann
ed
rows will not change but new rows may be add
ed
by other transactions. Locking – Serializable Read Scan Under serializable read isolation level, when database pages are scann
ed
, shar
ed
locks are held not only on rows but also on scann
ed
key range. SQL Server continues to hold these shar
ed
locks until the end of transaction. Because key range locks are held, not only will this prevent other transactions from modifying the rows, no new rows can be insert
ed
. 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 noncluster
ed
index, the index is search
ed
for a particular value. When that value is found, the index points to the disk address. The traditional approach would be to imm
ed
iately 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 strip
ed
disk sets. The prefetch feature takes a different approach. It continues looking for more record pointers in the noncluster
ed
index. When it has collect
ed
a number of them, it provides the storage engine with prefetch hints. These hints tell the storage engine that the query processor will ne
ed
these particular records soon. The storage engine can now issue several I/Os simultaneously, taking advantage of strip
ed
disk sets to execute multiple operations simultaneously. For example, if the engine is scanning a noncluster
ed
index to determine which rows qualify but will eventually ne
ed
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 revisit
ed
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 mov
ed
by a page split or cluster
ed
key update. For our example, the isolation level of the query is escalat
ed
to REPEATABLE READ, overriding the transaction isolation level. With SQL Server 7.0 and SQL Server 2000, portions of a transaction can execute at a different transaction isolation level than the entire transaction itself. This is implement
ed
as lock classes. Lock classes are us
ed
to control lock lifetime when portions of a transaction ne
ed
to execute at a stricter isolation level than the underlying transaction. Unfortunately, in SQL Server 7.0 and SQL Server 2000, the lock class is creat
ed
at the topmost operator of the query and hence releas
ed
only at the end of the query. Currently there is no support to release the lock (lock class) after the row has been discard
ed
or fetch
ed
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 acquir
ed
during the query will not be releas
ed
until the query completes. If prefetch is occurring you may see a single SPID that holds hundr
ed
s of Shar
ed
KEY or PAG locks even though the connection’s isolation level is READ COMMITT
ED
. Isolation level can be determin
ed
from DBCC PSS output. For details about this behavior see “SOX001109700040 INF: Queries with PREFETCH in the plan hold lock until the end of transaction”. Other Locking Mechanism Lock manager does not manage latches and spinlocks. Latches Latches are internal mechanisms us
ed
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 divid
ed
into I/O latches and non-I/O latches. If you see a high number of non-I/O relat
ed
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 us
ed
to protect vital information that is shar
ed
within SQL Server. On a multi-processor machine, when SQL Server tries to access a particular resource protect
ed
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-determin
ed
amount of time. When it wakes, hopefully, the lock is free and available. If not, the loop starts again and it is terminat
ed
only when the lock is acquir
ed
. 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 sav
ed
The new
thread
’s state must be reload
ed
The data stor
ed
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 imm
ed
iately. Lesson 2: Concepts – Batch and Transaction 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 transactions and transaction nesting level. Discuss how commit and rollback transaction done in stor
ed
proc
ed
ure and trigger affects transaction nesting level. Discuss various transaction isolation level and their impact on locking. Discuss the difference between
abort
ing a statement, a transaction, and a batch. Describe how @@error, @@transcount, and @@rowcount can be us
ed
for error checking and handling. Recommend
ed
Reading Charter 12 “Transactions 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:BatchComplet
ed
’ event is captur
ed
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:Complet
ed
’ with the sp_who information. RPC is simply another entry point to the SQL Server to call stor
ed
proc
ed
ures with native data types. This allows one to avoid parsing. The ‘RPC:Complet
ed
’ event should be consider
ed
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 execut
ed
within the batch. Autocommit, Explicit, and Implicit Transaction Autocommit Transaction Mode (Default) Autocommit mode is the default transaction management mode of SQL Server. Every Transact-SQL statement, whether it is a standalone statement or part of a batch, is committ
ed
or roll
ed
back when it completes. If a statement completes successfully, it is committ
ed
; if it encounters any error, it is roll
ed
back. A SQL Server connection operates in autocommit mode whenever this default mode has not been overridden by either explicit or implicit transactions. 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 BEGIN TRANSACTION statement starts an explicit transaction, or implicit transaction mode is set on. When the explicit transaction is committ
ed
or roll
ed
back, or when implicit transaction mode is turn
ed
off, SQL Server returns to autocommit mode. Explicit Transaction Mode An explicit transaction is a transaction that starts with a BEGIN TRANSACTION statement. An explicit transaction can contain one or more statements and must be terminat
ed
by either a COMMIT TRANSACTION or a ROLLBACK TRANSACTION statement. Implicit Transaction Mode SQL Server can automatically or, more precisely, implicitly start a transaction for you if a SET IMPLICIT_TRANSACTIONS ON statement is run or if the implicit transaction option is turn
ed
on globally by running sp_configure ‘user options’ 2. (Actually, the bit mask 0x2 must be turn
ed
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 transaction under ODBC and OLE DB (acdata.chm::/ac_8_md_06_2g6r.htm). Transaction Nesting Explicit transactions can be nest
ed
. Committing inner transactions is ignor
ed
by SQL Server other than to decrements @@TRANCOUNT. The transaction is either committ
ed
or roll
ed
back bas
ed
on the action taken at the end of the outermost transaction. If the outer transaction is committ
ed
, the inner nest
ed
transactions are also committ
ed
. If the outer transaction is roll
ed
back, then all inner transactions are also roll
ed
back, regardless of whether the inner transactions were individually committ
ed
. Each call to COMMIT TRANSACTION applies to the last execut
ed
BEGIN TRANSACTION. If the BEGIN TRANSACTION statements are nest
ed
, then a COMMIT statement applies only to the last nest
ed
transaction, which is the innermost transaction. Even if a COMMIT TRANSACTION transaction_name statement within a nest
ed
transaction refers to the transaction name of the outer transaction, the commit applies only to the innermost transaction. If a ROLLBACK TRANSACTION statement without a transaction_name parameter is execut
ed
at any level of a set of nest
ed
transaction, it rolls back all the nest
ed
transactions, including the outermost transaction. The @@TRANCOUNT function records the current transaction nesting level. Each BEGIN TRANSACTION statement increments @@TRANCOUNT by one. Each COMMIT TRANSACTION statement decrements @@TRANCOUNT by one. A ROLLBACK TRANSACTION statement that does not have a transaction name rolls back all nest
ed
transactions and decrements @@TRANCOUNT to 0. A ROLLBACK TRANSACTION that uses the transaction name of the outermost transaction in a set of nest
ed
transactions rolls back all the nest
ed
transactions and decrements @@TRANCOUNT to 0. When you are unsure if you are already in a transaction, SELECT @@TRANCOUNT to determine whether it is 1 or more. If @@TRANCOUNT is 0 you are not in a transaction. You can also find the transaction nesting level by checking the sysprocess.open_tran column. See SQL Server 2000 Books Online topic “Nesting Transactions” (acdata.chm::/ac_8_md_06_66nq.htm) for more information. Statement, Transaction, and Batch
Abort
One batch can have many statements and one transaction can have multiple statements, also. One transaction can span multiple batches and one batch can have multiple transactions. Statement
Abort
Currently executing statement is
abort
ed
. This can be a bit confusing when you start talking about statements in a trigger or stor
ed
proc
ed
ure. Let us look closely at the following trigger: CREATE TRIGGER TRG8134 ON TBL8134 AFTER INSERT AS BEGIN 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 execut
ed
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 issu
ed
for the ‘SELECT 1/0’ statement. Batch and Transaction
Abort
On SQL Server 2000 (and SQL Server 7.0) whenever a non-informational error is encounter
ed
in a trigger, the statement
abort
is promot
ed
to a batch and transactional
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 execut
ed
and a rollback is issu
ed
. On SQL Server 6.5, the statement
abort
s imm
ed
iately and results in a transaction
abort
. However, the rest of the statements within the trigger are execut
ed
. 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 avoid
ed
and subsequent SELECT statement can execute. The programmer should add an “if @@ERROR” check imm
ed
iately after the ‘select 1/0’ to T-SQL execution to control the flow correctly.
Abort
ing and Set Options ARITH
ABORT
If SET ARITH
ABORT
is ON, these error conditions cause the query or batch to terminate. If the errors occur in a transaction, the transaction is roll
ed
back. If SET ARITH
ABORT
is OFF and one of these errors occurs, a warning message is display
ed
, and NULL is assign
ed
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 ARITH
ABORT
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 Transact-SQL statement raises a run-time error, the entire transaction is terminat
ed
and roll
ed
back. When OFF, only the Transact-SQL statement that rais
ed
the error is roll
ed
back and the transaction continues processing. Compile errors, such as syntax errors, are not affect
ed
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 BEGIN 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 BEGIN 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 add
ed
. Key 2 insert fail
ed
and was roll
ed
back, but XACT_
ABORT
was OFF and rest of transaction succe
ed
ed
. Key 5 insert error with XACT_
ABORT
ON caus
ed
all of the second transaction to roll back. Also note that 'Continue running batch 2...' is not Return
ed
to indicate that the batch is
abort
ed
. */ SELECT * FROM t2 GO DROP TABLE t2 DROP TABLE t1 GO Compile and Run-time Errors Compile Errors Compile errors are encounter
ed
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 imm
ed
iate
abort
. The statement is not run and the batch is
abort
ed
. The transaction state is generally left untouch
ed
. 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 execut
ed
. 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 referenc
ed
in the query” error is report
ed
because a “work table” was add
ed
to the plan. Runtime Errors Runtime errors are those that are encounter
ed
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 execut
ed
, the third statement will fail because table foo does not exist, and the batch will terminate. Deferr
ed
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 referenc
ed
by the placeholder is resolv
ed
until the query is execut
ed
. 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 return
ed
. Error: 208, Level 16, State 1, Line 1 Invalid object name 'foo'. Message 208 can be encounter
ed
as a runtime or compile error depending on whether the Deferr
ed
Name Resolution feature is available. In SQL Server 6.5 this would be consider
ed
a compile error and on SQL Server 2000 (and SQL Server7.0) as a runtime error due to Deferr
ed
Name Resolution. In the following example, if a trigger referenc
ed
authors2, the error is detect
ed
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 encounter
ed
in a trigger, generally, the statement, batch, and transaction are
abort
ed
. You should be able to observe this by running the following script in pubs database: Create table tblTest(iID int) go create trigger trgInsert on tblTest for INSERT as begin select * from authors select * from authors2 select * from titles end go begin tran select 'Before' insert into tblTest values(1) select 'After' go select @@TRANCOUNT go When run in a batch, the statement and the batch are
abort
ed
but the transaction remains active. The follow script illustrates this: begin tran select 'Before' select * from authors2 select 'After' go select @@TRANCOUNT 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 begins so no statements are execut
ed
and the batch is
abort
ed
. 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) insert
ed
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 insert
ed
, no error return
ed
. 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 transaction isolation level, (e.g. using the NOLOCK lock hint), establish
ed
by the SPID the handling of the error can vary. Specifically, a 605 error is consider
ed
an ACCESS error. Errors associat
ed
with buffer and page access are found in the 600 series of errors. When the error is encounter
ed
, the isolation level of the SPID is examin
ed
to determine proper handling bas
ed
on information or fatal error level. Transaction Error Checking Not all errors cause transactions to automatically rollback. Although it is difficult to determine exactly which errors will rollback transactions 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 terminat
ed
a full rollback of any open transaction will imm
ed
iately be instantiat
ed
by the SQL Server (except distribut
ed
transaction with DTC involv
ed
). Severity levels lower than 20 will simply result in the error message being return
ed
to the client. They do not affect the transaction scope of the connection. Consider the following batch: use pubs begin tran update authors set au_lname = 'smith' raiserror ('This is bad', 19, 1) with log select @@trancount With severity set at 19, the 'select @@trancount' will be execut
ed
after the raiserror statement and will return a value of 1. If severity is chang
ed
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 stor
ed
proc
ed
ures, but also in application program code. Transactions and Triggers (1 of 2) Basic behavior assumes the implicit transactions 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 violat
ed
the business rule of the trigger. For more information, see also… SQL Server 2000 Books Online topic “Rollbacks in stor
ed
proc
ed
ure and triggers“ (acdata.chm::/ac_8_md_06_4qcz.htm) IMPLICIT_TRANSACTIONS ON Behavior The behavior of firing other triggers on the same table can be tricky. Say you add
ed
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 transactions on and only the current trigger would execute and then terminate the batch. However, a second client with implicit transactions 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 committ
ed
) but the initial row remains in the table because of the rollback operation. None of the delete operations should be allow
ed
but because the transaction scope was restart
ed
because of the implicit transactions setting, they did. Transactions 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 transactions. The RETURN statement is not allow
ed
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 BEGIN 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 Transaction It is possible to exit from a trigger and carry forward an open transaction by issuing a BEGIN TRAN or by setting implicit transaction on and doing INSERT, UPDATE, or DELETE. Warning It is never recommend
ed
that a trigger call BEGIN TRANSACTION. By doing this you increment the transaction count. Invalid code logic, not calling commit transaction, can lead to a situation where the transaction count remains elevat
ed
upon exit of the trigger. Transaction Count The behavior is better explain
ed
by understanding how the server works. It does not matter whether you are in a transaction, when a modification takes place the transaction count is increment
ed
. So, in the simplest form, during the processing of an insert the transaction count is 1. On completion of the insert, the server will commit (and thus decrement the transaction count). If the commit identifies the transaction count has return
ed
to 0, the actual commit processing is complet
ed
. Issuing a commit when the transaction count is greater than 1 simply decrements the nest
ed
transaction counter. Thus, when we enter a trigger, the transaction count is 1. At the completion of the trigger, the transaction count will be 0 due to the commit issu
ed
at the end of the modification statement (insert). In our example, if the connection was already in a transaction and call
ed
the second INSERT, since implicit transaction is ON, the transaction count in the trigger will be 2 as long as the ROLLBACK is not execut
ed
. At the end of the insert, the commit is again issu
ed
to decrement the transaction reference count to 1. However, the value does not return to 0 so the transaction remains open/active. Subsequent triggers are only fir
ed
if the transaction 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 transaction count at the end of a trigger execution. If the trigger that performs a rollback has done an explicit begin transaction or uses implicit transactions, subsequent triggers and the batch will continue. If the transaction count is not 1 or greater, subsequent triggers and the batch will not execute. Warning Forcing the transaction count after issuing a rollback is dangerous because you can easily loose track of your transaction nesting level. When performing an explicit rollback in a trigger, you should imm
ed
iately issue a return statement to maintain consistent behavior between a connection with and without implicit transaction settings. This will force the trigger(s) and batch to terminate imm
ed
iately. One of the methods of dealing with this issue is to run ‘SET IMPLICIT_TRANSACTIONS OFF’ as the first statement of any trigger. Other methods may entails checking @@TRANCOUNT at the end of the trigger and continue to COMMIT the transaction as long as @@TRANCOUNT is greater than 1. Examples The following examples are bas
ed
on this table: create table tbl50000Insert (iID int NOT NULL) go Note If more than one trigger is us
ed
, to guarantee the trigger firing sequence, the sp_settriggerorder command should be us
ed
. This command is omitt
ed
in these examples to simplify the complexity of the statements. First Example In the first example, the second trigger was never fir
ed
and the batch, starting with the insert statement, was
abort
ed
. Thus, the print statement was never issu
ed
. print('Trigger issues rollback - cancels batch') go create trigger trg50000Insert on tbl50000Insert for INSERT as begin select 'Insert
ed
', * from insert
ed
rollback tran select 'End of trigger', @@TRANCOUNT as 'TRANCOUNT' end go create trigger trg50000Insert2 on tbl50000Insert for INSERT as begin select 'In Trigger2' select 'Trigger 2 Insert
ed
', * from insert
ed
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 transaction is start
ed
, the second trigger will be fir
ed
and the print statement in the batch will be execut
ed
. Note that the insert is roll
ed
back. print('Trigger issues rollback - increases tran count to continue batch') go create trigger trg50000Insert on tbl50000Insert for INSERT as begin select 'Insert
ed
', * from insert
ed
rollback tran begin tran end go create trigger trg50000Insert2 on tbl50000Insert for INSERT as begin select 'In Trigger2' select 'Trigger 2 Insert
ed
', * from insert
ed
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 us
ed
to set the @@ERROR value and the BEGIN TRAN statement is us
ed
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 begin select 'Insert
ed
', * from insert
ed
rollback tran begin tran -- Increase @@trancount to allow -- batch to continue select @@trancount as ‘Trancount’ raiserror('This is from the trigger', 14,1) end go insert into tbl50000Insert values(3) select @@ERROR as 'ERROR', @@TRANCOUNT as 'Trancount' go -- Cleanup drop trigger trg50000Insert go delete from tbl50000Insert Fourth Example For the fourth example, a second trigger is add
ed
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 fir
ed
. print('Trigger issues rollback - uses raiserror to set @@ERROR, not seen in second trigger and clear
ed
in batch') go create trigger trg50000Insert on tbl50000Insert for INSERT as begin select 'Insert
ed
', * from insert
ed
rollback begin tran -- Increase @@trancount to -- allow batch to continue select @@TRANCOUNT as 'Trancount' raiserror('This is from the trigger', 14,1) end go create trigger trg50000Insert2 on tbl50000Insert for INSERT as begin select @@ERROR as 'ERROR', @@TRANCOUNT as 'Trancount' end go insert into tbl50000Insert values(4) select @@ERROR as 'ERROR', @@TRANCOUNT as 'Trancount' 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 us
ed
and their impact. Discuss the effect on locking when an application uses Microsoft Transaction Server. Identify the different kinds of deadlocks including distribut
ed
deadlock. Recommend
ed
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 Detect
ed
by SQL Server Q288752 – Block
ed
SPID Not Participating in Deadlock May Incorrectly be Chosen as victim Locking Hints UPDLOCK If update locks are us
ed
instead of shar
ed
locks while reading a table, the locks are held until the end of the statement or transaction. 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 chang
ed
since you last read it. READPAST READPAST is an optimizer hint for use with SELECT statements. When this hint is us
ed
, SQL Server will read past lock
ed
rows. For example, assume table T1 contains a single integer column with the values of 1, 2, 3, 4, and 5. If transaction A changes the value of 3 to 8 but has not yet committ
ed
, a SELECT * FROM T1 (READPAST) yields values 1, 2, 4, 5. Tip READPAST only applies to transactions operating at READ COMMITT
ED
isolation and only reads past row-level locks. This lock hint can be us
ed
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 servic
ed
in approximate insertion order but they do not have to be completely FIFO. If you have 4 worker
thread
s 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): BEGIN TRANSACTION -- 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 return
ed
? 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 block
ed
. So a single deadlock will trigger 20 seconds of more imm
ed
iate 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 ne
ed
ed
, 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 transaction of the deadlock victim but simply return a -3 to sp_getapplock, which the application ne
ed
s to handle itself. Deadlock Resolution How is a deadlock resolv
ed
? SQL Server picks one of the connections as a deadlock victim. The victim is chosen bas
ed
on either which is the least expensive transaction (calculat
ed
using the number and size of the log records) to roll back or in which process “SET DEADLOCK_PRIORITY LOW” is specifi
ed
. The victim’s transaction is roll
ed
back, held locks are releas
ed
, 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 transaction (process ID #%d) was deadlock
ed
with another process and has been chosen as the deadlock victim. Rerun your transaction. 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 cancel
ed
queries when using certain features of an application. May be accompani
ed
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 fil
ed
against SQL Server 2000 where a block
ed
SPID that is not a participant of a deadlock may incorrectly be chosen as a deadlock victim if the SPID is block
ed
by one of the deadlock participants and the SPID has the least amount of transaction logging. See KB article Q288752: “Block
ed
Spid Not Participating in Deadlock May Incorrectly be Chosen as victim” for more information. Distribut
ed
Deadlock – Scenario 1 Distribut
ed
Deadlocks The term distribut
ed
deadlock is ambiguous. There are many types of distribut
ed
deadlocks. Scenario 1 Client application opens connection A, begins a transaction, acquires some locks, opens connection B, connection B gets block
ed
by A but the application is design
ed
to not commit A’s transaction 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 transactions. This situation is discuss
ed
in scenario #4 in “Q224453 INF: Understanding and Resolving SQL Server 7.0 Blocking Problems”. Distribut
ed
Deadlock – Scenario 2 Scenario 2 Distribut
ed
deadlock involving bound connections. Two connections can be bound into a single transaction context with sp_getbindtoken/sp_bindsession or via DTC. Spid 60 enlists in a transaction with spid 61. A third spid 62 is block
ed
by spid 60, but spid 61 is block
ed
by spid 62. Because they are doing work in the same transaction, spid 60 cannot commit until spid 61 finishes his work, but spid 61 is block
ed
by 62 who is block
ed
by 60. This scenario is describ
ed
in article “Q239753 - Deadlock Situation Not Detect
ed
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 enhanc
ed
to detect this type of distribut
ed
deadlock. The diagram in the slide illustrates this situation. Resources lock
ed
by a spid are below that spid (in a box). Arrows indicate blocking and are drawn from the block
ed
spid to the resource that the spid requires. A circle represents a transaction; spids in the same transaction are shown in the same circle. Distribut
ed
Deadlock – Scenario 3 Scenario 3 Distribut
ed
deadlock involving link
ed
servers or server-to-server RPC. Spid 60 on Server 1 executes a stor
ed
proc
ed
ure on Server 2 via link
ed
server. This stor
ed
proc
ed
ure does a loopback link
ed
server query against a table on Server 1, and this connection is block
ed
by a lock held by Spid 60. Note No version of SQL Server is currently design
ed
to detect this distribut
ed
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 ne
ed
ed
for troubleshooting issues. Locate and collect information ne
ed
ed
for troubleshooting issues. Analyze output of DBCC Inputbuffer, DBCC PSS, and DBCC Page commands. Review information collect
ed
from master.dbo.sysprocesses table. Review information collect
ed
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. Recommend
ed
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 report
ed
with SQL Server 2000 Profiler Locking and Blocking Try This: Examine Block
ed
Processes 1. Open a Query Window and connect to the pubs database. Execute the following statements: BEGIN 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 block
ed
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 block
ed
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 transaction. 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 block
ed
or BlkBy column. More severe blocking incidents will have long blocking chains or large sysprocesses.waittime values for block
ed
spids. Possibl
acpi控制笔记本风扇转速
笔记本的风扇控制 ---------------------------------------- 09 November 2006. Summary of changes for version 20061109: 1) ACPI CA Core Subsystem: Optimiz
ed
the Load ASL operator in the case where the source operand is an operation region. Simply map the operation region memory, instead of performing a bytewise read. (Region must be of type SystemMemory, see below.) Fix
ed
the Load ASL operator for the case where the source operand is a region field. A buffer object is also allow
ed
as the source operand. BZ 480 Fix
ed
a problem where the Load ASL operator allow
ed
the source operand to be an operation region of any type. It is now restrict
ed
to regions of type SystemMemory, as per the ACPI specification. BZ 481 Additional cleanup and optimizations for the new Table Manager code. AcpiEnable will now fail if all of the requir
ed
ACPI tables are not load
ed
(FADT, FACS, DSDT). BZ 477 Add
ed
#pragma pack(8/4) to acobject.h to ensure that the structures in this header are always compil
ed
as align
ed
. The ACPI_OPERAND_OBJECT has been manually optimiz
ed
to be align
ed
and will not work if it is byte-pack
ed
. Example Code and Data Size: These are the sizes for the OS- independent acpica.lib produc
ed
by the Microsoft Visual C++ 6.0 32- bit compiler. The debug version of the code includes the debug output trace mechanism and has a much larger code and data size. Previous Release: Non-Debug Version: 78.1K Code, 17.1K Data, 95.2K Total Debug Version: 155.4K Code, 63.1K Data, 218.5K Total Current Release: Non-Debug Version: 77.9K Code, 17.0K Data, 94.9K Total Debug Version: 155.2K Code, 63.1K Data, 218.3K Total 2) iASL Compiler/Disassembler and Tools: Fix
ed
a problem where the presence of the _OSI pr
ed
efin
ed
control method within complex expressions could cause an internal compiler error. AcpiExec: Implement
ed
full region support for multiple address spaces. SpaceId is now part of the REGION object. BZ 429 ---------------------------------------- 11 Oc
BURNINTEST--硬件检测工具
PassMark BurnInTest V5.3 Copyright (C) 1999-2008 PassMark Software All Rights Reserv
ed
http://www.passmark.com Overview ======== Passmark's BurnInTest is a software tool that allows all the major sub-systems of a computer to be simultaneously test
ed
for reliability and stability. Status ====== This is a shareware program. This means that you ne
ed
to buy it if you would like to continue using it after the evaluation period. Installation ============ 1) Uninstall any previous version of BurnInTest 2) Double click (or Open) the download
ed
".exe" file 3) Follow the prompts UnInstallation ============== Use the Windows control panel, Add / Remove Programs Requirements ============ - Operating System: Windows 2000, XP, 2003 server, Vista (*) - RAM: 32 Meg - Disk space: 6 Meg of free hard disk space (plus an additional 10Meg to run the Disk test) - DirectX 9.0c or above software for 3D graphics and video tests (plus working DirectX drivers for your video card) - SSE compatible CPU for SSE tests - A printer to run the printer test, set-up as the default printer in Windows. - A CD ROM + 1 Music CD or Data CD to run the CD test. - A CD-RW to run the CD burn test. - A network connection and the TCP/IP networking software install
ed
for the Network Tests Pro version only: - A serial port loop back plug for the serial port test. - A parallel port loop back plug for the parallel port test. - A USB port loop back plug for the USB port test. - A USB 2.0 port loop back plug for the USB 2.0 port test. - PassMark ModemTest V1.3 1010 (or higher) for Plugin Modem testing. - PassMark KeyboardTest V2.2 1011 (or higher) for Plugin Keyboard testing. - PassMark Firewire Plugin V1.0 1000 (or higher) and a 揔anguru FireFlash?drive for Plugin Firewire testing. (*) Windows 2000 does not support the CD-RW burn test. The advanc
ed
RAM test is only available under Windows 2000 and Windows XP professional (the other RAM tests are support
ed
under the other OS's). Users must have administrator privileges. Windows 98 and Windows ME ========================= Windows 98 and ME are not support
ed
in BurnInTest version 5.3 and above. Use a version of BurnInTest prior to 5.2 for compatibility with W98 and ME. Windows 95 and Windows NT ========================= Windows 95 and NT are not support
ed
in BurnInTest version 4.0 and above. Use a version of BurnInTest prior to 3.1 for compatibility with W95 and NT. Version History =============== Here is a summary of all changes that have been made in each version of BurnInTest. Release 5.3 build 1035 revision 4 WIN32 release 10 November 2008 - Lenovo China specific build. Lenovo system detection changes. Release 5.3 build 1035 revision 3 WIN32 release 7 November 2008 - Lenovo China specific build. Lenovo system detection changes. Release 5.3 build 1035 revision 2 WIN32 release 6 November 2008 - Lenovo China specific build. Lenovo logo and Lenovo system detection changes. Release 5.3 build 1035 WIN32 release 5 November 2008 - Lenovo China specific build. Changes include: Lenovo logo add
ed
, Lenovo system support only, 32-bit BurnInTest restrict
ed
to 32-bit Windows and BurnInTest run as administrator. Release 5.3 build 1034 WIN32 release 3 October 2008 - Correction to setting the CD burn test drive in preferences. - Chang
ed
the mechanism to check for the requir
ed
DirectX Direct3D as the previous method did not work on some system (some W2003 servers). - Enhanc
ed
the mechanism to report memory hardware errors in the Memory torture test. Release 5.3 build 1033 WIN32 release 1 October 2008 - Changes to correct a BurnInTest crash problem on some systems. When the disk and standard RAM tests are run for many hours, BurnInTest may have disappear
ed
with no error message. Release 5.3 build 1030 WIN32 release 25 September 2008 - Changes to investigate a BurnInTest crash problem on XP SP3. Release 5.3 build 1028 WIN32 release 11 September 2008 - Two 2D Video memory test crash bug workarounds implement
ed
. Crashes in (i) DirectX DirectShow and (ii) ATI atiumdag.dll library. - A hang on startup has been correct
ed
. A 2 minute timeout has been add
ed
to the collection of system information. - Video playback, Hard disk and CD/DVD test 'no operations' error reporting chang
ed
. - When BurnInTest crashes, it will not generate a "minidump" file. Minidumps will ne
ed
to be sent to Microsoft as per the normal process. However, a log entry will be add
ed
to the normal BurnInTest log. - Changes to trace logging to r
ed
uce activity when trace logging is not turn
ed
on. - Note: We have seen a report of the Video Playback failing (crash) due to a faulty video codec, ffdshow.ax. If you are using this we suggest you try a different Video file and codec. Release 5.3 build 1027 revision 0003 WIN32 release 19 August 2008 - Chang
ed
the 2D test to wait for the Video Playback test in order to allow memory allocation for the Video playback test. - Chang
ed
the Memory test to wait for the Video Playback test and 3D test to allow memory allocation for these tests. - Minor changes to the No operation error watchdog timer for the CD and Hard disk tests. - Minor correction to the Butterfly seek test. - Video playback trace logging increas
ed
. Release 5.3 build 1027 revision 0002 WIN32 release 19 August 2008 - Video playback trace logging increas
ed
. Release 5.3 build 1027 WIN32 release 31 July 2008 - Correct
ed
a bug where BurnInTest would fail to start if Activity trace level 2 logging (debug level logging) was turn
ed
on and the Logging Summarize option was also select
ed
. - Minor change to the serial port test where, if "Disable RTS/CTS and DSR/DTR test phase" was select
ed
the DTR and RTS lines would be explicitly disabl
ed
to prevent any toggling of these lines. Previously these where enabl
ed
, but not explicitly toggl
ed
. Release 5.3 build 1026 WIN32 release 17 July 2008 - Updat
ed
Level 2 and Level 3 CPU cache information for newer Intel CPU's. - Updat
ed
the detection of Hyper
thread
ing and the number of logical CPUs for a new Intel CPU. Release 5.3 build 1025 WIN32 release 11 July 2008 - Correct
ed
a Disk test bug where on rare occasions a verification error is incorrectly display
ed
. This is during the random seeking phase of the "Random data with random seeking" test mode and only occurs with some specific test settings. Release 5.3 build 1024 WIN32 release 10 July 2008 - Workaround for the rare crash bug in Vista in atklumdisp.dll at address 0x730676ae. - Add
ed
trace debug information for BurnInTest startup and the 3D test. Release 5.3 build 1022 WIN32 release 12 June 2008 - Correct
ed
a bug where the 2D video memory test in BurnInTest v5.3.1020 and v5.3.1021 would report a "Not enough video memory available for test" error if the test was run a couple of times (without closing BurnInTest). Release 5.3 build 1021 WIN32 release 5 June 2008 - 32-bit BurnInTest PRO 5.3.1020 would not start on Windows 2000. This has been correct
ed
. Release 5.3 build 1020 WIN32 release 29 May 2008 - BurnInTest could have crash
ed
on accessing bad video memory hardware in the 2D test. This problem is now just report
ed
as an error (and BurnInTest) continues. - When BurnInTest crashes, it should now generate a "minidump" file to help debug which system component caus
ed
the failure (32-bit Pro version only). - Other minor changes. Release 5.3 build 1019 WIN32 release 16 May 2008 - Correct
ed
rare crash bugs in the 2D and Video tests. - Add
ed
a hot Key, F4, to set the auto run flag and run the tests (i.e. set "-r" and then run the tests). - Other minor changes. Release 5.3 build 1018 WIN32 release 16 April 2008 - Add
ed
an operation watchdog timer for all tests. In rare cases, a single test can stop in the operating system - i.e. there is a problem in the operating system/ device driver that prevents control being return
ed
to the BurnInTest for that test. This was add
ed
for specializ
ed
serial port hardware that could lockup after several hours of testing. Release 5.3 build 1017 WIN32 release 3 April 2008 - Correct
ed
the Advanc
ed
Network test to run on non-English Operating Systems. Release 5.3 build 1016 WIN32 release 17 March 2008 - Add
ed
additional USB 2.0 Loopback plug test initialization to ensure plugs are in a 'clean' state when starting the USB tests. This was add
ed
due to report
ed
USB data verification errors after script
ed
USB testing across multiple reboots. Release 5.3 build 1015 WIN32 release 27 February 2008 - Increas
ed
error reporting detail for the standard RAM test, when the -v command line option is us
ed
. Release 5.3 build 1014 WIN32 release 30 January 2008 - Correct
ed
a problem where the loopback sound test could run out of memory if run for several days. Release 5.3 build 1013 WIN32 release 31 December 2007 - Improv
ed
the reporting of COM port errors such that in the rare case a COM port locks up in the Operating System, the error is still report
ed
. - Correct
ed
a bug, where in rare cases, the result summary could be duplicat
ed
in a log file. - Updat
ed
license management, in an attempt to remove a rare crash on startup. Release 5.3 build 1012.0002 WIN32 release 31 October 2007 - New build of Rebooter (64-bit Windows correction). - Clarifications in the help file. Release 5.3 build 1012 WIN32 release 17 October 2007 - Chang
ed
the Standard Network Test, "Test all available NICs" such that the number of Network Addresses specifi
ed
in Preferences->Network will be the number of NICs test
ed
. This will error faulty NICs that are not detect
ed
by the BurnInTest auto NIC detection mechanism. - Minor change to the 2D memory test when run with the 3D test (multiple large windows) and the RAM test. Aim
ed
at correcting sympton: Access Violation 0x00404CF9. - Corrections to the mapping of paths with ".\". Release 5.3 build 1011 rev 2 WIN32 release 17 September 2007 - Modifi
ed
the Multi-Process torture test to better describe a new error message introduc
ed
in V5.3.1010. Release 5.3 build 1011 - Public release WIN32 release 11 September 2007 - Correct
ed
a bug where "Limit
ed
Evaluation Version" could be display
ed
even after BUrnInTest is licens
ed
(problem introduc
ed
in 32-bit BITPRO V5.3.1010). - Chang
ed
the Sound test to allow any of the tests (Wave, Midi or MP3) to be exclud
ed
from testing by blanking the filename. - The Command line parameter "-j" (cycle disk test patterns after each test file) could fail during the Random data test due to the mechanism us
ed
in BurnInTest. The Random data test is now exclud
ed
from the test when (and only when) the "-j" command line parameter is specifi
ed
. - In rare circumstances, the 2D test number of operations could potentially overflow and become negative. This has been correct
ed
. - In rare circumstances, BurnInTest could hang if there was a system problem in rebooting the system (ie. it fail
ed
to shutdown) using PassMark Rebooter. This has been correct
ed
. Release 5.3 build 1010 - Public release WIN32 release 28 August 2007 WIN64 release 28 August 2007 - As BurnInTest exercises system components, it is possible for faulty hardware or device drivers to cause software exceptions. These are normally seen as Windows reporting an "Access Violation". Changes have been made to handle these errors for the memory tests (for faulty RAM) and direct device driver access (for some device driver errors), as well as overarching more generic handling of these types of errors. - Correct
ed
a software failure bug on startup (particularly Vista) where a DirectX function was causing software failures in "dsetup.dll". - Updat
ed
the "Activity Event" generat
ed
with the periodic results summary report to be number
ed
(from 1 upwards) such that when "Logging->Summarize", these events are not summariz
ed
. - Correct
ed
a bug where the HTML log name could include a duplicate of the filename prefix. - Updat
ed
to the Common Errors section of help. Release 5.3 build 1009 - Public release WIN32 release 16 August 2007 - Correct
ed
a 'zip' version cleanup problem. Release 5.3 build 1008 - Komputer Swiat Expert magazine version WIN32 STD release 14 August 2007 Release 5.3 build 1007 - Public release WIN32 release 7 August 2007 - Correct
ed
a disk test startup problem for some large RAID systems when SMART testing is select
ed
. - Add
ed
additional logging for the disk test when an error occurs. - Chang
ed
the 3D test when run with the 2D EMC test to be 'behind' the EMC scrolling H's test. Allow
ed
the test to be easily exit
ed
when running the 3D test in Fullscreen mode. - Minor corrections to the Advanc
ed
Network test. - Chang
ed
the log file reference of "Network Name" to "Computer Name". WIN64 specific: - MMX and 3DNow! are obsolete for native 64-bit applications. BurnInTest has been chang
ed
to show "NA" (Not applicable) in the test window for these tests. Release 5.3 build 1006 - Limit
ed
release WIN32 release 17 July 2007 - Standard Network Test changes: - Increas
ed
the number of destination IP addresses from 4 to 6. - Add
ed
an option (default) "Test all available NICs", which will force traffic down every system NIC with a basic algorithm of NIC1 to IP Address 1, NIC2 to IP Address 2 etc. - Advanc
ed
Network test changes: - Simplifi
ed
the test. - Remov
ed
the UDP and FTP options. The Standard Network test can be us
ed
as a UDP test. - Remov
ed
the Advanc
ed
Network test specific logging, and includ
ed
all relevant logging in the standard BurnInTest logging mechanism. - Replac
ed
the complicat
ed
dynamic balancing of any system NIC to any Endpoint NIC with a simpler static allocation on test startup. - Chang
ed
the error detection mechanism to detect errors much more quickly. - Re-work
ed
the errors report
ed
. - Chang
ed
the CPU throttling mechanism to r
ed
uce the CPU load. - Updat
ed
endpoint.exe. - Remov
ed
checkend.exe (now obsolete). - Chang
ed
the logging rollover to work with the output of interim results (e.g. per 1 minute). Previously rollover only occurr
ed
on error events written to the log. This also correct
ed
an issue where interim results summary logging could be written to the physical disk with some delay (bas
ed
on Windows disk caching). - Correct
ed
the "Unknown" reporting of some operating systems. - Add
ed
the skipping of the Butterfly seek disk test when run on Vista and insufficient privileges. A notification of this is logg
ed
. - Intel Quad core L2 cache size reporting has been add
ed
. - Add
ed
new SMART threshold descriptions. - Add
ed
new disk test options, access
ed
via command line parameters: /ka: keep disk test files in all cases (c.f. /k keep disk test files on error). /j: cycle patterns between test files. Note: Random seeking will be skipp
ed
in this case. This option has been add
ed
to allow multiple test patterns to be us
ed
across very large disks. - Add
ed
an option to make some test settings unavailable to the user. An example configuration file available on request. Release 5.3 build 1005 0001 (STD only) - Public release WIN32 release 29 June 2007 - Correct
ed
a bug introduc
ed
in v5.3.1005.0000 STD (only) where the disk test would use up more and more system resources, thus causing test failures. Release 5.3 build 1005 rev 0003 (PRO only) - Limit
ed
public release WIN32 release 21 June 2007 - Correction to the behavior of a static RAM test pattern (rather than the default Cyclic pattern). Release 5.3 build 1005 rev 0002 (PRO only) - Limit
ed
public release WIN32 release 15 June 2007 - The "Select all CD/DVD drives" preferences option has been made user configurable, rather than using pre-defin
ed
test settings. Release 5.3 build 1005 rev 0001 (PRO only) - Limit
ed
public release WIN32 release 13 June 2007 - Bug correction for the CD auto selection feature. Release 5.3 build 1005 - Public release WIN32 release 18 May 2007 WIN64 release 18 May 2007 - In a number of cases, such as when specifying the post test application, uppercase application names were not accept
ed
. This has been correct
ed
. - The default font height in the 2D scrolling H's test should have been Arial 9. This has been chang
ed
. - The BurnInTest Video playback test incompatibility with Nero 6 and Nero 7 has been resolv
ed
. - The BurnInTest disk test throughput for dual core systems has been improv
ed
. Release 5.3 build 1004 rev2 - Limit
ed
release WIN32 release 8 May 2007 - Chang
ed
the Standard Network Test to better report packet error ratios. In addition, a new warning has been add
ed
to indicate that errors have been detect
ed
but not enough packets have been attempt
ed
to be sent to determine accurately whether the configur
ed
error ratio has been exce
ed
ed
. - Correct
ed
a bug where the "append to existing" logging option did not work across script
ed
reboots, and a new log file was creat
ed
instead of appending to the existing log file. - If the 3D test was running, then BurnInTest block
ed
a forc
ed
close of BurnInTest, this blocking has been remov
ed
. - Chang
ed
the PASS and FAIL windows so they can now also be clos
ed
by selecting the Windows Close "X" button. Release 5.3 build 1004 - Public release WIN32 release 10 April 2007 WIN64 release 10 April 2007 - Correct
ed
a problem introduc
ed
in BurnInTest v5.2 where BurnInTest could run out of memory (the main symptom) when tests where run for long periods (> 12hours). WIN64 specific: - Correct
ed
a bug where the number of cores report
ed
on a Quad core system was incorrectly report
ed
as CPU packages. Release 5.3 build 1003 - Limit
ed
release WIN32 release 3 April 2007 - A new 2D GUI (Graphical User Interface) test has been add
ed
to the standard 2D graphics test. - Resolv
ed
an issue where BurnInTest would fail to start on Vista systems with DEP enabl
ed
for all programs. - On some systems, the Disk test could pause momentarily even when a duty cycle of 100% was specifi
ed
. This pause has been remov
ed
. - When running the CD test under BartPE (Pre-install environment) 4 additional specific files are skipp
ed
as they are unavailable for testing. - Minor bug corrections. Release 5.3 build 1002 rev 0001 - Limit
ed
release WIN32 release 16 March 2007 - Changes to the new 3D test: - Add
ed
a Full screen non-window
ed
test for the primary monitor, where the resolution can be select
ed
from those support
ed
by the Graphics card. - Add
ed
the user option of changes the vertical sync in the full screen non-window
ed
test to be either the Maximum rate of the graphics card, or to be the rate of the monitor (this may prevent some flicker). - Add
ed
a more complex water texture using DirectX Vertex Shader 2.0 and Pixel Shader 2.0 effects (if support
ed
by the graphics card). This applies to 3D test windows that are 800x600 or larger. - Chang
ed
some error messages from window displays (that require user intervention) to standard error reporting. Add
ed
new 3D error messages and more detail in the error reporting. - Chang
ed
the definition of an operation to be a successfully display
ed
frame. - Chang
ed
the definition of a cycle to be 2000 frames. - Chang
ed
2D video memory test to wait until the 3D test starts (as per V5.2 and earlier). - A new version of rebooter has been includ
ed
. - If BurnInTest is start
ed
with the -p command line parameter (to use the bit.exe directory for files such as the configuration file), then BurnInTest will start rebooter with the -p option. This can be useful when running BurnInTest and Rebooter from a USB drive. Release 5.3 build 1002 - Limit
ed
release WIN32 release 19 March 2007 - Correct
ed
a bug introduc
ed
in V5.2 where selecting accumulat
ed
logging could lead to rebooter failing to launch. Release 5.3 build 1001 - Limit
ed
release WIN32 release 16 March 2007 - The 3D test has been improv
ed
. The 3D ball test has been replac
ed
with a more complex 3D terrain test. This will more thoroughly exercise modern graphics cards. Further, the 3D test has been chang
ed
to support multi- monitor testing (up to 4 monitors). Accordingly, a new preferences section has been add
ed
for the 3D test. The multi-monitor test options are only available in BurnInTest Professional. Release 5.3 build 1001 - Limit
ed
release WIN32 release 16 March 2007 - The 3D test has been improv
ed
. The 3D ball test has been replac
ed
with a more complex 3D terrain test. This will more thoroughly exercise modern graphics cards. Further, the 3D test has been chang
ed
to support multi- monitor testing (up to 4 monitors). Accordingly, a new preferences section has been add
ed
for the 3D test. The multi-monitor test options are only available in BurnInTest Professional. - BurnInTest uses DirectX 9.0c. This version of BurnInTest uses a more recent version of the Microsoft DirectX Direct3D component, October 2006. BurnInTest has been modifi
ed
to detect and install this component (file) if it does not exist. - A command line parameter -X has been add
ed
to skip the DirectX version checking on BurnInTest start-up. - With the recent introduction of multi-monitor support for the Video Playback test, it is now more likely that the system will run out of memory when running multiple video tests simultaneously, particularly when more memory intensive codecs are us
ed
. A specific Insufficient resources to complete test message has been add
ed
in this case, rather than the previous more generic unrecoverable error message. The video test have been chang
ed
to attempt recovery from this and the more generic unrecoverable error, by closing the current video and opening the next. The logging detail has been increas
ed
. - Note: The BurnIntest sample video pack has been alter
ed
with the DivX Compress
ed
Video file being remov
ed
due to the DivX codec failing with this Video file when us
ed
with multiple simultaneous Video playbacks. Access Violation: 0x69756e65. See: http://www.passmark.com/download/bit_download.htm - The video description is now collect
ed
for a larger range of Vista systems. - Windows 98 and ME are no longer support
ed
. Please see www.passmark.com for a link to an older version of BurnInTest that will support W98/ME. Release 5.3 build 1000 rev2 - Limit
ed
release WIN32 release 9 March 2007 - A command line parameter -P has been add
ed
to allow the BurnInTest directory to be us
ed
rather than the User's personal directory. This may be useful when running BurnInTest from a USB drive for example. - When running the CD test under BartPE (Pre-install environment) 4 additional specific files are skipp
ed
as they are unavailable for testing. - A change has been made to support Hmonitor temperature monitoring on Vista. - A number of undocument
ed
command line parameters have been document
ed
: -B: BurnInTest will generate additional Serial port test information when activity trace level 2 logging is set. -E [data]: Specifies the test data to use in the serial port test. -M: Automatically display the Machine ID Window when BurnInTest is start
ed
. -U: Force BurnInTest to set logging on at startup. Release 5.3 build 1000 - Limit
ed
release WIN32 release 8 March 2007 - Chang
ed
the 2D and Video playback tests to support multi-monitor testing. - When running the CD test under BartPE (Pre-install environment) 4 specific files are skipp
ed
as they are unavailable for testing. Release 5.2 build 1006 - Limit
ed
release WIN32 release 1 March 2007 - Correct
ed
a bug where BurnInTest would fail to start on certain Vista systems. - Correct
ed
a bug where some files where the full path was not specifi
ed
would be incorrectly referenc
ed
in the Program Files directory, rather than the user personal directory. Release 5.2 build 1005 - Public release WIN32 release 21 February 2007 WIN64 release 21 February 2007 - Updat
ed
the Graphics card description for Windows Vista systems. - Updat
ed
the Advanc
ed
Network test to indicate that elevat
ed
administrator privileges are requir
ed
when running on Vista. - Mov
ed
files from the Program files directory for the Advanc
ed
Network Test (BurnInTest, EndPoint and CheckEnd). Specifically, the User Application directory is now us
ed
for the temporary test FTP files and the User Personal directory is now us
ed
for the log and configuration files. - Updat
ed
the cleanup process for when running the "zip" version of BurnInTest Professional from a CD or flash drive. - Updat
ed
the help link from the Windows Start, All Programs, BurnInTest menu for the browser bas
ed
help. - Correct
ed
a bug where Disk preferences display
ed
in the Preferences window would be incorrect when the system had no Floppy drive. - Correct
ed
a bug where the Advanc
ed
Network test might not have been display
ed
until after entering the Duty Cycle selection (ie. just chaning from the standard network test to the advanc
ed
test). - Correct
ed
a USB bug in Beta 5.2.1003 where the test would not run if there where there insufficient USB loopback plugs attach
ed
to the system. - Includ
ed
a new version of PassMark Rebooter that supports Windows Vista. Release 5.2 build 1004 - Public Pre-release WIN32 release 13 February 2007 - Updat
ed
the report
ed
Operating system for the various Vista product
ed
itions. - Disk test settings can be configur
ed
for "Automatically Select all Hard Disks", rather than using defaults. - When running the CD test under BartPE (Pre-install environment) 4 specific files are skipp
ed
as they are unavailable for testing. - Correct
ed
a bug where temperature information could be duplicat
ed
in the HTML report. - Correct
ed
a bug certain 'save report' warning messages could be truncat
ed
. - Help file updat
ed
. Release 5.2 build 1003 - BETA RELEASE ONLY WIN32 release 23 January 2007 - Chang
ed
the USB preferences and test to more completely check for the PassMark USB Loopback plugs and ignore any device that is not a PassMark USB Loopback plug (due to report
ed
incorrect detection with another hardware device). - Increas
ed
Trace level debugging for Intel temperature monitoring. - Correct
ed
a bug with the disk test introduc
ed
in 5.2.1001 Release 5.2 build 1002 - BETA RELEASE ONLY WIN32 release 22 January 2007 - Increas
ed
the number of disks that can be test
ed
from 20 to 26. - Updat
ed
BurnInTest to reflect that Temperature monitoring with Intel Desktop utilities is support
ed
. Intel Desktop utilities essentially is a replacement for Intel Active Monitor for newer Intel motherboards. - Increas
ed
Trace level debugging for Intel temperature monitoring. Release 5.2 build 1001 - BETA RELEASE ONLY WIN32 release 19 January 2007 - Windows Vista support. - The Block size us
ed
in the disk test is now configurable per disk. The default block size has been increas
ed
from 16KB to 32KB. - An option has been add
ed
to automatically detect all of the CD and DVD drives for the CD test (as per the disk test). This may be useful when testing across many systems with different optical drive configurations. - Increas
ed
Trace level debugging for Intel temperature monitoring. - Bugs correct
ed
: - Disk preferences - in rare cases invalid default values could be set for a disk, an invalid value error would occur and the values would ne
ed
to be manually correct
ed
. Release 5.2 build 1000 - limit
ed
release WIN32 release 8 January 2007 - Windows Vista support. - R
ed
uc
ed
the ne
ed
for elevat
ed
administrator privileges: - Chang
ed
the location of the disk test files from the root directory of the test volume to a BurnInTest data files subdirectory (e.g from "C:\" to "C:\BurnInTest test files\") - Mov
ed
many of the files from the Program Files directory to the User directory for Windows 2000, XP and Vista. When running BurnInTest on Windows 98, ME or from a key.dat file (e.g. from a USB drive with a licens
ed
key.dat) BurnInTest will store these files in the BurnInTest program directory. Specifically, the following files have been mov
ed
from the Program Files directory to the User Personal directory, e.g. Vista - "C:\Users\\Documents\PassMark\BurnInTest\" XP - "My Documents\PassMark\BurnInTest\" Files: Configuration file, Configuration load/save default directory, Save log file and image default directory, parallel port override "ioports.dat" directory, default command line script directory, log file directory, video file directory, Plugin directory, machine id file directory, Run as script default directory, CD burn image, Advanc
ed
network FTP temp files. - Replac
ed
the Help system with Browser bas
ed
help. - Chang
ed
the Disk test block size from 16KB to 256KB. It is plann
ed
to make this user configurable in the next build. Release 5.1 build 1014 WIN32 release 2 November 2006 WIN64 release 2 November 2006 - Correct
ed
a bug when running on Vista, where the Standard network test would report a checksum error when the transmitt
ed
data was correct. - Correct
ed
a bug where BurnInTest would not stop the tests bas
ed
on the number of test cycles for the Plugin test or the Advanc
ed
Network test. - Made the "Could not set USB2Test mode" USB error message more specific by adding an error for insufficient system resources. - Chang
ed
the preferences Window to fit on an 800x600 resolution screen. - Correct
ed
a minor bug in Activity level 2 trace logging with the 'hide duplicate' preference setting. - Correct
ed
a minor memory leak if the 2D test fail
ed
to initialize (such as due to a DirectX problem). - The Parallel port test may now be us
ed
on Windows Vista. Specifically, the PassMark device driver us
ed
for the parallel port test could not be load
ed
on 64-bit Windows Vista as it was not digitally sign
ed
. It is now digitally sign
ed
. Release 5.1 build 1013 revision 0002 WIN32 release 19 September 2006 WIN64 release 19 September 2006 - Correct
ed
an Access Violation problem report
ed
by a customer on a particular MB. Release 5.1 build 1013 WIN32 release 7 September 2006 WIN64 release 7 September 2006 - The "Notes" section has been add
ed
to the Customer results certificate. - Some additional configuration range validation has been add
ed
. Release 5.1 build 1012 WIN32 release 15 August 2006 - Correct
ed
a false report of a "Unable to get disk volume extent information" for the disk butterfly seek test. - Advanc
ed
Network test changes for errors: "Corrupt header - packet discard
ed
" and "Advanc
ed
Network test tim
ed
out" - Advanc
ed
Network test Endpoint changes for problems on non-English Operating Systems and systems with the Windows "Network Interface" performance statistics disabl
ed
. - SMART parameters on a Samsung Hard Disk caus
ed
BurnInTest to fail when running the disk test with SMART thresholds enabl
ed
. This has been correct
ed
. - The 2D scrolling H's test could display corrupt characters on the second and subsequent test run. This has been correct
ed
. - A problem with the Integer maths test where the results could display a negative number of operations has been resolv
ed
. - Minor improvements to the help file. - HTML help file add
ed
for Windows Vista and Longhorn Server. - Minor improvements to the Error Classification file (error descriptions). - Some CD Trace level 1 logging has been mov
ed
to trace level 2. - Trace level 1 logging has been add
ed
to the test closing software. - New build of Endpoint.exe (1.0 1010). Release 5.1 build 1011 WIN32 release 6 July 2006 - New Advanc
ed
Network test error reporting add
ed
in the previous build V5.1 1010 has been remov
ed
. - A broader range of USB 2.0 Loopback plugs can now be us
ed
with BurnInTest. Release 5.1 build 1010 WIN32 release 4 July 2006 - Correct
ed
the HTML report description of the L2/L3 CPU cache when the L3 cache size could not be determin
ed
. Advanc
ed
network changes: - Endpoints ran at 100% CPU load as they contain
ed
no throttling. This impact
ed
their ability to effectively handle multiple
thread
s handling TCP/UDP messaging. Throttling has been add
ed
to the EndPoint side to r
ed
uce CPU load. This does not greatly impact Network load. - Throttling on the BurnInTest side contain
ed
a sleep that was not insignificant. This could have impact
ed
the BurnInTest data test
thread
to to handle incoming TCP and particularly UDP messages. This sleep has been r
ed
uc
ed
and other throttling parameters chang
ed
to suit. (ie. smaller sleeps more often). - EndPoint systems with x NICs (where x > 1), report
ed
themselves as an Endpoint with x NICs, x times. Effectively registering with BurnInTest as x * x EndPoint NICS. This impact
ed
the effectiveness of the load distribution to EndPoint NICs. An Endpoint system now only registers the once with BurnInTest. - The BurnInTest side did not report data verification Checksum errors for full duplex testing. This error determination has been correct
ed
and reporting add
ed
. - The Test statistics sent from the Endpoint to BurnInTest could fail if the statistics block is split across 2 lower level TCP send packets. This could lead to problems like incorrect reporting of Endpoint determin
ed
checksum errors, Endpoint load and load balancing. Further it would lead to an Endpoint test
thread
being put into an endless TCP send loop. This would eventually bring the Endpoint system to its knees as more and more of these test
thread
s go into this state. This has been correct
ed
. - The Data Receiv
ed
report
ed
by BurnInTest was double count
ed
. This has been correct
ed
. Release 5.1 build 1009 WIN32 release 23 June 2006 - Plugin test error classifications were incorrect in the log file detail
ed
description. - Corrections to the advanc
ed
network test (BurnInTest and EndPoint). Release 5.1 build 1008 - limit
ed
release WIN32 release 20 June 2006 - Advanc
ed
network changes corrections. Most notably, a bug where part of the payload data could be lost if the payload block (eg. 1000 bytes) was split across 2 (or more) lower level TCP packets. - Add
ed
version reporting for Endpoints. Release 5.1 build 1007 - limit
ed
release WIN32 release 16 June 2006 Advanc
ed
network changes: - Correct
ed
a BurnInTest access Violation introduc
ed
in V5.1 1006. - The Endpoint now reports its version and build to BurnInTest and BurnInTest reports this in the log file if it is an earlier version than expect
ed
. This is to help avoid the situation where old Endpoints are run on the Network, that may not be compatible with the version of BurnInTest being run by the user. - Remov
ed
a timeout report in a specific instance where a timeout is not an error. - Chang
ed
the Endpoint rebalancing and polling to occur less often after the test has been running 3 minutes. This is to help allowing the handling of polling from a larger number of multiple copies of BurnInTest on the Network. - Add
ed
a connection retries on failure for the Endpoint. - Correct
ed
a memory leak in the Endpoint. - Increas
ed
the number of sockets support
ed
. - Correct
ed
some Advanc
ed
Network error classifications. Release 5.1 build 1006 - limit
ed
release WIN32 release 14 June 2006 - Improvements to the Advanc
ed
Network test (both BurnInTest V5.1 1006 and EndPoint V1.0 1004) to remove corrupt
ed
false packet corruption errors. Improv
ed
the timeout recovery mechanism. Add
ed
some validation to the Windows Network performance data us
ed
for NIC utilization. - Changes to the collection of Disk drive information on startup to try to resolve a startup issue on Systems with a large number of physical drives and 'unusual' WMI namings. Release 5.1 build 1005 WIN32 release 2 June 2006 - Correct
ed
a bug in the Advanc
ed
network test where the test would not recover from timeout errors. The test appears to be running, but the results are 0 and the number of connect
ed
End Points are 0. Also improv
ed
the retry on timeout mechanism. - Remov
ed
some duplication in error reporting in the Advanc
ed
Network test. - Chang
ed
the Advanc
ed
Network display of Utilization to ensure a maximum of 100% display
ed
. - Correct
ed
an Advanc
ed
Network test bug where the number of Errors report
ed
in the test window would not take into account the corrupt packet threshold, and an error would be add
ed
for each occurrence of the corrupt packet (rather than when the user set threshold was reach
ed
). Release 5.1 build 1004b WIN32 release 25 May 2006 (not publicly releas
ed
) - Correct
ed
the default Advanc
ed
network corrupt packet threshold value. - Updat
ed
the data entry fields in the CD preferences when a different CD drive is select
ed
. - The Advanc
ed
Network specific log files should be concatenat
ed
for a script run. This was only occurring for the first NIC under test. The concatenation will now occur for each NIC under test, when run from a script. - Correct
ed
a bug where a log file name specifi
ed
with no directory path could be incorrect. - Correct
ed
a bug where the customer "Test Certificate" report incorrectly translat
ed
the "%" character from a customer specific HTML template. eg would be translat
ed
to . - The "Advanc
ed
Network test error" (215) has been remov
ed
and replac
ed
with other existing error messages 214, 219, 220, 221 or 222. - Add
ed
the Customer name and Technician name to the text and HTMl reports. Previously, this information was only includ
ed
in the "Test Certificate" report. - We have add
ed
a commandline option to specify the Serial port test data as a constant value. To specify specific data for the Serial port test you should specify e.g. "bit.exe /E 23" from the command line where 23 is in decimal and will be us
ed
for all test data (instead of random data). The vales should be between 0 and 255. Release 5.1 build 1004 WIN32 release 19 April 2006 (not publicly releas
ed
) - Add
ed
the COM port spe
ed
of 921600 Kbits/s for RS 422/RS485 testing. - Chang
ed
the CD test to ensure that the entire test CD data is not cach
ed
on systems with a large amount of RAM. - Add
ed
a -M command line option to display the Machine ID window automatically when BurninTest starts. - Chang
ed
the 2D EMC scrolling H's test to work on multiple monitors were the resolution on each is different. - Chang
ed
log files such the syntax "..\" could be us
ed
for files in the directory up a level. - Minor correction to the advanc
ed
network test. Release 5.1 build 1003 WIN32 release 18 April 2006 WIN64 release 18 April 2006 - Chang
ed
the Advanc
ed
network test to allow a corrupt packet threshold value up to 1 million. - Bundl
ed
a new version of rebooter. Release 5.1 build 1002 WIN32 release 11 April 2006 WIN64 release 11 April 2006 - Corrections to the translation of V4.0 to V5 configuration files. Note: Configuration files in V5.x builds prior to V5.1 1002 could become corrupt
ed
if a V4.0 configuration file is load
ed
. - Correct
ed
a bug where the main Window size and location were not restor
ed
on restarting BurnInTest. - Changes to the SMART attribute logging to support a greater range of Disk drive device drivers. Add
ed
additional Activity Level 2 trace logging. - Add
ed
an option to use CTS (Clear To Send) flow control in the loop back stage of the COM port test. - Correct
ed
a bug where the CPU L3 cache could be report
ed
as -1. - Help file updates. Release 5.1 build 1001 WIN32 release 30/March/2006 - Digitally sign
ed
the BurnInTest application to allow it to run under Windows Server "Longhorn". Note, previously only the installation package was digitally sign
ed
. - Updat
ed
the report
ed
Operating system descriptions, including: - Windows Vista - Windows Server "Longhorn" - Correct
ed
a bug where the Advanc
ed
network information was not display
ed
on the main window when it was run from a script. - The Advanc
ed
Network Corrupt threshold packet has been chang
ed
to produce an error every time the error is receiv
ed
after the threshold is reach
ed
. - Correct
ed
the reporting of "Network, Packet discard
ed
due to corrupt header" as a Network test error. - Correct
ed
a bug where a new log file was not creat
ed
if (only) the log prefix chang
ed
during the running of a script file. - Split the "Network, Advanc
ed
Network test error" error into 6 errors: "Network, Advanc
ed
Network test error" "Advanc
ed
Network Socket error" "Advanc
ed
Network Send error" "Advanc
ed
Network Send error - no data sent" "Advanc
ed
Network Receive error" "Advanc
ed
Network Receive error - no data receiv
ed
" Add
ed
either activity trace 1 or trace 2 logging for each of the errors, with additional information where available. - Add
ed
additional Serial port activity trace 2 logging. Including the logging of all transmit buffer data when the /B command line is us
ed
. Release 5.1 build 1000 WIN32 release 27/March/2006 (not a public release) Add
ed
the following features: - Create the log file directory specifi
ed
in the Logging Options if it does not exist. - Condense the Advanc
ed
Network Test log files to one log file per IP address per script run, when run from a script. - Add
ed
an option to summarize duplicate errors in the log file. - Color cod
ed
errors bas
ed
on severity in the Detail
ed
event log Window and the HTML log file. - Add
ed
an option to only create a log file when BurnIn actually runs a test as oppos
ed
to every time BurnIn is execut
ed
. - Add
ed
a warning if a test
thread
completes with 0 cycles and 0 operations. - In the results summary html file, insert
ed
more spacing between the 揘otes? and 揇etail
ed
Event Log? - Chang
ed
the Activity Trace file format to be the same as the log file, ie. text or HTML, rather than always text. - The 2D 揝crolling H抯?test will now display across multiple screens/displays ?i.e. all active displays. - A threshold has been add
ed
for the 揷orrupt header ?packet discard
ed
?event in the advanc
ed
network options so that a 揊ail?is not produc
ed
when that is the only thing that produces errors. - Add
ed
looping capability in scripting. LOOP n { ? } where n is the number of times to repeat the commands in the brackets. - Correct
ed
a bug where PASS could be display
ed
if the Advanc
ed
Network test was the only test running, but it fail
ed
. Release 5.0 build 1001 WIN32 release 9/March/2006 - Correct
ed
a bug where Network directory paths were not accept
ed
, eg. for the log file name and post test application file name. - The CPU maths test has been improv
ed
to better load up all CPU's. Previously BurnInTest start
ed
a maths test
thread
per physical CPU package. BurnInTest has been chang
ed
to start a maths test
thread
per CPU (= num. physical CPU packages x num. CPU cores x num. logical CPUs). - The CPU preferences have been chang
ed
to allow the CPU maths test to be lock
ed
to any CPU (ie. select a CPU from a list of CPU's where the number of CPU's = num. physical CPU packages x num. CPU cores x num. logical CPUs). - The Parallel and Serial port error message have been modifi
ed
in the case where a test plug may not have been connect
ed
to indicate that the user should check this. - Correct
ed
a bug where a licenc
ed
version could display the message "[limit
ed
evaluation version]" Release 5.0 build 1000 WIN32 release 24/February/2006 WIN64 release 24/February/2006 NEW TESTS & IMPROVEMENTS TO EXISTING TESTS BurnInTest Standard and Professional versions. - Add
ed
a customer style results certificate. This will save the log file in HTML format but from the perspective of a end customer. This report style can be tailor
ed
by the user (through changing an HTML template). - An MP3 playback test has been add
ed
to the Sound test. - A color printer test has been add
ed
. - A new post test option to allow the results to be print
ed
automatically at the end of a test has been add
ed
. - Add
ed
new Post-test action options of: - Optionally allow the user to "run an external program & exit" after BIT has been manually stopp
ed
. Modify the $RESULT variable to "PASS (manual
abort
)" or "FAIL (manual
abort
)" for this case. - Allow the results window to be display
ed
for all post test options (except Reboot). - Add
ed
new Pre-test actions to allow an external application to be run and have BIT wait for the application to exit. On continuing, BIT will run the subscript file (of scripting commands) if it has been creat
ed
. - Chang
ed
the manual Stop buttons, to
abort
the running of a script (rather than just the current test). BurnInTest Professional specific. - Add
ed
a "Plugin" test that allows users to develop their own BurnInTest test modules for specializ
ed
hardware. Three external plugins may be specifi
ed
at once. - A Modem test has been add
ed
to BurnInTest as a Plugin. PassMark's ModemTest Version V1.3 (latest build) is requir
ed
. - A KeyBoard Test has been add
ed
to BurnInTest as a Plugin. PassMark's KeyboardTest Version V2.2 (latest build) is requir
ed
. - A Firewire Test has been add
ed
to BurnInTest as a Plugin. PassMark's free Firewire plugin is requir
ed
and a "Kanguru FireFlash" drive is requir
ed
. - A new advanc
ed
network test has been add
ed
. BurnInTest Professional only. - The Memory test now allows the user to specify the type of test pattern to be us
ed
. - Testing with the USB 2.0 Loopback plug has been improv
ed
. When us
ed
with USB 2.0 Loopback device driver V2.0.1002, error details will now be report
ed
for: CRC error report
ed
by USB Host controller BIT STUFF error report
ed
by USB Host controller DATA TOGGLE MISMATCH error report
ed
by USB Host controller STALL PID error report
ed
by USB Host controller DEVICE NOT RESPONDING error report
ed
by USB Host controller PID CHECK FAILURE error report
ed
by USB Host controller UNEXPECT
ED
PID error report
ed
by USB Host controller DATA OVERRUN error report
ed
by USB Host controller DATA UNDERRUN error report
ed
by USB Host controller BUFFER OVERRUN error report
ed
by USB Host controller BUFFER UNDERRUN error report
ed
by USB Host controller NOT ACCESS
ED
error report
ed
by USB Host controller FIFO error report
ed
by USB Host controller TRANSACTION (XACT) ERROR report
ed
by USB Host controller BABBLE DETECT
ED
error report
ed
by USB Host controller DATA BUFFER ERROR report
ed
by USB Host controller In the case of these errors, BurnInTest will re-attempt the operation. The user can set the Error reporting to be skipp
ed
for the initial recovery attempt. IMPROVEMENTS TO TESTING FACILITIES - Add
ed
a disk autoconfig, such that when tests are start
ed
, the disk drives and settings will be defaults to all disks (exc. CD/DVD). This may be useful when testing multiple systems with different hard disk drive letters. - Store the position of the Main window on exiting BurnInTest. On starting BurnInTest, position the main window as sav
ed
; on starting tests, position the test windows as sav
ed
. - Allow a "drag & drop" of the Configuration file directly on the BurnInTest program icon. - Allow testing 99.5% to 100% of disk, instead of 94%, for disks that do not contain the Windows directory and do not contain a swap file. - Add
ed
the ability to log interim results, which may be useful for unstable systems. - AMD and Intel Dual core reporting add
ed
. - New L2 CPU cache sizes add
ed
to reports. - CPU support for SSE3, DEP and PAE add
ed
to reports. - Shortcut of "F1" for contextual help add
ed
to all Windows. - Improve the flexibility in specifying the EXECUTEWAIT scripting command for sleeper. - Updat
ed
logging header information with the hard and optical drive model. - The 2D and 3D tests have been updat
ed
to use DirectX 9.0c. - User interface updat
ed
. - The HTML report format has been improv
ed
. - The BurnInTest configuration file extension has been renam
ed
from .cfg to use .bitcfg, to ensure the configuration file is associat
ed
with BurnInTest. - An error message indicating that accumulat
ed
log files are not support
ed
when run from CD or DVD has been add
ed
. - To allow smaller test files with very large disks, the minimum disk test file size has been r
ed
uc
ed
from 0.1% to 0.01% of the disk space. - Log events were previously shown as "INFORMATION" if they were low level errors, or simply additional information (not errors). "INFORMATION" now refers to a low level error, and "LOG NOTE" now refers to additional information (that is not in the error count). - Improv
ed
the specific detail of the Serial Port errors detect
ed
. BurnInTest now reports framing errors, buffer overrun errors, input buffer overflow errors, parity errors and Transmit buffer full errors as specific error messages (rather than a broader error description). - Add
ed
the /k command line so the user can specify not to delete HDD test files if an error occurs. - Increas
ed
Activity trace level 1 error logging for Serial port testing. - Increas
ed
Activity trace level 1 error logging for Hyper
thread
ing detection. - Bundl
ed
a new version of the Rebooter program. - Improv
ed
the Serial port error logging (displaying baud rate) and increas
ed
Activity trace level 1 error logging (displaying erroneous data). - Modifi
ed
the Window sizes to help improve navigation on smaller displays (i.e. 640x480). - The CPU load for the Standard and Torture RAM tests has been made more linear with the duty cycle setting. Note: This means that compar
ed
to the previous build of BurnInTest, less RAM test operations will be run per second (when the duty cycle is less than 100). - Additional debug code and very minor changes in the Loopback sound test. - The Post test option of "Run external application and exit" has been modifi
ed
such that if no external file is specifi
ed
, this Post test option will just exit BurnInTest. - Allow
ed
the full range of PassMark USB1 loopback plugs to be us
ed
with BurnInTest Professional. - Add
ed
additional Activity Trace level 2 logging. - The delay insert
ed
between packets in the USB2 test, when the duty cycle is less than 50, has been chang
ed
from at least 1ms to at least 1ms to 50ms (for a Duty Cycle of 49 down to 0). - The subscript commands to configure BurnInTest from an external application (i.e. specifi
ed
in the bit-script-input.txt file and run by specifying either a pre-test or EXECUTEWAIT application) has been chang
ed
to allow "LOAD" commands (in addition to "SET" scripting commands). - Renam
ed
the "Error" log to "Event" log. - Chang
ed
the order of the items in an Event log line, such that the Severity is the first item. - The EXECUTEWAIT script command has been modifi
ed
such that the external application may provide an input script file (of SET... commands) to be run after the EXECUTEWAIT application closes. This allows external applications to define test environment parameters (such as the serial number and machine type). - Add
ed
scripting commands: SETSERIAL "1234-shdfgdhs-GHGHG" SETMACHINETYPE "HP XPS800" SETNOTES "Test notes defin
ed
by the external application." SETLOG "\Program Files\Plugin\plugin_log" SETPLUGIN "\Program Files\Plugin\plugin.exe" - Add
ed
POST TEST application parameter substitution to allow values to be pass
ed
to an external application at the end of a test. These are: $RESULT - "PASS" or "FAIL" will be substitut
ed
. $SERIAL - The serial number will be substitut
ed
. $MACHINETYPE - The machine type will be substitut
ed
. $NOTES - The notes will be substitut
ed
. - Add
ed
extra logging for memory allocation errors in the disk test - Add
ed
"log bad sector increase" and "bad sector threshold" options to disk test. This result
ed
in a change to the configuration file format and requir
ed
additional code to automatically convert from old formats. - Modifi
ed
the user interface in the preferences window for the disk test and the CD test - Improv
ed
the handling of USB 2.0 loopback plugs recovery from sleep states. BUG CORRECTIONS - Correct
ed
a bug where the System and Application events logg
ed
in the BurnInTest Trace logs were wrong if the event log had reach
ed
its maximum size. - Checks that the Sound test files (WAV and MIDI) exist have been add
ed
. - The continuous auto updating of the USB image (USB Loopback plug vs. USB 2.0 Loopback plug) on the main window has been remov
ed
. This is now updat
ed
on BIT startup, selecting Refresh in USB preferences or on starting a test. If there is a serious USB problem, this (together with the USB 2.0 Loopback device driver, V2.0.1002) will avoid the possibility of BurnInTest locking up. - Correct
ed
a bug with the Butterfly seek mode of the Disk test. This was found to occur with FAT32 disks where the Cylinder size was relatively small and the Sector size relatively large. - Reset Defaults on the Configuration Page now resets the Auto Stop Value. - Reset Defaults on the Configuration Page now resets the color indicators. - The CD test has been modifi
ed
to skip invalid files either with "?"'s , to avoid reporting errors that are due to the CD test m
ed
ia filenames. - The Network test results window scroll bar has been correct
ed
. - The Memory torture test could fail on some systems with a small amount of RAM and relatively high memory fragmentation. This has been correct
ed
. - Scripting correction for .cmd files. - Correct
ed
a bug that caus
ed
problems when running the disk test with SMART monitoring turn
ed
on. This problem only occurs on a small number of HDD's. - Correct
ed
memory leaks - On occasion, the measur
ed
waveform from the loopback sound test may have been slightly alter
ed
on starting or stopping all tests, possibly enough to trigger an error. This has been resolv
ed
. - If an error occurr
ed
in the final second of a test, the error may have been logg
ed
but not includ
ed
in the big PASS/FAIL results window. This has been correct
ed
. - After running a script file that load
ed
a configuration file, that had a full path specifi
ed
, the Save and Load configuration menu options no longer work
ed
. This has been correct
ed
. - Previously, the Version of BurnInTest was only written in the First log file after starting BurnInTest. This log line is now written in all log files. - For USB2 tests that have read or write failures, the Windows error codes are now includ
ed
in the level 2 Activity trace log. - Command line parameters may now be pass
ed
to a PreTest application. - Log files may now use a single static filename. This may be useful when the log file is to be pars
ed
by an external program. - Correct
ed
a bug where the Plugin test would stop prematurely. - Correct
ed
the specification of the Scripting EXECUTEWAIT filename. - Chang
ed
Script processing such that a script is
abort
ed
if a scripting error is encounter
ed
and Stop on error is select
ed
. - Add
ed
an indication on the main window that a script is currently running ("Script currently running"). - Correct
ed
the serial port test to identify non-existing plugs when the Disable RTS/CTS and DSR/DTR testing has been select
ed
. - Correct
ed
the display of strange results (666666) report
ed
by a user, relat
ed
to copy protection. - Fix
ed
a memory leak bug in the MBM interface which caus
ed
memory allocation errors. - Add
ed
BIT version number to the ASCII log file. - Fix
ed
a bug with the 3D Test that was causing it to stop before the autostop timer period - Chang
ed
an error in the tape drive test to a warning if tape drive doesn't support setting drive parameters. History of earlier releases: Please see http://passmark.com/products/bit_history.htm Documentation ============= All the documentation is includ
ed
in the help file. It can be access
ed
from the help menu. There is also a PDF format Users guide available for download from the PassMark web site. Support ======= For technical support, questions, suggestions, please check the help file for our email address or visit our web page at http://www.passmark.com Ordering / Registration ======================= All the details are in the help file documentation or you can visit our sales information page http://www.passmark.com/sales Compatibility issues with the Network & Parallel Port Tests =========================================================== If you are running Windows 2000 or XP, you ne
ed
to have administrator privileges to run this test. Enjoy.. The PassMark Development team
Thread
was being
abort
ed
分析与解决
Thread
was being
abort
ed
分析与解决 在捕获异常的try块中使用 response.r
ed
irect(); 或 response.write();response.end(); 有时会提示线程已被中止(英文:"
Thread
was being
abort
ed
")错误. 分析该错误的原因是由于执行这两个命令会重新发起一次请求,将当前请求的进程
abort
掉;
Thread
was being
abort
ed
.
异常:
Thread
was being
abort
ed
.(正在终止线程) 网上很多人说Response.r
ed
irect或Response.write()放在了try catch块中引起 百度一下就可已查到很多相关文章。 我尝试删掉catch块中的Response.write(),并不起作用。(其实我的是服务,间隔调取页面,异常只会在服务执行2次以上由我显式抛出,当时怀疑删掉后也不会起作用。前...
疑难问题
22,209
社区成员
121,731
社区内容
发帖
与我相关
我的任务
疑难问题
MS-SQL Server 疑难问题
复制链接
扫一扫
分享
社区描述
MS-SQL Server 疑难问题
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章