EVA3000 and Oracle

[Ryan0]

We have an EVA 3000 connected to two rp7440 risc servers, both running an instance of Oracle. The EVA contains one large disk group of 56 disks, with two oracle databases running.

When we turn CA on, the users just get egg timers and cant work. When we turn CA back off its ok. People still think the system is slow though. After running a glance on one of the risc boxes we see the attached screen shot.

Is this normal? thoughts and advice are apreciated

Andy

[TTr]

Yes 56 disks in one disk group is a bad idea. The slightest I/O will light up all 56 disks (well not all, minus the virtualization). You need to separate the I/O by creating more disk groups and at least 2 LUNs per disk group.

[Ryan0]

Yes 56 disks in one disk group is a bad idea. The slightest I/O will light up all 56 disks (well not all, minus the virtualization). You need to separate the I/O by creating more disk groups and at least 2 LUNs per disk group.

Hi and thanks for the speedy reply. I forgot to put in there that we do have one big disk group, but quite a few luns per risc box being presented out.

I've read a fair bit about how oracle works with regards to EVAs and everyone seems to think that the more disks (spindles) being used, the better for oracles performance.

the glance screenshot by the way was running for no more than a minute

Cheers

[TTr]

> how oracle works with regards to EVAs

Are you using raw volumes or filesystems?

> the more disks (spindles) being used, the better

I hear that a lot specially from sales people. And to some extend it is true, the total I/O throughput and bandwidth and is the sum of each spindle's I/O t-put and bw. BUT, at the same time it is up to the controllers to pump that total I/O and that's where the particulars of each controller and backend bus design come into play. And these are the limiting factors. I don't know what they are for the EVAs but I worked with another midrange disk array from another manufacturer and the optimal number of spindles in a array group was no more than 12 to 14. I don't think the EVAs have a backend bus design to be able to handle concurrent I/O from 56 disks in one array group.

[Ryan0]

Thanks again for the responce

We are using the disks in RAW format and the risc boxes are use=in hp-ux 11 and it was two guys from HP that configured the system quite some time ago.

CA only appears to become an issue when a specific 2 of the luns are being replicated.

Our production oracle database has 8 100gb luns presented, only 4 and 6 appear to be a problem though.

Is there anything i can check with oracle (not being a DBA) to figure out why the read writes are so high for an 800gb database with around 150 users?

[Phillip Thayer]

Using 56 disks in a single disk group is optimal for an EVA. Never create a disk group that is not a multiple of 8 and the more disks in a disk group the better your I/O throughput will be. The controllers will handle this I/O throughput prefectly fine.

What it sounds like is happening is that you are turning on CA and it is doing an initial synchronize of LUN's that are being replicated. It sounds to me like LUN 4 and 8 are being replicated. Normally, you want the initial synchronization to happen with the LUN's and applications down. Then once it is replicated you can start the application back up again.

The reason you are seeing the high I/O when the CA is turned off is most likely because the file systems are going through a synch and check on the UX side.

Phil

[TTr]

> Using 56 disks in a single disk group is optimal for an EVA

I 'd buy that if you provide some explanation as to why?

> Never create a disk group that is not a multiple of 8

Does the EVA3000 have 8 backend loops? And if so how do you ensure that you pick one spindle in each backend loop?

So when CA is turned on regardles of which LUN is being sync-ed or accessed, aren't all 56 disks being accessesd? And aren't they stil being accessed for normal server I/O?

> The reason you are seeing the high I/O when the CA is turned off is most likely because the file systems

There are no filesystems, he is using raw volumes. CA does not do anything on the servers. The only additional I/O as a result of turning of CA may be some buffer flushing which should not be sustained.