Hi Dan,
I think you are reading "way too much" into what I
was saying. I was not in any way saying the the
"physical blocks that support logical blocks were
contiguous". I was saying that if multiple logically
contiguous blocks (as in the leaf nodes of an index)
were requested by Oracle requested in quick succession
and if there is a 1-to-many ratio of
logical-to-physical mapping, the "read ahead
algorithm" in the I/O sub-system will be triggered
into performing pre-fetches that are larger than the
actual amount of data required for the process. This
is true even if the physical blocks were scattered.
The pre-fetching occurs due to multiple blocks being
read in random succession. I have encountered this
problem
at some customer sites and synching DB_BLOCK_SIZE = FS
Block Size, by re-engineering the filesystem block
size is what that helped us overcome the wastage and
the overhead.
Cheers,
Gaja
>--- Danisment Gazi Unal <dunal_at_ubtools.com> wrote:
> Hi Gaja,
>
> > Once again I've not tested, but I've some
questions
> > about your comments on physically contiguous" and
"Keep DB_BLOCK_SIZE = FS(or OS) Block Size"
> >
> >
> > "physically contiguous":
> >
> > We know that disk sectors are read and then
> > transfered to bus. There will
> > be a delay while transfering read sectors to bus,
> > but before the reading
> > next sector. Since disk rotates, while transfering
> > current sector to bus,
> > some or all of the next physically contiguous
> sector
> > may be missed. If
> > these sectors were really physically contiguous,
> OS
> > would wait for the
> > next rotation of the disk to read entire next
> > physically contiguous
> > sector. So, OS doesn't put logically contiguous
> > sectors as physically
> > contiguous. By depending on disk rotation speed
> and
> > transfer speed to bus,
> > it's scattered to disk. An optimized disk
> management
> > system finds next
> > sector immediately after the current sector is
> > transfered to bus. This may
> > be done by putting gaps between logically
> contiguous
> > sectors. These gaps
> > may be used for other data. Of course, there may
> be
> > different
> > implementation, but there will be always a delay
> to
> > bus and there will be
> > always a miss to next sector(s).
> >
> > I've not tested but If Oracle sequential data is
> > stored as physically
> > contiguous, it's a real problem for IO subsystem.
> I
> > guess it's logically
> > contiguous.
> >
> > "Keep DB_BLOCK_SIZE = FS(or OS) Block Size":
> >
> > As I remember(???), Oracle uses bytes as
> parameters
> > in IO system calls.
> > And, let's say we created a db which has
> > DB_BLOCK_SIZE = FS/OS block size.
> > is it guarantee that each new Oracle block will be
> > written to new OS block
> > ? Every file is identified by a file handle in OS
> > level, and also there
> > should be a specific value in a register which
> > points to last offset of
> > the file. I mean, next insert may be appended to
> > current OS block if there
> > is free space, and new block(s) may be allocated
> for
> > the remainings. Here
> > is a sample:
> >
> > - OS block size = db block size = 2k
> > - 1K of the last OS block is free and we would
> like
> > to insert 4K.
> >
> > 1K is appended to last OS block, a new OS block is
> > allocated for the
> > remaining 2K, another new OS block is allocated
> for
> > the remaining 1K. In
> > this sample, 4K is scattered to 3 blocks, not 2
> > blocks.
> >
> > I think this will not be a problem for Oracle.
> > Because Oracle uses its own
> > format. The check between block header and tail
> will
> > prevent scattered
> > data from any corruptions in physically different
> > blocks.
> >
> >
> > I've not tested them, I may be wrong. Looking
> > forward to hearing a
> > confirmation
> >
> >
> > regards....
> >
> >
> >
> >
> >
< stuff deleted>
Gaja Krishna Vaidyanatha
Director, Storage Management Products,
Quest Software, Inc.
Co-author - Oracle Performance Tuning 101
http://www.osborne.com/database_erp/0072131454/0072131454.shtml
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Gaja Krishna Vaidyanatha
INET: oraperfman_at_yahoo.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Sat Apr 27 2002 - 14:03:20 CDT
