Usage
Command line
Called without any parameter, report.sh displays a short help page concerning its command line parameters. A normal, successful run can be done with just passing it the ORACLE_SID of the instance to report on as only parameter - provided your Oracle environment is set up to support a connect with the syntax "CONNECT user/password@ORACLE_SID". More command line parameters are available and listed in the table below:
ParameterDescription
-c alternative configuration file to use. You may create different configurations according to e.g. special cases (such as e.g. running a complete report containing all blocks just once a week, while having a shorter everyday report), or for groups of instances you want to monitor the same blocks or having the same user/password combinations in, and then just specify the corresponding config file at the command line. This file needs to be executable by the user running the report.sh script.
-d Directory to change to before generating the reports. This may be useful if you defined a relative path for the REPDIR in your config file.
-u User name for the SQL CONNECT statement
-o Use alternative output file name (where the HTML output shall be written to)
-p Password for the SQL CONNECT statement
-r Use alternative report directory (where the HTML output shall be written to)
-s Connection string for the SQL CONNECT statement (if different from the ORACLE_SID). This is used for the SQL CONNECT string only, while the ORACLE_SID is also used for the report's file name.
An example command line could look like this:
./report.sh oradb -c maint.config -d /var/www/reports/oradb
Evaluation of results
Since database design and usage can differ a lot between different systems, there is no general recipe to success on the evaluation of the reports (not even on the configuration of OraRep). Nevertheless, there are some values we may identify problems generally (e.g. by ratios). For these you can use the "Go4Colors Mode", i.e. just scroll through the report and look for table cells having red (alert) or yellow (warning) background color and investigate their values first (the colors mentioned refer to the default stylesheet shipped with OraRep - if you modified this or use another one, the colors may be different or not even available if the classes are missing).
Moreover, there are several places of the report that may deserve closer attention even on the first evaluation and/or by the novice admin:
IssueDescription
Security Check the "User Information" segment and look for accounts that may have been created anew (and maybe should not exist: most important on this is the "Admin" table), the assigned Profile and Resource Groups. Check the users TableSpace Quotas: is there a user having (too much) quota on a TableSpace (s)he shouldn't have?
Integrity Still in the "User Information" segment, check that no user (except for SYS and SYSTEM) has the SYSTEM TableSpace set as "Default" (or even "Temporary") TableSpace. For temporary TableSpaces, check that nowhere is a permanent TableSpace assigned. Check the "DB Links" table for entries having a status other than "ACTIVE". Check the "Invalid Objects" block for e.g. invalid indices.
Performance Check the "Wait Events" (focus on TimeOuts here) and "Wait Objects" segments. If there are too many sequential reads (which may indicate too many full table scans), this is one reason I would recommend using Oracle Statspack and Level 6 snapshots together with OSPRep to easily identify the "bad SQL statements" possibly responsible for this).
Resources See the "Data Files" segment for file sizes, locations and average I/O. If e.g. all files with high I/O are located on the same device (disk), you may consider some reorganization to get rid of this I/O bottle neck - provided you have alternative devices (disks) available, of course. If you run Oracle 9i or higher, you may want to investigate the "Advices" section as well to see whether you may e.g. decrease some cache or pool size without performance loss (and use the gained memory at another place), or whether a slightly increase of some area may cause a significant performance gain.
These are just some ideas of where to start and what to keep in mind. Of course, there are many more things to consider - but either you already know about these, you will learn about these, or you will find somebody else to tell you: this documentation is not intended to be a seminary on Oracle Performance Tuning, there are other sources on this. If OraRep (with its documentation, reports and hints) got you started on this topic, or gave you new/more ideas about it, I did a good job :-)
Go4Colors
The "Go4Colors Mode" is intended to highlight possible problems in order to not overlook them. As a side effect, the DBA that supervises many instances has a quick way to determine whether there are possible problems that need his attention without reading the whole report. However, one should not rely on these colors alone, since they are mostly based on arbitrary values: again we have no perfect recipe on what "regular values" should look like - and a value suitable in an OLTP environment already could indicate issues for tuning in a batch environment, and vice versa.
Normally, a table cell with yellow background indicates a "warning", red background means "alert". But again, you shouldn't take these indicators literally: everything very much depends on your environment. So even a cell with red background doesn't mean you have to panic!
Some values that lead to a "warning" or "alert" are configurable (see configuration section of this document), others need no values (e.g. Quotas for non-existing tablespaces are marked with the "warning" color). For the default values used, please see the example config file shipped with OraRep.
w3cOraRep © 2003-2005 by Itzchak Rehberg & IzzySoftIzzySoft