May 22: Direct Path Reads

After one of my Hotsos Presentations, I had a discussion with one of the delegates about how his site used parallel execution for some jobs purely to take advantage of Direct Path Reads. He suggested that he thought that was why the parallel 2 tests I ran were always significantly faster than serial. I spoke to a couple of people about this and wondered how I could test it, until Jonathan Lewis pointed out the _serial_direct_read hidden parameter. The reason those last two words are in italics is that you shouldn't set the values of hidden parameters without discussing it with support. You have been warned ;-)


As I don't run my business on my server at home, it' s safe for me to test (now that I've bitten the bullet and run a cable down to the server room - it's the first decent playtime I've had for ages). Based on a simple test of a full table-scan on a 3-disk software RAID array, there was a small improvement, but I'm not sure it justifies switching to Direct Path Reads except where Oracle would normally use them anyway.


I ran the tests multiples times, immediately after startup to pick up any timing variations, but the timings were pretty stable. I also looked through raw trace files to check that everything looked as expected.


_serial_direct_read = false - average of 6 minutes
_serial_direct_read = true - average of 5 minutes 15 seconds


So direct path was about 10-15% quicker for this very basic full scan of a 9Gb / 65 million row table on my particular configuration


Updated 23rd May


Based on comments from Alex and Jonathan, I thought it might be worth adding snippets of the first few trace lines for direct and non-direct i/o. So you can blame them for the longer post ;-) I also had to re-run the tests because some other tests I'd been running overnight had deleted the existing trace files :-(

First the non-direct path version.

PARSING IN CURSOR #1 len=59 dep=0 uid=27 oct=3 lid=27 tim=1121447319073032 
hv=819013003 ad='7931a52c' 
select /*+ noparallel(test_tab1) */ count(*) from test_tab1
END OF STMT
PARSE #1:c=258960,e=282301,p=30,cr=490,cu=0,mis=1,r=0,dep=0,og=1,tim=1121447319073015
EXEC #1:c=1000,e=120,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1121447319073424
WAIT #1: nam='SQL*Net message to client' ela= 5 driver id=1650815232 #bytes=1 p3=0 
obj#=10321 tim=1121447319073538
WAIT #1: nam='db file sequential read' ela= 261 file#=6 block#=9 blocks=1 obj#=10645 tim=1121447319074867
WAIT #1: nam='db file scattered read' ela= 13255 file#=6 block#=10 blocks=128 obj#=10645 tim=1121447319090157
WAIT #1: nam='db file scattered read' ela= 12671 file#=6 block#=138 blocks=128 obj#=10645 tim=1121447319107768
WAIT #1: nam='db file scattered read' ela= 59119 file#=6 block#=266 blocks=128 obj#=10645 tim=1121447319170777
WAIT #1: nam='db file scattered read' ela= 13354 file#=6 block#=394 blocks=128 obj#=10645 tim=1121447319187905
WAIT #1: nam='db file scattered read' ela= 39190 file#=6 block#=522 blocks=128 obj#=10645 tim=1121447319231031
WAIT #1: nam='db file scattered read' ela= 44925 file#=6 block#=650 blocks=128 obj#=10645 tim=1121447319279664
WAIT #1: nam='db file scattered read' ela= 53011 file#=6 block#=778 blocks=128 obj#=10645 tim=1121447319336530
WAIT #1: nam='db file scattered read' ela= 13912 file#=6 block#=906 blocks=128 obj#=10645 tim=1121447319354510
WAIT #1: nam='db file scattered read' ela= 13537 file#=6 block#=1034 blocks=128 obj#=10645 tim=1121447319371915
WAIT #1: nam='db file scattered read' ela= 155474 file#=6 block#=1162 blocks=128 obj#=10645 tim=1121447319531089
WAIT #1: nam='db file scattered read' ela= 121519 file#=6 block#=1290 blocks=128 obj#=10645 tim=1121447319656727
WAIT #1: nam='db file scattered read' ela= 14227 file#=6 block#=1418 blocks=128 obj#=10645 tim=1121447319674802
WAIT #1: nam='db file scattered read' ela= 14165 file#=6 block#=1546 blocks=128 obj#=10645 tim=1121447319692961
WAIT #1: nam='db file scattered read' ela= 14300 file#=6 block#=1674 blocks=128 obj#=10645 tim=1121447319711088
WAIT #1: nam='db file scattered read' ela= 13211 file#=6 block#=1802 blocks=128 obj#=10645 tim=1121447319728129
WAIT #1: nam='db file scattered read' ela= 12815 file#=6 block#=1930 blocks=128 obj#=10645 tim=1121447319744562
WAIT #1: nam='db file scattered read' ela= 170935 file#=6 block#=2058 blocks=128 obj#=10645 tim=1121447319919103
WAIT #1: nam='db file scattered read' ela= 13233 file#=6 block#=2186 blocks=128 obj#=10645 tim=1121447319936146
WAIT #1: nam='db file scattered read' ela= 12734 file#=6 block#=2314 blocks=128 obj#=10645 tim=1121447319952560
WAIT #1: nam='db file scattered read' ela= 12588 file#=6 block#=2442 blocks=128 obj#=10645 tim=1121447319968803
WAIT #1: nam='db file scattered read' ela= 12784 file#=6 block#=2570 blocks=128 obj#=10645 tim=1121447319985244
WAIT #1: nam='db file scattered read' ela= 12841 file#=6 block#=2698 blocks=128 obj#=10645 tim=1121447320001782
WAIT #1: nam='db file scattered read' ela= 119155 file#=6 block#=2826 blocks=128 obj#=10645 tim=1121447320124638
WAIT #1: nam='db file scattered read' ela= 14094 file#=6 block#=2954 blocks=128 obj#=10645 tim=1121447320142658
WAIT #1: nam='db file scattered read' ela= 14177 file#=6 block#=3082 blocks=128 obj#=10645 tim=1121447320160695
WAIT #1: nam='db file scattered read' ela= 14348 file#=6 block#=3210 blocks=128 obj#=10645 tim=1121447320179073
WAIT #1: nam='db file scattered read' ela= 13571 file#=6 block#=3338 blocks=128 obj#=10645 tim=1121447320196489
WAIT #1: nam='db file scattered read' ela= 12636 file#=6 block#=3466 blocks=128 obj#=10645 tim=1121447320212753
WAIT #1: nam='db file scattered read' ela= 180444 file#=6 block#=3594 blocks=128 obj#=10645 tim=1121447320396801
WAIT #1: nam='db file scattered read' ela= 13109 file#=6 block#=3722 blocks=128 obj#=10645 tim=1121447320413796
WAIT #1: nam='db file scattered read' ela= 12731 file#=6 block#=3850 blocks=128 obj#=10645 tim=1121447320430198
WAIT #1: nam='db file scattered read' ela= 12603 file#=6 block#=3978 blocks=127 obj#=10645 tim=1121447320446431
WAIT #1: nam='db file scattered read' ela= 136330 file#=6 block#=12297 blocks=128 obj#=10645 tim=1121447320586371
WAIT #1: nam='db file scattered read' ela= 221123 file#=6 block#=12425 blocks=128 obj#=10645 tim=1121447320811727
WAIT #1: nam='db file scattered read' ela= 12813 file#=6 block#=12553 blocks=128 obj#=10645 tim=1121447320828202

Now the direct path version.

PARSING IN CURSOR #2 len=59 dep=0 uid=27 oct=3 lid=27 tim=1121446553535587 
hv=819013003 ad='792091ec'
select /*+ noparallel(test_tab1) **/ count(*) from test_tab1
END OF STMT
PARSE #2:c=1000,e=210,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1121446553535576
EXEC #2:c=0,e=180,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1121446553535975
WAIT #2: nam='SQL*Net message to client' ela= 4 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1121446553536079
WAIT #2: nam='reliable message' ela= 178 channel context=2100923636 channel handle=2100769092 broadcast
message=2101549144 obj#=-1 tim=1121446553537492
WAIT #2: nam='enq: KO - fast object checkpoint' ela= 142 name|mode=1263468550 2=65548 0=1 
obj#=-1 tim=1121446553537742
WAIT #2: nam='direct path read' ela= 34 file number=6 first dba=10 block cnt=118 obj#=10645 tim=1121446553552515
WAIT #2: nam='direct path read' ela= 23 file number=6 first dba=128 block cnt=128 obj#=10645 tim=1121446553560209
WAIT #2: nam='direct path read' ela= 37 file number=6 first dba=256 block cnt=128 obj#=10645 tim=1121446553567431
WAIT #2: nam='direct path read' ela= 24 file number=6 first dba=384 block cnt=128 obj#=10645 tim=1121446553574642
WAIT #2: nam='direct path read' ela= 36 file number=6 first dba=512 block cnt=128 obj#=10645 tim=1121446553581789
WAIT #2: nam='direct path read' ela= 22 file number=6 first dba=640 block cnt=128 obj#=10645 tim=1121446553589104
WAIT #2: nam='direct path read' ela= 36 file number=6 first dba=768 block cnt=128 obj#=10645 tim=1121446553596289
WAIT #2: nam='direct path read' ela= 24 file number=6 first dba=896 block cnt=128 obj#=10645 tim=1121446553603503
WAIT #2: nam='direct path read' ela= 36 file number=6 first dba=1024 block cnt=128 obj#=10645 tim=1121446553610829
WAIT #2: nam='direct path read' ela= 22 file number=6 first dba=1152 block cnt=128 obj#=10645 tim=1121446553618050
WAIT #2: nam='direct path read' ela= 38 file number=6 first dba=1280 block cnt=128 obj#=10645 tim=1121446553625165
WAIT #2: nam='direct path read' ela= 21 file number=6 first dba=1408 block cnt=128 obj#=10645 tim=1121446553632616
WAIT #2: nam='direct path read' ela= 36 file number=6 first dba=1536 block cnt=128 obj#=10645 tim=1121446553639771
WAIT #2: nam='direct path read' ela= 23 file number=6 first dba=1664 block cnt=128 obj#=10645 tim=1121446553647160
WAIT #2: nam='direct path read' ela= 38 file number=6 first dba=1792 block cnt=128 obj#=10645 tim=1121446553654347
WAIT #2: nam='direct path read' ela= 21 file number=6 first dba=1920 block cnt=128 obj#=10645 tim=1121446553661575
WAIT #2: nam='direct path read' ela= 37 file number=6 first dba=2048 block cnt=128 obj#=10645 tim=1121446553668804
WAIT #2: nam='direct path read' ela= 21 file number=6 first dba=2176 block cnt=128 obj#=10645 tim=1121446553676065
WAIT #2: nam='direct path read' ela= 36 file number=6 first dba=2304 block cnt=128 obj#=10645 tim=1121446553683242
WAIT #2: nam='direct path read' ela= 21 file number=6 first dba=2432 block cnt=128 obj#=10645 tim=1121446553690664
WAIT #2: nam='direct path read' ela= 38 file number=6 first dba=2560 block cnt=128 obj#=10645 tim=1121446553697846
WAIT #2: nam='direct path read' ela= 23 file number=6 first dba=2688 block cnt=128 obj#=10645 tim=1121446553705100
WAIT #2: nam='direct path read' ela= 37 file number=6 first dba=2816 block cnt=128 obj#=10645 tim=1121446553712275
WAIT #2: nam='direct path read' ela= 22 file number=6 first dba=2944 block cnt=128 obj#=10645 tim=1121446553719487
WAIT #2: nam='direct path read' ela= 36 file number=6 first dba=3072 block cnt=128 obj#=10645 tim=1121446553726668
WAIT #2: nam='direct path read' ela= 23 file number=6 first dba=3200 block cnt=128 obj#=10645 tim=1121446553734055
WAIT #2: nam='direct path read' ela= 35 file number=6 first dba=3328 block cnt=128 obj#=10645 tim=1121446553741235
WAIT #2: nam='direct path read' ela= 23 file number=6 first dba=3456 block cnt=128 obj#=10645 tim=1121446553748471
WAIT #2: nam='direct path read' ela= 37 file number=6 first dba=3584 block cnt=128 obj#=10645 tim=1121446553755657
WAIT #2: nam='direct path read' ela= 21 file number=6 first dba=3712 block cnt=128 obj#=10645 tim=1121446553762872
WAIT #2: nam='direct path read' ela= 38 file number=6 first dba=3840 block cnt=128 obj#=10645 tim=1121446553770034
WAIT #2: nam='direct path read' ela= 12 file number=6 first dba=3968 block cnt=128 obj#=10645 tim=1121446553772397
WAIT #2: nam='direct path read' ela= 36 file number=6 first dba=4096 block cnt=9 obj#=10645 tim=1121446553778625
Later on, I might even be able to put some explanation round this! For now, it's off to work.
Posted by Doug Burns Comments: (25) Trackback: (1)

Trackbacks
Trackback specific URI for this entry

PingBack
Weblog: hoopercharles.wordpress.com
Tracked: Apr 21, 07:03

Comments
Display comments as (Linear | Threaded)

#1 - Alex Gorbachev said:
2006-05-23 01:18 - (Reply)

Doug,
Did you check with 10046 that it was using direct reads instead of db file scattered read?
Also, I believe that the most important advantage is to avoid contention on buffer cache. So if you try concurrent processes than benefit should be higher. Well, perhaps, your IO subsystem will die first before you get stuck on latches concurrency. :-)

#2 - Jonathan Lewis said:
2006-05-23 05:51 - (Reply)

Possibly the improved performance is due to asynchronous (or at least non-blocked) I/O calls. When doing direct reads, Oracle may be using several overlapped I/O calls to populate read buffers in the PGA, thus allowing later reads to take place whilst the results from an earlier read are being processed. (You should see gaps in the 10046 trace of direct path reads if this is true).

You might also check on differences in CPU - possibly the absence of latching may be part of the difference.

Regards

Jonathan Lewis

#3 - Doug Burns said:
2006-05-23 05:56 - (Reply)

Alex,

"Did you check with 10046 that it was using direct reads instead of db file scattered read?"

Yes, I did. The funny thing was that I was trying to keep this blog shorter because one or two people have said they didn't really like longer blogs about px ;-)

Jonathan,

"When doing direct reads, Oracle may be using several overlapped I/O calls to populate read buffers in the PGA, thus allowing later reads to take place whilst the results from an earlier read are being processed. (You should see gaps in the 10046 trace of direct path reads if this is true)."

I was reading about that and trying to think how I could illustrate that.

I'll update this entry with some of the trace info.

#4 - gonen said:
2006-05-23 06:21 - (Reply)

I've also played with it , (http://www.orafaq.com/usenet/comp.databases.oracle.server/2005/02/07/0523.htm)

When of the issue raise (said by jonathan ) that direct_read is attrubite of the cursor . You must check that you don't have the cursor already parsed ( do hard parse).

#5 - Doug Burns said:
2006-05-23 06:25 - (Reply)

gonen,

Thanks for the pointer. On this issue

"You must check that you don't have the cursor already parsed ( do hard parse)."

I make sure that happens by restarting the instance before each test. It's an artificial but consistent test. It gives me a consistent starting position and, as I'm reading so much data, I wouldn't expect it to be in the buffer cache anyway.

#6 - Alex Gorbachev said:
2006-05-23 08:40 - (Reply)

"I make sure that happens by restarting the instance before each test."
Better parse it before the test to exclude hard parse influence (well, 1 parse shoud be negligible anyway).

"one or two people have said they didn't really like longer blogs about px"
They don't have to read it! %)

#7 - Doug Burns said:
2006-05-23 09:39 - (Reply)

Alex Gorbachev said...
"Better parse it before the test to exclude hard parse influence (well, 1 parse shoud be negligible anyway)."

I'm pretty sure that's not significant here, what do you think? The same single hard parse, followed by a fts of 9Gb?

#8 - David Aldridge said:
2006-05-23 21:26 - (Reply)

Ah ha, I smell an interesting wait event ..

'enq: KO - fast object checkpoint'

... required to allow the SGA to be bypassed of course (thanks JL!). I think this is new anyway -- I don't recall seeing it in 10.1. It's a caveat against the frequent use of direct read for busy OLTP tables anyway.

Interestingly different patterns in the elasped times too. The scattered reads start following a repeating pattern of one slow read followed by five fast reads, whereas the direct path alternates fast and slow reads. That suggests to me that something different is going on at a low level aside from the issue of the block buffer being bypassed.

btw, I'm supposing that the elapsed time units are different there, of course. That's also curious, but not surprising as the naming of the number of blocks read also follows different conventions -- those Hotsos profiler guys earn their money dealing with all those inconsistencies :-D

#9 - Jonathan Lewis said:
2006-05-23 21:46 - (Reply)

David,

The elapsed times are microseconds in both cases. But the (still outstanding) problem with the trace is that you really need TWO tim= stamps, one for the start of wait and one for the end. Then the time spent between the end of one and the start of next is time spent in CPU.

The trick with the "direct path reads" is that Oracle manages to dispatch N buffers for read requests (probably 4), which is a CPU and memory intensive strategy, then comes back to the first buffer - which in this case requires a very short wait to fill. Then Oracle uses the data, dispatches a new read and moves on to the second buffer. In the interim the second read has nearly completed, but requires a few more microseconds... if Doug's hardware were just a little faster, we wouldn't see any direct path read waits.

Although the 'scattered read' waits are much more variable, check the difference between adjacent tim= figures and the recorded elapsed. The "error" is in the ballpark of the gap between tim= in the "direct path" -- i.e. the CPU time of examining the blocks is about the same - and hides the asynchronous time taken to fill the buffers during the direct path read.

Re: KO - I think that appeared in 10.2. There is a new entry in the buffer header structure which allows for a linked list to be built between buffer headers of the same object. This, of course, means yet another little overhead when reading a block into the buffer in the first place. But it is useful for truncates, drops, and shrinks, as it avoids a massive scanning process if you drop a large object which has not been subject to much update.

Regards
Jonathan Lewis

#10 - Doug Burns said:
2006-05-23 22:17 - (Reply)

Dave,

Even though I'm in the middle of a very messy server consolidation (working from home), I was going to reply to some of your comments when I got the notification email (has anyone else noticed how slow Blogger has got in this respect). So I arrive here and Jonathan has got there first (as usual). I'd better get back to what I should be doing :-(

#11 - Doug Burns said:
2006-05-23 22:27 - (Reply)

Dave,

See Metalink Note 50415.1 for more on the direct path read wait timings :-

"Hence this wait event is very misleading as:

The total number of waits does not reflect the number of IO requests
The total time spent in "direct path read" does not always reflect the true wait time."

That was going to be the extent of my wisdom on this ;-)

#12 - David Aldridge said:
2006-05-24 18:13 - (Reply)

Hmmm.

So what would it mean if the timings for the direct path read were comparable to those for the scattered read, as they seem to be under 10.1 on Windows for example? I'm not seeing this effect of comparably much lower wait times for direct path than for scattered, and of course there are no tim= elements in there either.

example ...

WAIT #1: nam='direct path read' ela= 15848 p1=22 p2=1282793 p3=64
WAIT #1: nam='direct path read' ela= 14415 p1=22 p2=1282857 p3=64
WAIT #1: nam='direct path read' ela= 15261 p1=22 p2=1282921 p3=64

#13 - David Aldridge said:
2006-05-24 18:28 - (Reply)

... and yes, Blogger's emails are arriving late, and sometimes not at all.

#14 - Doug Burns said:
2006-05-24 20:30 - (Reply)

Dave,

What do you have disk_async_io set to?

#15 - Doug Burns said:
2006-05-24 20:38 - (Reply)

Dave,

I noticed there's a fair bit of information in the Oracle Press Wait Interface book on this subject that it might be worth you taking a look at.

Cheers

#16 - David Aldridge said:
2006-05-24 20:50 - (Reply)

disk_async_io = true

filesystemio_options is unset

I think that these are the default for windows.

#17 - David Aldridge said:
2006-05-24 20:51 - (Reply)

Oh yes, I'll dig that book out and see what they suggest in there.

#18 - Jonathan Lewis said:
2006-05-24 22:35 - (Reply)

David,

Timings for direct reads: are you using 16KB blocks ?

It could mean that your session isn't allocating much memory for read buffers - so there's only one buffer, and the direct read time starts counting from the moment the read request is dispatched.

Try doing a big sort with events 10032, 10033 and 10046 (level 8-) set to check the direct path reads and writes. The 10032 trace will tell you about the number of buffers used (for that sort) and some information about waits for synchronous and asynchronous I/Os. The other traces will show you the I/O sizes and locations. It may give you some clues.

#19 - David Aldridge said:
2006-05-26 14:22 - (Reply)

8kb blocks, so the reads in the trace are of 512kb. As a side-note, pushing thatto 1Mb causes a disastrous drop in performance.

I'll look at the 10032 etc next week -- I'm off camping for a few days.

#20 - Anonymous 2006-05-29 17:20 - (Reply)

The test is at best severly flawed for two major reasons:

- When serial direct reads are enabled a checkpoint of the data object is triggered. This means that all the dirty blocks need to be first written to disk. So depending how many dirty blocks there your measured timings are completely wrong.
- When several concurrent jobs are doing checkpoints it is getting even more expensive

#21 - Doug Burns said:
2006-05-29 18:32 - (Reply)

Steve,

"So depending how many dirty blocks there your measured timings are completely wrong."

As I said in an earlier comment

"I make sure that happens by restarting the instance before each test. It's an artificial but consistent test."

So there are no dirty blocks. This job is the first thing that touches that table after instance startup.

"- When several concurrent jobs are doing checkpoints it is getting even more expensive"

This is the only job running on this system.

So I think it's an exaggeration to say the test is 'at best severely flawed'.

#22 - Jonathan Lewis said:
2006-05-30 21:29 - (Reply)

Re: "The test is at best severely flawed for two major reasons"

I think this depends on what you think the test was supposed to demonstrate.

Clearly, there is a rather noticeable difference between the serial direct read time and the scattered read time - which is a worthwhile observation point, and means that some people might want to investigate the issue further.
(Doug does, after all, point out in the blog entry that (a) he restarts the system for each test, and (b)it is a very simple test. I don't think he is attempting to convince people that they can enable _serial_direct_reads with no further thought.


Your point about the object checkpoint is valid - and any further investigation would obviously consider the tradeoff between the time (apparently) gained from direct path reads, and the time lost waiting for dirty blocks from that object to be written.

Your point about the concurrent reads, however, raises a further interesting question. If we start two "direct path queryies" at the same time, won't the second query benefit from the writes performed by the first query ? After all, if there are (say) 4,500 dirty blocks to write won't the second query simply wait for the first query to write them, then find that the checkpoint queue has been cleared for it (plus or minus a few extra blocks) ?

In fact, increased concurrency might ensure that there are only ever a few blocks to write, so making Doug's "clean start" a reasonable model in many cases.

#23 - Amit Spitz 2008-12-12 00:02 - (Reply)

Jonathan -
You mentioned that in 10.2 "there is a new entry in the buffer header structure which allows for a linked list to be built between buffer headers of the same object"

You mention that this list is used for truncates, drops and shrinks - is it also used for performing the fast object checkpoint that preceeds direct reads ?

For partitioned objects - is there one single list for blocks from all partitons , or is there a separate list for each partition ?

This relates to your comment about the tradeoff between time (apparently) gained from direct path reads vs time lost waiting for dirty blocks to be written ; what would be the behavior in case of a partitioned table ?

For example - a table partitioned by date ranges , where heavy read/write activity occurs only against the most recent partition.
What would happen (checkpoint-wise) if we performed direct reads against an "old" partition for which there are currently no blocks in the buffer cache ?

#24 - Jonathan Lewis said:
2008-12-13 10:21 - (Reply)

Amit,

Answering your questions out of order:

If you do a dump of the buffer cache, the name for this particular linked list is the "objq".

I haven't tried to do an exhaustive analysis on how it works - but my first guess would be that each linked list links only the blocks of a given data_object_id (as opposed to object_id), which means each partition of a simple partitioned object would be on a difference queue, and each subpartition of a composite partitioned object would be on a separate queue. You could confirm this quite easily by setting up the example you've described and seeing what writes occur if you run a parallel query against the unchanged partition.


It is possible that this type of linked list could be used for the "object checkpoint" - but it is also possible that the database writer simply walks the checkpoint queue looking for buffers matching the relevant object id. In different circumstances, either stategy could be the faster strategy.

If you wanted to check it would be easy, but tedious, to set up an experiment that read a lot of blocks in an object at random, updated them randomly, then dumped the buffer cache to check the ordering on the different queues, then traced the database writer from the O/S level to see the order in which the blocks were written.

#25 - Tanel Poder said:
2008-12-30 20:04 - (Reply)

Yep, the object queues are organized by data object ID.

Btw there are two x$ tables in 10.2 which externalize the buffer cache object queues.

X$KCBOQH - KCB object queue header, has one row per data object id currently in buffer cache

X$KCBOBH - KCB object queue buffer headers, has one row per buffer in any object queue


Add Comment

Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
BBCode format allowed