LogMiner SESSION_INFO is empty
in [Oracle]
|
Prev: how to know the internal representation of a column of clob type
Next: To use Oracle 10g R2 on Linux which distribution?
From: ddf on 18 Mar 2010 10:52 On Mar 18, 6:19 am, andreik <spamme.andr...(a)gmail.com> wrote: > On Mar 17, 6:30 pm, ddf <orat...(a)msn.com> wrote: > > > > > > > On Mar 17, 9:32 am, andreik <spamme.andr...(a)gmail.com> wrote: > > > > On Mar 17, 1:54 pm, ddf <orat...(a)msn.com> wrote: > > > > > On Mar 17, 7:52 am, andreik <spamme.andr...(a)gmail.com> wrote: > > > > > > On Mar 16, 6:17 pm, ddf <orat...(a)msn.com> wrote: > > > > > > > On Mar 16, 12:10 pm, andreik <spamme.andr...(a)gmail.com> wrote: > > > > > > > > On Mar 16, 5:01 pm, ddf <orat...(a)msn.com> wrote: > > > > > > > > > On Mar 16, 11:33 am, andreik <spamme.andr...(a)gmail.com> wrote: > > > > > > > > > > Hi all, > > > > > > > > > > I'm trying to investigate a table drop using LogMiner. > > > > > > > > > > I can locate the needed SCN and can see the 'DROP' command in V > > > > > > > > > $LOGMNR_CONTENTS along with some internal stuff in one transaction. > > > > > > > > > But for some reason SESSION_INFO is missing for that transacation! > > > > > > > > > Next transaction already comes with session_info. Also when I do a > > > > > > > > > test drop now on the same database, I can nicely see myself in the > > > > > > > > > SESSION_INFO. But for that old transaction SESSION_INFO is not > > > > > > > > > displayed. > > > > > > > > > > Anyone has an idea how can I have SESSION_INFO retrieved for that > > > > > > > > > transaction? > > > > > > > > > > 10.2.0.1 on Solaris 64bit > > > > > > > > > > thanks > > > > > > > > > SESSION_INFO isn't available for that transaction else you'd see it > > > > > > > > displayed. > > > > > > > > > David Fitzjarrell > > > > > > > > so this is normal that session_info does not always get logged into > > > > > > > redo? > > > > > > > what does it depend on? > > > > > > > is this mentioned somewhere in the documentation? I couldn't find > > > > > > > anything like that.- Hide quoted text - > > > > > > > > - Show quoted text - > > > > > > > Presumsing you have a valid support contract you should read Metalink > > > > > > document 110301.1. Since you're running an unpatched 10.2.0.1 > > > > > > installation you may not be in possession of a valid CSI so reading > > > > > > that document may not be possible. > > > > > > > David Fitzjarrell > > > > > > I've already read that document. It doesn't help. Supplemental loggin > > > > > is also not the case, bacause the transaction which follows already > > > > > has the session_info and when I drop a test table I can see my traces > > > > > there as well. > > > > > Anyway, looks like no one is actually aware of how the session_info is > > > > > retrieved... I guess I'll just have to accept that oracle is a goofy > > > > > database :) > > > > > Thanks.- Hide quoted text - > > > > > > - Show quoted text - > > > > > then you haven't read that document fully as it states SESSION_INFO > > > > may be set for a series of transactions in a prior redo or archive log > > > > that you have NOT loaded. Please read item 2. under 'Explanations' > > > > again and again until you understand it as this is likely the cause of > > > > your 'problem'. > > > > > David Fitzjarrell > > > > I can see in the session audit a session connecting just a second > > > before the drops came and disconnected right after the last drop was > > > done. That's exactly how TOAD is doing it: connecting a new session, > > > drops tables and disconnects (I tested it). So the session information > > > must be in the same log.- Hide quoted text - > > > > - Show quoted text - > > > Are you running shared server with connection pooling? > > > David Fitzjarrell > > no, dedicated server only- Hide quoted text - > > - Show quoted text - You haven't patched this to 10.2.0.4 for what reason? 10.2.0.1 is rather 'buggy'. David Fitzjarrell
From: andreik on 18 Mar 2010 11:02
On Mar 18, 3:52 pm, ddf <orat...(a)msn.com> wrote: > On Mar 18, 6:19 am, andreik <spamme.andr...(a)gmail.com> wrote: > > > > > On Mar 17, 6:30 pm, ddf <orat...(a)msn.com> wrote: > > > > On Mar 17, 9:32 am, andreik <spamme.andr...(a)gmail.com> wrote: > > > > > On Mar 17, 1:54 pm, ddf <orat...(a)msn.com> wrote: > > > > > > On Mar 17, 7:52 am, andreik <spamme.andr...(a)gmail.com> wrote: > > > > > > > On Mar 16, 6:17 pm, ddf <orat...(a)msn.com> wrote: > > > > > > > > On Mar 16, 12:10 pm, andreik <spamme.andr...(a)gmail.com> wrote: > > > > > > > > > On Mar 16, 5:01 pm, ddf <orat...(a)msn.com> wrote: > > > > > > > > > > On Mar 16, 11:33 am, andreik <spamme.andr...(a)gmail.com> wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > I'm trying to investigate a table drop using LogMiner. > > > > > > > > > > > I can locate the needed SCN and can see the 'DROP' command in V > > > > > > > > > > $LOGMNR_CONTENTS along with some internal stuff in one transaction. > > > > > > > > > > But for some reason SESSION_INFO is missing for that transacation! > > > > > > > > > > Next transaction already comes with session_info. Also when I do a > > > > > > > > > > test drop now on the same database, I can nicely see myself in the > > > > > > > > > > SESSION_INFO. But for that old transaction SESSION_INFO is not > > > > > > > > > > displayed. > > > > > > > > > > > Anyone has an idea how can I have SESSION_INFO retrieved for that > > > > > > > > > > transaction? > > > > > > > > > > > 10.2.0.1 on Solaris 64bit > > > > > > > > > > > thanks > > > > > > > > > > SESSION_INFO isn't available for that transaction else you'd see it > > > > > > > > > displayed. > > > > > > > > > > David Fitzjarrell > > > > > > > > > so this is normal that session_info does not always get logged into > > > > > > > > redo? > > > > > > > > what does it depend on? > > > > > > > > is this mentioned somewhere in the documentation? I couldn't find > > > > > > > > anything like that.- Hide quoted text - > > > > > > > > > - Show quoted text - > > > > > > > > Presumsing you have a valid support contract you should read Metalink > > > > > > > document 110301.1. Since you're running an unpatched 10.2.0.1 > > > > > > > installation you may not be in possession of a valid CSI so reading > > > > > > > that document may not be possible. > > > > > > > > David Fitzjarrell > > > > > > > I've already read that document. It doesn't help. Supplemental loggin > > > > > > is also not the case, bacause the transaction which follows already > > > > > > has the session_info and when I drop a test table I can see my traces > > > > > > there as well. > > > > > > Anyway, looks like no one is actually aware of how the session_info is > > > > > > retrieved... I guess I'll just have to accept that oracle is a goofy > > > > > > database :) > > > > > > Thanks.- Hide quoted text - > > > > > > > - Show quoted text - > > > > > > then you haven't read that document fully as it states SESSION_INFO > > > > > may be set for a series of transactions in a prior redo or archive log > > > > > that you have NOT loaded. Please read item 2. under 'Explanations' > > > > > again and again until you understand it as this is likely the cause of > > > > > your 'problem'. > > > > > > David Fitzjarrell > > > > > I can see in the session audit a session connecting just a second > > > > before the drops came and disconnected right after the last drop was > > > > done. That's exactly how TOAD is doing it: connecting a new session, > > > > drops tables and disconnects (I tested it). So the session information > > > > must be in the same log.- Hide quoted text - > > > > > - Show quoted text - > > > > Are you running shared server with connection pooling? > > > > David Fitzjarrell > > > no, dedicated server only- Hide quoted text - > > > - Show quoted text - > > You haven't patched this to 10.2.0.4 for what reason? 10.2.0.1 is > rather 'buggy'. > > David Fitzjarrell bad planning and lack of resources I guess... anyway, thanks for your help. I guess I'll have to give up on this one. |