Re: LogMiner SESSION_INFO is empty

From: andreik <spamme.andreik_at_gmail.com>
Date: Thu, 18 Mar 2010 08:02:14 -0700 (PDT)
Message-ID: <e01ffe6f-960f-4d9d-b9cd-f1457b3b6e5b_at_e1g2000yqh.googlegroups.com>



On Mar 18, 3:52 pm, ddf <orat..._at_msn.com> wrote:
> On Mar 18, 6:19 am, andreik <spamme.andr..._at_gmail.com> wrote:
>
>
>
> > On Mar 17, 6:30 pm, ddf <orat..._at_msn.com> wrote:
>
> > > 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
>
> > 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. Received on Thu Mar 18 2010 - 10:02:14 CDT

Original text of this message