Вы находитесь на странице: 1из 60

Sybase ASE

Performance & Tuning

Sarosh Siddiqui
 What is Performance & Tuning
 Tuning Tool Box
◦ Tools and Utilities
◦ Set Commands
◦ System Procedures
◦ Monitoring Tables
◦ sp_sysmon
 Performance is characterized by amount of work
accomplished by a system compared to the time
and resources used.
 Performance may involve one or more of the
◦ Throughput : Number of transactions the db can do
in a given time period
◦ Response Time : Time it takes to get a response for
an inquiry
◦ Scalability : The ability to support large number of
users and large data without impacting
 Tuning is the process of tacking the appropriate
actions within the limit of available resources.
 Tuning is tradeoffs between
◦ Consistency or Concurrency (Locking)

◦ Select and Update (Workload)

◦ Space and Time (Indexing)

Consistency or Concurrency:

Adaptive Server is designed for a high number of

simultaneous users. It makes use of various locking
mechanisms to prevent users from interfering with each other
as they compete for the same recourse.
Selects or Updates:

The tradeoff between selects (read-only) and updates ( read

and/or write) becomes important when you are determining
the proper database structures for an application.

Index may speed up selects but slow down updates.

Space or Time:

The tradeoff between space and time is a classic computer

system issue.

Normalized data takes less space, but may require

complicated joins and thereby slow access time .




General Principles of
Performance & Tuning
Performance and tuning is done for a specific server, or a group
of identical servers with identical workloads, in a specific

There are no „magic number for performance and tuning

configuration parameters. Just consider all the factors that can
have an impact on performance.

Continue ….
General Principles of
Performance & Tuning
The Performance impacts on:
• Server Computer Hardware and Operating System

• Client Computer Hardware and Operating System

• The Size, structure, number, and characteristics of

• Front-end Application

• Query

• Network Architecture

So, you much determine which tuning parameter value

optimize performance for one server or group of identical
servers in your specific environment.
Performance & Tuning is an art,
not a science
There are many environmental factors that can have an impact
on performance. Thee are many tuning strategy to chose from,
and number of parameters that can be set.

In the face of this complexity, all you can do is to use your

knowledge and experience to make right judgment, about
which configurations might work, try each, then measure
performance and compare the results.
Tuning Tool Box

• Utilities:
Tools that exist as separate executables / binaries in
Adaptive Server.

• Set Commands:
Tools run at the session level that are preceded by
keyword set
Tuning Tool Box
• System Procedures:
Tools in the collection of store procedure that are
provided with the server and primarily resides in
sybsystemprocs system database

• Monitoring Tables:
A Set of system tables containing monitoring and
diagnostic information.

s p _ s y s m o n : a system procedure that produces

Adaptive Server performance data. It includes
suggestions for interpreting its output and deducing
possible implications.
• isql -p:
Interactive sql provides a performance statistics with
option (-p).

• optdiag:
Displays optimizer statistics or loads updated
statistics into system tables.

• Query Process Metrics: Query Processing (QP)

matrix identify and compare empirical matrix values in
query execution.
• Precise i3 indepth for Sybase:
Precise Indepth for Sybase, subsequently referred to as
Indepth for Sybase, provides you with the application
performance management you need, by supplying you
with the tools necessary for proactive monitoring,
diagnosing, detecting, and correcting of performance
problems, before they become visible in your Sybase
databases and related applications.
Isql -p
Interactive sql with –p option capture single / batch
execution time statistics.
From prompt
$isql –Uuser_id –Ppassword –p
1> select name from sysdatabases where name = 'pubs2'
2> go 10
Execution Time (ms.): 0 Clock Time (ms.): 0
Execution Time (ms.): 0 Clock Time (ms.): 0
Execution Time (ms.): 0 Clock Time (ms.): 0
Execution Time (ms.): 0 Clock Time (ms.): 0
Execution Time (ms.): 0 Clock Time (ms.): 0
Execution Time (ms.): 0 Clock Time (ms.): 16
Execution Time (ms.): 0 Clock Time (ms.): 16
Execution Time (ms.): 0 Clock Time (ms.): 16
Execution Time (ms.): 0 Clock Time (ms.): 16

(1 row affected)
Execution Time (ms.): 0 Clock Time (ms.): 16
10 xacts:
• The optdiag utility display statistics form
systabstatics and sysstatistics system tables.

• optdiag can also be used to update ststistics


• Only a system administrator can run optdiag utility

Continue .....
optdiag Syntax:
optdiag [binary] [simulate] statistics {-i input_file |
database[.owner[.[table[.column]]]] [-o output_file]} [-U
username] [-P password] [-I interfaces_file] [-S server]
[-v] [-h] [-s] [-Tflag_value] [-z language] [-J
client_charset] [-a display_charset]

Optdiag display the statistics for an entire database, for a

single table and its indexes and columns, or for a
particular column. To display statistics for all user tables
in the pubtune database, placing the output in the
pubtune.opt file, use the following command:

optdiag statistics pubtune -Usa -Ppasswd -o pubtune.opt

Query Process Metrics
•Query processing (QP) metrics identify and compare
empirical metric values in query execution.

• When a query is executed, it is associated with a set of

defined metrics that are the basis for comparison in QP

The metrics captured include:

•CPU execution time – the time, in milliseconds, it takes

to execute the query.

•Elapsed time – the difference in milliseconds between the

time the command started and the current time, as taken
from the operating system clock.
Continued ….
Query Process Metrics
The metrics captured include:

•Logical IO (LIO) reads – the number od Logical IO reads.

•Physical IO (PIO) reads – the number of Physical IO reads.

•Count – the number of times a query is executed.

•Abort count – the number of times a query is aborted by

the resource governor due to a resource limit being

Each metric has three values: minimum, maximum, and

average. Count and abort count are not included.
Query Process Metrics
You can activate and use QP metrics at the server level or
at the session level.

To activate at server level, use:

sp_configure “enable metrics capture”, 1

To activate at session level, use:

set metrics_capture on/off

Access metric information using a select statemant with

order by against the sysquerymetrics view
Monitor Server
Adaptive Server Enterprise Monitor™ (Adaptive Server
Monitor) provides a way to monitor Adaptive Server
performance in real time or in a historical data-gathering

System administrators can use this information to identify

potential resource bottlenecks, to research current
problems, and to tune for better performance.

Adaptive Server Monitor provides feedback for tuning at

several levels:
•Adaptive Server configuration
•Database design
•SQL statements in applications and stored procedures
Monitor Server - Components
Four components that gather or display Adaptive Server
Performance data:

•Adaptive Server Enterprise Monitor Server (Monitor


•Adaptive Server Enterprise Historical Server (Historical


•Monitor in Adaptive Server Enterprise plug-in for Sybase

Central (Monitor View)

•Adaptive Server Enterprise Monitor Client Library

(Monitor Client Library)
Embarcadero® DBArtisan®, the leading cross-platform
database administration tool, helps DBAs maximize
availability, performance, and security. DBArtisan boosts
productivity so DBAs can manage larger, more complex

DBArtisan is a popular DBA tool. You may find some DBA

job posting even has requirement on familiarity on this

The tool itself is very simple and not much different from
the native tool from database vendors, the main strength
is it provide same interface across all platform (Oracle,
Sybase, DB2 and SQL Server).
Precise i3 Indepth for Sybase
Performance management for Sybase environnements :

Precise i3 Indepth for Sybase provides DBAs with current

and historical information that can identify database
performance bottlenecks.
Precise i3 Indepth for Sybase

Indepth displays resource consumption by statements,

logins, programs, and more.
set Commands
• statistics io:
Get a count of read and write activity, both logical and
physical for a given statement.

• statistics time:
Get count of CPU time use and elapsed time for a
given statement.
set Commands
• showplan:
Show the plan chosen by the optimizer for handling a
particular statement, including access method, index use,
execution steps, I/O size, number of parallel worker
processors, join order, worktables used and so on.

• showplan and noexec:

Without executing the statement, show the plan the
optimizer would chose.
statistics io
set statistics io { on | off }

1> set statistics io on
2> go
Total writes for this command: 0
1> use pubs2
2> go
Total writes for this command: 0
1> select * from authors
2> go
Table: authors scan count 1, logical reads: (regular=1 apf=0
total=1), physical reads: (regular=1 apf=0 total=1), apf IOs
Total writes for this command: 0
(23 rows affected)
statistics io

Scan Count: The number of times the tables accessed

Logical reads: Logical reads are the total number of

physical read (including physical and cache read) reported
in 2k pages.

Physical reads: Physical I/O is the total number of physical

reads. If the I/O size is larger than 2k, each larger I/O
count as a single physical read.

Total writes from this command: The number of pages

written to disk.
statistics time
set statistics time { on | off }

1> use pubs2
2> go
1> set statistics time on
2> go

Execution Time 0.
SQL Server cpu time: 0 ms. SQL Server elapsed time: 0 ms.
1> select * from authors
2> go
Parse and Compile Time 0.
SQL Server cpu time: 0 ms.
Execution Time 0.
SQL Server cpu time: 0 ms. SQL Server elapsed time: 0 ms.

(23 rows affected)

statistics time

Parse and Compile time: The number of CPU ticks taken

to parse, optimize, and compile the statement.

Execution time: The number of CPU ticks taken to

execute the statement.

CPU time: Total number of CPU milliseconds taken to

execute the query.

Elapsed time: The difference between the time the

command started and the current time, as taken from
the operating system clock.
showplan and noexec
set showplan [,noexec] { on | off }
1> set showplan, noexec on
2> go
1> select name from sysdatabases where name = 'pubs2'
2> go
1 operator(s) under root

The type of query is SELECT.

ROOT:EMIT Operator
|SCAN Operator
| sysdatabases
| Using Clustered Index.
| Index : cdatabases
| Forward Scan.
| Positioning by key.
| Index contains all needed columns. Base table will not be read.
| Keys are:
| name ASC
| Using I/O Size 2 Kbytes for index leaf pages.
| With LRU Buffer Replacement Strategy for index leaf pages.
showplan and noexec

QUERY PLAN: Marks the beginning of each query plan.

STEP: Sequential number of each step and each

statement .

The type of query: Report the type of query select, insert,

update query.

Nested iteration: Indicates the execution of data retiieval


Table scan: Report when the query perform a table scan

showplan and noexec

Ascending scan: Indicates the direction of the scan

(Ascending or Descending )

Positioning at start of table: Indicates where the scan


Using I/O Size: The I/O size being used: (2, 4, 8, 16k).

With LRU Buffer Replacement Strategy: The buffer

replacement strategy being used.
System Procedures
System procedures are:

•Shortcuts for retrieving information from the system tables

•Mechanisms for performing database administration and other

tasks that involve:

•Process Activity: what is active on the system, what lock

have been taken, what work is being performed?

•Configuration: How do you view and control characteristics

of the server that can be manipulated ( for example total
memory used)

•Task Activity: What is happening in the system in response

to the actions of users on the system.
System Procedures
Process Activity
sp_who Display a list of currently active processes to
include a reference to inter-process
Syntax: blocking and related delays
sp_who [ login name | spid”]
sp_lock Display a list of table, page, and rows lock
active on the system that limit access for
Syntax: users.
sp_lock [spid1, spid2 ..]
sp_showplan Display the optimizers query plan for a
currently running processes.
sp_showplan spid, null, null, null

sp_object_stats Show lock contention, lock wait time, and

deadlock statistics for tables and indexes.
sp_object_stats interval [, top_n [,
dbname, objname [, rpt_option ]]]
System Procedures
sp_configure Displays configuration parameters by group,
their current values, their default values, the
Syntax: value to which they have most recently been
sp_configure [configname [, set, and the amount of memory used by this
configvalue] | group_name |
setting. Displays only the parameters whose
sp_configure "configuration display level is the same as or below that of
file", 0, {"write" | "read" | the user.
"verify" | "restore"}
sp_cacheconfig Creates, configures, reconfigures, and drops
data caches, and provides information about
Syntax: them
sp_cacheconfig [cachename [
,"cache_size[P|K|M|G]" ]
[,logonly | mixed ] [,strict |
relaxed ] ] [,
System Procedures
sp_poolconfig Creates, drops, resizes, and provides
information about memory pools within data
Syntax: caches.
To create a memory pool in an
existing cache, or to change pool
sp_poolconfig cache_name [,
"mem_size [P|K|M|G]", "config_poolK"
[, "affected_poolK"]] To change a
pool’s wash size:
sp_poolconfig cache_name, "io_size
", "wash=size[P|K|M|G]" To change a
pool’s asynchronous prefetch
sp_poolconfig cache_name, "io_size
"local async prefetch limit=percent

sp_monitorconfig Displays cache usage statistics regarding

metadata descriptors for indexes, objects,
Syntax: and databases.
sp_monitorconfig "configname" [ ,
“result_tbl_name”] [, “full”]
System Procedures
sp_sysmon Displays performance information.

sp_sysmon begin_sample

sp_sysmon interval [,
noclear,[,section [, applmon]]]

sp_sysmon { end_sample | interval }

[, section [, applmon] ] sp_sysmon {
end_sample | interval } [, applmon ]

sp_monitor Displays statistics about Adaptive Server.

sp_monitor [ connection, [cpu |
diskio | elapsed time ] ] [event,
[spid ] ] [procedure, [ dbname, [
procname, [, summary | detail ] ] ]
] [ enable ] [ disable ] [
statement, [ cpu | diskio | elapsed
time ] ] [ help], [ connection |
statement | procedure | event ] ]
Monitoring Tables
• MDA tables
• How it work
• Overview
• Installation and Configuration
• Examples & applications
Monitoring Tables
Starting in ASE, a new feature called 'MDA tables„
is available to ASE users. These MDA tables provide
access to low-level monitoring information in ASE; since
the MDA tables can be accessed with regular SQL select
statements, they're much easier to use than products like
Monitor Server/Historical Server.

MDA = 'Monitoring Data Access”

(or “Monitoring and Diagnostics for ASE”
or “Monitoring and Diagnostic Access
or “Monitoring and Diagnostic API ”)
Monitoring Tables
Only users with the mon_role role can access Adaptiver
Server‟s monitoring tables.

By deafult, Adaptive Server does not collect the

monitoring information required by the monitoring tables.

You must use sp_configure to configure Adaptive

Server to start collecting the monitoring information.

proxy tables mapped to native RPCs

Monitoring Tables
• Only users with the mon_role role can access Adaptiver
Server‟s monitoring tables.

• By deafult, Adaptive Server does not collect the

monitoring information required by the monitoring tables.

• You must use sp_configure to configure Adaptive

Server to start collecting the monitoring information.

• 35 proxy tables in the master database

• All named 'mon%' (i.e. 'monObjectActivity')

• Can be queried with regular SQL

Monitoring Tables

MDA licensing:

• no license needed

• included in ASE base product

Monitoring Tables
Out-of-the-box: no MDA tables present.

Installation steps:
Add a 'loopback' server alias name
sp_addserver loopback, null, @@servername
(assuming @@servername is also in the interfaces file)
Test this configuration: exec loopback…sp_who
(note: 3 dots!)

Run $SYBASE/ASE-12_5/scripts/installmontables
(when successful, prints no output whatsoever!)

Assign mon_role to logins allowed MDA access (incl. sa)

grant role mon_role to sa
Test this configuration: select * from
Monitoring Tables System Configuration

There are 18 sp_configure parameters that control the

behavior of Monitoring Tables.

Grant mon_role to a uset for accessing the Monitoring


These parameters may be displayed by referencing the

“Monitoring Group”

sp_configure Monitoring

Component Integration Services must be enabled to use

Monitoring tables.

sp_configure “enable cis”, 1

sp_sysmon Store Procedure System Monitor

sp_sysmon, a system procedure that produces Adaptive

Server performance data. It includes suggestions for
interpreting its output and deducing possible
When you invoke sp_sysmon, it clears all accumulated data
from a set of counters that will be used during the sample
interval to accumulate the results of user and system activity.
At the end of the sample interval, the procedure reads the
values in the counters, prints the report, and stops

sp_sysmon contributes 5 to 7% overhead while it runs on a

single CPU server, and more on multiprocessor servers. The
amount of overhead increases with the number of CPUs.
sp_sysmon When to run

You can run sp_sysmon both before and after tuning

Adaptive Server configuration parameters to gather data for
comparison. This data gives you a basis for performance
tuning and lets you observe the results of configuration

Use sp_sysmon when the system exhibits the behavior you

want to investigate. For example, if you want to find out how
the system behaves under typically loaded conditions, run
sp_sysmon when conditions are normal and typically loaded.

In many tests, it is best to start the applications, and then

start sp_sysmon when the caches have had a chance to reach
a steady state. If you are trying to measure capacity, be sure
that the amount of work you give the server keeps it busy for
the duration of the test.
sp_sysmon When to run

In general, sp_sysmon produces valuable information

when you use it:

•Before and after cache or pool configuration changes
•Before and after certain sp_configure changes
•Before and after the addition of new queries to your application mix
•Before and after an increase or decrease in the number of Adaptive
Server engines
•When adding new disk devices and assigning objects to them
•During peak periods, to look for contention or bottlenecks
•During stress tests to evaluate an Adaptive Server configuration for a
maximum expected application load
•When performance seems slow or behaves abnormally
sp_sysmon Invoking

There are two ways to use sp_sysmon:

1. Using a fixed time interval to provide a sample for a
specified number of minutes

2. Using the begin_sample and end_sample parameters to

start and stop sampling

You can also tailor the output to provide the information you

• You can print the entire report.

• You can print just one section of the report,

such as “Cache Management” or “Lock Management.”

sp_sysmon Fixed time intervals

To invoke sp_sysmon, execute the following

command using isql:
sp_sysmon interval [, section [, applmon]]

interval must be in the form “hh:mm:ss”. To run sp_sysmon for

10 minutes, use this command:
sp_sysmon "00:10:00"

The following command prints only the “Data Cache

Management” section of the report:
sp_sysmon "00:10:00", dcache
sp_sysmon Using begin_sample and end_sample

With the begin_sample and end_sample parameters, you can

invoke sp_sysmon to start sampling, issue queries, and
end the sample and print the results at any point in

For example:
sp_sysmon begin_sample
execute proc1
execute proc2
select sum(total_sales) from titles
sp_sysmon end_sample

Note : On systems with many CPUs and high activity, counters can
overflow if the sample period is too long.
If you see negative results in your sp_sysmon output, reduce your
sample time.
sp_sysmon Specifying report sections for output

Partial Syntax:
sp_sysmon {interval [, section]}

List of few Report Section and Parameter

Report Section Parameter
Application Management appmgmt
Cache Wizard cache wizard
Data Cache Management dcache
Disk I/O Management diskio
Houskeeper Task Activity housekeeper
Index Management indexmgmt
Kernel Utilization kernel
Lock Management locks
Memory Management memory
sp_sysmon Specifying report sections for output

It is easier to handle the output when looking a part

of the report

1> exec sp_sysmon “00:10:00”, dcache
2> go
sp_sysmon Specifying report sections with applmon

Partial Syntax:
sp_sysmon {interval [, section] [,applmon]}
Application Detail Parameter

Parameter Information Reported

appl_only CPU, I/O, priority changes, and resource
limit violations by application name.
appl_and_login CPU, I/O, priority changes, and resource
limit violations by application name and
login name. Can be used with all sections.
no_appl Skips the application and login section of
the report. This is the default.
Example: runs sp_sysmon for 5 minutes and prints the
“Application Management” section, including the application and
login detail report
sp_sysmon "00:05:00", appmgmt, appl_and_login