Performance Tuning   «Prev  Next»

Measure Oracle Performance - Exercise

How do we measure Oracle performance?

Oracle tuning metrics

Objective: Match each metric with its corresponding condition.
This exercise uses a Java applet to allow you to match items in the left column with the items in the right column. If you do not have Java active in your browser or are behind a firewall that does not allow Java applets, you will not be able to complete this exercise. If you do not see the applet below, click the Submit button to continue with the course. You will receive full credit for this exercise.

Instructions

In the left column below are seven metrics (things you can monitor to check Oracle's performance). In the right column you'll see a list of corresponding conditions that are indicated by each of these metrics. Click once on a metric in the left column, then click once on the resulting condition in the right column to make a match.
When you think you have all of the items matched correctly, click the Done button and you'll see whether or not you've matched the terms correctly--green lines mean the match is correct, red lines mean the match is incorrect. If you didn't get the matches right the first time, click Clear to erase your matches and try again.
When you have completed the exercise, click the Submit button to see the correct answers.

Exercise Scoring

You will receive 5 points for this exercise. The exercise is auto-scored; when you have completed the exercise, click the OK, I'm done button to receive full credit.
  1. Large database buffer
  2. High value of the log_buffer init.ora parameter
  3. Large sort_area_size
  4. High value of the shared_pool init.ora parameter
  5. Low number of buffer busy waits
  6. Large value stored in V$session_wait view
  7. Low number of table fetch continued rows
  1. Oracle had to wait for a physical I/O many times
  2. Fewer disk sorts
  3. Few rows that were fragmented onto a successive data block
  4. Few transactions waiting to access data block in data buffer
  5. Fewer redo log space requests
  6. Better library cache hit ratio
  7. High buffer hit ratio