Raw devices in Oracle - asyncdsk driver related

[TVS MURTY]

We have an L2000 server running HP-UX11 with Oracle8.1.6 DB. We are running a benchmarking activity to monitor/improve the performance. We are using raw devices on RAID(AutoRAID) for the DB.

In this regard I was going through various threads on
using raw devices. This is what I understand from the various posts and please correct me if I am wrong.

1. Setting fs_async to 1 will help only for File system i/o
and so shoudnot matter in our case. It is 0 in our system.

2. I would go to sam-->kernel config-->drivers-->and enable the asyncdsk(asynchronous disk pseudo driver). Rebuild the kernel.

Now my questions are:

Will this create the /dev/async and /dev/asyncdsk in
/dev ?
Or do I have to create them with mknod?
(Please note that these entries are not present right now).

Can someone give the sequence of steps to do next that are related to setprivgrp ?
What needs to be done in Oracle ?
What else needs to be done? How to check whether async i/o is working or not?
Any patches I have to check for before doing all this?

Thank you all for your help.

TVS

[Stefan Farrelly]

There is an awful lot of work to do to get all this setup!

First point is why are you using a slow old AutoRaid on a nice new fast L-class ? The internal drives on the L-class will be running at 40 MB/s and the slow old AutoRaid will only run a max of about 20 MB/s !! Its like buying a Porsche and putting a skoda engine inside it.

For best performance+reliability you can use Raw logical volumes for your Oracle database.
For best performance but not so good reliability (data integrity) you can use async IO, but most people dont becuase its risky to your data - better to use Raw if you really want performance+reliability. It sounds like you do want max performance - so get rid of the AutoRaid for starters - IMHO.

[Printaporn_1]

Checking that Asynchronous i/o is being used
================================================
Async i/o is being used if both the following are true:
a. /dev/async is open by DBWR
b. the relevant init.ora partameter is set (see Section 2.2)

To check if /dev/async is open by DBWR, do one of:
a. % fuser /dev/async
b. %lsof -p
lsof can be downloaded from ftp://vic.cc.purdue.edu/pub/tools/unix/lsof
c. use glance/gpm to check files opened by DBWR

[Printaporn_1 · Accepted solution]

below information is from Oracle Metalink website

2.0 Configuring asynchronous i/o
================================
aio requires configuration of both Oracle and HP-UX

2.1 HP-UX Configuration
-----------------------
a. create the /dev/async character device
% /sbin/mknod /dev/async c 101 0x0
% chown oracle:dba /dev/async
% chmod 660 /dev/async

b. configure the async driver in the kernel
Using SAM
-> Kernel Configuration
-> Drivers
-> the driver is called 'asyncdsk'
Generate new kernel
Reboot

c. set max_async_ports
Using SAM
-> Kernel Configuration
-> Configurable Parameters
-> max_async_ports

max_async_ports limits the maximum number of processes that can concurrently
use /dev/async. Set this parameter to the sum of
'processes' from init.ora + number of background processes

The background processes started at instance startup will open /dev/async
twice.

If max_async_ports is reached, subsequent processes will use synchronous i/o.


d. set aio_max_ops
Using SAM
-> Kernel Configuration
-> Configurable Parameters
-> aio_max_ops

aio_max_ops limits the maximum number of asynchronous i/o operations that
can be queued at any time. Set this parameter to the default value (2048),
and monitor over time (use glance).

e. if HP-UX patch PHKL_22126 (or one that supersedes it) is installed, then
see Section 3.0

2.2 Oracle Configuration
------------------------
The following init.ora parameters are required.

a. pre 7.3.0
no init.ora parameters required
b. 7.3.X
use_async_io = TRUE
c. 8.X
disk_asynch_io = TRUE

[Carlos Fernandez Riera]

After include asyn_disk and compile kernel , and reboot, file /dev/asyncdsk must exist.

Oracle needs /dev/async. So
mknod /dev/async c 101 0x000000
chown orauser:dbagroup /dev/async
chmod 660 /dev/async

Then you must set setprivgrp:

vi /etc/privgroup
MLOCK dbagroup
:x


and run setptivgrp
setprivgrp


Change fs_async to false. Archived redologs whithout async <-> raws async.

Regards.

[TVS MURTY]

Thank you all for your replies. I would try this out
shortly.

Stefan: Ours is a development system and
we are trying this so that it can be implement
it on a production system which has FC60 RAID.
But what you said was quite revealing.

How does OS handle crash recovery incase of
raw devices(as there is nothing to do fsck on) ?

Thank you all once again,

TVS

[Animesh Chakraborty]

Hi TVS,
You said "How does OS handle crash recovery incase of
raw devices(as there is nothing to do fsck on) ? "...
In case of raw device there is no file system..so no file system corruption..so no fsck business :)..
It is better to go for raw .....
Regards
Animesh

[Animesh Chakraborty]

Hi again,
forgot to give you the link
http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0x7e97abe92dabd5118ff10090279cd0f9,00.html

[TVS MURTY]

Animesh says that there is no corruption involved in using raw devices. But Stefan says 'don't use async
if you want reliability' which means that using raw devices with asyncdsk is not reliable.

Can this be clarified?

Thank you,

TVS

[Animesh Chakraborty]

Hi TVS,
The difference between the async i/o and the synchronous i/o is that async does
not wait for confirmation of the write before moving on to the next task. ***This
does increase the speed of the disk performance at the expense of ROBUSTNESS. ***
Synchronous I/O waits for acknowledgement of the write (or fail) before
continuing on. The write can have physically taken place or could be in the
buffer cache but in either case, acknowledgement has been sent. In the case of
async, no waiting.

I have seen many installation with raw device without any problem at all.
But while doing lv activity like creation of logical volumes etc.you must be very carefull as SAM will show it unused and by mistake someone may delete it.

Thanks
Animesh