Re: LogMiner SESSION_INFO is empty
From: ddf <oratune_at_msn.com>
Date: Wed, 17 Mar 2010 10:30:28 -0700 (PDT)
Message-ID: <5d523d9e-4d0d-49f2-b8d4-91fc54b4fbbc_at_g1g2000pre.googlegroups.com>
On Mar 17, 9:32 am, andreik <spamme.andr..._at_gmail.com> wrote:
> On Mar 17, 1:54 pm, ddf <orat..._at_msn.com> wrote:
>
>
>
>
>
> > On Mar 17, 7:52 am, andreik <spamme.andr..._at_gmail.com> wrote:
>
> > > On Mar 16, 6:17 pm, ddf <orat..._at_msn.com> wrote:
>
> > > > On Mar 16, 12:10 pm, andreik <spamme.andr..._at_gmail.com> wrote:
>
> > > > > On Mar 16, 5:01 pm, ddf <orat..._at_msn.com> wrote:
>
> > > > > > On Mar 16, 11:33 am, andreik <spamme.andr..._at_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 -
Date: Wed, 17 Mar 2010 10:30:28 -0700 (PDT)
Message-ID: <5d523d9e-4d0d-49f2-b8d4-91fc54b4fbbc_at_g1g2000pre.googlegroups.com>
On Mar 17, 9:32 am, andreik <spamme.andr..._at_gmail.com> wrote:
> On Mar 17, 1:54 pm, ddf <orat..._at_msn.com> wrote:
>
>
>
>
>
> > On Mar 17, 7:52 am, andreik <spamme.andr..._at_gmail.com> wrote:
>
> > > On Mar 16, 6:17 pm, ddf <orat..._at_msn.com> wrote:
>
> > > > On Mar 16, 12:10 pm, andreik <spamme.andr..._at_gmail.com> wrote:
>
> > > > > On Mar 16, 5:01 pm, ddf <orat..._at_msn.com> wrote:
>
> > > > > > On Mar 16, 11:33 am, andreik <spamme.andr..._at_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 Received on Wed Mar 17 2010 - 12:30:28 CDT