Simpler Navigation for Servers and Operating Systems - Please Update Your Bookmarks
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
If you have bookmarked forums or discussion boards in Servers and Operating Systems, we suggest you check and update them as needed.
Showing results for 
Search instead for 
Did you mean: 

Disk caching with Oracle

Paul Rohde

Disk caching with Oracle

We are looking to purchase a new server with a VA7400 disk subsystem for our Oracle database. This subsystem comes with disk caching. The cache is mirrored and the system contains a battery backup.

Currently and previously we have just used JBOD disk subsystems and mirrored with Mirror Disk UX.

My concern is the data corruption possiblities that could accure due to disk caching.

Does anyone have anthing good or bad to say about this configuration. HP tells me this is pretty solid, and they have many Oracle clients doing this.

Any input would be appreciated.
harry d brown jr
Honored Contributor

Re: Disk caching with Oracle

Corruption with disk cacheing? Possible, but very unlikely. I have never had the problem with the VA7400 or with EMC.

You want disk caching, because the IO is about a million times faster than waiting for an IO fetch or confirmation of a disk write.

live free or die
Live Free or Die
A. Clay Stephenson
Acclaimed Contributor

Re: Disk caching with Oracle

I haven't used the VA7400 but I have been using disk arrays with battery-backed caches for many years and have never experienced a problem. I have used what is probably the VA7400's more or less direct ancestor, the 12H AutoRAID, for many years without any loss of data. On these arrays, I have experienced disk failures, onboard controller failures, power supply failures, and battery replacements - all without the loss of any data or indeed with any downtime. All of the replacement were done completely on-line and the database never was aware of any problem. This is typical of all modern arrays.

Unless you are using raw/io (or the OnlineJFS equivalent), you really have the same problem if your host crashes after you have written to buffer cache but before you have actually written to disk. This is especially true if you are running async_io.

If you still want a high-performance array that specfically, intentionally uses no cache, check out XioTech's Magnitude at In this case, you would actually purchase two units are mirror them exactly as you would your JBODS - just a whole lot bigger.

Regards, Clay
If it ain't broke, I can fix that.
Bill Hassell
Honored Contributor

Re: Disk caching with Oracle

Actually, you probably have not used a disk without caching for the last several years. Your JBODs very likely had caching too. The cache is in the disk itself, not much, but has a few sectors at least. Disk caching is what gives modern disks the extra kick in performance.

Data corruption is just as likely to occur in the hundreds of circuits inside the disk as it might in the cache. And today's disks have very low failure rates. Usually the disks are scrapped because they are just too small rather than wearing out or failing electronically.

Generally, the larger the cache, the better the performance. Big disk arrays have gigabytes of RAM because disks are still way slower than memory.

Bill Hassell, sysadmin
Ryan Kogelheide
Frequent Advisor

Re: Disk caching with Oracle

As far as I know, Oracle will not use the disk write caching for the data files. Oracle has its own cache and makes specific API calls to make sure that writes have really occurred (for example, on a checkpoint).

The Oracle 8i HP-UX Administrator's Guide has this to say about Async IO and it should give you an idea about how Oracle goes about dealing with data writes:


Asynchronous I/O uses a special HP device driver to batch writes and reads to
shared memory segments. A number of writes/reads can be made with one system
call. The device driver kicks off multiple I/O operations at a low level where disk
scheduling can be optimized for maximum parallelization, and minimum HP-UX
This type of async is safe. Oracle is reliably notified if the data made it all the way to
disk or not. Transactions and database writes are not committed until Oracle knows
that the I/O has been completed.
The asynchronous I/O pseudo-driver on HP-UX allows the Oracle Server to
perform I/O to raw disk partitions using an asynchronous method, resulting in less
I/O overhead and higher throughput. You can use the asynchronous I/O
pseudo-driver on both HP 9000 Servers and Workstations.


Dennis J Robinson
Frequent Advisor

Re: Disk caching with Oracle


The cache on the 7400 is battery backed and should be impervious to corruption due to power failure.

The cache will provide performance boost on write() operations and sequential read operations out of oracle.

This has nothing to do with the async capabilities of Oracle.

Bill Mac, most modern disks do have small caches on board (1-4MB), but default HP-UX behavior is not to do "immediate reporting" on the JBOD type disks. Turning on "immediate reporting" can give - array like write times ( sub millisecond).

If your organization can afford it, use some smaller 15,000 RPM drives for the following heavy activity Oracle areas:

redo, rollback, temp. Datafiles and indexes can live on larger and slower drives.
You know the drill