Re: db_file_multiblock_read_count value

daniloa_at_bbirger.intnet.mu (danilo) wrote in message news:<9713eeb.0210310426.17a11a7_at_posting.google.com>...

I just wanted to point out that we are currently performing some benchmarking on a Sun Fire system running VERITAS Database Edition 3.5 ODM and Oracle 9i release 2 (64-bit) in a SAN Fabric environment. maxphys on Solaris is not limited to 1 MB, it's only the default value. sd driver can support request up to almost 32 MB in size. So we set the max. physical IO size to 8 MB and one also need to set sd_max_xfer_size in sd.conf to 8 MB as we are using an EMC symmetrix storage. We did also check that our Emulex HBA supports 8 MB requets. dd if=/dev/zero /data/data.dbf bs=8192k count=64 shows that we did get an average IO request size of 8 MB.

We've got some pretty good performance using the following: vol_maxio=16384 <-- 8 MB (same as the physical I/O size) Stripe unit size = 1 MB
Stripe width = 70
db_file_multiread_read_count=128

we were just trying to increase db_file_multiread_read_count to 1024 (as recommended by VERITAS, it should be set to maxphys/DB_BLOCK_SIZE) since the application will do intensive sequential scan.

From what I understand now, it's seem that Oracle has hard-coded the value in the SSTIOMAX.

Anyway, we are quite happy with the way the system is performing and we will sitck to db_file_multiread_read_count=128.

Danilo

> Hi,
> I would like to know why we can't set Oracle parameter
> db_file_multiblock_read_count greater than 128 on a Sun system running
> Solaris 8 (with latest patches) and Oracle 9i release 2.
>
> On the OS side, we set the max. physical I/O size(maxphys) to 8 M in
> /etc/system and sd_max_xfer_size is also set to 8M in the
> /kernel/drv/sd.conf. We tried to set db_file_multiblock_read_count to
> 1024 as recommended by VERITAS (maxphys/Oracle_block_size) = 8 M/8 K
> but Oracle just seems to retain the 128 value.
>
> Does anyone know if this is an Oracle limitation or something else?
>
> Thanks
>
> Danilo
Received on Fri Nov 01 2002 - 00:07:30 CST