Sybase ASE’s “lock hashtable size” is NOT just for Cluster Edition!!

The “cluster edition only” note in v15.0 documentation was a DOCUMENTATION BUG that was fixed in 15.5. Why the F is Sybase techsupport still saying it is only for cluster edition???? It was introduced in v11.9.2 more than a DECADE ago. Sybase TechSupport: read your manuals! 😉

New Functionality in Adaptive Server Enterprise 11.9.2

lock hashtable size

Summary Information
Default value 2048
Range of values 1-2147483647
Status Static
Display level Comprehensive
Required role System Administrator

The lock hashtable size parameter specifies the number of hash buckets in the lock hash table. This table manages all row, page, and table locks and all lock requests. Each time a task acquires a lock, the lock is assigned to a hash bucket, and each lock request for that lock checks the same hash bucket. Setting this value too low results in large numbers of locks in each hash bucket and slows the searches. On Adaptive Servers with multiple engines, setting this value too low can also lead to increased spinlock contention. You should not set the value to less than the default value, 2048.

lock hashtable size must be a power of 2. If the value you specify is not a power of 2, sp_configure rounds the value to the next highest power of 2 and prints an informational message.

The optimal hash table size is a function of the number of distinct objects (pages, tables, and rows) that will be locked concurrently. The optimal hash table size is at least 20 percent of the number of distinct objects that need to be locked concurrently. See “Lock Hash Table Information” for more information on configuring the lock hash table size.

Share Button

3 Replies to “Sybase ASE’s “lock hashtable size” is NOT just for Cluster Edition!!”

  1. As you can tell, I’m quite ticked about this. I keep running into the argument that a customer contacted Sybase TechSupport and “Sybase says it is only for Cluster Edition .. so we’re not going to make that change”

  2. I’ve tangled with this parameter in the past.
    We had a busy system which regularly ran large reports taking lots of locks.
    Occaisionally these failed and took an age to rollback leaving the system in a degraded state (logfills etc.).
    The workaround to the excessively long rollback periods (3rd party app) was to increase ‘lock hashtable size’ to 8192.
    We now set this as a default on all our systems to minimise rollback times.

Leave a Reply

Your email address will not be published. Required fields are marked *