How to tune your Oracle database's performance

Handy 101 explainer for DBAs

Make sure that your connections are stateful

Your database might be performing well, but what if your application isn't? When they access a database, applications have to make connections. The problem emerges when they make and drop a connection each time they access a table. Connections should be maintained in between each access, but sometimes – especially if an intermediary middleware program is used – this can be overlooked. It has a catastrophic effect on performance, and represents a huge win if you find an application doing this, and correct it.

Reduce serialization where necessary

Serialization happens when transactions seem to happen as though no other users were currently modifying the database, rather than happening concurrently. A little serialization might not be a bad thing, but too much will clog your system. If lots of data blocks are being serialized in the buffer, then this might be a sign that the database needs more rollback segments relative to the number of users, so that it can support multiple changes to the database at once.

Design your database I/O properly

If your application isn't causing problems, maybe your disk-based storage is. How you spread your datafiles across different physical disks can have an important effect on performance. A common mistake is to concentrate on disk space when configuring your disk architecture, rather than looking at I/O bandwidth.

You can find some important clues here in the V$SESSION EVENT row. If a session is waiting for a disk to send data to the buffer, it'll show up as either “db file sequential read” or “db file scattered read” (depending on whether you're running an index or full table scan. If you're seeing a lot of these, check your I/O bandwidth.

Check your statistics

Migration errors are a common cause of poor database performance for Oracle DBAs. If a table schema doesn't make it from a development environment to a production environment, or if it isn't transferred properly from an older version of the database, then indexes and statistics – the information about key database parameters – can go missing.

If this happens, then it can be difficult for the database to create well-performing execution plans (these are the various methods of getting data out of the database, based on structure of an SQL query).

You can avoid this by exporting the schema statistics, using Oracle's DBMS_STATS package. This gives you the ability to review, import, and export schema statistics for a database, so that the query optimizer can do its work properly.

Ultimately, optimizing Oracle database performance is a mixture of trial, error, and some informed decision making with the help of its built-in tools. There are also other, third party tools to help shift the balance even further towards informed action. Dell's Toad includes features including PL/SQL profiling, session information and performance metric display, and the ability to test PL/SQL performance under simulated user loads. It will also help to identify the heaviest SQL loads on the system.

Armed with these tools and techniques, you should be able to stay ahead of the curve when it comes to Oracle performance. Regularly tuning the database should keep it above predefined performance metrics, and keep those panicky user phone calls at bay.

The Register is running a series of Oracle DBA workshop articles in association with Dell Software.