When should you increase copy latches? What parameters control copy latches

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.

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

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.

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

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.

Discuss row chaining, how does it happen? How can you reduce it? How do you correct it

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.

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

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.

If you see contention for library caches how can you fix it

Increase the size of the shared pool.

If you see statistics that deal with “undo” what are they really talking about

Rollback segments and associated structures.

If a tablespace has a default pctincrease of zero what will this cause (in relationship to the smon process)

The SMON process won?t automatically coalesce its free space fragments.