• Redo Size & Block Changes Increase: If you see an increase here then more DML statements are taking place (meaning your users are doing more INSERTs, UPDATEs, and DELETEs than before.

• Buffer Nowait %: This is the percentage of time that the instance made a call to get a buffer (all buffer types are included here) and that buffer was made available immediately (meaning it didn't have to wait for the buffer...hence "Buffer Nowait").
  
  
• Buffer Hit %: This means that when a request for a buffer took place, the buffer was available in memory and physical disk I/O did not need to take place.
  
  
• Library Hit %: If your Library Hit percentage is low it could mean that your shared pool size is too small or that the bind variables are not being used (or at least being used properly).
  
  
• Execute to Parse %: This is the formula used to get this percentage:

  round(100*(1-parsevalue/executevalue),2)

  So, if you run some SQL and it has to be parsed every time you execute it (because no plan exists for this statement) then your percentage would be 0%. The more times that your SQL statement can reuse an existing plan the higher your Execute to Parse ratio is.
  
  One way to increase your parse ratio is to use bind variables. This allows the same plan to be used for multiple SQL statements. The only thing that changes in the SQL is the parameters used in your statement's WHERE clause. For Java/JDBC Programmers that means using PreparedStatements as opposed to regular Statements.
  
  
• Parse CPU to Parse Elapsd %: Generally, this is a measure of how available your CPU cycles were for SQL parsing. If this is low, you may see "latch free" as one of your top wait events.
  
  
• Redo NoWait %: You guessed it...the instance didn't have to wait to use the redo log if this is 100%.
  
  
• In-memory Sort %: This means the instance could do its sorts in memory as opposed to doing physical I/O...very good. You don't want to be doing your sorts on disk...especially in an OLTP system. Try increasing your SORT_AREA_SIZE or PGA_AGGREGATE_TARGET in your spfile/pfile to see if that helps if your in-memory sorting is not between 95% and 100%.
  
  
• Soft Parse %: This is an important one...at least for OLTP systems. This means that your SQL is being reused. If this is low (not between 95% and 100%) then make sure that you're using bind variables in the application and that they're being used properly.
  
  
• Latch Hit %: This should be pretty close to 100%; if it's not then check out what your top wait events are to try to fix the problem (pay specific attention to 'latch free' event).
  
  

• DB file scattered read: This can be seen fairly often. Usually, if this number is high, then it means there are a lot of full tablescans going on. This could be because you need indexes or the indexes you do have are not not being used.
  
  
• DB file sequential read: This could indicate poor joining orders in your SQL or waiting for writes to 'temp' space. It could mean that a lot of index reads/scans are going on. Depending on the problem it may help to tune PGA_AGGREGATE_TARGET and/or DB_CACHE_SIZE.
  
  
• CPU Time: This could be completely normal. However, if this is your largest wait event then it could mean that you have some CPU intensive SQL going on. You may want to examine some of the SQL further down in the Statspack report for SQL statements that have large CPU Time.
  
  
• SQL*Net more data to client: This means the instance is sending a lot of data to the client. You can decrease this time by having the client bring back less data. Maybe the application doesn't need to bring back as much data as it is.
  
  
• log file sync: A Log File Sync happens each time a commit takes place. If there are a lot of waits in this area then you may want to examine your application to see if you are committing too frequently (or at least more than you need to).
  
  
• Logfile buffer space: This happens when the instance is writing to the log buffer faster than the log writer process can actually write it to the redo logs. You could try getting faster disks but you may want to first try increasing the size of your redo logs; that could make a big difference (and doesn't cost much).
  
  
• Logfile switch: This could mean that your committed DML is waiting for a logfile switch to occur. Make sure your filesystem where your archive logs reside are not getting full. Also, the DBWR process may not be fast enough for your system so you could add more DBWR processes or make your redo logs larger so log switches are not needed as much.
  
  

SQL ordered by Parse Calls for DB: ORCL  Instance: ORCL  Snaps: 4873 -4875
-> End Parse Calls Threshold:      1000

                           % Total
 Parse Calls  Executions   Parses  Hash Value
------------ ------------ -------- ----------
     144,300      144,300     6.65 4199666855
Module: JDBC Thin Client
select parameter, value from nls_session_parameters

Tablespace IO Stats for DB: ORCL  Instance: ORCL  Snaps: 4873 -4875
->ordered by IOs (Reads + Writes) desc

Tablespace
------------------------------
                 Av      Av     Av                    Av        Buffer Av Buf
         Reads Reads/s Rd(ms) Blks/Rd       Writes Writes/s      Waits Wt(ms)
-------------- ------- ------ ------- ------------ -------- ---------- ------
UNDOTBS
           146       0    5.8     1.0      117,119       16     50,681    1.3
APP1
        19,395       3   10.5     1.0       32,613        5      1,886    2.8
INDEX1
        36,919       5    0.7     6.3          977        0        526    5.0
APP2
         6,969       1   11.7     1.0       13,559        2      2,513    2.5
SYSTEM
        15,056       2    0.8     1.8          360        0         13    3.8