On Apr 20, 9:06 pm, hpuxrac <johnbhur..._at_sbcglobal.net> wrote:
> On Apr 20, 8:13 am, BicycleRepairman <engel.ke..._at_gmail.com> wrote:
>
>
>
> > On Apr 20, 2:02 am, haiwu..._at_gmail.com wrote:
>
> > > On Apr 19, 6:25 pm, hpuxrac <johnbhur..._at_sbcglobal.net> wrote:
>
> > > > On Apr 19, 7:19 pm, haiwu..._at_gmail.com wrote:
>
> > > > > On Apr 16, 12:31 am, Digeratus 2006
>
> > > > > <digeratus2..._at_nospam.hotmaildotcom> wrote:
> > > > > > This looks like it is is a connect / as sysdba which is always audited.
> > > > > > I think that kind of connect can only come from the Linux database
> > > > > > server. You might be able to identify the Linux process by listing all
> > > > > > processes owned by oracle and trying to match it with the pid in the
> > > > > > .aud file. In HPUX, this is
> > > > > > ps -ef|grep oracle
>
> > > > > > HTH,
> > > > > > Andy Young
>
> > > > > > haiwu..._at_gmail.com wrote in news:1176503310.079589.89440
> > > > > > @w1g2000hsg.googlegroups.com:
>
> > > > > > > This is Oracle10g RAC, and there are lots of audit log files created
> > > > > > > by default under $ORACLE_HOME/rdbms/audit folder, they got created
> > > > > > > every one or two second(s) on each node, for each database instance
> > > > > > > running on this RAC.
>
> > > > > > > The following is one entry. As you can see, it does not have "CLIENT
> > > > > > > TERMINAL" information, and I don't know how to track this to find out
> > > > > > > which processes or application or background process is causing this
> > > > > > > sys login, so frequently.
>
> > > > > > > Any ideas?
> > > > > > > Thanks,
> > > > > > > Hai
>
> > > > > > > Audit file /home/oracle/app/product/10.1.0.4/rdbms/audit/ora_17242.aud
> > > > > > > Oracle Database 10g Enterprise Edition Release 10.1.0.4.2 - Production
> > > > > > > With the Partitioning, Real Application Clusters, OLAP and Data Mining
> > > > > > > options
> > > > > > > ORACLE_HOME = /home/oracle/app/product/10.1.0.4
> > > > > > > System name: Linux
> > > > > > > Node name: wpprddb1
> > > > > > > Release: 2.4.21-37.ELsmp
> > > > > > > Version: #1 SMP Wed Sep 7 13:28:55 EDT 2005
> > > > > > > Machine: i686
> > > > > > > Instance name: oid1
> > > > > > > Redo thread mounted by this instance: 1
> > > > > > > Oracle process number: 26
> > > > > > > Unix process pid: 17242, image: oracle_at_wpprddb1 (TNS V1-V3)
>
> > > > > > > Fri Apr 13 17:25:06 2007
> > > > > > > ACTION : 'CONNECT'
> > > > > > > DATABASE USER: '/'
> > > > > > > PRIVILEGE : SYSDBA
> > > > > > > CLIENT USER: oracle
> > > > > > > CLIENT TERMINAL:
> > > > > > > STATUS: 0- Hide quoted text -
>
> > > > > > - Show quoted text -
>
> > > > > The connection were done so fast, it is not possible for me to capture
> > > > > it.- Hide quoted text -
>
> > > > > - Show quoted text -
>
> > > > That's why I suggested using an after logon database trigger ... have
> > > > it enabled for just a brief period of time.
>
> > > > There's no way for a connection request to escape from the ater logon
> > > > trigger.
>
> > > I've been thinking about it, but I am not sure if the information the
> > > logon trigger captures would be helpful or not ...
>
> > And it would be dangerous as well -- the reason SYSDBA logins are
> > audited to a file rather than the DB is that you want to be able to
> > login to the DB as sysdba and fix a startup/mounting/disk error - type
> > problem. I don't know what type of process is causing the SYS
> > connections (some sort of RAC heartbeat connection?), but the behavior
> > doesn't sound like a bug to me...- Hide quoted text -
>
> > - Show quoted text -
>
> Activating for a brief period of time an after logon trigger that is
> looking for sysdba logins to gain extra information that the OP hasn't
> been able to obtain to date is "dangerous as well" exactly how?
>
> And your helpfule advice "I don't know what type of process is
> causing ..."
tell you what -- why don't you set one up in your production
environment -- then delete a datafile -- and tell us whether you can
connect as sysdba in order to recover the database. If you can, then
setting one up is merely dangerous. If you can't, it's more like
fatal.
Have fun.
Received on Fri Apr 20 2007 - 23:08:05 CDT
