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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
