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:
|
Parameter | Description |
-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:
|
Issue | Description |
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.
|