Oracle DBA Best Practices

The Oracle's DBA Best Practices Guide is intended to provide information regarding Oracle's
products. However, Oracle warns users that the guide does not represent any form of
commitment from Oracle on the delivery or functionality or any other commitment. The guide
should also not be used as a reference in order to make purchasing decisions as it is used solely
for educational purposes.
Top 3 DBA Activities
The DBA best practices guide highlights that the top 3 DBA activities include performance
diagnostics, SQL optimization, and space management. Each of these sectors is discussed
separately in the guide to provide sufficient insight about each activity.
Performance Diagnostics
Performance diagnostics is nothing but the process of reducing the total DB time to minimum in
an Oracle database. DB time is a measure of the time that is required to perform certain user
level calls in the database. This is often expressed in microseconds. This includes the CPU time,
IO time, and the non-idle wait time. So, if 'n' number of active sessions are being carried out on
your database, the total DB time is nothing but the sum of all the DB times for each of the 'n'
active sessions on your database.
Any session that is currently spending some time with respect to a database call is defined as an
active session. The ratio of the DB time to the elapsed time is known as average active sessions.
This was previously known as DB load. The document also highlights the use of ADDM or
Automatic Database Diagnostic Monitor to analyze the performance throughout a database. The
guide also addresses manual performance diagnostics for your database. While the ADDM runs
autonomously whenever required, manual performance diagnostics requires you to observe the
active sessions graph and determine the source of the problem by analyzing the peaks in the
graph.
Apart from these functions, you can use targeted performance analysis using different
dimensions. The various dimensions that could be used in targeted performance analysis include
time, session ID, SQL ID, client ID, wait class, module, action, and service. This will generate a
series of reports that you can use to analyze and arrive at the source of the problem that is
increasing your DB time.
With ADDM you can also create a comparative type performance analysis. You can make use of
the AWR or Automatic Workload Repository and create a baseline that can be used for the
performance analysis. You can also set thresholds so that you will be alerted on time whenever
the DB time increases. In addition, you can also use this method to monitor the performance,
compare the reports, workload variations, and a good number of other metrics that can help you
in effectively reducing the effort you would otherwise have to put into a performance diagnosis.

SQL Optimization
SQL statements are often used to retrieve data from the database. The same result can often be
achieved through the use of SQL queries. These queries also play an important role in optimizing
the database performance and it is essential to tune these queries according to your requirements.
One of the highlights of the Oracle DBA is the ability to understand SQL execution using the
real-time SQL monitoring tool. This tool shows the SQL processes taking place during an
execution. It also allows you to automatically monitor SQL queries that have been running for a
long time. The tool provides insights on SQL execution by monitoring statistics on the global
level of execution, parallel level of execution, and on the operational plan level. The tools also
provide reports that can help you to optimize the SQL queries for best performance.
The Oracle DBA contains yet another useful feature in SQL tuning advisor that can help you in
tuning the SQL queries as per your requirements. You can run a comprehensive analysis of how
the SQL queries are being executed on the basis of the statistics obtained from the tuning advisor.
You can also access the structural analysis, design the SQL analysis, and plan the tuning using
the tuning advisor's recommendations.
The Oracle DBA can be set at two different modes of resource consumption; limited and
resource consumption comprehensive. The limited mode, as the name suggests, consumes a
minimal amount of resources as opposed to the comprehensive mode where the SQL profiling
may consume even some non-trivial resources. Similarly, it also offers two different modes for
tuning SQL remote and live. These modes can help you tune the SQL queries based on different
situations.
The remote mode comes in handy during situations when the system is unable to spare any
additional resources or when the resources consumed by the SQL statements and queries are
quite significant. The live tuning mode, on the other hand, can be used in both situations. You
can run it using the limited mode when the system cannot spare additional resources and the
comprehensive mode in other circumstances. Oracle recommends the use of comprehensive
mode along with Live Tuning.
Automatic SQL tuning is also available in the Oracle DBA and it is a highly intuitive tool. This
can capture high load SQL automatically and can also tune the SQL queries and statements by
creating SQL profiles. This process is highly useful as it does not modify the application in any
way. In addition to this, the tool can also validate SQL profiles and implement SQL plans
automatically. You can get an automatic analysis of reports and the tool also runs during the
maintenance window making it one of the most innovative features in the DBA.
Space Management
Space management in a database management system such as Oracle is about understanding the
storage mechanisms offered by the Oracle DBA and making use of the best option available to
meet your storage demands. Oracle segregates this process into two main subdivisions known as
permanent tablespace management and temporary tablespace management. Both these

techniques optimize the space by either partially or completely eliminating fragmentation. The
end result is optimized access to data and improved transaction performance of your DBA.
Permanent tablespace management takes place by making use of the bitmaps that can be found
within the file headers using locally managed tablespace for extent management. Extent
management can also be achieved by two methods uniform allocation, where all extents are of
the same size, and auto allocation, where the extent size varies. Auto allocation is the
recommended approach toward extent management. You can also use permanent tablespace
management for segment management using the automatic segment space management feature.
This feature generates a segment free space that can be managed using bitmaps. This also leads
to minimum internal fragmentation and superior performance.
Internal fragmentation in segment management is nothing but the fragmented space that often
exists within a segment. This can have a significant impact on the performance as the fragmented
space can slow down certain access paths. This problem can be solved by using an online
segment shrink. The automatic segment advisor, on the other hand, evaluates the segments for
fragmentation and provides the much required recommendations to help you get rid of any
internal fragmentation you may come across.
Temporary tablespace management comes in handy when managing the space for temporary data
in your DBA. This includes managing space for data that is generated by operations such as
bitmap merges, creating bitmap indexes, sorting, hash joins, and so on. The data from such
operations generally persists only for the duration of the session and as a result, media and
instance recovery is not required. However, it is important to take a look at the concurrency of
space management in these operations. Using locally managed temporary tablespace for
temporary data allows for several advantages such as high concurrency in managing the space
and also allows the space to be shrunk using commands such as SHRINK TEMPFILE or
SHRINK SPACE.
Other than this, the guide also mentions and provides several highly useful and intuitive best
practices for SQL optimization, permanent tablespace management, temporary tablespace
management, tablespace management using RAC and much more. In addition to this, the guide
also highlights how the database control or the grid control tool can be used to manage the entire
database efficiently. Additionally, the guide also contains the schedules of the campground
demos and recommended sessions to better understand database management in Oracle. These
demos and sessions can be extremely useful when it comes to better understanding the features
of the Oracle DBA. Oracle also highlights the top 10 best practices for DBA activities as follows:
1. Using enterprise manager for database management
2. Using locally managed tablespace for temporary purposes
3. Using auto allocate and automatic segment space management or ASSM for managing
permanent tablespace
4. Using SQL performance analyzer

5. Automatic statistics collection

6. SQL tuning advisor to tune up SQL queries and statements
7. Real time monitoring to understand SQL execution
8. Making use of AWR baselines in performance analysis
9. Using ASH for targeted performance analysis
10. Using the ADDM for performance diagnostics

DBA Monitoring Top Five

Michelle Malcher on 19 January 2012 with 4 comments
Have you ever just sat there watching all of the processes running against the database, just
waiting for something to happen? Of course not! We are database administrators, architects,
developers and we dont have time for that! We also might get bored wondering why there seems
to be millions of the same query running against the database a discussion for another time.
However, there would be reasons that we are watching processes or statements running in against
the database and it is normally because something was alerted or the phone rang asking, why is
the database so slow.
The big question is what should we be alerted on to try to beat the phone call to a solution, or
what are some of the critical issues we still have to deal with in more automated environments?
Even with monitoring tools, what are the alerts we need and the thresholds to set them at? There
are several things that I can think of to monitor, but there have been a select few that have caused
the database to be down or not available no matter what version or option.
The monitoring can be done with tools, such as Oracle Enterprise Manager or other monitoring
tools, or scripts, but the list is short and there are specific things to look for to prevent the outage
or issue. Here is my short list to have monitored on any database:

1. Listener
The listener being available is obvious for new connections coming into the database. Maybe the
listener is now in the grid home or the database home but if it isnt up and running there is no
access to the database. The listener is easy to check if it is available at the OS level with
checking for tns process. Also using lsnrctl command line will give status of the listener and the
databases that it is listening for. The log will be useful for troubleshooting connectivity problems
and refusals. Here using OEM to alter on if the listener is available or using scripts to monitor
the process to make sure they are running. Logging into the database could be part of another test
and error messages would be similar to ORA-12560: TNS:protocol adapter error or other ORA
: TNS errors. However, not all TNS errors are listener issues which lead to the next item.

2. Processes
Hitting max processes can either cause a login to hang which makes it sometimes difficult to
monitor, especially if you are logging into the database to monitor it. It can also give a TNS
error, which can mislead you for a little while until looking through the alert log and finding the
ORA-00020: maximum number of processes error in the log. Here a threshold is useful to
monitor reaching a percent of max processes, so when it hits 80% there is time to research what
is going on to prevent lock out of the database. When hitting the threshold, killing processes is an
option to prevent reaching the max processes, because when needing to change the parameter
will require a restart of the instance. Adjusting the processes parameter is not always the solution
for this issue, but it might provide a Band-Aid to look at options and figure out why and where
the processes are coming from.

3. Archive log and recovery area

Archive log space will cause the system to hang and give the dreaded ORA-00257: archiver
error. Connect internal only, until freed error. If using file system space, monitoring the space
available on the mount point is important. Setting thresholds to monitoring when 80 or 85% of
space used is reached should allow time to back up the archive logs and remove them to free up
space. When using the recovery area, the alert log will have warnings based on the thresholds
that Oracle has set to monitor the recovery area. These are set at 85%, with a critical alert at
97%. Using the alert log could monitor these thresholds, or using v$flash_recovery_area_usage
to monitor.
Space can be easily added to the recovery area by the db_recovery_dest_size parameter
dynamically. This is an easy issue to prevent with properly sizing the archive log space and
taking care of the backups of the archive logs, which makes this a frustrating error to run into
and makes monitoring this area even more important.

4. Space, tablespace and filesystem

More space issues that can cause issues, but these space issues may not cause a system wide
outage like the issues listed already; this depends on how tablespaces are distributed. The system
tablespaces, such as SYSTEM, TEMP, UNDO, SYSAUX, can cause more issues but are fairly
easy to monitor and set thresholds in the monitoring by percent full. The trick here with all of the
tablespace is accounting for auto extend, and if you have very large tablespaces, the percent
thresholds might not be appropriate, and just provide alert noise if 10% free still has 100 to 200
GB free.
Being able to monitor both percent and size is useful, and I have normally just setup some shell
scripts to do this, which then can be used in the monitoring tools. Also with the auto extending of
the tablespace the secondary problem is the file system space, and that is easy enough to monitor
with OS tools or monitoring tools. Another good thing to monitor to be proactive about space is
monitor based on the auto extending and whether that could grow past the size of the file system.

5. Database availability
Whether the database is up or down is probably very obvious thing to monitor for and may seem
simple too. You can check for smon, pmon and other processes to make sure that they are
running, and this will work if you dont run into other issues, like archive space, processes or
tablespace issues. Even if the processes are available, the login to the database will either hang or
show another error, so actually logging into the database and a simple select will show if access
to the database is available.

Conclusion
This is by far not a complete list of things to monitor for, but they seem like issues that pop up
every time they are not being monitored. Most of these do cause issues that will cause the
database instance to hang or not allow any new connections. They are simple things to monitor
for in available tools or simple scripts and they have their little tricks to provide the right level of
proactive monitoring.
inShare

Michelle Malcher

Comments

Trackbacks

4 Comments

1.
desi
27/01/2012 Reply
Hi Michelle,
do the ora-00020 error show up in alert logs when occur? or there is some setting?
TU
DB

2.
Michelle Malcher
27/01/2012 Reply
Yes, the ORA-00020 error will show up in the alert logs, but it is not the message that
most client connections will get. They receive a TNS error, which can lead down a
different path for troubleshooting. Monitoring the alert for ORA-00020 will show when
you have already hit max processes, and at this point all you can do is close out sessions.

3.
Joseph Karpinski
11/02/2012 Reply
Hi Michelle,
I've been wrestling with performance questions like "the database is slow" since Oracle 7,
but more from a performance analyst point of view than a DBA.
I''ve a PowerPoint presentation I gave at TeamQuest 2011 on "Profiling Oracle Workloads
Across the Enterprise". You might find it interesting. The talk included an introduction
that compared approaches to solving a performance issue on Oracle, to having a knock
under the hood of your car. You take your car to one auto shop and they hook your car up
to an End-to-End diagnostic machine, where they apply best practices and replace your
oil, fan belt, spark plugs, tires, etc , and maybe even fix your original problem. You take
your car to a second auto shop, and the mechanic listens to what you have to say, lifts the
hoods, replaces a part or two, and fixes your problem. The first approach is very much
how many try to solve a performance issue on Oracle. We throw hardware at it, purge
data, add more memory, and tune top SQL. The second approach uses an understanding
of the problem, which in many cases gets you quickly to the root cause, and a solution.
Oracle did a great job with AWR.
The problem with the new AWR Diagnostic Pack is that in many cases it is still similar to
the example of the auto shop running end-to-end diagnostics along with best practices
and rules of thumb, but without any idea of what the problem is.
When a DBA runs an ASH or ADDM report, that's a great piece of information.
What's missing is the "compared to what" component.
If the top SQL identified in the report are always top each day between 10 AM and 11

AM,
why is today slow, but not yesterday?
I use the data-centric view to determine what table components have changed, and the
identify the corresponding SQL.
We had this one case where stats were run every week-end on a database.
No application changes were made but Monday morning the application was slow.
The DBA's ran ASH and ADDM reports but couldn't figure it out.
I ran those data-centric views and saw higher activity against a different index. The path
had changed based on the stats that were run on the tables over the weekend.
Once the problem was identified, the DBA's quickly corrected it.
If you have an interest, just drop me a line at [email protected]

4.
Michelle Malcher
15/02/2012 Reply
Hi Joseph,
Thanks for the response and additional information on looking at performance. It
definitely takes looking at more than one area of the database and tools to figure out what
might be happening, and like you said consider the history and time of the issue.
Statistics is normally an area that is high on my list to check if there are issues. Taking
backup of statistics using DBMS_STATS.export_table_stats and being able to see what
changed or import the statistics to a test environment is extremely useful in
troubleshooting.
Great comment, thanks!

Leave a response
* Required
* Required

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Cary Millsaps latest book

Learn all about Oracle extended SQL trace data from Cary Millsap. Includes a full chapter of
case studies using Method R software.