Memory View (Sybase ASE Performance Analyst)

From RapidSQL
Jump to: navigation, search

Go Up to Sybase ASE Performance Analyst Statistics

In addition to a Home page, the Memory category of Sybase ASE Performance Analyst includes the following tabbed pages:

Home

The Memory performance category view displays the following vital Sybase ASE memory statistics:


Key Ratio Analysis Pane

Database performance analysts typically use one of two methods for examining the performance levels of a database - ratio-based or wait/bottleneck-based. Ratio-based analysis involves examining a number of key database ratios that can be used to indicate how well a database is running. Performance ratios serve as very good roll-up mechanisms for busy DBA's to use for at-a-glance performance analysis. Many DBAs have large database farms to contend with and cannot spend time checking detailed wait-based analysis outputs for each and every database they oversee. Succinctly presented performance ratios can assist in such situations by giving DBAs a few solid indicators that can be quickly scanned to see if any database needs immediate attention.

While there are certainly many opinions as to what rules to follow, there are some standards that should always be adhered to. To start with, many of the formulas that make up ratio-based analysis must be derived from delta measurements instead of cumulative statistics. Many of the global ratios that a DBA will examine come from the master.sysperfinfo performance table. This table maintains a count of various statistics for the server and particular databases since the server was brought up. For servers that are kept up for long periods of time, these values can grow quite large and will impact how a particular ratio that a DBA might be looking at is interpreted. However, if delta statistics are used (taking, for a specified sampling period, the before and after counts of each statistic that make up a ratio), then an accurate and current portrayal of the various ratios can be had.

A final thing to remember about using ratio-based analysis is that, while there are a number of rules of thumb that can be used as starting points to begin the evaluation of database performance, DBAs must determine each SQL Server's individual 'personality' with respect to the key performance ratios. Some hard and fast rules simply do not apply to every database. The danger in using blanket ratio standards is that they can lead the DBA to haphazardly take action, which can at times contribute nothing to the situation, and sometimes even degrade performance.

The following memory ratios are used on the Performance Analyst Home page to succinctly communicate the general overall memory performance levels of the monitored database:


The following statistics, available on this pane, are duplicates of statistics appearing on the Key Ratio Analysis Pane of the Home View (Sybase ASE Performance Analyst) page:

Dirty Read Restarts

Sybase ASE allows dirty reads, which are reads of uncommitted data. To accomplish a dirty read, Sybase ASE uses a special lightweight protection mechanism to gain access to an object without using actual page locks. A dirty read restart occurs when a dirty read is active on an object page, and another process makes changes to the page that cause the page to be deallocated in memory. The scan for the dirty read must be restarted. The amount shown for dirty read restarts are the number of restarts that occurred since the last IDERA Performance Analyst refresh.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Key Ratio Analysis Pane

Metrics

Values observed much above zero should serve as a signal that application modifications can be in order. Most applications should do everything possible to avoid restarts because of the large overhead they incur.

Correction

If the numbers observed for dirty read restarts are significant, you can want to look into modifying applications that use dirty reads to accomplish data acquisition.

Dirty Read Requests

Sybase ASE allows dirty reads, which are reads of uncommitted data. To accomplish a dirty read, Sybase ASE uses a special lightweight protection mechanism to gain access to an object without using actual page locks. This statistic displays the number of dirty reads that occurred since the last refresh in IDERA Performance Analyst.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Key Ratio Analysis Pane

Metrics

Dirty read page requests can incur significant overhead if they are observed with many dirty read restarts.

Procedure Requests

The Procedure Requests statistic reports the number of times that stored procedures were executed since IDERA Performance Analyst was last refreshed. Such a request could use either an unused copy of the procedure’s query plan in memory or if no such copy exists, the procedure must be read in from disk.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Key Ratio Analysis Pane

Procedure Reads from Disk

The Procedure Reads from Disk statistic reports the number of times since IDERA Performance Analyst was last refreshed that stored procedures were read from disk rather than copied in the procedure cache.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Key Ratio Analysis Pane

Metrics

You should examine this number in conjunction with the overall procedure cache hit rate. Observing large numbers in this statistic indicates a lower than ideal procedure cache hit rate. Note that when a database is first started, this statistic is likely larger than desired because all code being used is relatively new and as such, must be read in from disk and placed into the cache. If, however, after a solid hour or two of steady database time, the procedure cache hit rate has not increased to desirable levels and this statistic continues to sport high numbers, you should look into the possibility of increasing the amount of memory allocated to the cache.

Correction

If a problem is found in Sybase ASE servers, versions 11-12, you can increase the amount of the total memory configuration parameter and/or increase the percentage of memory allocated to the procedure cache (by default, the data cache assumes any free memory left over after Sybase ASE has met its kernel and procedure cache needs). Take care when increasing the procedure cache alone, as this could increase query response times due to more physical I/O being performed. For Sybase ASE 12.5, the total memory configuration parameter can again be increased to provide more memory for the Sybase ASE server, but in 12.5, if you want to increase the size of the procedure cache, note that it is now configured in terms of literal size instead of a percentage of the overall configured memory. Once the procedure cache has been adjusted, monitor Sybase ASE to see if the cache hit rate improves. If it does not, another increase may be necessary. Also, keep a careful eye on the actual machine’s memory limits and swap activity. Increased swap activity can be indicative of too little memory left for the server machine.

Bottleneck Analysis Pane

When Sybase Adaptive Server is running, every connected process is either busy doing work or waiting to work. A process that is waiting might mean nothing in the overall scheme of things or it can be an indicator that a database bottleneck exists. And this is where wait-based or bottleneck analysis comes into play. DBAs use this form of performance analysis to determine if perceived bottlenecks in a database are contributing to a performance problem.

Bottleneck analysis is a valid method of measuring performance because it helps a DBA track where a database has been spending its time. If lock contention or heavy table scan activity has been dragging down database performance, a DBA can use bottleneck analysis to confirm the actual root cause. Once one or more wait events or other bottlenecks have been pinpointed as possible performance vampires, the DBA can drill down and oftentimes discover a fair amount of detail about which sessions and objects are causing the problem.

Memory bottlenecks can definitely cause performance degradation in an otherwise well-running database. Typically, these bottlenecks center around the server latches, which are lightweight locks used to protect certain resources in memory. To help you identify such problems, the following statistics are presented on the Performance Analyst Memory home page:

Log Semaphore Contention

The Log Semaphore Contention statistic measures the total number of times tasks requested a log semaphore. This includes those granted immediately and those for which the task had to wait.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Bottleneck Analysis Pane

Metrics

In high throughput environments with a large number of concurrent users committing transactions, you should expect a certain amount of contention for the log semaphore.

Latch Contention

The Latch Contention statistic reports the number of times a task was switched out because it needed to wait for a latch. If your user tables use only allpages-locking, this latch contention is taking place either on a data-only-locked system table or on allocation pages. If your applications use data-only-locking, the contention reported here includes all waits for latches, including those on index pages and OAM pages as well as allocation pages.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Bottleneck Analysis Pane

Metrics

In SMP environments where inserts and expanding updates are extremely high, so that page allocations take place very frequently, contention for the allocation page latch can reduce performance. Normally, Adaptive Server allocates new pages for an object on an allocation unit that is already in use by the object and known to have free space. For each object, Adaptive Server tracks this allocation page number as a hint for any tasks that need to allocate a page for that object. When more than one task at a time needs to allocate a page on the same allocation unit, the second and subsequent tasks block on the latch on the allocation page.

Correction

You can specify a "greedy allocation" scheme, so that Adaptive Server keeps a list of eight allocation hints for page allocations for a table. The effect of dbcc tune(des_greedyalloc) are not persistent, so you need to reissue the commands after a reboot. You should use this command only if all of the following are true: You have multiple engines. It is rarely useful with fewer than four engines. A large number of pages are being allocated for the object. You can use sp_spaceused or optdiag to track the number of pages. The latch contention counter shows contention.

Waits on Execution Plans

The Waits on Execution Plans value represents the number of times that a process attempting to use sp_showplan had to wait to acquire read access to the query plan.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Bottleneck Analysis Pane

Metrics

Query plans may be unavailable if you run sp_showplan before the compiled plan is completed or after the query plan finished executing. In these cases, Sybase ASE tries to access the plan three times and then returns a message to the user.

Large I/Os Denied

The Large I/Os Denied statistic represents the number of times that large I/O could not be performed.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Bottleneck Analysis Pane

Metrics

Adaptive Server cannot perform large I/O for the following reasons: If any page in a buffer already resides in another pool. When there are no buffers available in the requested pool. On the first extent of an allocation unit, since it contains the allocation page, which is always read into the 2K pool.

Correction

If a high percentage of large I/Os were denied, it indicates that using larger pools might not be as effective as it could be. If a cache contains a large I/O pool, and queries perform both 2K and 16K I/O on the same objects, there will always be some percentage of large I/Os that cannot be performed because pages are in the 2K pool.

If more than half of the large I/Os were denied, and you are using 16K I/O, try moving all of the space from the 16K pool to the 8K pool. Re-run the test to see if total I/O is reduced. Note that when a 16K I/O is denied, Adaptive Server does not check for 8K or 4K pools, but uses the 2K pool.

Buffers Grabbed Dirty

The Buffers Grabbed Dirty statistic represents the number of times Sybase ASE found dirty buffers since the last refresh in IDERA Performance Analyst.

As users request information, buffers are moved into and out of the Sybase ASE data cache. Pages are also modified in the cache (termed dirty buffers) and need to be written out to disk. If Sybase ASE has to wait for a dirty buffer to be written out to disk before a requested buffer is placed into the cache, performance can suffer.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Bottleneck Analysis Pane

Metrics

Ideally, the dirty buffer grab statistic should stay close to zero.

Correction

Seeing high numbers for this statistic could indicate that the cache size is too small. You should look into carefully adjusting the total memory configuration parameter to be higher. However, keep a careful eye on the actual machine's memory limits and swap activity. Increased swap activity can indicate too little memory left for the server machine.

Procedure Removals

The Procedure Removals statistic reports the number of times that stored procedures were aged out of the procedure cache since IDERA Performance Analyst was last refreshed.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Bottleneck Analysis Pane

Metrics

High numbers, along with a lower than desired procedure cache hit rate, could indicate a procedure cache that is too small.

Correction

If a problem is found in Sybase ASE servers, versions 11-12, you can increase the amount of the total memory configuration parameter and/or increase the percentage of memory allocated to the procedure cache (by default, the data cache assumes any free memory left over after Sybase ASE has met its kernel and procedure cache needs). Take care when increasing the procedure cache only, as this could increase query response times due to more physical I/O being performed. For Sybase ASE 12.5, the total memory configuration parameter can again be increased to provide more memory for the Sybase ASE server, but in 12.5, if you wish to increase the size of the procedure cache, note that it is now configured in terms of literal size instead of a percentage of the overall configured memory. Once the procedure cache has been adjusted, monitor Sybase ASE to see if the cache hit rate improves. If it does not, another increase may be necessary. Also, keep a careful eye on the actual machine's memory limits and swap activity. Increased swap activity can indicate too little memory left for the server machine.

Metadata Cache Ratio Analysis Pane

The following statistics are used on the Performance Analyst for Sybase ASE Memory Home Page to succinctly communicate the general overall performance levels of the memory structures:

Open Objects

The Open Objects statistic represents the use of the Adaptive Server metadata cache for open objects. The statistic includes number of active objects, free objects, and the maximum number of objects used.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Metadata Cache Ratio Analysis Pane

Metrics

When Adaptive Server accesses an object, it needs to read information about it in the corresponding system table: sysobjects. The metadata cache for objects lets Adaptive Server access the information that describes it in the sysobjects row directly in its in-memory structure. This improves performance because Adaptive Server bypasses expensive calls that require disk access. It also reduces synchronization and spinlock contention when Adaptive Server has to retrieve object information at runtime. Managing individual metadata caches for databases, indexes, or objects is beneficial for a database that contains a large number of indexes and objects, and where there is high concurrency among users.

Correction

You can use this information to set the configuration parameter’s number of open objects.

Open Indexes

The Open Indexes statistic represents the use of the Adaptive Server metadata cache for open indexes. The statistic includes the number of active indexes, free indexes, and the maximum number of indexes.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Metadata Cache Ratio Analysis Pane

Metrics

When Adaptive Server accesses an index, it has to access information about it in the respective system table: sysindexes. The metadata cache for indexes lets Adaptive Server access the information that describes it in the sysindexes row directly in its in-memory structure. This improves performance because it allows the Adaptive Server to bypass expensive calls that require disk access. It also reduces synchronization and spinlock contention when Adaptive Server has to retrieve index information at runtime. Managing individual metadata caches for databases, indexes, or objects is beneficial for a database that contains a large number of indexes and objects, and where there is high concurrency among users.

Correction

You can use this information to set the configuration parameter’s number of open indexes.

Open Databases

The Open Databases statistic shows the use of the Adaptive Server metadata cache for open databases. This statistic charts the number of active databases, free databases, and the maximum number of databases used.

When Adaptive Server opens a database, it has to access information about it in the respective system table: sysdatabases. The metadata cache for databases lets Adaptive Server access the information that describes it in the sysdatabases row directly in its in-memory structure. This improves performance because it allows the Adaptive Server to bypass expensive calls that require disk access. It also reduces synchronization and spinlock contention when Adaptive Server has to retrieve database information at runtime.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Metadata Cache Ratio Analysis Pane

Metrics

Managing individual metadata caches for databases, indexes, or objects is beneficial for a database that contains a large number of indexes and objects, and where there is high concurrency among users.

Correction

You can use this information to set the configuration parameter’s number of open databases.

Object Spinlock Contention

The Object Spinlock Contention statistic represents spinlock contention on the object descriptor caches.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Metadata Cache Ratio Analysis Pane

Correction

You can use this information to tune the configuration parameter’s open object spinlock and open index spinlock ratios. If the reported contention is more than 3%, decrease the value of the corresponding parameter to lower the number of objects or indexes that are protected by a single spinlock.

Index Spinlock Contention

The Index Spinlock Contention value represents spinlock contention on the index descriptor caches.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Metadata Cache Ratio Analysis Pane

Correction

You can use this information to tune the configuration parameter’s open object spinlock and open index spinlock ratios. If the reported contention is more than 3%, decrease the value of the corresponding parameter to lower the number of objects or indexes that are protected by a single spinlock.

Hash Spinlock Contention

This metric represents the contention for the spinlock on the index metadata cache hash table.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Metadata Cache Ratio Analysis Pane

Correction

You can use this information to tune the open index hash spinlock ratio configuration parameter. If the reported contention is greater than 3%, decrease the value of the parameter.

Memory Analysis Pane

The following statistics are used on the Performance Analyst for Sybase ASE Memory Home Page to succinctly communicate the general overall performance levels of the memory structures:

Buffer Cache

The Buffer Cache statistic displays the amount of memory currently allocated to the Buffer Cache.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Memory Analysis Pane

Procedure Cache

The Procedure Cache value displays the amount of memory currently allocated to the procedure cache.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Memory Analysis Pane

Metrics

The memory allocated for the procedure cache holds the optimized query plans (and occasionally trees) for all batches, including any triggers.

Connection Memory

The Connection Memory value indicates the amount of memory currently allocated to user connections.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Memory Analysis Pane

Metrics

Each connection requires approximately 60 KB.

Open Database Memory

The Open Database Memory value represents the current amount of memory allocated in the number of open databases parameter.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Memory Analysis Pane

Open Object Memory

This value represents the current amount of memory allocated in the number of open objects parameter.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Memory Analysis Pane

Open Index Memory

This value represents the current amount of memory allocated in the number of open indexes parameter.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Memory Analysis Pane

Workload Analysis Pane

The following statistics are used on the Performance Analyst for Sybase ASE Memory Home Page to succinctly communicate the general overall performance levels of the memory structures:

Top Memory Hogs

This metric identifies the process that currently is using the highest percentage of memory in the database.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Home > Workload Analysis Pane

Metrics

It is not uncommon for one or two users to cause the majority of runtime problems that plague a server. The problem could be a runaway process, an untuned batch procedure, or other user-initiated operation. If your database server does not have an overabundance of memory, then you should periodically check to see who your heavy memory users are along with the total percentage of memory each takes up. If you see one or two users who have more than 25-50% of the total memory usage, then you should further investigate the sessions to see what activities they are performing.

Data Cache Tab

The Data Cache tab of the Memory Detail View includes the following sections:

The following statistic, available on this tab, duplicates a statistic available on the Key Ratio Analysis Pane of the Home View (Sybase ASE Performance Analyst) page:

Cache Configurations

The Cache Configuration view represents the default and named data caches and the memory configuration in MB.

Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Data Cache Tab

Cache Efficiency

The Cache Efficiency section summarizes behavior for the default data cache and all named data caches combined. The table below describes the information available on the Cache Efficiency detail view:

Column Description

Cache Name

The name of the specified cache

Hit Rate

The percentage of cache hits compared to the total number of cache searches.

Percent Used

The percentage of searches using this cache as a percentage of searches across all caches.

Spinlocks

The number of spinlocks.

LRU Buffers

The number of buffers that were retrieved and replaced in the Least Recently Used section of the pool.

MRU Buffers

The number of buffers that were retrieved and replaced in the Most Recently Used section of the pool.

Large I/Os

The size (bytes) of the I/O buffer for the pool.

Dirty Reads

The number of dirty reads.


Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Data Cache Tab

Metrics

Interpreting cache hit data requires an understanding of how the application uses each cache. In caches that are created to hold specific objects such as indexes or look up tables, cache hit ratios can reach 100%. In caches used for random point queries on huge tables, cache hit ratios can be quite low but still represent effective cache use. This data can also help you determine if adding more memory would improve performance. For example, if "Cache Hits" is high, adding memory probably would not help much.

Correction

You can compare the "percent used" value for each cache to determine if there are caches that are over- or under-utilized. If you decide that a cache is not well utilized, you can: Change the cache bindings to balance utilization. Resize the cache to correspond more appropriately to its utilization.

Cached Objects

The Cached Objects section shows the objects that are currently cached. The table below describes the information available on the Cached Objects detail view:

Column Description

Cache Name

The name of the specified cache.

Database Name

The name of the database where the object resides.

Object Owner

The owner of the object.

Object Name

The name of the object.

Object Type

The type of the object.

Cached (KB)

The amount, in Kilobytes, of the cached object.

Processes Accessing

The number of processes accessing the specified object.


Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Data Cache Tab

Cache I/O Activity

The Cache I/O Activity view shows how many searches were directed to each cache. The table below describes the information available on the Cache I/O Activity view:

Column Description

Cache Name

The name of the specified cache.

Physical Reads

The number of physical reads associated with the specified cache.

Pages Touched

The number of pages touched by the cache.

Pages Read

The number of pages read by the cache.

Buffers to MRU

The number of buffers that were retrieved and replaced in the Most Recently Used section of the pool.

Buffers to LRU

The number of buffers that were retrieved and replaced in the Least Recently Used section of the pool.

I/O Buffer Size

The size (bytes) of the I/O buffer for the pool.

Allocated (KB)

The number of KB that have been allocated for the pool.

Stalls

The number of times a process had to wait for a free procedure cache buffer when installing a stored procedure into cache.


Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Data Cache Tab

Metrics

You can compare the values in this view for each cache to determine if there are caches that are over- or under-utilized.

Correction

If you determine that a cache is not used as well as you would like, you can: Change which objects are bound to each cache to balance use. Resize the cache to correspond more appropriately to its use.

Procedure Cache Tab

The Procedure Cache tab of the Memory Detail View includes the following sections:

The following statistic, available on this tab, duplicates astatistic available on the Key Ratio Analysis Pane of the Home View (Sybase ASE Performance Analyst) page:

Procedure Cache Activity

The Procedure Cache Activity view summarizes the key metrics concerning the Procedure Cache. The table below describes the information available on the Procedure Cache Activity view:

Column Description

Requests

The number of stored procedures requested from the cache.

Loads

The number of stored procedures loaded into cache.

Writes

The number of times a stored procedure was normalized and the tree was written back to sysprocedures. This happens when a stored procedure (or trigger) is created during the interval between polls. A degradation in performance can occur if an application program generates stored procedures.

Stalls

The number of times a process had to wait for a free procedure cache buffer when installing a stored procedure into cache.


Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Procedure Cache Tab

Procedure Cache Detail

The Procedure Cache Detail view summarizes the key metrics concerning the Procedure Cache. The table below describes the information available on the Procedure Cache Detail view:

Column Description

Object Name

The name of the object.

Object Owner

The object’s owner.

Object Type

The type of object.

Database

The name of the database where the object resides.

Compile Date

The last month/day/year object data was compiled.

Memory Used (KB)

The amount of memory used by the object in kilobytes.


Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Procedure Cache Tab

Current Procedure Usage

The Current Procedure Usage view displays the number of procedures currently in use. The table below describes the information available in the Current Procedure Usage view:

Column Description

SPID

The process name.

User Name

The name of the user attached to the process.

Database

The database attached to the process.

Object Owner

The object’s owner.

Object Name

The object’s name.

Object Type

The object’s type.

Memory Used (KB)

The amount of memory the procedure used in kilobytes.

Program Name

The name of the program where the procedure is used.


Location

Sybase ASE Performance Analyst Statistics > Memory View (DBArtisan - Sybase ASE Performance Analyst) > Procedure Cache Tab

Retrieved from "https://docwiki.embarcadero.com/RapidSQL/171/e/index.php?title=Memory_View_(Sybase_ASE_Performance_Analyst)&oldid=11988"