Beruflich Dokumente
Kultur Dokumente
Page 1
Tips and Tricks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Troubleshooting Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
SQL Server Tips and Tricks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Checking for Available Free Space on SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . 4
SQL Server Lock Wait Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
CXPACKET Wait in SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
PAGEIOLATCH_EX Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
RESOURCE_SEMAPHORE Waits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
sp_who and sp_who2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
SQL Server Execution Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
WMI Permissions and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Collector Fails to Connect to SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Oracle Tips and Tricks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
'db file sequential' Read Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
'read by other session' Wait Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Direct Path Reads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Enqueues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
pga_aggregate_target Parameter for Performance Tuning . . . . . . . . . . . . . . . . . . . . 18
MySQL Tips and Tricks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Check Database and Table Space in MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Connect to MySQL Using SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Copying to tmp Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Monitor MySQL Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Monitor the MySQL Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
MySQL Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
MySQL Explain Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
MySQL Optimize Table Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
MySQL query_cache_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
MySQL Query Cache Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Repair with keycache Performance Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Page 2
Tips and Tricks
Troubleshooting Tips
IBM DB2 Tips and Tricks
DB2 UDB/WebSphere Performance Tuning Guide
mongoDB Tips and Tricks
mongoDB Performance Tuning
Oracle RAC Tips and Tricks
Monitoring and Diagnosing Oracle RAC Performance with Oracle Enterprise Manager
PostgreSQL Tips and Tricks
Performance Optimization
Sybase Tips and Tricks
Performance and Tuning: Basics, Locking, Monitoring and Analyzing, Optimizer and
Abstract Plans
Troubleshooting Tips
SQL Server Tips and Tricks
Checking for Available Free Space on SQL Server
SQL Server Lock Wait Types
CXPACKET Wait in SQL Server
PAGEIOLATCH_EX Waits
RESOURCE_SEMAPHORE Waits
sp_who and sp_who2
SQL Server Execution Plan
WMI Permissions and Security
Collector Fails to Connect to SQL Server
Oracle Tips and Tricks
'db file sequential' Read Event
'read by other session' Wait Event
Direct Path Reads
Enqueues
pga_aggregate_target Parameter for Performance Tuning
MySQL Tips and Tricks
Check Database and Table Space in MySQL
Connect to MySQL Using SSH
Copying to tmp Table
Monitor MySQL Connections
Monitor the MySQL Log File
MySQL Connections
MySQL Explain Plan
MySQL Optimize Table Command
MySQL query_cache_size
MySQL Query Cache Performance
Repair with keycache Performance Issues
LCK_M_S Share
LCK_M_U Update
LCK_M_X Exclusive
LCK_M_IS Intent-Share
LCK_M_IU Intent-Update
LCK_M_IX Intent-Exclusive
LCK_M_SIX Share-Intent-Exclusive
LCK_M_UIX Update-Intent-Exclusive
LCK_M_RS_S Range-share-share
LCK_M_RS_U Range-share-Update
LCK_M_RI_NL Range-Insert-NULL
LCK_M_RI_S Range-Insert-Shared
LCK_M_RI_U Range-Insert-Update
LCK_M_RI_X Range-Insert-Exclusive
LCK_M_RX_S Range-exclusive-Shared
LCK_M_RX_U Range-exclusive-update
LCK_M_RX_X Range-exclusive-exclusive
PAGEIOLATCH_EX Waits
PAGEIOLATCH_EX is a wait event often seen in SQL Server related to I/O, It actually
corresponds to an "Exclusive I/O page latch".
This wait event occurs when a user needs a page that is not in the buffer cache, SQL Server has
to first allocate a buffer page, and then puts an exclusive PAGEIOLATCH_EX latch on the buffer
while the page is transferred from disk to cache. After the write to cache finishes, the
PAGEIOLATCH_EX latch is released.
Waits of this type are to be expected whenever SQL Server carries out I/O operations, but if you
see excessive waits of this type then it may indicate problems with the disk subsystem.
The following AppDynamics for Databases screenshot displaying an instance with
PAGEIOLATCH_EX waits:
RESOURCE_SEMAPHORE Waits
RESOURCE_SEMAPHORE waits occurs when a query memory request cannot be granted
immediately due to other concurrent queries. High waits and wait times may indicate excessive
number of concurrent queries, or excessive memory request amounts.
High waits on RESOURCE_SEMAPHORE usually result in poor response times for all database
users, and need to be addressed.
The AppDynamics for Databases Waits Report displays a time-series profile of wait events for
your monitored instance. The example below is taken from a SQL Server 2000 instance which
suffered from sporadic problems which resulted in a spike in RESOURCE_SEMAPHORE waits.
If you want to analyze why your queries or stored procedures are performing poorly, the first place
to look is the execution plan. You can visualize the plan in SQL Server query analyzer, or other
products, and of course in AppDynamics for Databases.
In Query Analyzer you can see the Estimated Execution Plan or the Actual Execution Plan. If you
want to see an estimation of how SQL Server will execute your query select the "Display
Estimated Execution Plan" button on the toolbar; this shows you the plan without actually
executing the query (which should be very similar if not identical to the real plan anyway).
For long running queries, or those involving DML i.e. inserts/updates/deletes etc. this is the best
option. The downside to the Estimate Plan is if you have a stored procedure, or other batch T-SQL
code that uses temp tables, you cannot use the "Display Estimated Execution Plan". The reason
for this is that the Optimizer, which is what is used to generate the estimated plan, doesn't execute
the T-SQL, so since the query has not been executed the temporary table does not exist. An error
message of this type will be displayed if you do try to display an estimated plan for a query
containing temp tables:
If you have a poorly performing piece of T-SQL that you are trying to tune, the obvious place to
start it to look at the most costly step of the plan. The screenshot displays the plan for a stored
procedure in the MSPetShop database. You can see the step of the plan with the greatest cost,
and therefore the step which you can optimize.
Tuning T-SQL is of course a vast topic, but a couple of things to look out for include:
Index or table scans: May indicate a need for better or additional indexes.
Bookmark Lookups: Consider changing the current clustered index, using a covering index
and limiting the number of columns in the SELECT statement.
Filter: Remove any functions in the WHERE clause, don't include views in your
Transact-SQL code, may need additional indexes.
Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can
sorting be done at the client more efficiently?
When monitoring CPU information on a Windows based machine with AppDynamics for
Databases, either the OS collector part of the database collector, or the Server collector, Windows
WMI makes use of RPC. RPC listens on a well-known port (135) but then allocates a dynamic port
for subsequent communication. Therefore, you need to configure your firewall to allow 135
(always) and follow the dynamic RPC ports. It can be done - you do not need to restrict the port
range, and there are several articles already on the internet that explain this, just ask Google!
To delegate permissions for WMI Control, run wmimgmt.msc. If you don't have a shortcut to the
program, then simple click the Start Menu, and then search for the executable.
Now step through the following instructions to confirm you will have the correct permissions:
1. Right click the WMI Control icon on the left and click Properties.
2. Click the Security tab.
3. Click the Root node of the tree, and click Properties.
4. For the named user account you would like to run AppDynamics for Databases as you will
need to ensure that it has the relevant permissions. The minimum permissions that your
remote Windows account needs for AppDynamics for Databases are:
Execute Methods
Enable Account
Remote Enable
If you miss any one of the three then you end up with one of:
or
You can also setup extra security in the WIndows Distributed Component Object Model (DCOM) to
prevent unauthorized users from accessing WMI remotely. The following prevents users other than
those configured as follows from remotely accessing the WMI. You can configure the named user
account under which you would like to run AppDynamics for Databases as follows:
1. Add the user to the Performance Monitor Users group
2. In Services and Applications, bring up the properties dialog of WMI Control. On the Security
tab, highlight Root/CIMV2, click Security->add Performance Monitor Users and enable
the options: Enable Account and Remote Enable.
3. Run dcomcnfg. Click Component Services->Computers->My
Computer->Properties->COM Security, and then click Edit Limits for both Access
Permissions and Launch and Activation Permissions. Add Performance Monitor Users and
Definition
When information is requested from the database, Oracle will first read the data from disk into the
database buffer cache. If two or more sessions request the same information, the first session will
read the data into the buffer cache while other sessions wait. In previous versions this wait was
classified under the "buffer busy waits" event. However, in Oracle 10.1 and higher this wait time is
now broken out into the "read by other session" wait event. Excessive waits for this event are
typically due to several processes repeatedly reading the same blocks, e.g. many sessions
scanning the same index or performing full table scans on the same table. Tuning this issue is a
matter of finding and eliminating this contention.
Enqueues
Enqueues are locks that coordinate access to database resources. This event indicates that the
session is waiting for a lock that is held by another session.
The name of the enqueue is included as part of the wait event name, in the form enq:
enqueue_type - related_details. In some cases, the same enqueue type can be held for different
purposes, such as the following related TX types:
enq: TX - allocate ITL entry
Waits for TX in mode 4 can occur if the session is waiting for an ITL (interested transaction list)
To dynamically re-size pga_aggregate_target run the following command (this example changes
the value to 100 megabytes):
The bottom line is that you need to monitor in order to understand exactly what's going on in your
Oracle instance, and tune accordingly!
AppDynamics for Databases is a MySQL monitoring tool which gives a database administrator
(DBA) the ability to monitor what is happening, in real time and historically, within the MySQL
server. It was one of the first deep-dive database monitoring solutions available for MySQL,
pre-dating MySQL's own Query Analyzer.
AppDynamics for Databases is an essential tool for any IT organization using MySQL; it allows the
DBA to work re-actively to resolve current/past MySQL performance issues, and potentially more
importantly to work pro-actively by giving visibility into the user activity of the database which
allows the team to prioritize and focus on the needs of the business.
SELECT s.schema_name,
CONCAT(IFNULL(ROUND((SUM(t.data_length)+SUM(t.index_length))/1024/1024,2),0.00),
"Mb") total_size,
CONCAT(IFNULL(ROUND(((SUM(t.data_length)+SUM(t.index_length))-SUM(t.data_free))/
1024/1024,2),0.00),"Mb") data_used,
CONCAT(IFNULL(ROUND(SUM(data_free)/1024/1024,2),0.00),"Mb") data_free,
IFNULL(ROUND((((SUM(t.data_length)+SUM(t.index_length))-SUM(t.data_free))/((SUM(
t.data_length)+SUM(t.index_length)))*100),2),0) pct_used
FROM INFORMATION_SCHEMA.SCHEMATA s, INFORMATION_SCHEMA.TABLES t
WHERE s.schema_name = t.table_schema
GROUP BY s.schema_name
ORDER BY total_size DESC
This SQL will check for all objects with free space. It will display tables with any more than 100Kb
of free space so you may want to tweak the having clause, but the idea is that it can spot tables
which may benefit from an Optimize Table command.
For example:
If you do not have direct network connectivity from your client to your MySQL database e.g. if a
firewall is blocking port communication, then an SSH tunnel is often the best and easiest solution.
An SSH tunnel can be set up using PuTTY (freely downloadable from the official PuTTY site) with
the MySQL port (e.g. 3306 by default) forwarded. Once a tunnel has been set up a port on your
local machine will be listening and forwarding to your remote server's port, which means you can
effectively connect to the remote server's MySQL database as though it were running on your local
box.
1. Create a session in PuTTY - Insert the hostname or IP address of the machine running
MySQL.
This time the query now takes 1.5 seconds (650% slower!) to execute which is much longer than
before, due to the fact that MySQL now needs to create a temporary table on disk.
So... the bottom line is:
Temporary tables are used frequently in MySQL, and can be a source of bottlenecks
particularly if the tables need to be created on disk.
Although the above example shows you how you can quickly degrade performance by
reducing the size of tmp_table_size, the inverse could be true if your MySQL Server
tmp_table_size value is configured too low i.e. you could dramatically improve performance
and throughput by increasing the value.
You need to monitor to get visibility into exactly what it occurring.
This will provide a percentage figure output e.g. X% of your connections are in use etc. Why not
plug it into your alerting framework (Alerts) and set a threshold e.g. 80%, and then receive a
warning as soon as your connection count creeps up into the danger zone?
C:\> C:\AppD4DBInstallDir\mysql\bin\startClient.bat
mysql> show variables like 'log_error';
+-------------------------------------------------------------------+
| Variable_name | Value |
+-------------------------------------------------------------------+
| log_error | C:\AppD4DBInstallDir\mysql\data\hostname.err |
+-------------------------------------------------------------------+
2. Check that you can read the file from the command line:
You can then use a custom SQL alert to monitor the log file by creating a diff alert, which will
notify you of changes to the log file:
3. Click Alerts->New Alert and then click Custom SQL Alert.
4. Paste the "select load_file( 'file name...' )" command in as the SQL Text text box.
5.
A "Too many connections" error when trying to connect to the mysqld server means that all
available connections are in use by database clients.
The number of connections allowed is controlled by the max_connections system variable. Its
default value is 100. If you need to support more connections, you should set a larger value for this
variable.
MySQL actually allows max_connections+1 clients to connect. The extra connection is reserved
for use by accounts that have the SUPER privilege. The AppDynamics user should have SUPER
privilege, which means that AppDynamics for Databases highlights the issue with the "Too many
connections" error. For example:
According to MySQL, the maximum number of connections MySQL can support depends on the
quality of the thread library on a given platform. Linux should be able to support 500-1000
simultaneous connections, depending on how much RAM you have and what your clients are
doing. Static Linux binaries provided by MySQL AB can support up to 4000 connections.
You should also research the best approach to mysql connection handling supported by your
language (such as PHP and Java ) or a 3rd party DB library (such as Pear.) In MySQL it is
relatively easy to create and destroy connections; therefore, connection pooling is not always the
best option. It may be best to open a new connection for a client request and then explicitly close
the connection at the end of the request.
For example:
The AppDynamics for Databases window displays the explain output for this command:
+----------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| content | text | NO | | NULL | |
| author_id | int(11) | YES | | NULL | |
| article_title | varchar(120) | YES | | NULL | |
| article_hash | int(11) | YES | | NULL | |
+----------------+--------------+------+-----+---------+----------------+
The size of the table on disk is about 190MB. Query the table on a column that is indexed to see
the average query response time:
+----------+
| count(*) |
+----------+
| 15830 |
+----------+
+-----------------------+----------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+-----------------------+----------+----------+----------+
| books.articles | optimize | status | OK |
+-----------------------+----------+----------+----------+
The optimization has the effect of defragmenting the table and reducing the size of the table on
disk down to 105 MB. It also has a very positive effect on query performance, reducing the select
query response time from 0.63 to 0.39 seconds.
Note: The MySqQL query cache was turned off to demonstrate.
+----------+
| count(*) |
+----------+
| 15830 |
+----------+
MySQL query_cache_size
The MySQL Query Cache can have a huge positive impact on your database performance if you
have a database which processes lots of reusable SELECT statements. By reusable I am referring
to statements which repeated by multiple users, therefore if user A executes a SELECT, and then
user B issues the exact same statement, the MySQL Query Cache will just return the results of the
first execution without needing to re-execute the SQL.
What are the Query Cache Key Performance Indicators?
This article addresses what metrics to look for when assessing the benefits of your query cache.
1. Current Size compared with maximum available size. To calculate the percentage used
value for the query cache you can use the following formula:
((query_cache_size-Qcache_free_memory)/query_cache_size)*100
((Qcache_hits/(Qcache_hits+Qcache_inserts+Qcache_not_cached))*100)
This percentage figure shows how much the query cache is used e.g. the figure in the
screenshot of 33% says that of all select statements executed, 33% of them can be satisfied
by the cache and hence do not have to be re-executed.
Qcache_hits/Qcache_inserts
Qcache_inserts/Qcache_prunes
A ratio of Hits to Inserts is displayed in order to show the Query Cache effectiveness. A high
ratio of hits to inserts tells us that there are lots of identical SQL statements being run on the
database and are therefore being serviced directly from cache. A low ratio (as indicated in
the sceenshot above) shows that the cache is not much utilized.
The ratio of Inserts to Prunes represents how many times SQL queries are being inserted
into the cache compared with how many times a query is being removed from the cache
(pruned). This is also a good indicator of SQL reuse on the database and hence query
cache effectiveness.
The Repair by sorting method is over a minute faster in this case, or 64% Faster.
AppDynamics for Databases can display both executions, and also the time spent in each wait
state.