|
README for monitor.ksh
======================
CONTENTS:
1) Purpose of this tool
2) Architecture
3) Handling
4) TODO
1) Purpose of this tool
There a some really good GUI-tools for assisting DBAs - have
a look at Quest's Toad which comes with expert databases for
DBAs and Developers; or look at Oracles SQL Developer or
Grid Control. This is really fine in companies with a handful
of databases, but not in companies with thousands of servers,
clusters and databases simply because you can't establish
the connections because of security issues or the pure number of
instances to be monitored or the cluster software which forces
to guess where the database actually lives.
Expert DBAs in these environments have developed their preferred
and beloved set of scripts, but unfortunately this set has grown
and grown in the course of the years and it is not funny to grep
through this large library of old and new scripts for the appropriate
script when you are on emergency-service and there is a critical
situation an 3:00 AM.
So if we are not allowed to use GUI-tools, then we write some
tools with a "smell of GUI". This one comes out from my actual
situation and I am sure that some smart DBAs on the world have
already done similar things, but until now I have seen only
these script libraries with hundreds of scripts forcing me to
guess for the contents. Take this one as proposal to make your
own solution and feel free to adapt or complete it with other
reports. If you know the kornshell you will easily understand
how to do this.
The "GUI-smell" is achieved by old features of the korn shell:
the select-feature and the capability of the terminfo database
applied by the tput commands. The terminfo manual shows a rich
variety of features including colours. But with respect to the
variety of different ksh-releases I limit myself to black,
white and bold.
2) Architecture
There is a script bundle which comes in mon[version].tar.gz .
After unpacking this tar you will see
README
monitor.ksh
But for the sake of design and simplicity the code is distributed
between the central script monitor.ksh and helper scripts named
.Dba.ksh, etc. in order not to confuse the user. Actually there
are
.monitor.lib (contains the global functions)
.About.ksh
.Ash.ksh
.Dba.ksh
.Dict.ksh
.Jobs.ksh
.Locks.ksh
.Objects.ksh
.Security.ksh
.Session.ksh
This architecture reflects the report section of Oracle's SQLDEVELOPER.
The functions of every script are listed in the respective script headers.
3) Handling
The first window coming up shows my old technique of presenting the running
oracle instances for selecting one of them, thus proceeding to the further
functions. If there is no instance running, the tool exits with a message.
When you know the common GUI tools, the handling is mostly self-explaining.
It was quite a bit of work to persuade the kornshell performing a sort of
"window dialog" for select object_names, owners, synonym_names, beginSnapIds,
endSnapIds, DBID, Instance_number, etc. So, starting a report, there is first
coming up a window with up to 4 parameters you can choose.
There are simple reports which don't need any parameters. Then the window just
offers c(ancel), r(eset), s(ave report: y). If you let this single field null,
then report runs only at stdout. If you say "y", then report ist saved in a
logfile which is shown at the and of the report. c is really cancel and r is
resetting the dialog mask because of typos.
There are other reports with one or two paramters. For example the "All Objects-
Report". If you let the owner null, then report will show all objects in the
database which will probably last minutes to do. So be wise and select an owner
and probably an object_name. You can do this case insensitive, because there
is an upper(...)-function in my scripts. You may - and I encourage you to do
so - choose a partial string of owner or object_name or other parameters,
because there is also a LIKE upper('%variable%') in my scripts. Therefore it does not
make sense to choose with wildcards. SQLDEVELOPER behaves similar.
There are some reports which accept only exact inputs - e.q. the "View columns report"
or the "Enqueue Activity report" which understably need an exact Viewname, BeginSnap, EndSnap, DBID and Instance Number.
As you see, there are some reports which cant' run on Oracle9, but most of them run on
all actual Oracle Releases.
4) TODO
As I'm working in my freetime on the completion of the tool or only when I urgently
need a special report for my work, there are a lot of features not yet implemented.
When you choose a report section or a report which is not yet implemented, the tool
sends a message.
Feel welcome to contribute your favourites.
Hans Werner Koertgen
13 December 2009
|
