Stripe Size

[Paul Yarborough]

My question is concerning the stripe size in conjunction with Oracle. We are using
raw disk (not true raw) and have a stripe size of 32 KB across 16 volumes. As I understand it, this is the maximum amount of data written to each disk during a write. Is this also the maximum amount read from each disk?

[Dale McNamara]

Alot of the performance you are looking for is determined by the db_block_size you have set in your init file.

The stripe size should be the same as the primary I/O size for the application.

[Dan_4]

Perhaps a clearer explanation of striping is in order here. Imagine you have 3 disks in an lvol and it is striped at 32k. When a write occurs, it will lay down 32k of data on one of the disks (let's assume disk 1). The next 32k of data will go on disk 2, the next 32k on disk 3, then back to 1 again for the next little chunk of the data, and so on, round and round until the whoile file is written.

When a program asks LVM for that data file, it goes out and reads the data from where it's at, which is spread out over the three disks in sequential 32k chunks.

The performance increase from striping comes from the fact that if the disks are on different controllers, the reads and writes can be done simultaneously. If all the data were on one disk, the entire operation has to go through 1 controller, which takes longer.

So I think the answer to your question, if I understand it, is "sorta". The amount of data read at a time is the same as the amount of data written at a time. Whether this is the amount of data your app does in a single i/o operation is not relevant to this particular operation.

Dale makes a good suggestion for block size. If you have a specific app, like Oracle that will be using the data, matching stripe size to i/o is a good way to go.

[Paul Yarborough]

Just so I am clear on this. There is noticable performance gain when the stripe size is set to the db_block_size parameter in the config*.ora?

[Dale McNamara · Accepted solution]

Hopefully, I can help with any confusion I have created.

First, the db_block_size is specified at database creation time.
Oracle delivers its software with 2kb as the default. This can be
set to also 4kb and 8kb.
The best performance comes from matching the db_block_size to that of the
OS (HP defaults HFS to 8kb, VxFS is 1kb).

So on HP-UX with HFS file systems, you would want to create your databases
with db_block_size=8.

You are working with an existing database so this may not be modifyable.

The last factor is the size of your data files and how much OLTP versus reads
your application does. With larger stripe sizes, you will utilize more of one disk
at a time. Smaller stripe size would span across the disks more often.

On a side note, check your db_file_multiblock_read_count setting in your init file.
Note this is the "read" setting only.
This specifies the maximum number of blocks read in one I/O op. The default
setting on this is 8. Smaller data files and OLTP benefit more from 4 - 16,
whereas data warehouses would run better 16 - 32.

Now the kicker to this is that the amount of performance increase available by
adjusting these settings: about 5%.

You can benefit more by addressing areas such as the number of database buffers.
(db_block_buffers)