Who issued ALTER DATABASE RECOVER

[NDT]

Originally posted by marist89

Originally posted by Mr.Hanky

Hire honest employees, I would have told you ASAP.

If it IS one of my DBA's, I might have an opening soon ...

Maybe it's a honest mistake, maybe someone accidently run a b&r shellscript which would trigger that command.

[marist89]

Originally posted by np70
Jeff,

listener.log will tell you which machine and time request came from (if it was different machine).

All the entries in listener.log have been accounted for. They all had a purpose and can be explained.

[marist89]

Originally posted by NDT

Maybe it's a honest mistake, maybe someone accidently run a b&r shellscript which would trigger that command.

I agree it's a mistake. I want to find out WHO so I can make them an honest person.

[maachan]

If this was issued from OS, then do

last | more

at OS prompt

You can see what was logged on from what IP address at what time.

That might help to narrow it down some.

[Mr.Hanky]

Ted Night, Caddyshack.

"WELL, WE'RE WAITING"

What's the deal, did you find the cause of this error.

MH

[marist89]

Originally posted by maachan
If this was issued from OS, then do

last | more

at OS prompt

You can see what was logged on from what IP address at what time.

That might help to narrow it down some.

last only shows who was logged on and not what commands they ran. There was nobody logged in to the box at the time. I would need lastcomm to show me which commands were executed, but that relies on OS accounting to be turned on.

[marist89]

Originally posted by Mr.Hanky

What's the deal, did you find the cause of this error.

Still investigating. I have my suspects, but no evidence yet.

[sln81]

can you use the PARSING_USER_ID column in the V$SQLAREA and get some result?

[jmodic]

Originally posted by sln81
can you use the PARSING_USER_ID column in the V$SQLAREA and get some result?

The parsing of that statement obviously failed (insufficient privileges ORA error), so that particular statement was realy never put in the library cache. So looking for it in V$SQLAREA is useless, IMHO.

[marist89]

It was actually in v$sqlarea with the correct timestamp, but since the parsing failed, I don't think the PARSING_USER_ID or PARSING_SCHEMA_ID are reliable (they both indicate SYS did the parsing but SYS would have privs...)