Re: Oracle vs filesystem block size

>Why do you prefer 8K blocks to 2K blocks? When doing table scans the parameter
>db_file_multiblock_read_count kicks in and can be adjusted larger in response to
>small blocks giving maximum I/O throughput. On the other hand when doing single
>row retrieval, such as indexed retrieval, won't the smaller I/O complete faster?
>
Well somewhere (I think the 7.0.15 config and installation guide for Solaris) Oracle says the db_block_size must be a multiple of the filesystem block size. Since db_block_size has a max of 8K and we want at least 8K filesystem blocks there seems little choice. I didn't see the same comment from Oracle in the config guide for HP (but didn't look hard). The thing is that HP-UX 9 defaults filesystem block to 8K and the default Oracle block size is 2K (same values hold on Solaris 2.3) which contradicts their suggestion!

>Another option to consider on HP/UX is to use the logical volume manager to
>create raw volumes, and take the file system out of the picture completely. This
>was the approach stongly recommended by Oracle's Product Manager for HP at IOUW.
>
This is being considered. Some say the difference is not as marked with Oracle 7 as for 6. Apparently a future release of OmniBack is designed to work with raw devices to simplify backup of this type of datafile.

Cheers

Gavin

---
      .
     /| The
    / | Vector 
   /  | Group   ---------------------------------------
  /\  |____           Gavin Maltby, Vector Durban
 /  \/|    |          Email: gavin_at_durban.vector.co.za
 \   \|    |          Tel: INT+ 27 31 266 9948
  \   |   /           Fax: INT+ 27 31 266 0811
   \  |  /            Note: I speak for myself, and not
    \ | /             necessarily for Vector or Sun!
     \|/         --------------------------------------
      " Sun Partner in South Africa