This section contains error messages for the Adaptive Server Lock Manager.
20
Caller of lock manager is incorrectly trying to unlock an unlocked object. spid=%d locktype=%d dbid=%d object id or page number=%ld.
Before the Lock Manager tries to unlock an object, it checks to make sure the object is in fact locked. When an object is not locked during this check, Error 1203 occurs.
This error is usually due to an Adaptive Server problem which causes an incorrect session descriptor pointer or logical page number to be passed to the Lock Manager.
Error 1203 can occur during an insert, update, or select, particularly on a table with an index.
Call Sybase Technical Support.
Before calling Technical Support, have the following information available:
Server version and SWR version level
Server error log
Output of sp_lock
Text of all error messages
All versions
19
SQL Server has run out of LOCKS. Re-run your command when there are fewer active users, or contact a user with System Administrator (SA) role to reconfigure SQL Server with more LOCKS.
This error occurs when Adaptive Server runs out of locks . The number of locks available is controlled by the Adaptive Server configuration parameter number of locks.
Following is an example of the output from sp_configure, and a brief description of the output related to locks:
1> sp_configure "number of locks" 2> go
Parameter Name Default Memory Used Config Value Run Value --------------------- ----------- ----------- ------------ ----------- number of locks 5000 0 5000 5000
The Default column contains the default value for number of locks, 5000.
The Memory Used column indicates the amount of memory used by the configured locks. Each lock requires 72 bytes of memory (11.5.x and earlier) or 120 bytes (11.9.x and later).
The Config Value column contains the value to which the number of locks configuration parameter has been set with sp_configure. If the value has not been explicitly configured, there is a 0 in this column and the default value is used.
The Run Value column contains the value Adaptive Server is using.
Rerun the command when there are fewer active users, or ask the Sybase System Administrator (“sa”) to reconfigure Adaptive Server for more locks. Increasing the number of available locks impacts performance and memory requirements.
WARNING! Before making any changes to Adaptive Server, refer to the Performance and Tuning Guide and “Configuring Memory” in the System Administration Guide for information about how Adaptive Server uses memory resources.
To increase the number of locks available, complete the following steps:
Determine the number of locks currently configured for Adaptive Server:
1> use master 2> go
1> sp_configure "number of locks" 2> go
WARNING! If you increase the number of locks available by too many locks, Adaptive Server may run out of memory and be unable to restart. Refer to Chapter 1, “Adaptive Server Does Not Start After Altering Configuration” if you run out of memory and cannot restart Adaptive Server.
Choose the number of locks you want to configure and issue the following command:
1> sp_configure "number of locks", new_value 2> go
Restart Adaptive Server to operate with the new values.
Refer to the Performance and Tuning Guide for information about locks and other Adaptive Server resources.
Refer to “number of locks” in the System Administration Guide for information about the number of locks configuration parameter.
All versions
13
Your server command (family id #%d, process id #%d) encountered a deadlock situation. Please re-run your command.
This error occurs when a process tries to acquire a lock on an object that is locked by a second process when the second process is waiting for a lock on an object that has been locked by the first process. This situation is a deadlock, and can involve more than two processes.
Adaptive Server detects this situation, rolls back the transaction that has accumulated the least amount of CPU time, and notifies the application program of this action with Error 1205. This allows the other users' processes to move forward.
Deadlocks are caused by a number of situations, including:
Transactions modify tables in different orders. There is a greater chance of deadlock between two transactions if one is processing in the sequence A - B - C while the other runs C - B - A.
Transactions access tables via a nonclustered index. If the optimizer chooses a different nonclustered index for the same table for two different queries, a nonclustered index is not in the physical data sequence and the two processes are acquiring page locks in a random order. Thus, there is a greater chance that one process will lock a page that the other needs.
Transactions that use the keyword holdlock or use the set isolation level command to hold shared locks. When holdlock is appended to a select transaction it holds the shared lock for the remainder of the transaction. This increases the risk of deadlock.
Transactions that require a long time to run. The longer a transaction runs, the more likely it is that another user will require a resource held by the transaction.
Restart the transaction that has been rolled back.
To minimize future occurrences of deadlocks, use any of the following procedures that apply to your site.
Each application should have deadlock handling routines. Refer to the dbsetuserdata entry in the Open Client DB-Library Reference Supplement for a sample deadlock handling routine.
Using transactions constructed to avoid deadlocks greatly reduces their occurrence. Some techniques for writing transactions that avoid deadlock include:
Access tables in the same order in each transaction. Use coding conventions that require all transactions that access several tables to process them in the same order.
Access tables via a clustered index when possible. If it is not possible to change a nonclustered index to a clustered index to minimize deadlocks, then trap the deadlock error in the application and provide appropriate recovery routines.
If you are using holdlock, decide whether you really need to be using it. Use holdlock only when you require repeatable reads within a transaction.
Avoid long-running transactions. Some ways to avoid long-running transactions are:
Never allow user interaction within a transaction.
Separate logical units of work into transactions. For example, acquiring a sequential key from a key table for use in an insert statement can be separated into transactions similar to the following (in the first set of commands, you acquire the key; in the second set of commands, you use the key to do the insert):
1> declare @key int 2> begin transaction 3> update key_table set key = key + 1 4> select @key = key 5> commit transaction 6> go 1> insert mytable 2> values (@key, ...) 3> go
Check whether client applications, including third party tools, allow users to accidentally create long running transactions.
Refer to “Lock Manager” in the System Administration Guide.
All versions
26
Couldn't find object to be released.
When Adaptive Server no longer needs a lock, it releases it. Error 1243 occurs when Adaptive Server cannot find the object for the lock to be released. It occurs with the following states:
State |
Meaning |
1 |
Adaptive Server uses address locks to lock memory addresses for buffers containing OAM and allocation pages. If, during the release of an address lock, Adaptive Server fails to find one of the buffers, Error 1243 occurs with State 1. |
2 |
Adaptive Server uses logical locks for database pages and tables. The server searches for the logical lock before releasing it. If, during the release of a logical lock, the server fails to find the requested object on the lock chain, Error 1243 is raised with State 2. |
Shut down and restart Adaptive Server.
Since the unreleased lock may be an exclusive lock,
there may be some objects you cannot access until you restart Adaptive
Server.
If Error 1243 occurs again, call Sybase Technical Support.
All versions
20
Process became runnable before lock it was waiting for was released.
Process (spid=%d) became runnable before lock it was waiting for was released. This is an unexpected lock manager error. Please contact Technical Support and provide them the information logged in the errorlog.
The Lock Manager maintains queues of lock requests to enable server tasks to obtain read, write and update locks as needed. A task sleeps while waiting for a lock request to be granted. Error 1249 is raised when the task awakes but the Lock Manager detects an abnormal condition in the lock queue for that lock. Error 1249 is raised in the following states:
State |
Meaning |
|---|---|
1 |
The lock request was granted, but the lock is not at its expected position in the queue. |
2 |
The lock received a signal to requeue, but it is not at its expected position in the queue. |
Error 1249 is caused by an Adaptive Server problem and breaks the connection to the server. In a common scenario leading to this error, separate sessions open cursors on the same table, and the user aborts one session in the middle of an update; attempting the same transaction again raises the 1249 error.
Call Sybase Technical Support.
Have the following information ready when you call Sybase Technical Support:
Server version and SWR rollup level
Server error log
Operating System error log
All versions
20
A lock manager routine expected a lock record as an argument but was passed something else. lr=0x%x, lrmagic=%c.
This error occurs when the Adaptive Server Lock Manager is:
Releasing a lock
Transferring a lock
Waiting for a lock
and the lock record structure is not valid.
This error is usually due to an Adaptive Server problem.
Shutting down and restarting Adaptive Server will usually clear the 1265 error. If it does not clear the error or if the error occurs repeatedly, call Sybase Technical Support.
Before calling Technical Support, have the following information available:
Server version and SWR version level
Server error log
Output of sp_lock at the time the 1265 error occurred
Text of all error messages
All versions
16
SQL Server has run out of locks on engine %d. Re-run your command when there are fewer active users, or contact a user with System Administrator (SA) role to reconfigure maximum engine freelocks or number of locks.
An Adaptive Server engine is a process running an Adaptive Server that communicates with other Adaptive Server processes via shared memory. An Adaptive Server running on a multiprocessor machine can have one or more engines.
Adaptive Server uses two configuration parameters to control lock use:
number of locks controls lock use Server-wide
max engine freelocks controls lock use for each Adaptive Server engine
Adaptive Server maintains a list of Server-wide free locks and a list of per-engine free locks. When locks are needed for an engine, Adaptive Server moves a block of free locks from the Server-wide free lock list to the free lock cache for that engine.
Error 1279 occurs when Adaptive Server runs out of locks on an engine and is unable to move any more locks from the Server-wide free list but there is an another engine with some free locks. (Error 1204 occurs when Adaptive Server completely runs out of locks.) The error message includes the number of the engine that has run out of locks.
Run your command again later when there are fewer active users or increase the number of locks available to the engine. If you want to increase the resources, you can do one of the following:
Increase the total number of locks available Server-wide by using sp_configure to increase the value of the number of locks configuration parameter.
Decrease the maximum number of locks available for each engine by using sp_configure to decrease the value of the max engine freelocks configuration parameter. By decreasing the value of this parameter, you make more locks available to the engine for which you are getting the error.
Increasing the value of the number of locks parameter
increases the memory resources used by Adaptive Server. Make sure
your Adaptive Server memory is configured appropriately if you change
this value.
Refer to “Lock Manager” in the System Administration Guide for information about Adaptive Server engines and the Adaptive Server Lock Manager.
Refer to the Reference Manual for information about sp_configure and configuration parameters.
Refer to the Performance and Tuning Guide for information about memory management for Adaptive Server.
All versions
