How to tune your Oracle database's performance
Handy 101 explainer for DBAs
Workshop It's the call that every Oracle database admin (DBA) dreads: the "too slow" call. Users, or their managers, may argue that online performance is so bad that it stops staff from doing their jobs. Batch jobs such as billing runs may run too slowly. Customers may be walking away from an Oracle-driven ecommerce site because pages are taking too long to refresh.
If your database performance isn’t passing muster, there are things that you can do to make it better. This is a handy guide to possible problems, and how to fix them.
Oracle has its own performance improvement model, which is an incremental process designed to test for different performance hits, and then measure the results. To properly use the model, an Oracle DBA will need benchmarks to measure the improvement by.
Setting performance targets for the database is crucial if a DBA is to understand what to aim for. Setting them in easily understandable technical terms (such as number of customer interactions served per second, or the length of time taken for a billing run) will give them a suitable target.
Similarly, you have to know where you're coming from, in order to know where you're going. Establishing firm baselines for existing performance is an important step. Measure database performance at both the times, and off-peak times, to get a sense of current capabilities.
Once you have established these parameters, you'll be able to begin testing for some of the common performance problems often found in Oracle databases.
To make performance tuning easier, it's often useful to talk to the database, and ask it what it's doing within a user session. It will be in one of three states: idle, processing, or waiting. You can query the database's current state using a view called V$SESSION. This can give you some clues about where the problem lies.
For example, if an application's users are complaining that it's slow, but you notice that the database is idle for large periods of the time during that application's session, then that means that the database simply has no work to do, possibly because the application itself is having performance issues.
Another useful tool is Oracle's Automatic Database Diagnostic Monitor, which is self-diagnostic software designed to highlight performance and other issues in the database. This explores data stored in the Automatic Workload Repository (AWR), which takes a regular snapshot of performance statistics from the database.
Toad for Oracle, one of the more popular - if not the most popular - third party DBA tool for Oracle, has an entire section dedicated to diagnostics, called Spotlight on Oracle. This provides real-time diagnostics in visual form, making them easy to digest. It is good for outcomes including pinpointing and resolving bottlenecks, and peering into database processes.
Whether or not you use tools such as these, there are some common problems that plague Oracle databases. Here are some things to try, which may help streamline performance:
Tune your SQL
Poorly written SQL queries can take their toll on database performance. It's possible to choose SQL manually, but Oracle also includes tools to help you with this. Its Query Optimizer includes an automatic SQL Tuning facility, accessed via the SQL Tuning Advisor.
Toad for Oracle has several SQL tuning features, including the Quest SQL optimizer, and it lets you access that, along with Oracle's Tuning advisor, from its dashboard. The SQL Optimizer analyses SQL or PL/SQL statements that are already running, and explores options for improving performance. It will also optimise your indexes.
V$SESSION can also give you insights into what the database is doing. It shows you the ID of the last SQL statement run by the database, which you can find in the V$SESSION's SQL_ID column.
Be selective here. The SQL statements to look for are high-remote ones, which are good candidates to run through the SQL tuning engine. The ADDM can help you to find these.
Improve table management
How you manage your tables can have a big effect on the performance of your Oracle database. Table partitioning is a method generally used to simplify tables in large, complex databases, by splitting them into smaller, more manageable pieces. But partitioning can also have a positive effect on database performance. The Oracle database recognizes partitions and optimizes SQL statements to focus just on both small and tables, in a process known as 'partition pruning'.
Also, keep a lookout for full table scans, in which an SQL query reads every single block in a table. While this can be useful in some batch-style applications, such as decision support, they can bring online transaction processing-focused databases to their knees. In many cases, a SQL statement may be running a full table scan when it could just as easily use a far faster index-based search.
This applies to small tables, but even more so with long tables. Long tables are not cached, and they have a high watermark greater than five blocks. A high water mark is the highest block that ever contained data, and it is relevant because a full table scan will search every block up to the high watermark – even if many of those blocks no longer contain rows.
Table space management choices can also affect database performance. In particular, if you see lots of recursive SQL statements, it could be a sign that the system is spending too long on space management activities, such as allocating extents (that is, a contiguous collection of data blocks, allocated for storing some specific information).
If you're seeing lots of recursive SQL executed by SYS (the built-in account, which owns the Oracle data dictionary), then it's a sign that this extent allocation may be taking up too much resource at the data dictionary level. Switching to locally managed table spaces, in which extent allocation is handled in the table's own header, may help to solve the problem.