Users (Sybase ASE Performance Analyst)
Go Up to Sybase ASE Performance Analyst Statistics
In addition to a Home page, the Users category of Sybase ASE Performance Analyst includes the following tabbed pages:
Contents
- 1 Home
- 2 Key User Analysis pane
- 3 Active User Processes
- 4 Extended Procedure Requests
- 5 Inactive User Processes
- 6 Parallel Queries
- 7 Procedure Requests
- 8 System Processes
- 9 Bottleneck Analysis Pane
- 10 Average Hash Chain Length
- 11 Average Lock Contention %
- 12 Current Locks
- 13 Deadlock %
- 14 Lock Promotions
- 15 Lock Timeouts
- 16 Total Priority Changes
- 17 Index Scan Analysis Pane
- 18 Ascending
- 19 Descending
- 20 DOL Ascending
- 21 DOL Descending
- 22 Total Index Scans
- 23 Transaction Analysis - Users
- 24 Active Transactions
- 25 Committed Transactions
- 26 Workload Analysis Pane
- 27 Workload Analysis
- 28 Top Sessions tab
- 29 Top I/O Processes
- 30 Top Memory Processes
- 31 Top CPU Processes
- 32 Top Sessions
- 33 Locks tab
- 34 Locks
- 35 Locks by Database
- 36 Locks by Lock Type
- 37 Transactions tab
- 38 System Waits tab
- 39 System Waits
- 40 Wait Percent by Total Waits (By Wait Class)
- 41 Wait Percent by Time Waited (By Wait Class)
- 42 Session Waits tab
- 43 Session Waits
- 44 Wait Percent by Total Waits (By Wait Class)
- 45 Wait Percent by Time Waited (By Wait Class)
- 46 Session Details
- 47 SQL tab
- 48 Current SQL
- 49 Current Procedures
- 50 I/O tab
- 51 Object Access tab
- 52 Locks/Waits
- 53 Waits
Home
The Users performance category view displays the following vital Sybase ASE user statistics:
- Key User Analysis pane
- Bottleneck Analysis Pane
- Index Scan Analysis Pane
- Transaction Analysis - Users
- Workload Analysis Pane
Key User Analysis pane
The following statistics are used on the Performance Analyst for Sybase ASE User page to succinctly communicate the general overall performance levels of user specific metrics:
- Active User Processes
- Extended Procedure Requests
- Inactive User Processes
- Parallel Queries
- Procedure Requests
- System Processes
Active User Processes
The Active User Processes statistic is the total number of active and open threads reported on the Server. Active Sessions displays the number of processes actively performing work.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Key User Analysis pane |
Extended Procedure Requests
The Extended Procedure Requests value represents the number of times extended procedures were executed in the sample interval.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Key User Analysis pane |
Inactive User Processes
The Inactive Sessions statistic represents the total number of threads logged onto the server that are idle at the current time.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Key User Analysis pane |
Metrics |
A large number of inactive users could indicate user sessions that have mistakenly been left logged on. Since each user thread consumes a portion of memory on the server, to reduce resource usage, you should sever any sessions not needing a connection. |
Correction |
Drill down into the Session Waits page and check sessions that have many seconds idle or that have been logged on for very long periods of time, as indicated by the logon time column. After verifying that a session is no longer necessary, you can KILL it. |
Parallel Queries
The Parallel Queries value represents the total number of queries eligible to be run in parallel.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Key User Analysis pane |
Metrics
The optimizer determines the best plan, and decides whether a query should be run serially or in parallel and how many worker processes should be used for parallel queries.
Procedure Requests
The Procedure Requests value represents the number of times stored procedures were executed in the sample interval.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Key User Analysis pane |
System Processes
The System processes value represents the total number of threads logged onto the server that are Sybase ASE internal processes.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Key User Analysis pane |
Bottleneck Analysis Pane
The following statistics are used on the Performance Analyst for Sybase ASE User Home Page to succinctly communicate the general overall performance levels of user specific metrics:
- Average Hash Chain Length
- Average Lock Contention %
- Current Locks
- Deadlock %
- Lock Promotions
- Lock Timeouts
- Total Priority Changes
The following statistics, available on this pane, are duplicates of statistics available on the Bottleneck Analysis Pane of the Home View (Sybase ASE Performance Analyst) page:
Average Hash Chain Length
This value represents the average number of locks per hash bucket during the sample interval.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Bottleneck Analysis Pane |
Correction |
If the average number of locks per hash chain is more than four, consider increasing the size of the hash table. Large inserts with bulk copy are an exception to this guideline. Lock hash chain lengths may be longer during large bulk copies. |
Average Lock Contention %
The Average Lock Contention % represents the average number of times there was lock contention as a percentage of the total number of lock requests.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Bottleneck Analysis Pane |
Correction |
If the lock contention average is high, investigate the locks to see if the application is causing a lock contention or deadlock-related problem. |
Current Locks
There are varieties of operations in Sybase ASE that require the use of locks. The Current Locks statistic represents the number of total locks currently active in Sybase ASE.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Bottleneck Analysis Pane |
Metrics |
You should watch to see if the if the number approaches the Sybase ASE limit for available locks. |
Correction |
If the number of current locks in a Sybase ASE server approaches the Sybase ASE limit for available locks, you can look into increasing the Number of Locks configuration parameter. |
Deadlock %
A deadlock occurs when two processes have a lock on a separate page or object and each wants to acquire a lock on the other process' page or object. Each waits for the other to release the necessary lock. Sybase ASE constantly checks for deadlocks and, when found, chooses the transaction that has accumulated the least amount of CPU time and terminates the transaction. The server then rolls back that transaction and issues a notification of the event. The other process gets to move forward.
The deadlock % rate displays the percentage of times deadlocks occurred vs. the percentage of locks requested and immediately granted.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Bottleneck Analysis Pane |
Metrics |
Immediately investigate a percentage much above zero to prevent the situation from mushrooming. You can easily drill down and discover the exact process(es) holding locks and deadlocks that are blocking out other user activity. |
Correction |
Well-designed applications can minimize deadlocks by always acquiring locks in the same order. You should always do updates to multiple tables in the same order. Once Sybase ASE discovers a deadlock, it takes action and remedies the situation. IDERA Performance Analyst makes it easier to discover how prevalent deadlock activity is on a system; preventing deadlocks from occurring in the first place is more difficult. Those responsible for writing systems can minimize deadlocks by ensuring that applications acquire locks in the same order. Likewise, you should always do updates and other DML that act on multiple tables in the same order. You can also shrink the amount of time that Sybase ASE waits to check for deadlocks by modifying the deadlock checking period configuration parameter. |
Lock Promotions
The Lock Promotions value represents the average number of lock promotion types combined per second and per transaction.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Bottleneck Analysis Pane |
Metrics |
Lock promotions occur when the following escalations take place: "Sh-Page to Sh-Table" - Shared page to shared table. "Ex-Row to Ex-Table" - Exclusive row to exclusive table. "Sh-R to Sh-Table - Shared row to shared table. "Sh-Next-Key to Sh-Table" - Shared next-key to shared table. "Ex-Page to Ex-Table" - Exclusive page to exclusive table. |
Correction |
If lock contention is high and lock promotion is frequent, you should consider changing the lock promotion thresholds for the tables involved. You can configure the lock promotion threshold either server-wide or for individual tables. |
Lock Timeouts
The Lock Timeouts value represents the total number of locks timing out during the sample period.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Bottleneck Analysis Pane |
Metrics |
You can specify the time that a task waits for a lock: At the server level, with the lock wait period configuration parameter For a session or in a stored procedure, with the set lock wait command For a lock table command |
Correction |
Except for lock table, a task that attempts to acquire a lock and fails to acquire it within the time period returns an error message and the transaction is rolled back. Using lock timeouts can be useful for removing tasks that acquire some locks, and then wait for long periods of time blocking other users. However, since transactions are rolled back, and users may simply resubmit their queries, timing out a transaction means that the work needs to be repeated. |
Total Priority Changes
Total Priority Changes represent the total number of priority changes during the sample period.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Bottleneck Analysis Pane |
Metrics |
It is normal to see some priority switching due to system-related activity. Such priority switching occurs, for example, when: A task sleeps while waiting on a lock - Adaptive Server temporarily raises the task's priority. The housekeeper task sleeps - Adaptive Server raises the priority to medium while the housekeeper sleeps, and changes it back to low when it wakes up. A task executes a stored procedure - the task assumes the priority of the stored procedure and resumes its previous priority level after executing the procedure. |
Correction |
If you are using logical process management and there are a high number of priority changes compared to steady state values, it may indicate that an application, or a user task related to that application, is changing priorities frequently. Check priority change data for individual applications. You should verify that applications and logins are behaving expected. If you determine that a high-priority change rate is not due to an application or to related tasks, then it is likely due to system activity. |
Index Scan Analysis Pane
The following statistics are used on the Performance Analyst for Sybase ASE User page to succinctly communicate the general overall performance levels of user specific metrics:
Ascending
The Ascending value represents the number of forward scans on allpages-locked tables.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Index Scan Analysis Pane |
Descending
The Descending statistic represents the number of backward scans on allpages-locked tables.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Index Scan Analysis Pane |
DOL Ascending
The DOL Ascending value represents the number of forward scans on data-only-locked tables.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Index Scan Analysis Pane |
DOL Descending
The DOL Descending value represents the number of backward scans on data-only-locked tables.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Index Scan Analysis Pane |
Total Index Scans
The Total Index Scans statistic represents the total number of index scans (forward and backward).
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Index Scan Analysis Pane |
Transaction Analysis - Users
The following statistics are used on the Performance Analyst for Sybase ASE User page to succinctly communicate the general overall performance levels of user-specific metrics:
Active Transactions
The Active Transaction statistic represents a count of the number on in-process transactions for SQL Server.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Index Scan Analysis Pane |
Committed Transactions
Committed Transactions gives the number of transactions committed since the last refresh inside Performance Analyst. This includes transactions that meet explicit, implicit, and ANSI definitions for committed transactions. Note that multi-database transactions are counted.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Index Scan Analysis Pane |
Metrics |
Multi-database transactions generally incur more overhead than single database transactions (for example, a transaction that modifies two databases is counted as two transactions). They usually involve more log activity and two-phase commits between the different databases, as well as cause more ULC flushes. You can improve performance by reducing the number of multi-database transactions. |
Workload Analysis Pane
The following statistics are used on the Performance Analyst for Sybase ASE User page to succinctly communicate the general overall performance levels of user specific metrics:
Workload Analysis
When your phone starts ringing with complaints of performance slowdowns, some of the first questions you should answer are:
- What users are currently connected to the database?
- What resources are they using?
- What are they currently executing?
The Workload Analysis section of the Performance Analyst page provides insight into the leading resource hogs of a server. The table below describes the information available in the Workload Analysis section of the Users page:
Column | Description |
---|---|
Activity |
Statistics are presented for the Top CPU Process, Top I/O Process, or Top Memory Process. |
SPID |
The process ID. |
Login |
The logon name the session is using. |
% Used |
The percentage of CPU, I/O, or Memory consumed by the process. |
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Home > Workload Analysis Pane |
Metrics |
If any one session appears to be using more than 50% of a total resource (CPU, memory, etc.), then you should drill down into the session to find out what they are currently executing. |
Top Sessions tab
The following statistics are used on the Performance Analyst for Sybase ASE Users Drill-down Top Sessions to succinctly communicate the general overall performance levels of user specific metrics:
Top I/O Processes
The Top I/O Processes statistic identifies the current Sybase ASE process with the highest % of I/O activity.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Top Sessions tab |
Correction |
If any one session uses more than 50% of a total resource (CPU, memory, etc.), you should drill down into that particular session and investigate the cause. |
Top Memory Processes
The Top Memory Process statistic identifies the Sybase ASE process that currently is using the highest percentage of memory in the database.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Top Sessions tab |
Top CPU Processes
The Top CPU Process statistic identifies the Sybase ASE process that currently has the highest percentage of CPU usage in the database.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Top Sessions tab |
Top Sessions
When a system experiences heavy activity, sometimes you will find that all the user connections are contributing somewhat equally to the overall load. More often than not, however, one or two user connections are causing most of the activity. It might be that a large batch load or other typical process is running that is perfectly okay for your system. Or it might be a runaway process or other rogue connection that needs to be tracked down and possibly eliminated.
The table below describes the information available on the Top Sessions detail view:
Column | Description |
---|---|
SPID |
The process ID. |
User |
The name of the session user. |
FID |
The process ID of the worker process' parent. |
Status |
The current status of the session. |
Database |
The database the session is attached to. |
Host |
The client machine name the session is using. |
Program |
This identifies the program being run by the session. |
Mem Usage |
The amount of memory being used by the session. |
CPU Time |
The cumulative CPU time for the process. |
Physical Reads |
The number of physical reads produced by the session. |
Logical Reads |
The number of logical reads produced by the session. |
Physical Writes |
The number of physical writes generated by the session. |
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Top Sessions tab |
Locks tab
The following statistics are used on the Performance Analyst for Sybase ASE User Drill-down Locks tab to succinctly communicate the general overall performance levels of user specific metrics:
Locks
To modify database information or structures, a user session must obtain a lock on the object to perform its task. In addition to user locks, Sybase ASE itself issues lock requests to carry out its internal duties. The Locks section gives information about the locks currently on the system and also indicates if any blocking situations are occurring. You can elect to show only blocking locks in the Lock detail view.
The table below describes the information available on the Locks detail view:
Column | Description |
---|---|
SPID |
The process ID. |
User |
The name of the current user |
Database |
The name of the database where the process is running. |
Lock Type |
The type of lock (database, table, row id, etc.). |
Object Name |
The name of the object involved in the lock. |
Status |
The lock's status (waiting or granted). |
Lock Page |
The number of pages, if any, that are experiencing locks. |
Lock Class |
Lets you see the lock class. |
Host |
The client machine name the session is using. |
Program |
The executable the process is using against the server. |
Command |
The command currently being issued by the process. |
CPU Time |
The amount of time the process took to parse, execute, and fetch the data needed to satisfy the process’ execution. |
I/O |
The amount of I/O activity for the target process. |
Mem Usage |
The amount of memory being used by the target process. |
FID |
The process ID of the worker process' parent. |
Transaction |
The current transactions generated by processes on the Sybase ASE Server |
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Locks tab Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Locks/Waits |
Metrics |
A single blocking user has the potential to stop work for nearly all other processes on a small system, and can cause major headaches even on large systems. Blocks are most often caused by user processes holding exclusive locks and not releasing them via a proper COMMIT frequency. Unless a process times out via an application timeout mechanism, or the process has specified a timeout period, a process waiting for a lock will wait indefinitely. |
Correction |
Once discovered, a blocking lock situation can normally be quickly remedied - the DBA issues a KILL against the offending process, which eliminates the user's stranglehold on the objects the user was accessing. Other user processes then nearly almost always complete in an instant. Discovering the blocked lock situation is made easier by using tools like Performance Analyst, but preventing the blocking lock situation in the first place is where it gets tricky. The DBA can drill down into user detail and view all current blocking locks to see exactly which sessions are holding the currently restrictive locks. The culprit of blocking lock scenarios is usually the application design, or the SQL being used within the application itself. Properly coding an application to reference database objects in an efficient order, and then using the right SQL to get the job done, is an art. The key to avoiding lock contention is to process user transactions in the quickest and most efficient manner possible - something not always easy to do. |
Locks by Database
The Locks by Database view represents the total locks occurring on the Sybase ASE Server stratified by which database they are occurring on.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Locks tab |
Locks by Lock Type
To modify database information or structures, a user session must obtain a lock on the object to perform its task. In addition to user locks, Sybase ASE itself issues lock requests to carry out its internal duties. The Locks by Lock Type section provides a breakdown of the different locks types being issued across all databases.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Locks tab |
Transactions tab
The Transactions view displays current transactions generated by processes on the Sybase ASE Server.
The table below describes the information available on the Transactions detail view:
Column | Description |
---|---|
SPID |
The process ID. |
User |
The name of the user generating the session. |
Status |
The current status of the session. |
Start Time |
The time the session started. |
Type |
The type of session. |
State |
The current state of the session, for example, whether or not it is active. |
Command |
The command currently being issued by the session. |
Connection |
The amount of memory allocated to the session’s connections |
CPU Time |
The amount of time the process took to parse, execute, and fetch the data needed to satisfy the process’ execution. |
Mem Usage |
The amount of memory being used by the session. |
Physical I/O |
The amount of physical I/O for the session. |
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Transactions tab |
Metrics |
Transaction activity is a good measurement of general performance by a user. If the total or committed numbers do not increase over a period of time, either the process is inactive or it may be hung or blocked. |
Correction |
Look at CPU and I/O statistics to see if any activity for the process is being noted there. |
System Waits tab
The following statistics are used on the Performance Analyst for Sybase ASE User Drill-down System Waits tab to succinctly communicate the general overall performance levels of user specific metrics:
- System Waits
- Wait Percent by Total Waits (By Wait Class)
- Wait Percent by Time Waited (By Wait Class)
System Waits
When the Sybase ASE Server is up and running, every connected process is either busy doing work or waiting to perform work. A process that is waiting may mean nothing in the overall scheme of things or it can be an indicator that a database bottleneck exists. The System Waits section identifies the waits that have occurred on the Sybase ASE Server.
The table below describes the information available on the System Waits detail view. You can elect to display the internal system and scheduler events.
Column | Description |
---|---|
Wait Event |
The name of the wait event. |
Wait Class |
The type of wait, often called a wait category or class. |
Wait Count |
The number of waits that have occurred. |
Percent Waits |
The percent of waits as compared to the total number of waits. |
Wait Time |
The amount of time waited in seconds. |
Percent Wait Time |
The percent of wait time as compared to the total wait time. |
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > System Waits tab |
Wait Percent by Total Waits (By Wait Class)
When the Sybase ASE Server is up and running, every connected process is either busy doing work or waiting to perform 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. The Wait Percent by Total Waits section graphically depicts the top waits by their percentage to all waits.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > System Waits tab |
Wait Percent by Time Waited (By Wait Class)
When the Sybase ASE Server is up and running, every connected process is either busy doing work or waiting to perform 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. The Wait Percent by Time Waited section graphically depicts the top waits by their percentage of time waited to total time waited.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > System Waits tab |
Session Waits tab
The following statistics are used on the Performance Analyst for Sybase ASE User Drill-down Locks tab to succinctly communicate the general overall performance levels of user specific metrics:
- Session Waits
- Wait Percent by Total Waits (By Wait Class)
- Wait Percent by Time Waited (By Wait Class)
Session Waits
Session waits is merely a subset of contention that is viewable at the global database level. Often it takes analysis at the session level to pinpoint the exact source of the wait that is occurring globally. Therefore, you need to become accustomed to viewing contention statistics and waits at the user process level.
When monitoring waits with respect to user sessions, there are two areas of interest:
- What HAS the user session been waiting on?
- What IS the user session waiting on?
The table below describes the information available on the Session Waits detail view. You can elect to include background process in the detail display.
Column | Description |
---|---|
SPID |
The unique identifier for the process. |
User |
The name of the process’ user. |
FID |
The process ID of the worker process' parent. |
Status |
The current status of the process. |
Database |
The name of the database where the process is running. |
Hostname |
The client machine name where the session is running. |
Program Name |
The name of the program being run by the process. |
Wait Event |
The name of the wait event. |
Wait Class |
The type of wait, often called a wait category or class. |
Waits |
The number of waits that have occurred. |
Process Waits |
The percent of waits as compared to the total number of waits. |
Wait Time (s) |
The number of seconds the process spent waiting for this wait. |
Percent Waits |
The percent of wait time as compared to the total wait time. |
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Session Waits tab |
Metrics |
To determine the actual wait causes currently experienced by user connections, you should drill down from the global count of users waiting, into the actual system and user wait details. |
Correction |
If you find a problem, drill down into wait details to determine whether the waits are resource-related. |
Wait Percent by Total Waits (By Wait Class)
The Wait Percent by Total Waits section graphically depicts the waits that have experienced the highest percentage of occurrences on the system.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Session Waits tab |
Wait Percent by Time Waited (By Wait Class)
When the Sybase ASE Server is up and running, every connected process is either busy doing work or waiting to perform 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. The Session Wait Percent by Time Waited section graphically depicts the top session waits by their percentage of time waited to total time waited.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Session Waits tab |
Session Details
The Sessions Detail view includes the following tabbed pages:
SQL tab
The SQL tab of the Sessions Detail view offers the following information:
Current SQL
This view shows a snippet of the SQL associated with the user in question.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Session Waits tab |
Current Procedures
Here, in tabular format, you find the following information about the user’s current procedures:
- Owner
- Object Name
- Object Type
- Database: The name of the database on which the procedure resides.
- Compile Date: The last date on which the object was compiled.
- Memory (KB): The number of pages in the procedure cache that is currently allocated to the process. A negative number indicates that pages are being released (freed) from the process.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Session Waits tab |
I/O tab
The I/O tab of the Session Detail view displays the following statistical information about the current user’s activities in a graphical display:
- Physical Reads
- Logical Reads
- Pages Read
- Pages Written
- Physical Writes
- Table Accesses (scans): The number of table accesses (scans) by the user.
- Index Accesses: The number of index accesses by the user.
- Tempdb Objects: The number of times the Tempdb was accessed by the user.
Object Access tab
The Object Access tab of the Session Detail view displays information about the current objects being accessed. Here you’ll see, in tabular format:
- Database: The name of the database
- Owner ID: The ID number assigned to the process accessing the object.
- Object Name
- Object Type: The type of object being accessed.
- Index ID
- Physical Reads: The number of physical disk reads issued against the object.
- Physical APF Reads: Number of physical Asynchronous Pre-Fetch buffers read.
- Logical Reads: The number logical reads issued against the object.
Locks/Waits
The Lock/Waits tab of the Session Details page offers statistics on:
The following statistic, available on this tab, duplicates a statistic on the Locks tab of the Users (DBArtisan - Sybase ASE Performance Analyst) page:
Waits
When the Sybase ASE Server is up and running, every connected process is either busy doing work or waiting to perform work. A process that is waiting may mean nothing in the overall scheme of things or it can be an indicator that a database bottleneck exists. The Waits section shows processes that are currently waiting on the Sybase ASE Server.
Here you find, in tabular format, details for:
- Login: The logon name used by the session.
- Database: The name of the database the process is attached to.
- Wait Event: The name of the wait event.
- Wait Class: The type of wait, often called a wait category or class.
- Waits: The number of waits that have occurred.
- Wait Time (sec): The amount of time waited in seconds.
Location |
Sybase ASE Performance Analyst Statistics > Users (DBArtisan - Sybase ASE Performance Analyst) > Session Waits tab |