LVM Question

[Madanagopalan S]

I have created a logical volume combined as 8 disks with stripe option for the
oracle database and application. If I split that volume group into two logical
volume for database and application will it improve the performance?
Are Logical volumes and file system include in Performance Issues pertaining
to Disk I/O?

[Sundararajan Anandhan]

Hi,

I didn't quite get your first question but
having a Raw Logical Volume definetely helps u to overcome the filesystem overhead and hence you can use the Raw LVs than file system to get a better performance.

Hope this helps.
Regards,
Sundar.

[S.Jagadeesh Babu]

Hi,

As sundar said, RAw LV's definitely improve performance. So it is better suggested to have the database on the sepearate LV as raw LV and application in separatee LV as filesystem.

Hope this is OK.

Regs,
S.J.Babu

[Manju Kampli]

By making two logical volumes, you will have better control on the space allocation and easy administration. I don't think it would add any additional performance to the system.

where as raw partition will give you better performance over file systems for database usage.

[Adrian Voysey]

Yes raw logical volumes will improve performance , also under ORACLE use_async_io = true . set this if you are using raw logical volumes this is saying it writes to raw logical volumes asyncronously.

hpe this helps

[Madanagopalan S]

Sorry. Both logical volumes will be filesystem volumes. If I split single
logical volume into two logical volumes (data and application) , will it
increase system performance/ increase logical io read/write performance.

[John Palmer]

There is no performance benefit in splitting one large volume striped over 8 disks into two smaller volumes striped over the same disks.

There are other issues though, among which are:-

Advantages:
- Filling up one smaller volume will not affect the other.
- May reduce the backup requirement (application may not need backing up as often as the database)

Disadvantages:
- Loss of a single common area of free space i.e. you don't have to guess how big the smaller volumes actually have to be.
- Requires a change to path names (if everything is already installed) unless you resort to soft links.

I'm sure that others can expand on the above.

Regards,

John

[Marcelo De Florio]

Another alternative is create the datafiles in filesystem with the direct option (in the mount moment, HP-UX 11.x). This option by-pass the file buffer cache of operating system.

Regards

[Alan Riggs]

I disagree slighly with some of the above relies. there is no guarantee that splitting the logical volumes will have a performance benefit. But it might. It might also result in performance degredation. The only way to be certain is to benchmark both options.

One combined volume:
+) 8 disk stripe distributes all reads/writes across larger number of disks reducing possibility of overall contention.
-) database and application share same disks, increasing likelihood of conflicting access requests.

Two volumes:
-) 4 disk stripes use fewer controllers and so are less effective at distributing access requests.
+) segregated application/DB means application I/O requests will not hang waiting for large DB I/O fulfillment.

In general, if the application and Database both hit the disks hard you are *probably* better served in segregating the logical volumes. This will let you better diagnose hotspots and attempt to tune appropriately. If the DB hits the disks much harder than the application, you might get better performance from a single partition (or an uneven partition in which more disks are given to the DB than the application).

Personally, I prefer to segregate my DBs from applications for flexibility in continued maintenance.

[Anthony deRito]

Aside frome the performance issue, what I would do is split up the 8 disks into 2 RAID 5 groups. Why have such a large logical volume? Do you require one large filesystem? If your talking filesystems, one for the application and one for database exports or imports (which is what I think you are saying) why not have two smaller, separate, easier to manage groups. If your using dual controllers and require alternate data paths, then this is a good choice. The performance gain would be a definite if you have dual controllers and you are using a disk array.

Hope this helps.

Tony

[Tim Malnati]

There is another potential side benefit using separate file systems. You have the opportunity to tune each file system based on its contents. The parameters that have the biggest oppotunity for tuning is block/fragment size. Adjusting these to your needs can have a very significant benefits.

[Madanagopalan S]

In glance, I have found the statistics about IO by logical volume. What is it mean?
Is it require to consider this one regarding performance issue? I found only one
logical volume have higher rate always since both database and application
reside on that volume. I thought it will improve the performance if I split the logical
volume for data and application. Any idea?

[Geetam]

Oracle (any database really) performance can be increased dramatically by spreading disk I/O in a controlled manner over different disk spindles (eg data on one disk, index on another, reduced contention on disk I/O) In an IT environment mechanical actions (disk head movements, printing, etc) are still the main performance bottleneck. Find out which datafiles are accessed at the same time and put them on different disks.

This requires that you create your logical volumes carefully, so you know exactly where each logical volume (and its mirror) is placed on which bits of hardware, so you can place your datafiles accordingly.

This is difficult (if not impossible) to do if using RAID5 and/or striping. I prefer buying a few more disks and use mirroring (also less overhead of RAID checksumming)

Performance improvements of raw volumes, striping, etc. are minimal compared to placing files so they can be accessed without getting in each other's way (disk heads shifting from one file to the other and back on the same disk)

Regards

Geetam

[Martin Geil]

Two points to consider:

1) It appeared to me that by "application" you meant just the Oracle application and associated files, which I would expect to be small compared to the size of your database. I also would expect that once you start the Oracle server processes, they would do very little I/O to the application files, so I'm guessing that you will find the vast majority of your I/Os are to the database.

2) If you are really striping across 8 disks without using RAID or mirroring, you are asking for database downtime when just one of those disks fails. Not knowing what kind of disks you are using, how clean the power is, how often they are spun down, etc..., if we guess at 4 yrs MTBF for them, you will have a failure of one of the disks (and a database crash) every 6 months. Database restores can be painful if you are not careful about frequent backups of your transaction log, so I liked (and happen to practice) the idea of mirroring. However, this assumes your database structure allows you to manually distribute the most frequently accessed tables/indices/logs to different spindles.

[Dave Wherry]

Yet one more thing to consider along the lines of Geetam's post. Considering the physical. How are these 8 disks connected to your host? If you are using SCSI that's a lot of disks on one controller. If you have FC/AL it is not that many. How many controllers do you have?
Some basic concepts to consider. Keep your data files and your indexes on seperate physical spindles. Also try to keep them on different controllers. Keep your operating system file systems and swap space seperate from the application and database file systems. Basically, spread out.
Without knowing all the hardware you have it's difficult to give a very good answer on how to set it up.

[Madanagopalan S]

8 disks are connected to two different controllers and operating system is on
internal harddisk. I have one more doubt. I have found some logical read/writes
status on glance under i/o on logical volume. What is it mean? Do we have
to consider this parameters in performance tuning?

[Ramesh Donti]

Hi,
You are saying that you have 4 disks on each controller and you have used all the disks without mirroring. Are these disks are legacy disks or disks in some disk array. If so, already some RAID level might have been implemented. So you will not get any performance improvement even if you do any striping at LVM level.

If your disks are not sitting in a disk array, you can try the following:

1. Increase the strip size. This will improve the performance if amount of data for each disk I/O request is more.

2. Check that both the controllers and their disks are of same SCSI type like SE-SCSI, FWD-SCSI. Otherwise, you will get the performance of the slowest SCSI Channel.

3. Even if they are of same SCSI type, check that all the disks are of same type like disk rpm, etc.

Above all these, are you sure that performce gain outweighs redundancy/reliability of the data.