Re: EMC and Tuning Oracle: Manuals are wrong?

It gets worse and worse.

One horrid thought about print servers and file servers - these tend to handle large I/Os (especially Windows print servers !). The EMC algorithms tend to be biased (I understand) to handling large I/Os.

SO ... The small random I/Os from your database will effectively get a lower priority than your print jobs.

The mirroring may help a bit - at least you have double the number of spindles to read from, so the I/O contention (queuing effect) will be reduced a bit.

How many disks in total, and are the hypervolumes being used as print-server space being mirrored too ?

Have a look at my web-site - there is an article about picking block sizes for Oracle databases to suit the hardware configuration; it includes a simple C program to exercise disks in the same way as an Oracle database. This may give you a clue about how fast/slow the reads get when the print/file server side of the system is busy.

BTW - Even a very large cache on an EMC does little to help with a system that does large numbers of small reads - most of them tend to be read through cache: the cache tends to help writes though.

--

Jonathan Lewis
Yet another Oracle-related web site: www.jlcomp.demon.co.uk

benryan_at_my-deja.com wrote in message <7ke7bt$qg3$1_at_nnrp1.deja.com>...
>I simplified the actual situation a little bit. There are infact
>8 physical disk setup as mirrored pairs. (i.e. 4 logical disks)
>The Oracle Database has half of each logical disk. The tablespaces
>are spread across the disks in the traditional way, (tables are
>separated from indexes, redo logs on their own. system, rbs, temp
>squashed on to the remaining disk). The other servers are Novell and
>Windows-NT servers performing as file and print servers. Which bothers
>me even more because there will no particular pattern to the disk I/O
>on these servers! Oh, the EMC only has 1Gb of cache, the minimum!
>
Received on Fri Jun 18 1999 - 18:35:55 CDT