The original problem:
>We have a client-side process which is causing massive core dumps
>through Oracle. We have been able to identify the process ids causing
>the dumps, but by the time we get the ids the processes are gone from
>the system. Is there any log (or logging that could be turned on)
>that records PID information?
My thanks to all who replied!
Summary of solutions:
You may configure auditing to capture PID's and process
information. The "object selection" mode may be most helpful.
It allows you to specify exactly what executables or user id's
to monitor.
Alan Davis
Digital Unix Consultant
Compaq's cpcunix data collecor will give a a pid breakdown. Works on
Unix 4.0d (unlike polycenter)
Paul O'SULLIVAN
If you have process accounting turned on, you might be able to get the
info you need using the "acctcom" command.
Tom Ackenhusen
Fermi National Accelerator Laboratory
And
J.James(Jim)Belonis II, U of Washington Physics Computer Cost Center
Manager
belonis_at_phys.washington.edu
Put a series of "ps auxww >file.N " commands into a crontab at frequent
intervals. Since you'll have a fixed number of these, you won't have a
problem w/the file growing on you. You just need to be sure you
retrieve the data before it gets overwritten.
There may be a more elegant solution, but this is quick and easy to
implement.
Good luck!
Reg Beardsley
rhb_at_acm.org
And
Ron Bowman
Techno-Sciences, Inc.
rdbowma_at_tsi.clemson.edu
Oracle will output information to "trace" files based on setting for the
Oracle instance "init<SID>.ora" file. These files along with the
<SID>alert.trc file should give you some indication as to what is going
on. Here are some of the "init<SID>.ora file parameters that I have set:
# define directories to store trace and alert files
background_dump_dest = /xxx/trace
user_dump_dest = /xxx/trace
sql_trace = true
Be careful with the "sql_trace" parameter because it forces all
connections
to generate a trace file.
Goebel, Greg [ggoebel_at_grci.com]
The audit tool with enhanced security does record pid.
Do not just arbitrarily enable audit... default is everything which
will rapidly fill your var space and default is to freeze the system
when it can no longer audit. Plan some space and which events
you wish to enable. Some examples are included within:
ftp://raven.alaska.edu/pub/sois/README.uaio
kit:
ftp://raven.alaska.edu/pub/sois/uaio-v2.1a.tar.Z
Under examples/audit*.... the audit data can be useful for a number
of purposes. The large oracle dumps can be significant problems...
not just for space but for IO load on the system
Kurt Carlson University of Alaska, ARSC
mailto:snkac_at_java.sois.alaska.edu
Received on Mon Jan 25 1999 - 17:40:37 NZDT