Tuning Questions
1. A tablespace has a table with 30 extents in it. Is this bad?
Why or why not.
Level:
Intermediate
Expected answer:
Multiple extents in and of themselves aren?t bad. However if you also have
chained rows this can hurt performance.
2. How do you set up tablespaces during an Oracle installation?
Level: Low
Expected answer: You
should always attempt to use the Oracle Flexible Architecture standard or
another partitioning scheme to ensure proper separation of SYSTEM, ROLLBACK,
REDO LOG, DATA, TEMPORARY and INDEX segments.
3. You see multiple fragments in the SYSTEM tablespace, what
should you check first?
Level: Low
Expected answer:
Ensure that users don?t have the SYSTEM tablespace as their TEMPORARY or
DEFAULT tablespace assignment by checking the DBA_USERS view.
4. What are some indications that you need to increase the
SHARED_POOL_SIZE parameter?
Level:
Intermediate
Expected answer: Poor
data dictionary or library cache hit ratios, getting error ORA-04031. Another
indication is steadily decreasing performance with all other tuning parameters
the same.
5. What is the general guideline for sizing db_block_size and
db_multi_block_read for an application that does many full table scans?
Level: High
Expected answer:
Oracle almost always reads in 64k chunks. The two should have a product equal
to 64 or a multiple of 64.
6. What is the fastest query method for a table?
Level:
Intermediate
Expected answer: Fetch
by rowid
7. Explain the use of TKPROF? What initialization parameter
should be turned on to get full TKPROF output?
Level: High
Expected answer: The
tkprof tool is a tuning tool used to determine cpu and execution times for SQL
statements. You use it by first setting timed_statistics to true in the
initialization file and then turning on tracing for either the entire database
via the sql_trace parameter or for the session using the ALTER SESSION command.
Once the trace file is generated you run the tkprof tool against the trace file
and then look at the output from the tkprof tool. This can also be used to
generate explain plan output.
8. When looking at v$sysstat you see that sorts (disk) is high.
Is this bad or good? If bad -How do you correct it?
Level:
Intermediate
Expected answer: If
you get excessive disk sorts this is bad. This indicates you need to tune the
sort area parameters in the initialization files. The major sort are parameter
is the SORT_AREA_SIZe parameter.
9. When should you increase copy latches? What parameters
control copy latches?
Level: high
Expected answer: When
you get excessive contention for the copy latches as shown by the "redo
copy" latch hit ratio. You can increase copy latches via the
initialization parameter LOG_SIMULTANEOUS_COPIES to twice the number of CPUs on
your system.
10. Where can you get a list of all initialization parameters
for your instance? How about an indication if they are default settings or have
been changed?
Level: Low
Expected answer: You
can look in the init.ora file for an indication of manually set parameters. For
all parameters, their value and whether or not the current value is the default
value, look in the v$parameter view.
11. Describe hit ratio as it pertains to the database buffers.
What is the difference between instantaneous and cumulative hit ratio and which
should be used for tuning?
Level:
Intermediate
Expected answer: The
hit ratio is a measure of how many times the database was able to read a value
from the buffers verses how many times it had to re-read a data value from the
disks. A value greater than 80-90% is good, less could indicate problems. If
you simply take the ratio of existing parameters this will be a cumulative
value since the database started. If you do a comparison between pairs of
readings based on some arbitrary time span, this is the instantaneous ratio for
that time span. Generally speaking an instantaneous reading gives more valuable
data since it will tell you what your instance is doing for the time it was
generated over.
12. Discuss row chaining, how does it happen? How can you reduce
it? How do you correct it?
Level: high
Expected answer: Row
chaining occurs when a VARCHAR2 value is updated and the length of the new
value is longer than the old value and won?t fit in the remaining block space.
This results in the row chaining to another block. It can be reduced by setting
the storage parameters on the table to appropriate values. It can be corrected
by export and import of the effected table.
13. When looking at the estat events report you see that you are
getting busy buffer waits. Is this bad? How can you find what is causing it?
Level: high
Expected answer:
Buffer busy waits could indicate contention in redo, rollback or data blocks.
You need to check the v$waitstat view to see what areas are causing the
problem. The value of the "count" column tells where the problem is,
the "class" column tells you with what. UNDO is rollback segments,
DATA is data base buffers.
14. If you see contention for library caches how can you fix it?
Level:
Intermediate
Expected answer:
Increase the size of the shared pool.
15. If you see statistics that deal with "undo" what
are they really talking about?
Level:
Intermediate
Expected answer:
Rollback segments and associated structures.
16. If a tablespace has a default pctincrease of zero what will
this cause (in relationship to the smon process)?
Level: High
Expected answer: The
SMON process won?t automatically coalesce its free space fragments.
17. If a tablespace shows excessive fragmentation what are some
methods to defragment the tablespace? (7.1,7.2 and 7.3 only)
Level: High
Expected answer: In
Oracle 7.0 to 7.2 The use of the 'alter session set events 'immediate trace
name coalesce level ts#';? command is the easiest way to defragment contiguous
free space fragmentation. The ts# parameter corresponds to the ts# value found
in the ts$ SYS table. In version 7.3 the ?alter tablespace coalesce;? is best.
If the free space isn?t contiguous then export, drop and import of the
tablespace contents may be the only way to reclaim non-contiguous free space.
18. How can you tell if a tablespace has excessive
fragmentation?
Level:
Intermediate
If a select against
the dba_free_space table shows that the count of a tablespaces extents is
greater than the count of its data files, then it is fragmented.
19. You see the following on a status report:
redo log space
requests 23
redo log space wait
time 0
Is this something to
worry about? What if redo log space wait time is high? How can you fix
this?
Level:
Intermediate
Expected answer: Since
the wait time is zero, no. If the wait time was high it might indicate a need
for more or larger redo logs.
20. What can cause a high value for recursive calls? How can
this be fixed?
Level: High
Expected answer: A
high value for recursive calls is cause by improper cursor usage, excessive
dynamic space management actions, and or excessive statement re-parses. You
need to determine the cause and correct it By either relinking applications to
hold cursors, use proper space management techniques (proper storage and
sizing) or ensure repeat queries are placed in packages for proper reuse.
21. If you see a pin hit ratio of less than 0.8 in the estat
library cache report is this a problem? If so, how do you fix it?
Level:
Intermediate
Expected answer: This
indicate that the shared pool may be too small. Increase the shared pool
size.
22. If you see the value for reloads is high in the estat
library cache report is this a matter for concern?
Level:
Intermediate
Expected answer: Yes,
you should strive for zero reloads if possible. If you see excessive reloads
then increase the size of the shared pool.
23. You look at the dba_rollback_segs view and see that there is
a large number of shrinks and they are of relatively small size, is this a
problem? How can it be fixed if it is a problem?
Level: High
Expected answer: A
large number of small shrinks indicates a need to increase the size of the
rollback segment extents. Ideally you should have no shrinks or a small number
of large shrinks. To fix this just increase the size of the extents and adjust
optimal accordingly.
24. You look at the dba_rollback_segs view and see that you have
a large number of wraps is this a problem?
Level: High
Expected answer: A
large number of wraps indicates that your extent size for your rollback
segments are probably too small. Increase the size of your extents to reduce
the number of wraps. You can look at the average transaction size in the same
view to get the information on transaction size.
25. In a system with an average of 40 concurrent users you get
the following from a query on rollback extents:
ROLLBACK CUR
EXTENTS
---------------------
--------------------------
R01 11
R02 8
R03 12
R04 9
SYSTEM 4
You have room for each
to grow by 20 more extents each. Is there a problem? Should you take any
action?
Level:
Intermediate
Expected answer: No
there is not a problem. You have 40 extents showing and an average of 40
concurrent users. Since there is plenty of room to grow no action is needed.
26. You see multiple extents in the temporary tablespace. Is
this a problem?
Level:
Intermediate
Expected answer: As
long as they are all the same size this isn?t a problem. In fact, it can even
improve performance since Oracle won?t have to create a new extent when a user
needs one.
No comments:
Post a Comment