Category: ASE


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.

Sybase

We’ve been upgrading a number of Sybase ASE databases from the end-of-life’d 12.5.x to v15.0.3 esd 4 the last few weeks.   My coworker (Degang He) ran into an interesting error when the upgrade process was failing on sysprocedures.

Database ‘my_db’: beginning upgrade step [ID 26]: alter table (table sysprocedures)
Command has been aborted.

Msg 3461, Level 20, State 1:
Server ‘my_server’, Line 1:
Database ‘my_db’: upgrade could not install required upgrade item ’26′. Please refer to previous error messages to determine the problem. Fix the problem, then try again.

Msg 3451, Level 20, State 1:
Server ‘my_server’, Line 1:
Database ‘my_db’: upgrade has failed for this database. Please refer to previous messages for the cause of the failure, correct the problem and try again.

Msg 3454, Level 20, State 1:
Server ‘my_server’, Line 1:

Database ‘my_db’: ASE could not completely upgrade this database; upgrade item 1501 could not be installed.

We looked on Sybase’s Solved Cases and Google but didn’t find anything that would really fit the problem.  So we called up Sybase Technical Support.  Somdev Sharma of Sybase was able to determine that this was a bug in the ASE 15x codeline and provided a workaround:

CR #643188:

Title Online database failed with 3461 error during upgrade , ‘max parallel degree’ >1

Workaround:

Before online the database, disable parallel sort via sp_configure ‘max parallel degree’,1

Sanitized:

Online database failed with 3461, 3451 and 3454 errors during upgrade sysprocedures table (upgrade  item ’26′). If ‘max parallel degree’ > 1, then please disable parallel sort with sp_configure ‘max parallel degree’, 1.

After disabling parallel sort, the database was upgraded successfully.

On the sybase-l mailing list,

Sybase

Jeff Tallman replied to a question on how to avoid unnecessary reorgs. He graciously agreed to let me post his response here :)

You can avoid most (if not all) of the reorgs by doing:

  1. setting the exp_row_size to something that covers about 90% of the space each row takes up
  2. changing enable housekeeper GC to a 4 or 5

Both of these are a *MUST* do for DOL (datapages or datarows). See manuals on ‘enable housekeeper GC’ for correct setting of 4 or 5 (refers to whether deletes are batch or OLTP).

You can also watch for housekeeper overflows in monEngine/monOpenObjectActivity……and if you see any HKGC pending – wait a few before shutting down.

Jeff wrote up an excellent article, Locking Redux – APL vs. DOL and Tuning, that goes into detail why this is the case.

I was able to move a VMware Server 2.0 (v7) vm to VMware ESX..  it was a *live* copy where I performed a Windows Volume Shadow copy of the vm files.  Everything worked for the most part but because the database, Sybase ASE 15.0.3, was running when the shadow copy was made, we had corruption in one database.  Restore from backup and all is good.

Now we need to get an updated license file from Sybase as the NIC mac address has changed..   You can *not* use the mac address from the VMware Server on ESX.  grr.

Twenty hours for the volume shadow copy to complete plus another 12 hours to scp the files to the esx box (esx console access is sloooow).   Keep in mind that the host VMware Server box was rebooting itself randomly so I really couldn’t leave it alone.  Then 3 hours to convert/clone the vmdk files and 2 hours to correct the database…  I’m tired.

It turned out to be an issue with allocating 3.75GB to a VM that was causing the rebooting.  Dropping it to 2 GB resolved the rebooting… who knew?  Nothing in Google and VMware Support wasn’t able to find anything on their side.

I asked Jeff Tallman if I could redistribute his excellent MDA posters for Sybase’s ASE 15.5 database server.  He said yes so …  here they are in both Adobe PDF and Sybase PowerDesigner PDM formats!

Jeff Tallman also provided us with the MDA posters for Sybase 15.0.3 last year.