Académique Documents
Professionnel Documents
Culture Documents
General Approach
The successful DBA practitioner must develop a general course of treatment--a regimen, that can be used to treat a variety of ills. I have found the following steps to be helpful: Step 1: Step 2: Step 3: Step 4: Step 5: Define Problem: What is the chief complaint? Investigate: Confirm/quantify the problem Isolate root cause: Simplify and hone in on the essence of the problem Devise solution: The creative step Implement/confirm solution: Make sure the solution addresses the problem
Page 1
Page 2
Sample Problems
Remember that Step 1 should define the problem, not propose a solution. Dont allow yourself to assume a solution. For instance, some good problem statements would be: The Accounting Quarterly Profit Report takes 5 hours to complete. Typical user login takes one minute. These are both good descriptions of what the user sees. They dont try to guess at a cause; rather, they restrict their scope to what, not why. On the other hand, the following statements are either too vague, or pre-suppose a solution: The network is slow Database is slow; I need another index The database needs more memory I need Parallel Query option I need version 8.1.6 because it is faster To prepare a good problem statement, interview the users. Ask, What is your main complaint?
In some cases, it is best to watch the end-user as he executes the program. Get to know a little about how the application works. A side benefit of this is that the user will understand that you are serious about solving the problem. They will appreciate your interest. In many cases, it will be necessary to capture the actual SQL statements that have been issued. Run SQL trace on a session to discover all database queries; alternatively, look at the v$sqlarea view to list all SQL in the shared pool. Oracle Enterprise Manager (OEM) can be very helpful at this stage. For instance, the Top Sessions tool can be used to show resource consumption (e.g., disk reads) for any session. It is probably a good idea to also check the alert log for the database being queried, just in case there are any space problems indicated.
Page 3
Simplify
In order to identify the true root cause, it is important to simplify. Remove irrelevant distractions, such as formatting, irrelevant tables, etc. from the query. If many different fields are listed in the query, remove most. Reformulate complex equations as simple SQL, that still use the same problem tables, joins, etc. If views are involved, break down views to underlying tables. If a multiple-transaction set is the problem, break the large transaction into smaller pieces. Then eliminate the portions that execute quickly. It is often helpful to build new database objects similar to the problem query in order to test theories. This way, the problem can be further isolated without impacting the production system. For instance, if queries on a certain type of table are a problem, create a similar table (and associated indexes) in another schema and try querying. The query can be made more and more complex, until the problem area is isolated.
Be Suspicious
When trying to find a root cause, the DBA should ask the question, What is the optimizer doing with the SQL? That is: what is the execution plan, by which the database runs the query? A very simple way to find this is to use the Autotrace function in SQL*Plus. It is mandatory that the DBA become very familiar with how Oracle determines the executions plan for a SQL statement. Lack of knowledge will lead to guesswork, and poor performance. When trying to isolate a complex performance problem, be suspicious--consider all the subsystems. Dont be too quick to eliminate any subsystem from your list of suspects. For example, if the query is run across a network, measure how many bytes were transferred across the network for that session. (OEM Performance Manager easily lists these statistics.) Also, try running the query locally and check the difference. It may be helpful to consider the various causes of performance degradation that I have encountered. As shown in the figure, application and database design are almost always involved in correcting performance problems. At the other end, rarely have I seen problems that are truly caused by inadequate hardware sizing.
Page 4
Involvement
Cause
Page 5
Init.ora parameters Greatly undersized SGA--e.g., db_block_buffers set too low. Unusual or exotic features used unnecessarily--e.g., MTS Hardware Server greatly undersized. Few disk drives cause I/O conflicts
Page 6
In Step 4, however, the DBA becomes an artist. Instead of analyzing, we now synthesize. Now is the time to be creative: he must try to imagine the perfect solution that addresses the root cause in the simplest fashion possible. For example, is the solution just a matter of adding the missing index, or is a minor change to the application required? Rack your brain trying to conceive of potential solutions. Here are some good starting places: Use Oracle Metalink It is free with metal support. It can be used to search for a particular ORA error number, or find other users who have had similar problems. The Technical Forums provide quick answers to the simpler problems. Brainstorm with other DBAs No one has all the answers! On numerous occasions, I have consulted with other DBAs on what I believed was an extremely thorny problem. Often I am surprised when the other DBA sees an obvious fact that I have simply missed. Regardless of the tools used, the knowledgeable DBA will be able to consider a much broader range of potential solutions. This is because a good DBA will understand the cause-and-effect relationship between database changes and performance. He will also see that many offered solutions are irrelevant, because they do not address the underlying problem.
Page 7
In conclusion, remember the steps that should be part of each performance investigation: Step 1: Step 2: Step 3: Step 4: Step 5: Define the problem Investigate Isolate root cause - Analyze Create solution - Synthesize Implement and confirm solution
Followers of a systematic tuning regimen will gain great job satisfaction, and will also earn the users gratitude and respect. If instead, the DBA chooses to wear the Dunce Cap and follow the guessing method, be prepared for frustrated, mad users, who rightly question the competence of the administrator. Followers of the guessing method will quickly gain a reputation for shoddy work that never really solves the problem. The only magic then, will be how fast the client can make the DBA disappear. So, which hat will you wear?
Page 8