Alert Log Monitoring / Notification
Charles Davis
I would like to be notified almost immediately if Oracle 9.2 writes certain
messages to the Alert Log, such as any of the 'unable to extend' messages.
An email sent at the moment of the error would be best.
Can this be done somehow within Oracle v9.2?? If so, please describe it or
point me to the docs on this.
I already have an external alert log monitor process, but am looking for
something more immediate that its polling interval.
Many thanks.
charles
Brian Peasland
Instead of reinventing the wheel, why not look into Oracle Enterprise
Manager's Alerts???? It should do the trick.
HTH,
Brian
Daniel Morgan
Capture the alert log as an external table or read it with UTL_FILE.
Then have DBMS_JOB check it from time-to-time an fire of the email
using UTL_SMTP.
--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damo...@x.washington.edu
(replace 'x' with a 'u' to reply)
Yong Huang
Hi, Charles,
You can use the tail -f method to achieve this. Look at "How to get
alert by reading log files" here
http://rootshell.be/~yong321/computer/logfile.html
Yong Huang
Burt Peltier
- on first run, just copy alert.log to a different file
- on subsequent runs, do the following...
- run the Unix diff command on the copy and the current alert.logs
- process the diff command output and strip out "ok messages"
- email the rest (not ok) messages
- before copying the log to the different file, check the size and if
gettting too large (100K, 10K, whatever)
- if the file is getting too large, copy it off to another location for
archiving and zero out the current log file by doing command
- cat /dev/null > alert_SID.log
By keeping the size of the alert.log small, you can run the above script
very often and not even notice it.
We run with the max size to check for of 100K and have not had any problems
running every 5 minutes 7x24.
You may want to make the maxsize 24K and run every 1 or 2 minutes.
Obviously, test test test the above ....
Note: A nice thing about the above is when the server/machine reboots, you
don't loose a thing in monitoring the alert.log.
--
"Charles Davis" <cdavi...@comcast.net> wrote in message
news:Y_ydnUWWlpL...@comcast.com...
Niall Litchfield
ALERT.LOG
I'm not sure that relying on email for almost instantaneous notification is
necessarily as reliable as the OP thinks.
--
Niall Litchfield
Oracle DBA
Audit Commission UK
"Daniel Morgan" <damo...@x.washington.edu> wrote in message
news:1078788261.888269@yasure...
Burt Peltier
We have an internal paging system that sends text pages to pagers/beepers.
This has been more reliable for a quicker response.
But, in our new global environment, the quicker internal paging system is
being dropped for standardizing on Email for such things.
The potentially slower response of Email is considered "less important" when
compared to the huge pennies we are going to save :)
--
"Niall Litchfield" <n-litc...@audit-commission.gov.uk> wrote in message
news:404d9b6b$0$22402$ed9e...@reading.news.pipex.net...
Niall Litchfield
OEM envisages paging the dba, but not sending an SMS.
--
Niall Litchfield
Oracle DBA
Audit Commission UK
"Burt Peltier" <burttemp1...@bellsouth.net> wrote in message
news:JGj3c.33444$JN2....@bignews4.bellsouth.net...
Glen A Stromquist
> I agree about the Email not being reliable for instantaneous notification.
>
> We have an internal paging system that sends text pages to pagers/beepers.
> This has been more reliable for a quicker response.
>
> But, in our new global environment, the quicker internal paging system is
> being dropped for standardizing on Email for such things.
>
> The potentially slower response of Email is considered "less important" when
> compared to the huge pennies we are going to save :)
>
I use OEM to alert via e-mail for certain things, which then gets
forwarded to my cellphone e-mail, and it is usually, but not always
instantaneous in sending the e-mail. I can't recall any time that it was
held up in the internal e-mail, but I have received the messages hours
late on my cell at times, but I attributed that to the less than ideal
digital coverage in my area...
Brian Peasland
> forwarded to my cellphone e-mail, and it is usually, but not always
> instantaneous in sending the e-mail. I can't recall any time that it was
> held up in the internal e-mail, but I have received the messages hours
> late on my cell at times, but I attributed that to the less than ideal
> digital coverage in my area...
Why not email directly to your phone then? You could even set up OEM to
email your work account during the day and your phone during off hours,
for example.
Cheers,
Brian
Glen A Stromquist
Tried that, but the way our internal e-mail is set up it wouldnt work,
so I had to get our exchange guru to set up a separate e-mail called
oralert (or something like that) and have any e-mails coming to that
account auto forwarded to an outside smtp account. It would not work
with my regular internal e-mail address, but I can't remember exactly
why now...
I'd have to say for the most part this works very well, when I shut an
instance down often within seconds my phone beeps indicating a message,
but sometimes it wont arrive until much later, but I blame that on the
telco as the same thing happens with voicemail from time to time.
I'm waiting until blackberry coverage gets a bit better up here,
thinking that the e-mails will be much easier to read than scrolling
thru in the tiny cellphone display.
cheers
GAS
Ana C. Dent
On Solaris 9 if the system load exceeds a certain value,
sendmail decides to stay dormant until after the load
decreases sufficiently. It can take HOURS before a "warning"
message actually gets sent/delivered. :-(
I know this from first hand experience.
Burt Peltier
I wonder if Oracle calls to utl_smtp would work?
--
"Ana C. Dent" <anac...@hotmail.com> wrote in message
news:lxP3c.16628$BA.14445@fed1read03...
Ana C. Dent
> Well, that is a "nice feature".
>
> I wonder if Oracle calls to utl_smtp would work?
Define "work".
UTL_SMTP simply delivers the message to the MTA (a.k.a. sendmail);
where the messages sits until sendmail decides that it is OK to
deliver it to the client.
Burt Peltier
to deliver the message to. So, if you use some other "smtp capable" server
to pass the email to, it might work where sendmail would fail.
In our company intranet, all Unix machines send sendmail mail to "localhost"
and it then gets routed to a central smtp server . So, if it is possible to
bypass "localhost" and localhost was the problem, this might fix the
problem?
--
"Ana C. Dent" <anac...@hotmail.com> wrote in message
news:7J74c.22337$BA.14976@fed1read03...
Niall Litchfield
> Not sure about sendmail, but I know utl_smtp has to specify the smtp
server
> to deliver the message to. So, if you use some other "smtp capable" server
> to pass the email to, it might work where sendmail would fail.
>
> In our company intranet, all Unix machines send sendmail mail to
"localhost"
> and it then gets routed to a central smtp server . So, if it is possible
to
> bypass "localhost" and localhost was the problem, this might fix the
> problem?
and what if the central server was 'the problem'.
To me the base issue is that email is not designed to be a real-time system.
it is designed around retries, comms failures etc. Instead it is best to
thing of email as a 'real-enough' time system, you should get mail
reasonably promptly. If you really, really need alerts guaranteed in seconds
email is not the medium of choice. Of course there is also the prossibility
that if the system is so critical to the business that low second alert time
is required, it is probably the case that you will get low second response
time via the end-user/work telephone interface :(
Ana C. Dent
Burt Peltier wrote:
> Not sure about sendmail, but I know utl_smtp has to specify the smtp server
> to deliver the message to. So, if you use some other "smtp capable" server
> to pass the email to, it might work where sendmail would fail.
>
> In our company intranet, all Unix machines send sendmail mail to "localhost"
> and it then gets routed to a central smtp server . So, if it is possible to
> bypass "localhost" and localhost was the problem, this might fix the
> problem?
>
Of course all of the above is possible, but still there is NO
guarantee of (timely?) delivery. What happens if/when the "other"
system is down, unavailable or otherwise VERY busy?
I was just warning that I know from 1st hand experience that
email ALERT messages do not always get promptly delivered.
Exactly how you decide to best deal with reality is between you
and your boss. You've been warned.
Paul Drake
this is my biggest problem with *nix users.
they think that they _have_ to have a local MTA configured, on their
local machine. send SMTP client messages to a mail server that is
properly configured, and don't make the network admins maintain a
freaking Sendmail server on every host on their network.
Pd
Burt Peltier
the posts I post.
I stated above in an earlier post that I agree email is not reliable for
instant notification.
Also, when I search google group archives, it seems to me that posting at
the top is better than having to read posting at the bottom.
So, why is posting at the top soooo bad?
--
"Ana C. Dent" <anac...@hotmail.com> wrote in message
news:YLt4c.22760$BA.21327@fed1read03...
Eric Parker
> Also, when I search google group archives, it seems to me that posting at
> the top is better than having to read posting at the bottom.
>
> So, why is posting at the top soooo bad?
>
Burt
IMO posting at the top is not soooo bad, but it is logical to read a
conversation from
top to bottom - rather than read in sections from bottom to top.
The google archives thing is a constant pain to me especially the ones
without any
of the new posters text. I keep hoping that google will think up something
clever here -
like starting their visible selection with the start of the new poster's
text.
I thought about putting these comments in-line just to be different (but
didn't).
eric
--
Remove the dross to contact me directly
Mark
I've had the exact same thing happen to me. Inside our script, we had
to monitor the mail queue with '/usr/lib/sendmail -bp'. If the local
mail queue was backed up, we sent the message from a different server.
Mark Simmons
Sr. Oracle DBA
Sabre-Holdings, Southlake, TX
"Ana C. Dent" <anac...@hotmail.com> wrote in message news:<lxP3c.16628$BA.14445@fed1read03>...