- The script now detects "caused by" and "signalled by" errors and alert them accordingly.
Tuesday, March 22, 2005
Version 0.1.3
Only one annoying fix:
Friday, February 18, 2005
Version 0.1.2 is out
Only minor changes.
- GNU GPL License text added to the files
- Simpler config file lookup (just leave on the same directory as the run file)
- Run it from any directory
- Show the line error in the alert mails, not only the error code.
Monday, February 14, 2005
OraAlertCheck 0.1.1 is out
A couple of changes, I've add an automatic alert.log truncation: the script moves the file and then compress it in the same bdump directory. Just add TRUNCATE_BYTES="nnn" in the config file to enable, "0" to disable.
Also now the script send different alerts to reflect different ORA-00600 parameters instead of sending only one mail.
Also now the script send different alerts to reflect different ORA-00600 parameters instead of sending only one mail.
Sunday, February 13, 2005
ChangeLog
0.1.5
- OraAlertCheck is fully functional in AIX (thanks Fayyaz, tested on 5.3).
- Corrections on the way the script treats filenames. When the oracle error was ORA-00600 and had special characters on the arguments the script created temporary files with spaces or : characters which made the script failed.
- OraAlertCheck is fully functional in HPUX and Solaris (thanks Raghu Maddula).
- oratab file location can now be specified in the Config file.
- The tail command needs to support the -n flag. In Solaris the default one did not, so a new config parameter exists to specify a new location (/usr/xpg4/bin/tail for Solaris).
- The "test" run of the script will not only show if it find the alert.log but also will let you now if that instance won't be checked becouse the startup parameter in oratab is "N".
- Support for detection of the "encountered when generating server alert" message was added.
- Detects "caused by" and "signalled by" errors and alert them accordingly.
- GNU GPL License text added to the files
- Simpler config file lookup (just leave on the same directory as the run file)
- Run it from any directory
- Show the line error in the alert mails, not only the error code.
- Automatic alert.log truncation
- Send different emails if ORA-00600 arguments are differents.
- Initial release.
Features
This is the list of features that currently OraAlertCheck supports:
- Parse "^ORA-NNNNN" errors and send emails depending on the severity of the error (this will be enhanced as other DBAs contribute with more and more errors).
- If the errors are on the errors list the alert will provide more information (example: if potential bug then sends a reference to the proper metalink notes).
- Errors can be costomized accordingly to db version.
- Only uses korn shell and basic commands like df, compress, tail, cat, echo, etc., so it should be very portable between *nix platforms, as well as Windows using Cygwin.
- Automatic alert.log truncation
- Sends first and second parameters in ORA-00600 and ORA-07445 internal errors.
Saturday, February 12, 2005
Quick Howto
Download the latest release and uncompress on your unix oracle account home directory. Put all the files in the same directory (/home/oracle/OraAlertCheck for example).
Rename OraAlertCheck_config.sh.sample to OraAlertCheck_config.sh. Edit the file and change the variables to suit your needs. It's important to set the WORKDIR to where the scripts are located.
OraAlertCheck look for your instances on /etc/oratab by default, so if this does not exists you should create it or link it to the real path.
Check to see if the script can find your alert.log files running:
$ ./OraAlertCheck.sh test
You should see the ORACLE_SID followed by the alert.log path. If you can't and you discover a bug in the program, let me know, if it does then skip to the next paragraph. The script connects to the database "/ as sysdba" to get the value of the background_dump_dest parameter (where alert_SID.log file should be). Sometimes this parameter has characters like "?" to indicate the ORACLE_HOME. Be sure to have the full path there.
Now that the log file was found you can run the script with no parameters. NOTE: Since it's the first time, it will run through all your log file and email you with a lot of errors. The script will generate a hidden file where it will set the current line number so next time it will start just where it finished.
If all worked fine, you can add the script to your crontab, every five minutes should be fine.
The script needs some work yet so please don't hesitate to send me your opinions.
NOTE: We need your help!!! In order to develop a good error detection we need every DBA using this script to send new errors that the script does not have. So please send us every error you find! You can email me to newalertlogerrors (at) jluis.com.ar
Rename OraAlertCheck_config.sh.sample to OraAlertCheck_config.sh. Edit the file and change the variables to suit your needs. It's important to set the WORKDIR to where the scripts are located.
OraAlertCheck look for your instances on /etc/oratab by default, so if this does not exists you should create it or link it to the real path.
Check to see if the script can find your alert.log files running:
$ ./OraAlertCheck.sh test
You should see the ORACLE_SID followed by the alert.log path. If you can't and you discover a bug in the program, let me know, if it does then skip to the next paragraph. The script connects to the database "/ as sysdba" to get the value of the background_dump_dest parameter (where alert_SID.log file should be). Sometimes this parameter has characters like "?" to indicate the ORACLE_HOME. Be sure to have the full path there.
Now that the log file was found you can run the script with no parameters. NOTE: Since it's the first time, it will run through all your log file and email you with a lot of errors. The script will generate a hidden file where it will set the current line number so next time it will start just where it finished.
If all worked fine, you can add the script to your crontab, every five minutes should be fine.
The script needs some work yet so please don't hesitate to send me your opinions.
NOTE: We need your help!!! In order to develop a good error detection we need every DBA using this script to send new errors that the script does not have. So please send us every error you find! You can email me to newalertlogerrors (at) jluis.com.ar
Why Korn shell??
I've choose korn shell becouse it's considered the "standard" shell of Unix, and it's available by default on most *nix systems, so no extra things needs to be installed on your server.
Friday, February 11, 2005
OraAlertCheck 0.1 is out!
Well, today I decide to get these scripts out. There are three files, you should only edit the config file and rename it. Put it in /etc or /home/user/etc. The other two can go anywhere, but be sure to complete the right parameters in the config file.
You can use it from the crontab by calling the main script. You can add a "test" parameter in the call to see which instances it has detected and where the alert log will be search. Instance detection is done through /etc/oratab.
Still they need some work, but they are functional. I've been testing it on HP-UX and Oracle 8.0.5, but it should work on any kourne shell *nix.
You can use it from the crontab by calling the main script. You can add a "test" parameter in the call to see which instances it has detected and where the alert log will be search. Instance detection is done through /etc/oratab.
Still they need some work, but they are functional. I've been testing it on HP-UX and Oracle 8.0.5, but it should work on any kourne shell *nix.
Subscribe to:
Posts (Atom)