Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: constant monitoring and enqueues?

Re: constant monitoring and enqueues?

From: <hailey_kyle_at_my-deja.com>
Date: Tue, 16 Jan 2001 23:47:39 GMT
Message-ID: <942mio$kig$1@nnrp1.deja.com>

   Cool, I hadn't looked into this. For other people's edification, if they want to use this stuff the can join x$kqfco(kqfcotab) with x$kqfta (indx) to get the table names along with those column names and sizes from x$kqfco(kqfcosiz)

Just curious, you might be able to help with this one because it sounds like you are pretty well informed. Do you know how to use the "file name" (second arg, ie x$ksled(ksledp2) ) from the wait event "file identify" to actually get the file?

Best
Kyle

In article <979377212.22702.0.nnrp-09.9e984b29_at_news.demon.co.uk>,   "Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote:
>
> Very interesting post.
>
> You do get a bit more help though, since x$kqfco
> gives codes for the internal and external representations
> of the columns, so you don't have to rely on the column
> types in 'desc X$TABLE' to make guesses about the
> actual fields - although your comment about hidden
> structues is obviously a dire warning.
>
> --
> Jonathan Lewis
> Yet another Oracle-related web site: http://www.jlcomp.demon.co.uk
>
> Practical Oracle 8i: Building Efficient Databases
>
> Publishers: Addison-Wesley
> See a first review at:
> http://www.ixora.com.au/resources/index.htm#practical_8i
> More reviews at: http://www.jlcomp.demon.co.uk/book_rev.html
>
> hailey_kyle_at_my-deja.com wrote in message <93njfh$rb6
 $1_at_nnrp1.deja.com>...
> >permissions. Anyway it's hardly worth doing for most people unless
 you
> >are a firefighter and that is all you do. Without knowledge of the
> >underlying C structure we don't know the widths of the fields in the
> >structure. Oracle often packs alot of bit flags into the same C-code
> >integer variable, but a describe of the X$table doesn't say they are
> >bit fields; it says they are numbers. So if we start at address X for
> >field A, which is actually a bit value, and then try to find field B
> >which is also a bit value, assuming we skip a byte to find the
> >next "number" we have gone too far since A and B are bit values and
> >only 1 bit wide, so B is at X+1 not X+8. It gets all the more
> >complicated with pointers and longs and characters and 64 bit
> >archictecture etc, but of course if we have access to the source this
> >is easy.
>
>

Sent via Deja.com
http://www.deja.com/ Received on Tue Jan 16 2001 - 17:47:39 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US