05-01-2008 12:33 PM
After all the research I’ve done, this should not be problem. The command is SET AUDIT/SERVER=EXIT. Do I need to stop anything else?
Can I execute the command through SYSMAN after setting environment/cluster? Can I start the audit server in SYSMAN too?
I want piece of mind that I do need to shutdown another process and that this will not cause a problem when I start the audit server again
Solved! Go to Solution.
05-01-2008 01:06 PM
A thread was on that exact topic
See particularly what John Gillings says, and the procedure he posted.
05-01-2008 01:46 PM
Thanks for your vote of confidence, but I don't think that's Lucie's real problem.
If you've already disabled the alarms, stopping the audit server won't stop the flood of messages - they've already been sent, they're just queued up on the way to being displayed by OPCOM. There are several places that queues of messages can form, and they can be exceptionally long.
Your problem is usually due to the very slow speed of OPA0. A very short action can generate numerous alarms, but they can take a relatively long time to display. If you've turned off the source, you may be able to just leave the system overnight to catch up.
It may be quicker to REPLY/DISABLE until the flood has drained. If there's a process logged in on OPA0 just type the command blind and wait a few minutes to see if the messages settle. If there is no process logged in, you can do it remotely with:
$ DEFINE/USER SYS$COMMAND OPA0:
Since some types of audit can generate large numbers of messages, it's usually best to turn on AUDITs only for a short period, then analyze the audit journal to determine the level of traffic.
$ SET AUDIT/AUDIT/ENABLE=(whatever)
(wait a minute or so)
$ SET AUDIT/AUDIT/DISABLE=(same)
Now look at the size of the output file to see how many audits you got, and what type.
Enabling ALARMs is fine, but take into account the real output speed of your console. Maybe turn off SECURITY alarms on OPA0 to and use a terminal window instead.