One large filesystem vs. several smaller

[Brian M. Fisher]

We have a new Oracle database going into place that will be approx. 300GB. Our DBAs would like to put this in one large filesystem. In the past I have always broken this space up into multiple filesystems. The storage is on an HDS system so it is already presented to the server as RAID5 units.

Any suggestions or reasons I should go with one approach over another?

Thanks in advance,
Brian
<*(((>< er

[Sridhar Bhaskarla]

Hi Brian,

I would suggest to go with multiple ( but not several) file system approach.

I would also configure the volume groups and file systems based on the type of activity. For ex., create two file systems that do only sequential IOs, two random, two mixed etc., . Have your vendor (or you) carve the LUNs (RAID5 units) on different Raid groups and configure them into the volume groups so that one type of activity will not interfere with the other. Have your DBAs place the datafiles accordingly.


-Sri

[Martin Johnson]

Ideally, you want to spread out the data of as many spindles as possible, to allow concurrent processing of I/O. Usually, this is easier to do with small file systems.

However, with today's disk arrays with large amounts of cache, it is not necessary to break the data into small file systems to get preformance.

Whether you need to use small file systems depends on the size of your disk cache and how the disks are configured to the system.

HTH
Marty

[Steven E. Protter]

With all issues, this one has at least two answers.

Most storage vendors don't understand how to optimize oracle performance anyway. Their disk array tests commonly use RAID 5. They then claim that this provides optimal performance.

Few go into the depth and details. Would the oracle database perform better if the index and data files were on seperate filesystems? Little testing has been done. Most administrators don't have time to do it.

We did spend some effort to performance test.

We found little difference in performance between having all the data on one RAID 1/0 filesystem versus breaking them up. Thus, we decided on the larger fs to make things easier on the dba.

Not that we are as big as you. Our data drive is about 30G in our new L2000 servers.

Steve

[James R. Ferguson]

Hi Brian:

Since you indicate that this ia an Oracle database filesystem, I assume that the number of files within the filesystem isn't a performance issue when searches are made through the directory trees. Therefore defining one filesystem or several is immaterial from that standpoint.

My personal preference, however, would be to use several mountpoints (filesystems) instead of one large one. From a backup and recovery standpoint it might be easier to manage smaller "chunks".

Regards!

...JRF...

[Scott Van Kalken]

I would typically have multiple filesystems.

It depends on your disk setup and what you hope to achieve.

We would generally use mirrored sets for oracle because it's slightly faster than raid (according to oracle & our DBA). So it keeps those parties happy.

Given that we use multiple disks and mirroring, we also have multiple controllers.

We balance the i/o load over the spindles and controllers (checked roughly every three months).

As others have mentioned spreading your data files and index files etc around can have other benefits as well.

however, this is always a trade off.

With the setup we have, it's a slightly higher administrative overhead.

Depends on what you're trying to achieve.

[Jeff Schussele]

Hi Brian,

One reason to seperate them would be caching.
Optimally you want Oracle to cache the data & index LVs - whereas the logs & redo LVs should be OS buffer-cached.
If all these are in the same FS, you cannot apply the different mount options - they's have to all be one or the other.

Rgds,
Jeff

[A. Clay Stephenson]

I would split this into at least two filesystems and possibly three. Here's why (and I assume that you have OnlineJFS; if not, you should). Typically, datafiles and indices perform perform better using the mount options convosync=direct,mincache=direct to bypass the UNIX buffer cache while archive and redo logs should use the normal mount options and utilize the buffer cache. If these are all in one filesystem, you don't have that degree of tuning.

The other thing to note is that all things being equal, RAID5 is not a particularly good performer although if heavily cached it may be fine.

[SteveKirby]

Well the caching and layout have a lot to do with how the database is designed.
Is it one large tablespace that everyone hits with multiple datafiles?
Do you have indexes split off?
Do have radically different concurrent processes going on.
e.g. Order Entry vs. Purchasing?
Are you primarily READING or WRITEING data?

I wouldn't about number of filesystems. It is number of spindles/ drives that is important. e.g. you could put 5 filesystems on one drive ... or 5 filesystems on 15 drives. The 15 drive option, if the drives are the same speed, will be faster.

So to answer your question. For ease of use I would just use a single file system... I am surprised you don't see any improvement off of splitting the data, but to do that properly there are a bunch of stats I would need. (e.g. archiving status, redo logs, file systems, read/write stats of the tablespaces.)

Steve