Tuning

• Resource contention levels. Adding engines can increase contention for data caches, database devices, and locks.
• Number of usable CPUs on the machine. Never configure more engines than CPUs.

• bulk copy
• readtext and writetext commands
• select statements resulting in large amounts of data

• Encourage use of stored procedures, views, and triggers. These features store code on Adaptive Server and require only a short command across the network to invoke them.
• Use larger packet sizes by increasing default packet size or encouraging connections that request packet sizes larger than the default.
• Set the tcp no delay configuration parameter to off (the default). The off setting allows TCP to batch small logical packets into large physical packets.
• Tune the TCP packet size to better accommodate Adaptive Server average packet size.
• Tune SQL statements to select (and send across the network) the specific information required. For example, an application should not select all columns in a table when it only needs information from one column.
• Tune SQL statements that use cursors to request multiple rows in each fetch command if a single row does not fill up a network packet.
• Run applications with large data transfers at non-peak hours or use a separate network for such operations. Run backups at non-peak hours.
• Use replication processing and two-phase commits only when necessary. These features contribute heavily to network traffic.
• Place heavy network users on a separate network.
• Configure multiple network listener ports for a single Adaptive Server. See platform specific configuration guides for more information.

• Named Data Cache Monitor
• Databases-->User Tables folder - Cache Binding tab.

• Research long-running statements to reduce table scans.
• Research index design to reduce table scans.

• Object Page I/O Monitor
• Named Data Cache Monitor

• Object Lock Status Monitor to see details about specific locks
• Object Lock Contention Monitor to see contention statistics by table.

• sp_sysmon command (task management section) to see reasons for task context switches
• Process Activity Monitor to see execution classes of concurrently running processes
• Execution Classes folder -- Bindings tab.

• Place a heavily used index on a different segment from its table.
• Separate heavily used tables by placing them on different devices
• Place tempdb on its own physical disk.
• Place transaction logs on different devices from tables
• Split a large table over several devices. Split tables by:
  • Separate text and data pages
  • Partition a heap table
  • Partially load a clustered index table

• Perform maintenance
• In ASE version 11.9.x, reduce future fragmentation by setting reserve page gap.

• Table property sheet - Lock tab
• Index property sheet - Misc. tab

• the operating system cannot keep pace with Adaptive Server disk I/O requests
• limits imposed by these Adaptive Server configuration parameters: disk i/o structure, max async i/os per server, or max async i/os per engine
• limits on asynchronous I/Os imposed by an operating system parameter

• Resource contention levels. Adding engines can increase contention for data caches, database devices, and locks.
• Number of usable CPUs on the machine. Never configure more engines than CPUs.

• lock promotion LWM
• lock promotion HWM
• lock promotion PCT

• Process Activity Monitor
• Stored Procedure Activity Monitor
• Object Lock Status Monitor to identify hotspots. (If the same page address shows up repeatedly, the page might be a hot spot.)

• Process Activity Monitor to see execution classes of concurrently running processes.
• Execution Classes folder -- Bindings tab.

• Creating at least one unique index on a table.
• Redesign statements to use non-key columns in the where clause when updating a key.

Increase the chances that enough room will exist on a page for a direct update to occur by:

• Using fixed length datatypes instead of variable length datatypes.
• Using max_rows_per_page attribute on tables or indexes.

An optimally sized named cache retains a good percentage of often-used pages in cache, increasing hit rates.

Adding space to a named data cache detracts from available procedure cache space.

• Object Page I/O Monitor. Logical Reads identifies high-use objects.
• Caches folder -- Configuration tab.

Optimal object binding reduces physical reads. Indexes and their table data can be bound to separate caches.

• Object Page I/O Monitor. Logical Reads identifies high-use objects.
• Caches folder -- Cache Bindings tab.

Efficiency is low when hit rates are low and memory allocations are relatively high. This could mean that space is being wasted in this named cache. Redistributing that space (to the default cache, for example) might improve the hit rate of another cache.

High efficiency means that space is appropriately allocated to this named cache.

• Perform maintenance.
• In ASE versions 11.9 or greater, reduce future fragmentation by setting reserve page gap.

• Caches folder -- Cache Bindings tab.

  To set reserve page gap:

• Tables property sheet - Lock tab
• Index property sheet - Misc. tab

The Adaptive Server optimizer attempts to use the buffer pool with the largest sized buffers. If it cannot use that pool, it uses the 2K pool. All other pools are ignored.

The Adaptive Server Optimizer cannot perform large I/O if there are no buffers to handle the large reads.

• Research long-running statements to reduce table scans
• Research index design to reduce table scans

Test the results carefully. Allocating more memory to Adaptive Server reduces available memory elsewhere, possibly slowing down some processes.

Investigate configuration of named caches.

Test the results carefully. Allocating more memory when a very large number of processes are running might have minimal gain.

Engine affinity reduces the chances of a process to gain a time slice. Critical processes should be free to run on any engine.

Consider raising execution attributes of I/O bound applications, logins, and stored procedures and/or lowering execution attributes of cpu-bound applications, logins, and stored procedures.

• Stored Procedure Activity Monitor
• Application Activity Monitor

• Named Data Cache Monitor
• Device I/O Monitor

• Stored Procedure Activity Monitor to identify blocking SPIDs
• Object Lock Status Monitor to identify objects involved in lock contention

General trend for many processes:

• Object Lock Status Monitor
• Object Lock Contention Monitor to see lock statistics by table.

• Split a heavily used table into two tables to create the potential for more shared locking. (Separate frequently updated information from frequently accessed read-only columns.)
• Decrease the number of rows stored per page by using fillfactor or max_rows_per_page.
• In small tables or indexes experiencing heavy contention, use a low value for the max_rows_per_page option in the create table, create index or alter table command. (A value of 1 in max_rows_per_page makes a lock on a page a lock on only one row. While this technique will reduce lock contention for that table, it causes a page split for every insert.)

• avoid user interactions within transactions.
• make transactions short.
• make sure update or delete transactions can use an index to locate rows.
• avoid cursors that acquire exclusive locks within transactions. (Such locks are held for the duration of the transaction.)
• make sure cursors within transactions include a close on endtran clause. (Without this clause, the cursor's locks are held beyond the transaction.)
• avoid overusing holdlock.
• avoid overusing transaction isolation level 3. (Isolation levels 0 or 1 are less restrictive.)
• keep a transaction in a single batch. This reduces network latency time and thus releases locks quicker.

• Partitioning or increasing the number of partitions on heap tables. (Partitioning provides more than one last page, reducing contention for exclusive locks on the last page.)
• Creating a clustered index.