small file sytems vs. larger file systems for Oracle

[Wes Kaufmann]

I have 80 GB free on a Model 12H autoraid that I would like to make into 4 20 GB file systems for our DBA. Database is lightly used with no real heavy IO. Our DBA wants 2 20GB fs and 6 6GB file systems.

If we had a lot of usage I might say ok so we could use different mount options for the datafiles and the indexes but we don't so I would prefer larger file systems, just plain easier to manage.

6 GB is hardly anything now a days and the DBAs tend to stuff 3.1 GB in a file system and than say they can't use anymore since they need more than the 2.9 GB that is available.

Any comments?

[James A. Donovan]

Really depends on the databases expected growth patterns, but your DBA's request doesn't seem unreasonable. 20 GB each for seperate table and index table space filesystems. And seperate file systems for redo logs, archive redo logs, rollback segments and control files....

Of course, the true performance killer in this setup is the 12H itself. Has to be one of the slowest RAID boxes I've ever worked with....

[Sridhar Bhaskarla]

Hi,

While it is generally easy to manage large filesystems, you may get into difficulties once the *hotspots* start showing up. Because all you have are few filesystems and you cannot really spread the data wherever you want at crisis times.

If you have multiple smaller filesystems, if you find one filesystem busy, then either you can move the data over to another filesystem or move the entire filesystem over to another disk that is less active.

Unless you are dealing with tens of filesystems, I would suggest to go with your DBA's recommendations.

-Sri

[Tim Sanko]

Jim may be right.

This time they aren't being unreasonable. Especially if you can balance the IO through separate controllers.

Tim

[A. Clay Stephenson · Accepted solution]

Well, you see, any DBA could tell you that the more the better because its spreading the IO across more spindles - that's got to be better. Of course, the 12H is spreading the I/O across all the spindles anyway so its really a pointless execise - although you may make things APPEAR better to Glance by using more devices.

There is really no point in going beyond 2 filesystems. One for datafiles and indices and the other for redo/archivelogs. Splitting like this will allow you to play with different mount options for the datafiles/indices. Typically on 11.0 and below, the datafiles and indices performed best with convosync=direct,mincache=direct to bypass the buffer cache. You could also reduce buffer cache and used the memory for larger SGA's. In 11.11, Oracle tends to work best with everything in cooked files.

My "recipe" is to configure 2 identically sized LUNS on the 12H. LUNA should have primary path thru controller X (alternate Y) and LUNB should use primary path Controller Y (alternate X). You then crerate each LVOL striping across both LUN's in 64K chunks. This will fully utilize both external SCSI buses and the four internal buses.

[A. Clay Stephenson]

One other point: If you configure no more than about 50% capacity as LUN's (everything is now RAID 1/0) and leave the remainder unconfigured AND split the IO as I've outlined, you will be amazed at how well these old gals will perform.

[Wes Kaufmann]

Thank you all, Mr. A. Clay Stephenson makes a real valid point that on a 12 H everything is already spread across all of the spindles. So if you have 10 file systems or one it's spread across the same spindles.

The real trick with the 12 H is splitting the IO across the x and the y controllers and I like Mr. A. Caly Stephenson's recepie although I may try a couple of tests.

File system mounting options is the only thing we might loose than and since we are upgrading to 64 bit 11i than even that seems like a stretch.

Also, note that this system is lightly loaded. I would have to see an increase by a factor of 10 or more to see any real usage.

I'll give out point tomrrow.