Thursday, July 29, 2010

Installing Oracle 9i Real Application Cluster (RAC) on Red Hat Linux Advanced Server

********Written by Ranjeet Singh from Oracle India Corporation.**********



The following procedure is a step-by-step guide (Cookbook) with tips and information for installing Oracle 9i Real Application Cluster (RAC) on Red Hat Linux Advanced Server 2.1. It shows how I installed Oracle 9i Real Application Cluster on three RH AS 2.1 servers. Among other things, this article covers Raw Devices, Oracle Cluster File System (OCFS), and FireWire-Based Shared Storage. Note that OCFS is not required for 9i RAC. In fact, I never use OCFS for RAC systems. However, this article covers OCFS since some people want to know how to configure and use OCFS.

The primary goal of this article is to show how to quickly install Oracle9i RAC on RH AS 2.1. I welcome emails from any readers with comments, suggestions, or corrections. You can find my email address at the bottom of this website.

If you have never installed Oracle9i on Linux before, then I recommend that you first try to install an Oracle9i database on Linux by following the steps in my other article Installing Oracle9i on RedHat Linux.

This article covers the following subjects and steps:

Introduction

* General
* Important Notes
* Oracle9i RAC Setup
* Shared Disks Storage
General
FireWire-Based Shared Storage for Linux

Pre-Installation Steps for All Clustered RAC Nodes

* Installing Red Hat Advanced Server
Installing Software Packages (RPMs)
* Upgrading the Linux Kernel
General
Upgrading the Linux Kernel for FireWire Shared Disks Only
* Configuring Public and Private Network
* Configuring Shared Storage Devices
General
Configuring FireWire-Based Shared Storage
Automatic Scanning of FireWire-Based Shared Storage
* Creating Oracle User Accounts
* Setting Oracle Environments
* Sizing Oracle Disk Space for Database Software
* Creating Oracle Directories
* Creating Partitions on Shared Storage Devices
General
Creating Partitions for OCFS
Creating Partitions for Raw Devices
* Installing and Configuring Oracle Cluster File Systems (OCFS)
Installing OCFS
Installing OCFS for FireWire Shared Disks Only
Configuring OCFS
Additional Changes for Configuring OCFS for FireWire Drive
Creating OCFS File Systems
Mounting OCFS File Systems
Configuring the OCFS File Systems to Mount Automatically at Startup
Additional Changes for FireWire Storage to mount OCFS File Systems Automatically at Startup
* Installing the "hangcheck-timer" Kernel Module
The hangcheck-timer.o Module
Installing the hangcheck-timer.o Module
Configuring and Loading the hangcheck-timer Module
* Setting up RAC Nodes for Remote Access
* Checking Packages (RPMs)
* Sizing Swap Space
* Adjusting Network Settings
* Setting Shared Memory
* Checking /tmp Space
* Setting Semaphores
* Setting File Handles

Setting Up Oracle 9i Cluster Manager

* General
Checking OCFS and rsh
Downloading and Extracting Oracle Patch Set
* Installing Oracle 9i Cluster Manager
Creating the Cluster Manager Quorum File
Installing Oracle9i Cluster Manager 9.2.0.1.0
Applying Oracle9i Cluster Manager 9.2.0.4.0 Patch Set
* Configuring Oracle 9i Cluster Manager
* Starting and Stopping Oracle 9i Cluster Manager

Installing Oracle 9i Real Application Cluster

* General
* Installing Oracle 9i Database Software with Real Application Cluster
Creating the Shared Configuration File for srvctl
Installing Oracle9i 9.2.0.1.0 Database Software with Oracle9i Real Application Cluster
Applying Oracle9i 9.2.0.4.0 Patch Set

Creating an Oracle 9i Real Application Cluster (RAC) Database

* Starting Oracle Global Services
* Creating the Database
Using OCFS for Database Files and Other Files
Using Raw Devices for Database Files and Other Files
Running Oracle Database Configuration Assistant

Transparent Application Failover (TAF)

* Introduction
* Testing Transparent Application Failover (TAF) on the New Installed RAC Cluster
Setup
Example of a Transparent Application Failover


Introduction *************************************


General
Oracle Real Application Cluster (RAC) is a cluster system at the application level. It uses shared disk architecture that provides scalability for all kind of applications. Applications without any modifications can use the RAC database.

Since the requests in a RAC cluster are spread evenly across the RAC instances, and since all instances access the same shared storage, addition of server(s) require no architecture changes etc. And a failure of a single RAC node results only in the loss of scalability and not in the loss of data since a single database image is utilized.


Important Notes
There are few important notes that might be useful to know before installing Oracle9i RAC:

(*) If you want to install Oracle9i RAC using FireWire drive(s), make sure to read first FireWire-Based Shared Storage for Linux!

(*) At the time of this writing, there is a bug that prevents you from successfully installing and running Oracle9i RAC using OCFS on FireWire drives on RH AS 2.1. Note that FireWire-based shared storage for Oracle9i RAC is experimental! See Setting Up Linux with FireWire-Based Shared Storage for Oracle9i RAC for more information. At the time of this writing, the only option is to use raw devices for all partitions on the FireWire drives. However, you might be lucky and get RAC working using OCFS on FireWire drives in RH AS 2.1. And this article will show you how to do it in case you are one of the lucky ones :)

(*) If you want to setup a FireWire shared drive using raw devices for all Oracle files, then keep in mind that Linux uses the SCSI layer for FireWire drives. This means that you can only create 14 raw devices on a single FireWire drive. Since /dev/sda16 is really /dev/sdb, you have 15 partitions minus 1 partition for the extended partition. Therefore you can create only 14 raw devices on a single FireWire disk. This means that you might have to buy a second FireWire drive.

(*) See also Oracle 9i RAC Problems and Errors
Oracle9i RAC Setup
For this article I used the following Oracle setup:
RAC node Database Name Oracle SID $ORACLE_BASE Oracle Datafile Directory
--------------- ------------- ---------- ------------ ----------------------------
rac1pub/rac1prv orcl orcl1 /opt/oracle/ /var/opt/oracle/oradata/orcl
rac2pub/rac2prv orcl orcl2 /opt/oracle/ /var/opt/oracle/oradata/orcl
rac3pub/rac3prv orcl orcl3 /opt/oracle/ /var/opt/oracle/oradata/orcl

Shared Disks Storage
General

A requirement for Oracle9i RAC cluster is a set of servers with shared disk access and interconnect connectivity. Since each instance in a RAC system must have access to the same database files, a shared storage is required that can be accessed from all RAC nodes concurrently.

The shared storage space can be used as raw devices, or by using a cluster file system. This article will address raw devices and Oracle's Cluster File System OCFS. Note that Oracle9i RAC provides it's own locking mechanisms and therefore it does not rely on other cluster software or on the operating system for handling locks.

FireWire-Based Shared Storage for Linux

Shared Storage can become expensive. If you just want to check out the advanced features of Oracle9i RAC without spending too much money, I'd recommend to buy an external FireWire-Based Shared Storage for Oracle9i RAC. Caveat: You can download a patch from Oracle for FireWire-Based Shared Storage for Oracle9i RAC, but Oracle does not support the patch. It is intended for testing and demonstration only! See Setting Up Linux with FireWire-Based Shared Storage for Oracle9i RAC for more information.

Note that it is very important to get a FireWire-Based Shared Storage that allows concurrent access for more than one server. Otherwise the disk(s) and partitions can only be seen by one server at a time. Therefore, make sure the FireWire drive(s) have a chipset that supports concurrent access for at least two servers or more. If you have already a FireWire drive, you can check the maximum supported logins (concurrent access) by following the steps as outlined under Configuring FireWire-Based Shared Storage.

For test purposes I used an external 250 GB and 200 GB Maxtor hard drive which support a maximum of 3 concurrent logins. Here are the technical specifications for these FireWire drives:
- Vendor: Maxtor
- Model: OneTouch
- Mfg. Part No. or KIT No.: A01A200 or A01A250
- Capacity: 200 GB or 250 GB
- Cache Buffer: 8 MB
- Spin Rate: 7200 RPM
- "Combo" Interface: IEEE 1394 and SPB-2 compliant (100 to 400 Mbits/sec) plus USB 2.0 and USB 1.1 compatible
Here are links where these drives can be bought:
Maxtor 200GB One Touch Personal Storage External USB 2.0/FireWire Hard Drive
Maxtor 250GB One Touch Personal Storage External USB 2.0/FireWire Hard Drive

The FireWire adapter I'm using is a StarTech 4 Port IEEE-1394 PCI Firewire Card. Don't forget that you will also need a FireWire hub if you want to connect more than 2 RAC nodes to the FireWire drive(s).

Pre-Installation Steps for All Clustered RAC Nodes

The following steps need to be performed on all nodes of the RAC cluster unless it says otherwise!
Installing Red Hat Advanced Server
You can find the installation guide for installing Red Hat Linux Advanced Server under Red Hat Enterprise Linux Manuals.

You cannot download Red Hat Linux Advanced Server, you can only download the source code. If you want to get the binary CDs, you have to buy it at http://www.redhat.com/software/rhel/.

Installing Software Packages (RPMs)

You don't have to install all RPMs when you want to run an Oracle9i RAC database on Red Hat Advanced Server. You are fine when you select the Installation Type "Advanced Server" and when you don't select the Package Group "Software Development". There are only a few other RPMs that are required for installing Oracle9i RAC. These other RPMs are covered in this article.

Make sure that no firewall is selected during the installation.
Upgrading the Linux Kernel

General

Using the right Red Hat Enterprise Linux kernel is very important for an Oracle database. Beside important fixes and improvements, the hangcheck-timer.o module comes now with newer Red Hat Enterprise Linux kernel versions which is a requirement for a RAC system. Therefore it is important to follow the steps as outlined under Upgrading the Linux Kernel unless you are using FireWire shared drives (see below).


Upgrading the Linux Kernel for FireWire Shared Disks ONLY

You can download a patch from Oracle for FireWire-Based Shared Storage for Oracle9i RAC, but Oracle does not support the patch. It is intended for testing and demonstration only! See Setting Up Linux with FireWire-Based Shared Storage for Oracle9i RAC for more information.

Download the experimental kernel for FireWire shared drives from http://oss.oracle.com/projects/firewire/files/old.

There are two experimental kernels for FireWire shared drives, one for UP machines and one for SMP machines. To install the kernel for a single CPU machine, run the following command:
su - root
rpm -ivh --nodeps kernel-2.4.20-18.10.1.i686.rpm
Note that the above command does not upgrade your existing kernel. This is my preferred method since I always want to have the option to go back to the old kernel in case the new kernel causes problems or doesn't come up.

To make sure that the right kernel is booted, check the /etc/grub.conf file if you use GRUB, and change the "default" attribute if necessary. Here is an example:
default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title Red Hat Linux (2.4.20-18.10.1)
root (hd0,0)
kernel /vmlinuz-2.4.20-18.10.1 ro root=/dev/hda1 hdc=ide-scsi
initrd /initrd-2.4.20-18.10.1.img
title Red Hat Linux Advanced Server-up (2.4.9-e.25)
root (hd0,0)
kernel /boot/vmlinuz-2.4.9-e.25 ro root=/dev/hda1 hdc=ide-scsi
initrd /boot/initrd-2.4.9-e.25.img

In this example, the "default" attribute is set to "0" which means that the the experimental FireWire kernel 2.4.20-18.10.1 will be booted. If the "default" attribute would be set to "1", the 2.4.9-e.25 kernel would be booted.

After you installed the new kernel, reboot the server:
su - root
reboot
Once you are sure that you don't need the old kernel anymore, you can remove the old kernel by running:
su - root
rpm -e
When you remove the old kernel, you don't need to make any changes to the /etc/grub.conf file.
Configuring Public and Private Network
Each RAC node should have at least one static IP address for the public network and one static IP address for the private cluster interconnect.

The private networks are critical components of a RAC cluster. The private networks should only be used by Oracle to carry Cluster Manager and Cache Fusion inter-node connection. A RAC database does not require a separate private network, but using a public network can degrade database performance (high latency, low bandwidth). Therefore the private network should have high-speed NICs (preferably one gigabit or more) and it should only be used by Oracle9i RAC and Cluster Manager.

It is recommended that private network addresses are managed using the /etc/hosts file. This avoids the problem of making DNS, NIS, etc. a single point of failure for the database cluster.

Here is an example how the /etc/hosts could look like:
# Public hostnames - public network

192.168.10.1 rac1pub.puschitz.com rac1pub # RAC node 1
192.168.10.2 rac2pub.puschitz.com rac2pub # RAC node 2
192.168.10.3 rac3pub.puschitz.com rac3pub # RAC node 3

# Private hostnames, private network - interconnect

192.168.1.1 rac1prv.puschitz.com rac1prv # RAC node 1
192.168.1.2 rac2prv.puschitz.com rac2prv # RAC node 2
192.168.1.3 rac3prv.puschitz.com rac3prv # RAC node 3

If you are trying to check out the advanced features of Oracle9i RAC on a cheap system where you don't have two Ethernet adapters, you could assign both server names (public and private) to the same IP adddress. For example:
192.168.1.1 rac1prv rac1pub # RAC node 1 - for server with single network adapter
192.168.1.2 rac2prv rac2pub # RAC node 2 - for server with single network adapter
192.168.1.3 rac3prv rac3pub # RAC node 3 - for server with single network adapter

To configure the network interfaces, run the following command on each node:
su - root
redhat-config-network

Configuring Shared Storage Devices
General

For instructions on how to setup a shared storage device on Red Hat Advanced Server, see the installation instructions of the manufacturer.

Configuring FireWire-Based Shared Storage

First make sure the experimental kernel for FireWire was installed and the server has been rebooted (see Upgrading the Linux Kernel for FireWire Shared Disks Only):
# uname -r
2.4.20-18.10.1

To load the kernel modules/drivers with the right options etc., add the following entries to the /etc/modules.conf file:
options sbp2 sbp2_exclusive_login=0
post-install sbp2 insmod sd_mod
post-remove sbp2 rmmod sd_mod
It is important that the parameter sbp2_exclusive_login of the Serial Bus Protocol module sbp2 is set to zero to allow multiple hosts to log into or to access the FireWire storage at the same time. The second line makes sure the SCSI disk driver module sd_mod is loaded as well since sbp2 needs the SCSI layer. The SCSI core support module scsi_mod will be loaded automatically if sd_mod is loaded - there is no need to make an entry for it.

Now try to load the firewire stack:
su - root
modprobe ohci1394 # Load OHCI 1394 kernel module (my FireWire drive is OHCI 1394 compliant)
modprobe sbp2 # Load Serial Bus Protocol 2 kernel module
#
If everything worked fine, the following modules should now be loaded:
su - root
# lsmod |egrep "ohci1394|sbp2|ieee1394|sd_mod|scsi_mod"
sd_mod 13564 0 (unused)
sbp2 20000 0 (unused)
scsi_mod 119768 2 [sd_mod sbp2]
ohci1394 28384 0 (unused)
ieee1394 60352 0 [sbp2 ohci1394]
#

If the ieee1394 module was not loaded, then your FireWire adapter might not be supported.
I'm using the StarTech 4 Port IEEE-1394 PCI Firewire Card which works great:
# lspci
...
00:0c.0 FireWire (IEEE 1394): VIA Technologies, Inc. OHCI Compliant IEEE 1394 Host Controller (rev 46)
...

To detect the external FireWire drives, download the rescan-scsi-bus.sh script from http://oss.oracle.com/projects/firewire/files/old. Copy the script to /usr/local/bin and make sure it has the right access permissions:
su - root
chmod 755 /usr/local/bin/rescan-scsi-bus.sh

Now run the script to rescan the SCSI bus and to add the FireWire drive to the system:
su - root
# /usr/local/bin/rescan-scsi-bus.sh
Host adapter 0 (sbp2_0) found.
Scanning for device 0 0 0 0 ...
NEW: Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: Maxtor Model: OneTouch Rev: 0200
Type: Direct-Access ANSI SCSI revision: 06
1 new device(s) found.
0 device(s) removed.
#

When you run dmesg, you should see entries similar to this example:
# dmesg
...
ohci1394_0: OHCI-1394 1.0 (PCI): IRQ=[9] MMIO=[fedff000-fedff7ff] Max Packet=[2048]
ieee1394: Device added: Node[00:1023] GUID[0010b920008c85cb] [Maxtor]
ieee1394: Device added: Node[01:1023] GUID[00110600000032a0] [Linux OHCI-1394]
ieee1394: Host added: Node[02:1023] GUID[00110600000032c7] [Linux OHCI-1394]
ieee1394: Device added: Node[04:1023] GUID[00110600000032d0] [Linux OHCI-1394]
SCSI subsystem driver Revision: 1.00
scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
ieee1394: sbp2: Query logins to SBP-2 device successful
ieee1394: sbp2: Maximum concurrent logins supported: 3
ieee1394: sbp2: Number of active logins: 0
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: sbp2: Node[00:1023]: Max speed [S400] - Max payload [2048]
scsi singledevice 0 0 0 0
Vendor: Maxtor Model: OneTouch Rev: 0200
Type: Direct-Access ANSI SCSI revision: 06
blk: queue cc28b214, I/O limit 4095Mb (mask 0xffffffff)
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 490232832 512-byte hdwr sectors (250999 MB)
sda: sda1 sda2
scsi singledevice 0 0 1 0
scsi singledevice 0 0 2 0
scsi singledevice 0 0 3 0
scsi singledevice 0 0 4 0
scsi singledevice 0 0 5 0
scsi singledevice 0 0 6 0
scsi singledevice 0 0 7 0
...
The kernel reports that the FireWire drive can concurrently be shared by 3 servers (see "Maximum concurrent logins supported:"). It is very important that you have a drive where the chip supports concurrent access for the nodes. The "Number of active logins:" shows how many servers are already sharing the drive before this server added this drive to the system.

Problems:
If the rescan-scsi-bus.sh script says: "0 new device(s) found.", then try to run rescan-scsi-bus.sh several times. If this doesn't work, try to run the following commands:
su - root
/usr/local/bin/rescan-scsi-bus.sh -r
/usr/local/bin/rescan-scsi-bus.sh
If this doesn't work either, remove the modules, power off/on the FireWire drive, and rerun the whole procedure. This always worked for me when my FireWire drive was not recognized by the system. You could also use the "fwocfs" service script to reload the modules and to rescan the the SCSI bus. See Automatic Scanning of FireWire-Based Shared Storage for more information.

Note that if you have a USB device attached, the system might not be able to recognice your FireWire drive!
If everything worked fine, you should now be able to see the partitions of the FireWire drives:
su - root
# fdisk -l

Disk /dev/sda: 255 heads, 63 sectors, 30515 cylinders
Units = cylinders of 16065 * 512 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 2550 20482843+ 83 Linux
...

Automatic Scanning of FireWire-Based Shared Storage

To have the FireWire drives automatically added to the system after each reboot, I wrote a small service script called "fwocfs" for FireWire drives. This service script also mounts OCFS filesystems if configured, see Configuring the OCFS File Systems to Mount Automatically at Startup for more information. Therefore, this service script can be used for OCFS filesystems or for raw devices. It is also very useful for reloading the kernel modules for the FireWire drives and for rescanning the SCSI bus if your FireWire drives were not recognized. The "fwocfs" script can be downloaded from here.

To install this service script, run the following commands:
su - root
# cp fwocfs /etc/rc.d/init.d
# chmod 755 /etc/rc.d/init.d/fwocfs
# chkconfig --add fwocfs
# chkconfig --list fwocfs
fwocfs 0:off 1:off 2:on 3:on 4:on 5:on 6:off
#
Now start the new fwocfs service:
su - root
# service fwocfs start
Loading ohci1394: [ OK ]
Loading sbp2: [ OK ]
Rescanning SCSI bus: [ OK ]
#
The next time when you reboot the server, the FireWire drives should have been added to the system automatically.

If for any reason the FireWire drives have not been recognized, try to restart the "fwocfs" service script with the following command:
su - root
service fwocfs restart

Creating Oracle User Accounts
If you use OCFS, it is important that the UID of "oracle" and GID of "oinstall" are the same across all RAC nodes. Otherwise the Oracle files on the OCFS filesystems on some nodes would either be "unowned", or even be owned by another user account. In my setup the UID and GID of oracle:dba is 700:700.
su - root
groupadd -g 700 dba # group of users to be granted with SYSDBA system privilege
groupadd -g 701 oinstall # group owner of Oracle files
useradd -c "Oracle software owner" -u 700 -g oinstall -G dba oracle
passwd oracle
To verify the oracle account, enter the following command:
# id oracle
uid=700(oracle) gid=701(oinstall) groups=701(oinstall),700(dba)

For more information on the "oinstall" group account, see When to use "OINSTALL" group during install of oracle.
Setting Oracle Environments
When you set the Oracle environment variables for the RAC nodes, make sure to assign each RAC node a unique Oracle SID!

In my test setup, the database name is "orcl" and the Oracle SIDs are "orcl1" for RAC node one, "orcl2" for RAC node two, etc.
# Oracle Environment
export ORACLE_BASE=/opt/oracle
export ORACLE_HOME=/opt/oracle/product/9.2.0
export ORACLE_SID=orcl1 # Each RAC node must have a unique Oracle SID! E.g. orcl1, orcl2,...
export ORACLE_TERM=xterm
# export TNS_ADMIN= Set if sqlnet.ora, tnsnames.ora, etc. are not in $ORACLE_HOME/network/admin
export NLS_LANG=AMERICAN;
export ORA_NLS33=$ORACLE_HOME/ocommon/nls/admin/data
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
export LD_LIBRARY_PATH

# Set shell search paths
export PATH=$PATH:$ORACLE_HOME/bin

# Specify that native threads should be used when running Java software
export THREADS_FLAG=native
Native threads are implemented using pthreads (POSIX threads) which take full advantage of multiprocessors. Java also supports green threads. Green threads are user-level threads, implemented within a single Unix process, and run on a single processor.

Make sure to add these environment settings to the ~oracle/.bash_profile file if you use bash. This will make sure that the Oracle environment variables are always set when you login as "oracle", or when you switch to the user "oracle" by running "su - oracle".
Sizing Oracle Disk Space for Database Software
You will need about 2.5 GB for the Oracle9i RAC database software.

Here is the estimate file space usage on one of my RAC servers:
$ du -s -m /opt/oracle
2344 /opt/oracle

Creating Oracle Directories
At the time of this writing, OCFS only supports Oracle Datafiles and a few other files. Therefore OCFS should not be used for Shared Oracle Home installs. See Installing and Configuring Oracle Cluster File Systems (OCFS) for more information. Therefore I'm creating a separate, individual ORACLE_HOME directory on each and every RAC server for the Oracle binaries.


To create the Oracle directories, go to:
Creating Oracle Directories

To create the Oracle datafile directory for the ORCL database, run the following commands:
su - oracle
mkdir -p /var/opt/oracle/oradata/orcl
chmod -R 775 /var/opt/oracle

Some directories are not replicated properly to other nodes when RAC is installed. Therefore the following commands must be run on all cluster nodes:
su - oracle

# For Cluster Manager
mkdir -p $ORACLE_HOME/oracm/log

# For SQL*Net Listener
mkdir -p $ORACLE_HOME/network/log
mkdir -p $ORACLE_HOME/network/trace

# For database instances
mkdir -p $ORACLE_HOME/rdbms/log
mkdir -p $ORACLE_HOME/rdbms/audit

# For Oracle Intelligent Agent
mkdir -p $ORACLE_HOME/network/agent/log
mkdir -p $ORACLE_HOME/network/agent/reco

Creating Partitions on Shared Storage Devices
The partitioning of a shared disk needs to be performed on only one RAC node!

General

Note that it is important for the Redo Log files to be on the shared disks as well.

To partition the disks, you can use the fdisk utility:
su - root
fdisk
For SCSI disks (including FireWire disks), stands for device names like /dev/sda, /dev/sdb, /dev/sdc, dev/sdd , etc. Be careful to use the right device name!

Here is an example how to create a new 50 GB partition on drive /dev/sda:
su - root
# fdisk /dev/sda

The number of cylinders for this disk is set to 30515.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sda: 255 heads, 63 sectors, 30515 cylinders
Units = cylinders of 16065 * 512 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 6375 51207156 83 Linux

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (6376-30515, default 6376):
Using default value 6376
Last cylinder or +size or +sizeM or +sizeK (6376-30515, default 30515): +50GB

Command (m for help): p

Disk /dev/sda: 255 heads, 63 sectors, 30515 cylinders
Units = cylinders of 16065 * 512 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 6375 51207156 83 Linux
/dev/sda2 6376 12750 51207187+ 83 Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.
#
For more information on fdisk, see the fdisk(8) man page.


Creating Partitions for OCFS

If you use OCFS for database files and other Oracle files, you can create several partitions on your shared storage for the OCFS filesystems. If you use a FireWire disk, you could create one large partition on the disk which should make things easier.

For more information on how to install OCFS and how to mount OCFS filesystems on partitions, see Installing and Configuring Oracle Cluster File Systems (OCFS).

After you finished creating the partitions, I recommend that you reboot the kernel on all RAC nodes to make sure all partitions are recognized by the kernel on all RAC nodes:
su - root
reboot

Creating Partitions for Raw Devices

In the follwing example I will show how to setup raw devices on FireWire disk(s) for all Oracle files including the Cluster Manager Quorum File and the Shared Configuration File for srvctl. It requires more administrative work to use raw devices for Oracle datafiles. And using a FireWire drive makes it even more complicated since there is a hard limit of 15 partitions per SCSI drive since the FireWire drive uses the SCSI layer.

In the following example I will setup 19 partitions for an Oracle9i RAC database using raw devices on two FireWire disks. Keep in mind that we can only have 14 partitions on a single FireWire drive not including the Extended Partition.

Using 2 MB for the Cluster Manager Quorum File (raw device) should be more than sufficient. And using 20 MB for the Shared Configuration File (raw device) for the Oracle Global Services daemon should be more than sufficient as well.

After I created the following 19 partitions on one RAC node, I bound the raw devices by running the raw command on all RAC nodes:
su - root

# /dev/sda1: Left it untouched since I want to keep it for my OCFS filesystem

raw /dev/raw/raw1 /dev/sda2 # Used for the Cluster Manager Quorum File
raw /dev/raw/raw2 /dev/sda3 # Used for the Shared Configuration file for srvctl

# /dev/sda4: Used for creating the Extended Partition which starts as /dev/sda5.

raw /dev/raw/raw3 /dev/sda5 # spfileorcl.ora
raw /dev/raw/raw4 /dev/sda6 # control01.ctl
raw /dev/raw/raw5 /dev/sda7 # control02.ctl
raw /dev/raw/raw6 /dev/sda8 # indx01.dbf
raw /dev/raw/raw7 /dev/sda9 # system01.dbf
raw /dev/raw/raw8 /dev/sda10 # temp01.dbf
raw /dev/raw/raw9 /dev/sda11 # tools01.dbf
raw /dev/raw/raw10 /dev/sda12 # undotbs01.dbf
raw /dev/raw/raw11 /dev/sda13 # undotbs02.dbf
raw /dev/raw/raw12 /dev/sda14 # undotbs03.dbf
raw /dev/raw/raw13 /dev/sda15 # users01.dbf

# /dev/sda16: Cannot be used for a partition. /dev/sda16 is really the same device node as /dev/sdb.

# /dev/sdb1 - /dev/sdb3: Left it unused.
# /dev/sdb4: Used for creating the Extended Partition which starts as /dev/sdb5.

raw /dev/raw/raw14 /dev/sdb5 # redo01.log (Group# 1 Thread# 1)
raw /dev/raw/raw15 /dev/sdb6 # redo02.log (Group# 2 Thread# 1)
raw /dev/raw/raw16 /dev/sdb7 # redo03.log (Group# 3 Thread# 2)
raw /dev/raw/raw17 /dev/sdb8 # orcl_redo2_2.log (Group# 4 Thread# 2)
raw /dev/raw/raw18 /dev/sdb9 # orcl_redo3_1.log (Group# 5 Thread# 3)
raw /dev/raw/raw19 /dev/sdb10 # orcl_redo3_2.log (Group# 6 Thread# 3)

To see all bindings, run:
su - root
raw -qa

NOTE: It is important to make sure that the above binding commands are added to the /etc/rc.local file! The binding for raw devices has to be done after each reboot.


Set the permissions and ownership for the 19 raw devices on all all RAC nodes:
su - root

for i in `seq 1 19`
do
chmod 660 /dev/raw/raw$i
chown oracle.dba /dev/raw/raw$i
done

Optionally, you can create soft links to the raw devices. If you do this it will be transparent to you whether you use OCFS or raw devices when you run the Oracle Database Assistant. In the following example I use the exact same file names which the Database Configuration Assistant will use for the cluster system by default.

To create the soft links, run the following command on all RAC nodes.
su - oracle
ln -s /dev/raw/raw1 /var/opt/oracle/oradata/orcl/CMQuorumFile
ln -s /dev/raw/raw2 /var/opt/oracle/oradata/orcl/SharedSrvctlConfigFile

ln -s /dev/raw/raw3 /var/opt/oracle/oradata/orcl/spfileorcl.ora

ln -s /dev/raw/raw4 /var/opt/oracle/oradata/orcl/control01.ctl
ln -s /dev/raw/raw5 /var/opt/oracle/oradata/orcl/control02.ctl
ln -s /dev/raw/raw6 /var/opt/oracle/oradata/orcl/indx01.dbf
ln -s /dev/raw/raw7 /var/opt/oracle/oradata/orcl/system01.dbf
ln -s /dev/raw/raw8 /var/opt/oracle/oradata/orcl/temp01.dbf
ln -s /dev/raw/raw9 /var/opt/oracle/oradata/orcl/tools01.dbf
ln -s /dev/raw/raw10 /var/opt/oracle/oradata/orcl/undotbs01.dbf
ln -s /dev/raw/raw11 /var/opt/oracle/oradata/orcl/undotbs02.dbf
ln -s /dev/raw/raw12 /var/opt/oracle/oradata/orcl/undotbs03.dbf
ln -s /dev/raw/raw13 /var/opt/oracle/oradata/orcl/users01.dbf

ln -s /dev/raw/raw14 /var/opt/oracle/oradata/orcl/redo01.log
ln -s /dev/raw/raw15 /var/opt/oracle/oradata/orcl/redo02.log
ln -s /dev/raw/raw16 /var/opt/oracle/oradata/orcl/redo03.log
ln -s /dev/raw/raw17 /var/opt/oracle/oradata/orcl/orcl_redo2_2.log
ln -s /dev/raw/raw18 /var/opt/oracle/oradata/orcl/orcl_redo3_1.log
ln -s /dev/raw/raw19 /var/opt/oracle/oradata/orcl/orcl_redo3_2.log

After you finished creating the partitions, I recommend that you reboot the kernel on all RAC nodes to make sure all partitions are recognized by the kernel on all RAC nodes:
su - root
reboot

Installing and Configuring Oracle Cluster File Systems (OCFS)
Note that OCFS is not required for 9i RAC. In fact, I never use OCFS for RAC systems. However, this article covers OCFS since some people want to know how to configure and use OCFS.

The Oracle Cluster File System (OCFS) was developed by Oracle to overcome the limits of Raw Devices and Partitions. It also eases administration of database files because it looks and feels just like a regular file system.

At the time of this writing, OCFS only supports Oracle Datafiles and a few other files:
- Redo Log files
- Archive log files
- Control files
- Database datafiles
- Shared quorum disk file for the cluster manager
- Shared init file (srv)

Oracle says that in the later part of 2003 they will support Shared Oracle Home installs. So don't install the Oracle software on OCFS yet. See Oracle Cluster File System for more information. In this article I'm creating a separate, individual ORACLE_HOME directory on local server storage for each and every RAC node.

NOTE:
If files on the OCFS file system need to be moved, copied, tar'd, etc., or if directories need to be created on OCFS, then the standard file system commands mv, cp, tar,... that come with the OS should not be used. These OS commands can have a major OS performance impact if they are being used on the OCFS file system. Therefore, Oracle's patched file system commands should be used instead.
It is also important to note that some 3rd vendor backup tools make use of standard OS commands like tar.


Installing OCFS

You can download the OCFS RPMs for RH AS 2.1 from http://oss.oracle.com/projects/ocfs/files/RedHat/RHAS2.1/ (make sure to use the latest OCFS version!). For OCFS RPMs for FireWire shared disks, see Installing OCFS for FireWire Shared Disks Only.

To find out which OCFS driver you need for your server, run:
$ uname -a
Linux rac1pub 2.4.9-e.25smp #1 Fri Oct 6 18:27:21 EDT 2003 i686 unknown

For my SMP servers with <=4GB RAM I downloaded the following OCFS RPMs (make sure to use the latest OCFS version!):
ocfs-2.4.9-e-smp-1.0.9-9.i686.rpm # OCFS driver for SMP kernels
ocfs-tools-1.0.9-9.i686.rpm
ocfs-support-1.0.9-9.i686.rpm
To install the RPMs for SMP kernels on servers with <= 4 GB RAM, run:
su - root
rpm -ivh ocfs-2.4.9-e-smp-1.0.9-9.i686.rpm \
ocfs-tools-1.0.9-9.i686.rpm \
ocfs-support-1.0.9-9.i686.rpm
To install the OCFS RPMs for uniprocessor kernels, run:
su - root
rpm -ivh ocfs-2.4.9-e-1.0.9-9.i686.rpm
ocfs-tools-1.0.9-9.i686.rpm \
ocfs-support-1.0.9-9.i686.rpm

NOTE: It is also very important to install an updated fileutils package that adds support for the O_DIRECT flag which controls the use of synchronous I/O on file systems such as OCFS. This updated package is required for better performance. If commands like cp, mv, dd, etc. don't support the O_DIRECT flag when used on OCFS file systems, then you can experience a big performance impact. For instance, some 3rd party products use the dd command for doing the backup.

Therefore, it is recommended to download the fileutils package version 4.1-10.4 (RHSA-2003:310) or a newer version from https://rhn.redhat.com. To upgrade the RPM, run:
su - root
rpm -Uvh fileutils-4.1-10.4.i386.rpm

Installing OCFS for FireWire Shared Disks Only

For FireWire kernels, download the latest OCFS RPMs for RH AS 2.1 from http://oss.oracle.com/projects/firewire/files.

To find out which OCFS driver you need for your server, run:
$ uname -a
Linux rac1pub 2.4.9-e.25 #1 Fri Oct 6 18:27:21 EDT 2003 i686 unknown

To install the OCFS RPMs for uniprocessor kernels, run e.g. (make sure to use the latest OCFS version!):
su - root
rpm -Uvh ocfs-2.4.20-18.10-1.0.10-2.i386.rpm \
ocfs-tools-1.0.10-2.i386.rpm \
ocfs-support-1.0.10-2.i386.rpm
I would also recommend to update the fileutils package, see note above.


Configuring OCFS

To generate the /etc/ocfs.conf file, run the ocfstool tool. But before you run the GUI tool, make sure you have set the DISPLAY environment variable. You can find a short description about the DISPLAY environment variable here

Run the ocfstool tool as root to generate the /etc/ocfs.conf file:
su - root
ocfstool
- Select "Task" - Select "Generate Config"
- Select the interconnect interface (private network interface), e.g. rac1prv
- Confirm the values displayed and exit
The generated /etc/ocfs.conf file will appear similar to the following example:
$ cat /etc/ocfs.conf
#
# ocfs config
# Ensure this file exists in /etc#

node_name = rac1prv
node_number =
ip_address = 92.168.1.1
ip_port = 7000
guid = 167045A6AD4E9EAB33620010B5C05E7F
The guid entry is the unique group user ID. This ID has to be unique for each node. You can create the above file without the ocfstool tool by editing the /etc/ocfs.conf file manually and by running ocfs_uid_gen -c to assign/update the guid value in this file.

To load the ocfs.o kernel module, run:
su - root
# /sbin/load_ocfs
/sbin/insmod ocfs node_name=rac1prv ip_address=92.168.1.1 ip_port=7000 cs=1812 guid=582A8C17A7555FA41D350010B5C05E7F
Using /lib/modules/2.4.9-e-ABI/ocfs/ocfs.o
#
Note that the load_ocfs command doesn't have to be executed again once everything has been setup for the OCFS filesystems, see Configuring the OCFS File Systems to Mount Automatically at Startup.


Additional Changes for Configuring OCFS for FireWire Drives

If a FireWire storage is being used, the OCFS File Systems won't mount automatically at startup with the steps described above. Some addional changes need to be made.

When I run load_ocfs on a system with the experimental FireWire kernel, it returns the following error message:
su - root
# load_ocfs
/sbin/insmod ocfs node_name=rac1prv ip_address=192.168.1.1 ip_port=7000 cs=1841 guid=BB669BEFEA6C470479D10050DA1A2424 comm_voting=1
insmod: ocfs: no module by that name found
load_ocfs: insmod failed
#
The ocfs.o module can be found here:
su - root
# rpm -ql ocfs-2.4.20
/lib/modules/2.4.20-ABI/ocfs
/lib/modules/2.4.20-ABI/ocfs/ocfs.o
#
So for the experimental kernel for FireWire drives, I manually created a link for the ocfs.o file:
su - root
mkdir /lib/modules/`uname -r`/kernel/drivers/addon/ocfs
ln -s `rpm -qa | grep ocfs-2 | xargs rpm -ql | grep "/ocfs.o$"` \
/lib/modules/`uname -r`/kernel/drivers/addon/ocfs/ocfs.o
Now you should be able to load the OCFS module and the output will look similar to this example:
su - root
# /sbin/load_ocfs
/sbin/insmod /lib/modules/2.4.20-ABI/ocfs/ocfs.o node_name=rac1prv ip_address=192.168.1.1 ip_port=7000 cs=1833 guid=01A553F1FD7B719E9D290010B5C05E7F comm_voting=1
#

Creating OCFS File Systems

Before you continue with the next steps, make sure you've created all needed partitions on your shared storage.

Under Creating Oracle Directories I created the /var/opt/oracle/oradata/orcl directory for the Oracle data files. In the following example I will create one large OCFS filesystem and mount it on /var/opt/oracle/oradata/orcl.

The following steps for creating the OCFS filesystem(s) should only be executed on one RAC node!

To create the OCFS filesystems, you can run the ocfstool:
su - root
ocfstool
- Select "Task" - Select "Format"

Alternatively, you can run the "mkfs.ocfs" command to create the OCFS filesystems:
su - root
mkfs.ocfs -F -b 128 -L /var/opt/oracle/oradata/orcl -m /var/opt/oracle/oradata/orcl \
-u `id -u oracle` -g `id -g oracle` -p 0775
Cleared volume header sectors
Cleared node config sectors
Cleared publish sectors
Cleared vote sectors
Cleared bitmap sectors
Cleared data block
Wrote volume header
#
For SCSI disks (including FireWire disks), stands for devices like /dev/sda, /dev/sdb, /dev/sdc, dev/sdd, etc. Be careful to use the right device name! For this article I created a large OCFS filesystem on /dev/sda1.

mkfs.ocfs options:

-F Forces to format existing OCFS volume
-b Block size in kB. The block size must be a multiple of the Oracle block size. Oracle recommends to set the block size for OCFS to 128.
-L Volume label
-m Mount point for the device (in this article "/var/opt/oracle/oradata/orcl")
-u UID for the root directory (in this article "oracle")
-g GID for the root directory (in this article "oinstall")
-p Permissions for the root directory


Mounting OCFS File Systems

As I mentioned previously, for this article I created one large OCFS fileystem on /dev/sda1. To mount the OCFS filesystem, run:
su - root
# mount -t ocfs /dev/sda1 /var/opt/oracle/oradata/orcl
Now run the ls command on all RAC nodes to check the ownership:
# ls -ld /var/opt/oracle/oradata/orcl
drwxrwxr-x 1 oracle oinstall 131072 Aug 18 18:07 /var/opt/oracle/oradata/orcl
#
NOTE: If the above ls command does not display the same ownership on all RAC nodes (oracle:oinstall), then the "oracle" UID and the "oinstall" GID are not the same accross the RAC nodes, see Creating Oracle User Accounts for more information.

If you get the following error:
su - root
# mount -t ocfs /var/opt/oracle/oradata/orcl
mount: wrong fs type, bad option, bad superblock on /dev/sda1,
or too many mounted file systems
You probably tried to mount the OCFS filesystem on more than one server at a time. Try to wait until the OCFS file system has been mounted on one server before you mount it on the other server.


Configuring the OCFS File Systems to Mount Automatically at Startup

To ensure the OCFS filesystems are mounted automatically during a reboot, the OCFS mount points need to be added to the /etc/fstab file.

Add lines to the /etc/fstab file similar to the following example:
/dev/sda1 /var/opt/oracle/oradata/orcl ocfs _netdev 0 0
The "_netdev" option prevents the OCFS filesystem from being mounted until the network has first been enabled on the system (see mount(8)) which provides access to the storage device.

To make sure the ocfs.o kernel module is loaded and the OCFS file systems are mounted during the boot process, run:
su - root
# chkconfig --list ocfs
ocfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off
If the flags are not set to "on" as marked in bold, run the following command:
su - root
# chkconfig ocfs on
You can also start the "ocfs" service manually by running:
su - root
# service ocfs start
When you run this command it will not only load the ocfs.o kernel module but it will also mount the OCFS filesystems as configured in /etc/fstab.


Additional Changes for FireWire Storage to mount OCFS File Systems Automatically at Startup

If a FireWire storage is being used, the OCFS File Systems won't mount automatically at startup with the "ocfs" service script. In Automatic Scanning of FireWire-Based I already introduced the "fwocfs" service script which can be used for mounting the OCFS file systems automatically for FireWire drives.

If you have not installed the "fwocfs" service script yet, follow the steps as outlined in Automatic Scanning of FireWire-Based. Since the "ocfs" service script does not work for FireWire drives, disable the "ocfs" service script. The "fwocfs" service script can now be used instead.
su - root
chkconfig ocfs off
Now start the new fwocfs service:
su - root
# service fwocfs start
Loading ohci1394: [ OK ]
Loading sbp2: [ OK ]
Rescanning SCSI bus: [ OK ]
Loading OCFS: [ OK ]
Mounting OCFS file systems: [ OK ]
#
To see the mounted OCFS file systems, you can run the following command:
su - root
# service fwocfs status
/dev/sda1 on /var/opt/oracle/oradata/orcl type ocfs (rw,_netdev)
#
Next time when you reboot the server, the OCFS filesystems should be mounted automatically for the FireWire drives.
Installing the "hangcheck-timer" Kernel Module
To monitor system health of the cluster and to reset a RAC node in case of a failure, Oracle 9.0.1 and 9.2.0.1 used a userspace watchdog daemon called watchdogd. But starting with Oracle 9.2.0.2, this deamon has been deprecated by a Linux kernel module called hangcheck-timer which addresses availability and reliability problems much better. This hang-check timer is loaded into the kernel and checks if the system hangs. It sets a timer and checks the timer after a certain amount of time. If a configurable threshold is exceeded, it will reboot the machine.
The hangcheck-timer module is not required for Oracle Cluster Manager operation, but Oracle highly recommends it.

The hangcheck-timer.o Module

The hangcheck-timer module uses a kernel-based timer to periodically check the system task scheduler. This timer resets the node when the system hangs or pauses. This module uses the Time Stamp Counter (TSC) CPU register which is a counter that is incremented at each clock signal. The TCS offers much more accurate time measurements since this register is updated by the hardware automatically. For more information, see Project: hangcheck-timer.

Installing the hangcheck-timer.o Module

Originally, hangcheck-timer was shipped by Oracle, but this module comes now with RH AS starting with kernel versions 2.4.9-e.12 and higher. So hangcheck-timer is now part of all newer RH AS kernels. If you upgraded the kernel as outlined in Upgrading the Linux Kernel, then you should have the hangcheck-timer module on your node:
# find /lib/modules -name "hangcheck-timer.o"
/lib/modules/2.4.9-e.25smp/kernel/drivers/char/hangcheck-timer.o
#
Therefore you don't need to install the Oracle Cluster Manager patch (e.g. patch 2594820) before you install the Oracle9i database patch set.

Configuring and Loading the hangcheck-timer Module

The hangcheck-timer module parameters hangcheck-tick and hangcheck-margin need to be coordinated with the MissCount parameter in the $ORACLE_HOME/oracm/admin/cmcfg.ora file for the Cluster Manager.

The following two hangcheck-timer module parameter can be set:
hangcheck_tick
This parameter defines the period of time between checks of system health.
The default value is 60 seconds. Oracle recommends to set it to 30 seconds.
hangcheck_margin
This parameter defines the maximum hang delay that should be tolerated before
hangcheck-timer resets the RAC node. It defines the margin of error in seconds.
The default value is 180 seconds. Oracle recommends to set it to 180 seconds.


These two parameters indicate how long a RAC node must hang before the hangcheck-timer module will reset the system. A node reset will occur when the following is true:
system hang time > (hangcheck_tick + hangcheck_margin)

To load the module with the right parameter settings, you can run the following command:
# su - root
# /sbin/insmod hangcheck-timer hangcheck_tick=30 hangcheck_margin=180
# grep Hangcheck /var/log/messages |tail -1
Oct 18 23:05:36 rac1prv kernel: Hangcheck: starting hangcheck timer (tick is 30 seconds, margin is 180 seconds).
#
But the right way to load modules with the correct parameters is to make entries in the /etc/modules.conf file. To do that, add the following line to the /etc/modules.conf file:
# su - root
# echo "options hangcheck-timer hangcheck_tick=30 hangcheck_margin=180" >> /etc/modules.conf
Now you can run modprobe to load the module with the configured parameters in /etc/modules.conf:
# su - root
# modprobe hangcheck-timer
# grep Hangcheck /var/log/messages |tail -1
Oct 18 23:10:23 rac1prv kernel: Hangcheck: starting hangcheck timer (tick is 30 seconds, margin is 180 seconds).
#
Note: To ensure the hangcheck-timer module is loaded after each reboot, add the modprobe command to the /etc/rc.local file.
Setting up RAC Nodes for Remote Access
When you run the Oracle Installer on a RAC node, it will use the rsh feature for copying Oracle software to other RAC nodes. Therefore, the oracle account on the RAC node where runIntaller is launched must be trusted by all other RAC nodes. This means that you should be able to run rsh, rcp, and rlogin on this RAC node against other RAC nodes without a password. The rsh daemon validates users using the /etc/hosts.equiv file and the .rhosts file found in the user's (oracle's) home directory. Unfortunatelly, SSH is not supported.

The following steps show how I setup a trusted environment for the "oracle" account on all RAC nodes.

First make sure the "rsh" RPMs are installed on all RAC nodes:
rpm -q rsh rsh-server
If rsh is not installed, run the following command:
su - root
rpm -ivh rsh-0.17-5.i386.rpm rsh-server-0.17-5.i386.rpm
To enable the "rsh" service, the "disable" attribute in the /etc/xinetd.d/rsh file must be set to "no" and xinetd must be refreshed. This can be done by running the following commands:
su - root
chkconfig rsh on
chkconfig rlogin on
service xinetd reload
To allow the "oracle" user account to be trusted among the RAC nodes, create the /etc/hosts.equiv file:
su - root
touch /etc/hosts.equiv
chmod 600 /etc/hosts.equiv
chown root.root /etc/hosts.equiv
And add all RAC nodes to the /etc/hosts.equiv file similar to the following example:
$ cat /etc/hosts.equiv
+rac1prv oracle
+rac2prv oracle
+rac3prv oracle
+rac1pub oracle
+rac2pub oracle
+rac3pub oracle
In the preceding example, the second field permits only the oracle user account to run rsh commands on the specified nodes. For security reasons, the /etc/hosts.equiv file should be owned by root and the permissions should be set to 600. In fact, some systems will only honor the content of this file if the owner of this file is root and the permissions are set to 600.

Now you should be able to run rsh against each RAC node without having to provide the password for the oracle account:
su - oracle
$ rsh rac1prv ls -l /etc/hosts.equiv
-rw------- 1 root root 49 Oct 19 13:18 /etc/hosts.equiv
$ rsh rac2prv ls -l /etc/hosts.equiv
-rw------- 1 root root 49 Oct 19 14:39 /etc/hosts.equiv
$ rsh rac3prv ls -l /etc/hosts.equiv
-rw------- 1 root root 49 Oct 19 14:42 /etc/hosts.equiv
$

Checking Packages (RPMs)
Some packages will be missing when you selected the Installation Type "Advanced Server" during the Red Hat Advanced Server installation.

The following additional RPMs will be required:
rpm -q gcc cpp compat-libstdc++ glibc-devel kernel-headers binutils \
pdksh ncurses4
To install these RPMS, run:
su - root
rpm -Uvh cpp-2.96-108.1.i386.rpm \
glibc-devel-2.2.4-26.i386.rpm \
kernel-headers-2.4.9-e.3.i386.rpm \
gcc-2.96-108.1.i386.rpm \
binutils-2.11.90.0.8-12.i386.rpm \
pdksh-5.2.14-13.i386.rpm \
ncurses4-5.0-5.i386.rpm
I recommend using the latest RPM versions.
Adjusting Network Settings
In Oracle 9.2.0.1 and onwards, Oracle now uses UDP as the default protocol on Linux for interprocess communication, such as cache fusion buffer transfers between the instances.
It is strongly suggested to adjust the default and maximum send buffer size (SO_SNDBUF socket option) to 256 KB, and the default and maximum receive buffer size (SO_RCVBUF socket option) to 256 KB. The receive buffers are used by TCP and UDP to hold received data until is is read by the application. The receive buffer cannot overflow because the peer is not allowed to send data beyond the buffer size window. This means that datagrams will be discarded if they don't fit in the socket receive buffer. This could cause the sender to overwhelm the receiver.

The default and maximum window size can be changed in the proc file system without reboot:
su - root
sysctl -w net.core.rmem_default=262144 # Default setting in bytes of the socket receive buffer
sysctl -w net.core.wmem_default=262144 # Default setting in bytes of the socket send buffer
sysctl -w net.core.rmem_max=262144 # Maximum socket receive buffer size which may be set by using the SO_RCVBUF socket option
sysctl -w net.core.wmem_max=262144 # Maximum socket send buffer size which may be set by using the SO_SNDBUF socket option
To make the change permanent, add the following lines to the /etc/sysctl.conf file, which is used during the boot process:
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=262144
net.core.wmem_max=262144

Sizing Swap Space
It is important to follow the steps as outlined in Sizing Swap Space.
Setting Shared Memory
It is important to follow the steps as outlined in Setting Shared Memory.
Checking /tmp Space
It is important to follow the steps as outlined in Checking /tmp Space.
Setting Semaphores
It is recommended to follow the steps as outlined in Setting Semaphores.
Setting File Handles
It is recommended to follow the steps as outlined in Setting File Handles.

Setting Up Oracle 9i Cluster Manager
General
At this point the pre-installation steps for all RAC nodes should be completed.

Checking OCFS and rsh

Before you continue, make sure the OCFS filesystems are mounted on all RAC nodes and that rsh really works for the oracle account on all RAC nodes. Here is the output of the df command on my RAC test system:
su - oracle
rsh rac1prv df | grep oradata
/dev/sda1 51205216 45152 51160064 1% /var/opt/oracle/oradata/orcl
rsh rac2prv df | grep oradata
/dev/sda1 51205216 45152 51160064 1% /var/opt/oracle/oradata/orcl
rsh rac3prv df | grep oradata
/dev/sda1 51205216 45152 51160064 1% /var/opt/oracle/oradata/orcl

rsh rac1pub df | grep oradata
/dev/sda1 51205216 45152 51160064 1% /var/opt/oracle/oradata/orcl
rsh rac2pub df | grep oradata
/dev/sda1 51205216 45152 51160064 1% /var/opt/oracle/oradata/orcl
rsh rac3pub df | grep oradata
/dev/sda1 51205216 45152 51160064 1% /var/opt/oracle/oradata/orcl

Downloading and Extracting Oracle Patch Set

It is wise to first patch the Oracle 9iR2 software before creating the database. To patch Oracle9iR2 (Cluster Manager, etc.), download the Oracle 9i Release 2 Patch Set 3 Version 9.2.0.4.0 for Linux x86 (patch number 3095277) from metalink.oracle.com.

Copy the downloaded "p3095277_9204_LINUX.zip" file to e.g. /tmp and run the following commands:
su - oracle
$ unzip p3095277_9204_LINUX.zip
Archive: p3095277_9204_LINUX.zip
inflating: 9204_lnx32_release.cpio
inflating: README.html
inflating: patchnote.css
$
$ cpio -idmv < 9204_lnx32_release.cpio
Disk1/stage/locks
Disk1/stage/Patches/oracle.apache.isqlplus/9.2.0.4.0/1/DataFiles/bin.1.1.jar
Disk1/stage/Patches/oracle.apache.isqlplus/9.2.0.4.0/1/DataFiles/lib.1.1.jar
...

Installing Oracle 9i Cluster Manager
In order to install the Cluster Manager (Node Monitor) oracm on all RAC nodes, runInstaller has to be launched on only one RAC node, e.g. rac1prv. For more information on how to start runInstaller, see Starting runInstaller.

Creating the Cluster Manager Quorum File

The Cluster Manager and Node Monitor oracm accepts registration of Oracle instances to the cluster and it sends ping messages to Cluster Managers (Node Monitor) on other RAC nodes. If this heartbeat fails, oracm uses a quorum file or a quorum partition on the shared disk to distinguish between a node failure and a network failure. So if a node stops sending ping messages, but continues writing to the quorum file or partition, then the other Cluster Managers can recognize it as a network failure. The Cluster Manager (CM) uses now UDP instead of TCP for communication.

Once the Oracle Cluster Manager is running on all RAC nodes, OUI will automatically recognice all nodes on the cluster. When you run the Installer, you will see the "Cluster Node Selection" screen if the oracm process is running on the RAC nodes. This also means that you can launch runInstaller on one RAC node and have the Oracle software automatically installed on all other RAC nodes as well.
• For OCFS Filesystems:
In the following "Oracle Cluster Manager" installation I will use a quorum file on the OCFS file system called /var/opt/oracle/oradata/orcl/CMQuorumFile which will be accessible by all RAC nodes. It is important that all RAC nodes are accessing the same quorum file! To create the quorum file, run the following command on one RAC node:
su - oracle
touch /var/opt/oracle/oradata/orcl/CMQuorumFile
NOTE Regarding Cluster Manager Quorum File on OCFS on FireWire Drives:

If you have the quorum file on an OCFS (1.0.10-2 OCFS) file system on the FireWire drive, then the Cluster Manager oracm will only come up on one RAC node. If you start oracm on a second RAC node, it will crash. Until this bug is resolved, a raw device needs to be used for FireWire drives.
• For Raw Devices:
In Creating Partitions for Raw Devices I created a 2 MB partitions (raw device) for the quorum file on my external FireWire drive. The name of my quorum partition on the FireWire drive is /dev/sda2 which is bound to /dev/raw/raw1.
Optionally, you can create a soft link to this raw device. If you haven't done it yet as show in Creating Partitions for Raw Devices, then do it now by running the following command on all RAC nodes:
su - oracle
ln -s /dev/raw/raw1 /var/opt/oracle/oradata/orcl/CMQuorumFile

Installing Oracle9i Cluster Manager 9.2.0.1.0

To install the Oracle Cluster Manager, insert the Oracle 9i R2 Disk 1 and launch /mnt/cdrom/runInstaller. These steps only need to be performed on one RAC node, the node you are installing from.

Mount the disk in one terminal:
su - root
mount /mnt/cdrom
And in another terminal, run the following commands.
su - oracle
$ /mnt/cdrom/runInstaller

- Welcome Screen: Click Next
- Inventory Location: Click OK
- Unix Group Name: Use "oinstall".
- Root Script Window: Open another window, login as root, and run /tmp/orainstRoot.sh
on the node where you are running this installation (runInstaller).
After you run the script, click Continue.
- File Locations: Check the defaults. I used the default values and clicked Next.
- Available Products: Select "Oracle Cluster Manager 9.2.0.1.0"
- Public Node Information:
Public Node 1: rac1pub
Public Node 2: rac2pub
Public Node 3: rac3pub
Click Next.
- Private Node Information:
Private Node 1: rac1prv
Private Node 2: rac2prv
Private Node 3: rac3prv
Click Next.
- WatchDog Parameter: Accept the default value and click Next. We won't use the Watchdog.
- Quorum Disk Information: /var/opt/oracle/oradata/orcl/CMQuorumFile
Click Next.
- Summary: Click Install
- When installation has completed, click Exit.

Applying Oracle9i Cluster Manager 9.2.0.4.0 Patch Set

To patch the Oracle Cluster Manager, launch the installer either from /mnt/cdrom/runInstaller or from $ORACLE_HOME/bin/runInstaller
su - oracle
$ $ORACLE_HOME/bin/runInstaller
- Welcome Screen: Click Next
- Inventory Location: Click Next
- File Locations: - Click "Browse for the Source"
- Navigate to the stage directory where the patch set is located.
On my system it is: "/tmp/Disk1/stage"
- Select the "products.jar" file.
- Click OK
- Click Next on the File Location screen
- Available Products: Select "Oracle9iR2 Cluster Manager 9.2.0.4.0
- Public Node Information:
Public Node 1: rac1pub
Public Node 2: rac2pub
Public Node 3: rac3pub
- Private Node Information:
Private Node 1: rac1prv
Private Node 2: rac2prv
Private Node 3: rac3prv
- Summary: Click Install
- When installation has completed, click Exit.

Configuring Oracle 9i Cluster Manager
The following changes have to be done on ALL RAC nodes.

It is not necessary to run the watchdogd daemon with the Oracle Cluster Manager 9.2.0.2 or with any newer version. Since watchdogd has been replaced with the hangcheck-timer kernel module, some files need to be updated.

The following changes need to be done if the Oracle9i Cluster Manager 9.2.0.1.0 has been patched to e.g. version 9.2.0.4.0 as described under Applying Oracle9i Cluster Manager 9.2.0.4.0 Patch Set.


REMOVE or comment out the following line(s) from the $ORACLE_HOME/oracm/admin/ocmargs.ora file:
watchdogd
REMOVE the following line(s) from the $ORACLE_HOME/oracm/admin/cmcfg.ora file:
WatchdogSafetyMargin=5000
WatchdogTimerMargin=60000
ADD the following line to the $ORACLE_HOME/oracm/admin/cmcfg.ora file:
KernelModuleName=hangcheck-timer
ADJUST the value of the MissCount parameter in the $ORACLE_HOME/oracm/admin/cmcfg.ora file based on the sum of the hangcheck_tick and hangcheck_margin values. The MissCount parameter must be set to at least 60 and it must be greater than the sum of hangcheck_tick + hangcheck_margin. In my example, hangcheck_tick + hangcheck_margin is 210. Therefore I set MissCount in $ORACLE_HOME/oracm/admin/cmcfg.ora to 215.
MissCount=215
My $ORACLE_HOME/oracm/admin/cmcfg.ora file looks as follows:
HeartBeat=15000
ClusterName=Oracle Cluster Manager, version 9i
PollInterval=1000
MissCount=215
PrivateNodeNames=rac1prv rac2prv rac3prv
PublicNodeNames=rac1pub rac2pub rac3pub
ServicePort=9998
CmDiskFile=/var/opt/oracle/oradata/orcl/CMQuorumFile
HostName=rac1prv
KernelModuleName=hangcheck-timer

MODIFY the $ORACLE_HOME/oracm/bin/ocmstart.sh file and comment out the following lines:
# watchdogd's default log file
#WATCHDOGD_LOG_FILE=$ORACLE_HOME/oracm/log/wdd.log

# watchdogd's default backup file
#WATCHDOGD_BAK_FILE=$ORACLE_HOME/oracm/log/wdd.log.bak

# Get arguments
#watchdogd_args=`grep '^watchdogd' $OCMARGS_FILE |\
# sed -e 's+^watchdogd *++'`

# Check watchdogd's existance
#if watchdogd status | grep 'Watchdog daemon active' >/dev/null
#then
# echo 'ocmstart.sh: Error: watchdogd is already running'
# exit 1
#fi

# Backup the old watchdogd log
#if test -r $WATCHDOGD_LOG_FILE
#then
# mv $WATCHDOGD_LOG_FILE $WATCHDOGD_BAK_FILE
#fi

# Startup watchdogd
#echo watchdogd $watchdogd_args
#watchdogd $watchdogd_args

Starting and Stopping Oracle 9i Cluster Manager
To start the Cluster Manager (CM) and Node Monitor oracm, run the following commands on all RAC nodes:
su - root
# . ~oracle/.bash_profile # Set Oracle environment
# $ORACLE_HOME/oracm/bin/ocmstart.sh
oracm &1 >/opt/oracle/product/9.2.0/oracm/log/cm.out &
#
# ps -ef |grep oracm
root 15249 1 0 Nov08 pts/2 00:00:00 oracm
root 15251 15249 0 Nov08 pts/2 00:00:00 oracm
root 15252 15251 0 Nov08 pts/2 00:00:00 oracm
root 15253 15251 0 Nov08 pts/2 00:00:00 oracm
root 15254 15251 0 Nov08 pts/2 00:00:04 oracm
root 15255 15251 0 Nov08 pts/2 00:00:00 oracm
root 15256 15251 0 Nov08 pts/2 00:00:00 oracm
root 15257 15251 0 Nov08 pts/2 00:00:00 oracm
root 15258 15251 0 Nov08 pts/2 00:00:00 oracm
root 15298 15251 0 Nov08 pts/2 00:00:00 oracm
root 15322 15251 0 Nov08 pts/2 00:00:00 oracm
root 15540 15251 0 Nov08 pts/2 00:00:00 oracm
#
NOTE:

Once the Cluster Manager is upgraded, oracm won't come up any more if you use OCFS. It will always die after a few seconds. To fix this run the following command on only one RAC node:
su - oracle
dd if=/dev/zero of=/var/opt/oracle/oradata/orcl/CMQuorumFile bs=4096 count=96
After that restart CM.

To stop oracm, you have to kill it:
su - root
pkill oracm
For more information on Oracle cluster administration, see Oracle9i Real Application Clusters Administration.


Note about Using the procps RPM:

If the procps RPM was installed, you will only see one oracm process in the process table when you run the ps command. That's because the ps command that comes with the procps RPM does not show a thread as a separate process in the ps output.
rpm -qf /bin/ps
procps-2.0.7-11

Installing Oracle 9i Real Application Cluster
General
Before you install the Oracle9i Real Application Cluster 9.2.0.1.0 software (RAC software + database software), you have to make sure that the pdksh and ncurses4 RPMs are installed on all RAC nodes! If these RPMs are not installed, you will get the following error message when you run $ORACLE_HOME/root.sh on each RAC node during the software installation:
...
error: failed dependencies:
libncurses.so.4 is needed by orclclnt-nw_lssv.Build.71-1
error: failed dependencies:
orclclnt = nw_lssv.Build.71-1 is needed by orcldrvr-nw_lssv.Build.71-1
error: failed dependencies:
orclclnt = nw_lssv.Build.71-1 is needed by orclnode-nw_lssv.Build.71-1
orcldrvr = nw_lssv.Build.71-1 is needed by orclnode-nw_lssv.Build.71-1
libscsi.so is needed by orclnode-nw_lssv.Build.71-1
libsji.so is needed by orclnode-nw_lssv.Build.71-1
error: failed dependencies:
orclclnt = nw_lssv.Build.71-1 is needed by orclserv-nw_lssv.Build.71-1
orclnode = nw_lssv.Build.71-1 is needed by orclserv-nw_lssv.Build.71-1
/bin/ksh is needed by orclserv-nw_lssv.Build.71-1
package orclman-nw_lssv.Build.71-1 is already installed

** Installation of LSSV did not succeed. Please refer
** to the Installation Guide at http://www.legato.com/LSSV
** and contact Oracle customer support if necessary.

To check for these RPMs, run the following command:
rpm -q pdksh ncurses4
To install these RPMs, run:
su - root
rpm -Uvh pdksh-5.2.14-13.i386.rpm ncurses4-5.0-5.i386.rpm

Installing Oracle 9i Database Software with Real Application Cluster
Creating the Shared Configuration File for srvctl

A shared configuration file is needed for the srvctl utility which is used to manage Real Application Clusters instances and listeners.
• For OCFS Filesystems:
To create the shared configuration file for srvctl, run the following command on one RAC node::
su - oracle
touch /var/opt/oracle/oradata/orcl/SharedSrvctlConfigFile
• For Raw Devices:
In Creating Partitions for Raw Devices I created a 20 MB partitions (raw device) for the shared configuration file. The device name of the shared configuration file is /dev/sda1 which is bound to /dev/raw/raw2.
Optionally, you can create a soft link to this raw device. If you haven't done it yet as show under Creating Partitions for Raw Devices, do it now by running the following command on all RAC nodes:
su - oracle
ln -s /dev/raw/raw2 /var/opt/oracle/oradata/orcl/SharedSrvctlConfigFile

Installing Oracle9i 9.2.0.1.0 Database Software with Oracle9i Real Application Cluster

To install the Oracle9i Real Application Cluster 9.2.0.1.0 software, insert the Oracle9iR2 Disk 1 and launch runInstaller. These steps only need to be performed on one node, the node you are installing from.

Mount the disk in one terminal:
su - root
mount /mnt/cdrom
And in another terminal, run the following commands. Do not change directory to /mnt/cdrom before running the runInstaller script, or you will be unable to unmount Disk1 and mount Disk2 and Disk3.
su - oracle
$ /mnt/cdrom/runInstaller
- Welcome Screen: Click Next
- Cluster Node Selection: Select/Highlight all RAC nodes using the shift key and the left mouse button.
Click Next
Note: If not all RAC nodes are showing up, or if the Node Selection Screen
does not appear, then the Oracle Cluster Manager (Node Monitor) oracm is probably not
running on all RAC nodes. See Starting and Stopping Oracle 9i Cluster Manager for more information.
- File Locations: Click Next
- Available Products: Select "Oracle9i Database 9.2.0.1.0" and click Next
- Installation Types: Select "Enterprise Edition" and click Next
- Database Configuration: Select "Software Only" and click Next
- Shared Configuration File Name:
Enter the name of an OCFS shared configuration file or the name of
the raw device name.
Select "/var/opt/oracle/oradata/orcl/SharedSrvctlConfigFile" and click Next
- Summary: Click Install.
When the window for running "root.sh" comes up, run it on ALL RAC servers before clicking "OK". See below.
- When installation has completed, click Exit.

When the Oracle Enterprise Manager Console comes up, don't install a database yet.

When the Install window displays "Performing remote operations (99%)", you will see a command like this one running on the RAC nodes:
bash -c /bin/sh -c cd /; cpio -idmuc
If this command is running, it shows that the Oracle software is currently being installed on the RAC node(s).

NOTE: There are still bugs that prevent Oracle sometimes from installing the Oracle software on all RAC nodes. If the Installer hangs at "Performing remote operations (99%)" and the above bash command is not running on the Oracle RAC nodes any more, then you need to abort the installation. One time I kept the Installer running the whole night without success. And one time I had to run the Installer five times because it was alway hanging at "Performing remote operations (99%)". A workaround would be to run runInstaller on all RAC nodes to install the software on each RAC node separately.


Applying Oracle9i 9.2.0.4.0 Patch Set

Before any other Oracle patches are applied, you first need to patch runInstaller in $ORACLE_HOME/bin.

But before runInstaller is started, the following commands must be run to avoid runInstaller from crashing:
su - oracle
cd $ORACLE_BASE/oui/bin/linux
ln -s libclntsh.so.9.0 libclntsh.so
If you don't create the link, runInstaller will crash with an error messages similar to this one:
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x40008e4a
Function name=_dl_lookup_symbol
Library=/lib/ld-linux.so.2

Current Java thread:
at java.lang.ClassLoader$NativeLibrary.find(Native Method)
at java.lang.ClassLoader.findNative(ClassLoader.java:1441)
at ssOiGenClassux22.linkExists(Native Method)
at sscreateLinkux.createLink(sscreateLinkux.java:256)
at sscreateLinkux.installAction(sscreateLinkux.java:83)
at oracle.sysman.oii.oiis.OiisCompActions.doActionWithException(OiisCompActions.java:1357)
at oracle.sysman.oii.oiis.OiisCompActions.doActionImpl(OiisCompActions.java:1157)
at oracle.sysman.oii.oiis.OiisCompActions.doAction(OiisCompActions.java:604)
at Patches.oracle.cartridges.context.v9_2_0_4_0.CompActions.doAction(Unknown Source)
at Patches.oracle.cartridges.context.v9_2_0_4_0.CompInstallPhase1.doActionP1createLink11(Unknown Source)
at Patches.oracle.cartridges.context.v9_2_0_4_0.CompInstallPhase1.stateChangeActions(Unknown Source)
at Patches.oracle.cartridges.context.v9_2_0_4_0.CompActions.stateChangeActions(Unknown Source)
at oracle.sysman.oii.oiic.OiicInstallActionsPhase$OiilActionThr.run(OiicInstallActionsPhase.java:604)
at oracle.sysman.oii.oiic.OiicInstallActionsPhase.executeProductPhases(OiicInstallActionsPhase.java:2199)
at oracle.sysman.oii.oiic.OiicInstallActionsPhase.doInstalls(OiicInstallActionsPhase.java:2052)
at oracle.sysman.oii.oiic.OiicInstallActionsPhase$OiInstRun.run(OiicInstallActionsPhase.java:2945)
at java.lang.Thread.run(Thread.java:484)

Dynamic libraries:
08048000-0804c000 r-xp 00000000 03:05 1044862 /opt/oracle/jre/1.3.1/bin/i386/native_threads/java
0804c000-0804d000 rw-p 00003000 03:05 1044862 /opt/oracle/jre/1.3.1/bin/i386/native_threads/java
40000000-40016000 r-xp 00000000 03:05 767065 /lib/ld-2.2.4.so
40016000-40017000 rw-p 00015000 03:05 767065 /lib/ld-2.2.4.so
40018000-40025000 r-xp 00000000 03:05 767061 /lib/i686/libpthread-0.9.so
40025000-40029000 rw-p 0000c000 03:05 767061 /lib/i686/libpthread-0.9.so
...
4bb27000-4bb2e000 r-xp 00000000 03:05 2415686 /opt/oracle/oui/bin/linux/libsrvm.so
4bb2e000-4bb2f000 rw-p 00006000 03:05 2415686 /opt/oracle/oui/bin/linux/libsrvm.so
4bf27000-4c823000 r-xp 00000000 03:05 1518276 /opt/oracle/product/9.2.0/lib/libclntsh.so.9.0
4c823000-4c8e5000 rw-p 008fb000 03:05 1518276 /opt/oracle/product/9.2.0/lib/libclntsh.so.9.0

Local Time = Sun Oct 19 22:17:55 2003
Elapsed Time = 163
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.3.1_02-b02 mixed mode)
#
# An error report file has been saved as hs_err_pid6574.log.
# Please refer to the file for further information.
#
#

To patch the runInstaller in $ORACLE_HOME/bin, run the following commands:
su - oracle
cd $ORACLE_HOME/bin
$ ./runInstaller
- Welcome Screen: Click Next
- Inventory Location: Click Next
- File Locations: - Click "Browse for the Source"
- Navigate to the stage directory where the patch set is located.
On my system it is: "/tmp/Disk1/stage"
- Select the "products.jar" file.
- Click OK
- Available Products: Select "Oracle Universal Installer 2.2.0.18.0
- Components Locations: Click Next
- Summary: Click Install
- When installation has completed, click Exit.

To patch the Oracle Software to Oracle9iR2 Patch Set 3 9.2.0.4, launch the Installer. These steps only need to be performed on one node, the node you are installing from.
su - oracle
cd $ORACLE_HOME/bin
$ ./runInstaller
- Welcome Screen: Click Next
- Inventory Location: Click Next
- Cluster Node Selection:Select/Highlight all RAC nodes using the shift key and the left mouse button.
Note: If not all RAC nodes are showing up, or if the Node Selection Screen
doesn't appear, then the Oracle Cluster Manager (Node Monitor) oracm is probably not
running on all RAC nodes. See Starting and Stopping Oracle 9i Cluster Manager for more information.
- File Locations: - Click "Browse for the Source"
- Navigate to the stage directory where the patch set is located.
On my system it is: "/tmp/Disk1/stage"
- Select the "products.jar" file.
- Click OK
- Available Products: Select "Oracle9iR2 Patch Set 3 9.2.0.4"
- Summary: Click Install
- When installation has completed, click Exit.

Run the root.sh script on all RAC nodes when prompted:

Creating an Oracle 9i Real Application Cluster (RAC) Database

Starting Oracle Global Services
To check if the Oracle Global Services daemon gsd is running, execute the following command:
su - oracle
$ gsdctl stat
GSD is not running on the local node
$
To initialize the shared configuration file, run the following command only on one RAC node:
su - oracle
$ srvconfig -init

If you get a PRKR-1064 error, then check if /var/opt/oracle/oradata/orcl/SharedSrvctlConfigFile file is accessable by all RAC nodes:
$ ls -l /var/opt/oracle/oradata/orcl/SharedSrvctlConfigFile
-rw-r--r-- 1 oracle oinstall 10565120 Nov 10 17:06 /var/opt/oracle/oradata/orcl/SharedSrvctlConfigFile
If you use raw devices, then your raw device for the shared configuration file is probably too small. Increase the size and try again.


To start the Global Services daemon gsd on all RAC nodes, run the following command on all RAC nodes:
su - oracle
$ gsdctl start
Successfully started GSD on local node
$

Creating the Database
Using OCFS for Database Files and Other Files

The Database Configuration Assistant will create the Oracle database files automatically on the OCFS filesystem if "dbca -datafileDestination /var/opt/oracle/oradata" is executed.

Using Raw Devices for Database Files and Other Files

Optionally, you can create soft links to the raw devices. In my setup I created soft links to /var/opt/oracle/oradata/orcl.
If you haven't created the soft links yet as shown in Creating Partitions for Raw Devices, run now the following commands on all RAC nodes since OCFS is not being used here:
su - oracle

ln -s /dev/raw/raw3 /var/opt/oracle/oradata/orcl/spfileorcl.ora

ln -s /dev/raw/raw4 /var/opt/oracle/oradata/orcl/control01.ctl
ln -s /dev/raw/raw5 /var/opt/oracle/oradata/orcl/control02.ctl
ln -s /dev/raw/raw6 /var/opt/oracle/oradata/orcl/indx01.dbf
ln -s /dev/raw/raw7 /var/opt/oracle/oradata/orcl/system01.dbf
ln -s /dev/raw/raw8 /var/opt/oracle/oradata/orcl/temp01.dbf
ln -s /dev/raw/raw9 /var/opt/oracle/oradata/orcl/tools01.dbf
ln -s /dev/raw/raw10 /var/opt/oracle/oradata/orcl/undotbs01.dbf
ln -s /dev/raw/raw11 /var/opt/oracle/oradata/orcl/undotbs02.dbf
ln -s /dev/raw/raw12 /var/opt/oracle/oradata/orcl/undotbs03.dbf
ln -s /dev/raw/raw13 /var/opt/oracle/oradata/orcl/users01.dbf

ln -s /dev/raw/raw14 /var/opt/oracle/oradata/orcl/redo01.log
ln -s /dev/raw/raw15 /var/opt/oracle/oradata/orcl/redo02.log
ln -s /dev/raw/raw16 /var/opt/oracle/oradata/orcl/redo03.log
ln -s /dev/raw/raw17 /var/opt/oracle/oradata/orcl/orcl_redo2_2.log
ln -s /dev/raw/raw18 /var/opt/oracle/oradata/orcl/orcl_redo3_1.log
ln -s /dev/raw/raw19 /var/opt/oracle/oradata/orcl/orcl_redo3_2.log

Running Oracle Database Configuration Assistant

Launch the Installer with the following option whether you use OCFS or raw devices (assuming you created soft links to the raw devices):
su - oracle
dbca -datafileDestination /var/opt/oracle/oradata

- Type of database: Select "Oracle Cluster Database"
- Operation: Select "Create a Database"
- Nodes: Click "Select All" (rac1pub, rac2pub, rac3pub) and click Next.
Note: If not all RAC nodes are showing up, then the Oracle Cluster Manager (Node Monitor)
oracm is probably not running correctly on all RAC nodes.
See Starting and Stopping Oracle 9i Cluster Manager for more information.
- Database Templates: Select "New Database"
- Database Identification: Global Database Name: orcl
SID Prefix: orcl
- Database Features: - Clear all boxes and confirm deletion of tablesspaces.
- Click "Standard database features"
- Clear all boxes and confirm deletion of tablesspaces.
- Click OK
- Click Next
- Database Connection Options:
Select "Dedication Server Mode"
- Initialization Parameters:
Click Next
- Database Storage: - Select Controlfile and delete control03.ctl (highlight and click Backspace)
- Click Next
- Creation Options: Click Finish
- Summary: Click OK

When prompted to perform another operation, click No.

Your RAC cluster should now be up and running:
su - oracle
$ srvctl status database -d orcl
Instance orcl1 is running on node rac1pub
Instance orcl2 is running on node rac2pub
Instance orcl3 is running on node rac3pub
$

Transparent Application Failover (TAF)
Introduction
Processes external to the Oracle9i RAC cluster control the Transparent Application Failover (TAF). This means that the failover types and methods can be unique for each Oracle Net client. The re-connection happens automatically within the OCI library which means that you do not need to change the client application to use TAF. Note that a Java thin client won't be reconnected automatically since it doesn't read the tnsnames.ora file.
Testing Transparent Application Failover (TAF) on the New Installed RAC Cluster
Setup

To test TAF on the new installed RAC cluster, configure the tnsnames.ora file for TAF on a non-RAC server where you have either the Oracle database software or the Oracle client software installed.

Here is an example how my /opt/oracle/product/9.2.0/network/admin/tnsnames.ora: looks like:
ORCL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1pub)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2pub)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac3pub)(PORT = 1521))
(LOAD_BALANCE = on)
(FAILOVER = on)
)
(CONNECT_DATA =
(SERVICE_NAME = orcl)
(FAILOVER_MODE =
(TYPE = session)
(METHOD = basic)
)
)
)

The following SQL statement can be used to check the sessions's failover type, failover method, and if a failover has occured:
select instance_name, host_name,
NULL AS failover_type,
NULL AS failover_method,
NULL AS failed_over
FROM v$instance
UNION
SELECT NULL, NULL, failover_type, failover_method, failed_over
FROM v$session
WHERE username = 'SYSTEM';

Example of a Transparent Application Failover

Here is an example of a Transparent Application Failover:
su - oracle
$ sqlplus system@orcl

SQL> select instance_name, host_name,
2 NULL AS failover_type,
3 NULL AS failover_method,
4 NULL AS failed_over
5 FROM v$instance
6 UNION
7 SELECT NULL, NULL, failover_type, failover_method, failed_over
8 FROM v$session
9 WHERE username = 'SYSTEM';

INSTANCE_NAME HOST_NAME FAILOVER_TYPE FAILOVER_M FAI
---------------- ---------- ------------- ---------- ---
orcl1 rac1prv
SESSION BASIC NO

SQL>

Now do a "shutdown abort" on "rac1prv" for instance "orcl1". You can use the srvctl utility to do this:
su - oracle
$ srvctl status database -d orcl
Instance orcl1 is running on node rac1pub
Instance orcl2 is running on node rac2pub
Instance orcl3 is running on node rac3pub
$
$ srvctl stop instance -d orcl -i orcl1 -o abort
$
$ srvctl status database -d orcl
Instance orcl1 is not running on node rac1pub
Instance orcl2 is running on node rac2pub
Instance orcl3 is running on node rac3pub
$

Now rerun the SQL statement:
SQL> select instance_name, host_name,
2 NULL AS failover_type,
3 NULL AS failover_method,
4 NULL AS failed_over
5 FROM v$instance
6 UNION
7 SELECT NULL, NULL, failover_type, failover_method, failed_over
8 FROM v$session
9 WHERE username = 'SYSTEM';


INSTANCE_NAME HOST_NAME FAILOVER_TYPE FAILOVER_M FAI
---------------- ---------- ------------- ---------- ---
orcl2 rac2prv
SESSION BASIC YES

SQL>

The SQL statement shows that the sessions has now been failed over to instance "orcl2".

ORACLE AUTOMATIC STORAGE MANAGEMENT :

Oracle Database 10g Automatic Storage Management (ASM) is an integrated volume manager and file system for Oracle database files, that supports single-instance Oracle Database and Oracle Real Application Clusters (Oracle RAC) configurations


ASM uses disk groups to store datafiles; an ASM disk group is a collection of disks that ASM manages as a unit. Within a disk group, ASM exposes a file system interface for Oracle database files. The content of files that are stored in a disk group are evenly distributed, or striped, to eliminate hot spots and to provide uniform performance across the disks. The performance is comparable to the performance of raw devices.


You can add or remove disks from a disk group while a database continues to access files from the disk group. When you add or remove disks from a disk group, ASM automatically redistributes the file contents and eliminates the need for downtime when redistributing the content.




***********************************************************************************


About ASM Instances

An ASM instance is built on the same technology as an Oracle Database instance. An ASM instance has a System Global Area (SGA) and background processes that are similar to those of Oracle Database.


However, because ASM performs fewer tasks than a database, an ASM SGA is much smaller than a database SGA. In addition, ASM has a minimal performance effect on a server. ASM instances mount disk groups to make ASM files available to database instances; ASM instances do not mount databases.

ASM metadata is the information that ASM uses to control a disk group and the metadata resides within the disk group. ASM metadata includes the following information:

*

The disks that belong to a disk group
*

The amount of space that is available in a disk group
*

The filenames of the files in a disk group
*

The location of disk group datafile data extents
*

A redo log that records information about atomically changing data blocks

ASM and database instances require shared access to the disks in a disk group. ASM instances manage the metadata of the disk group and provide file layout information to the database instances.

ASM instances can be clustered using Oracle Clusterware; there is one ASM instance for each cluster node. If there are several database instances for different databases on the same node, then the database instances share the same single ASM instance on that node.

If the ASM instance on a node fails, then all of the database instances on that node also fail. Unlike a file system failure, an ASM instance failure does not require restarting the operating system. In an Oracle RAC environment, the ASM and database instances on the surviving nodes automatically recover from an ASM instance failure on a node.


***********************************************************************************

About ASM Disk Groups

A disk group consists of multiple disks and is the fundamental object that ASM manages. Each disk group contains the metadata that is required for the management of space in the disk group.

Files are allocated from disk groups. Any ASM file is completely contained within a single disk group. However, a disk group might contain files belonging to several databases and a single database can use files from multiple disk groups. For most installations you need only a small number of disk groups, usually two, and rarely more than three.


**********************************************************************************


About Mirroring and Failure Groups

Mirroring protects data integrity by storing copies of data on multiple disks. The disk group type determines the mirroring levels with which Oracle creates files in a disk group.

When you create a disk group, you specify an ASM disk group type based on one of the following three redundancy levels:

*

Normal for 2-way mirroring
*

High for 3-way mirroring
*

External to not use ASM mirroring, such as when you configure hardware RAID for redundancy

The disk group type determines the mirroring levels with which Oracle creates files in a disk group. The redundancy level controls how many disk failures are tolerated without dismounting the disk group or losing data.

ASM mirroring is more flexible than traditional RAID mirroring because you can specify the redundancy level for each file. Two files can share the same disk group with one file being mirrored while the other is not.

When ASM allocates an extent for a normal redundancy file, ASM allocates a primary copy and a secondary copy. ASM chooses the disk on which to store the secondary copy in a different failure group other than the primary copy. Failure groups are used to place mirrored copies of data so that each copy is on a disk in a different failure group. The simultaneous failure of all disks in a failure group does not result in data loss.

You define the failure groups for a disk group when you create an ASM disk group. After a disk group is created, you cannot alter the redundancy level of the disk group. To change the redundancy level of a disk group, create another disk group with the appropriate redundancy and then move the files to the new disk group. Oracle recommends that you create failure groups of equal size to avoid space imbalance and uneven distribution of mirror data.

If you omit the failure group specification, then ASM automatically places each disk into its own failure group. Normal redundancy disk groups require at least two failure groups. High redundancy disk groups require at least three failure groups. Disk groups with external redundancy do not use failure groups.


************************************************************************************



Allocation Units

Every ASM disk is divided into allocation units (AU). An AU is the fundamental unit of allocation within a disk group. A file extent consists of one or more AU. An ASM file consists of one or more file extents.

When you create a disk group, you can set the ASM AU size to be between 1 MB and 64 MB in powers of two, such as, 1, 2, 4, 8, 16, 32, or 64. Larger AU sizes typically provide performance advantages for data warehouse applications that use large sequential reads.


*************************************************************************************

ASM Disk Group Administration

This section describes ASM disk group administration and it contains the following topics:

*

About Discovering Disks
*

About Mounting Disk Groups
*

About Adding and Dropping Disks

About Discovering Disks

The disk discovery process locates the operating system names for disks that ASM can access. Disk discovery is also used to find all of the disks that comprise a disk group to be mounted. This can include the disks that you want to add to a disk group and the disks that you might consider adding to a disk group.

An ASM instance requires an ASM_DISKSTRING initialization parameter value to specify its discovery strings. Only pathnames that the ASM instance has permission to open are discovered. The exact syntax of a discovery string depends on the platform and ASMLIB libraries. The pathnames that an operating system accepts are always usable as discovery strings.


*********************************************************************************


ASM_DISKGROUPS

The ASM_DISKGROUPS initialization parameter specifies a list of the names of disk groups that an ASM instance mounts at startup. Oracle ignores the value that you set for ASM_DISKGROUPS when you specify the NOMOUNT option at startup or when you issue the ALTER DISKGROUP ALL MOUNT statement. The default value of the ASM_DISKGROUPS parameter is a NULL string. If the parameter value is NULL or is not specified, then ASM does not mount any disk groups.

The ASM_DISKGROUPS parameter is dynamic. If you are using a server parameter file (SPFILE), then you should not need to manually alter the value of ASM_DISKGROUPS. ASM automatically adds a disk group to this parameter when the disk group is successfully created or mounted. ASM also automatically removes a disk group from this parameter when the disk group is dropped or dismounted. The following is an example of setting the ASM_DISKGROUPS parameter dynamically:

SQL> ALTER SYSTEM SET ASM_DISKGROUPS = 'CONTROLFILE, DATAFILE, LOGFILE, STANDBY'

When using a text initialization parameter file (PFILE), you must edit the initialization parameter file to add the name of any disk group that you want mounted automatically at instance startup. You must remove the name of any disk group that you no longer want automatically mounted. The following is an example of the ASM_DISKGROUPS parameter in the initialization file:

ASM_DISKGROUPS = CONTROLFILE, DATAFILE, LOGFILE, STANDBY


**********************************************************************************



The following is a sample SQL*Plus session for starting an ASM instance.

SQLPLUS /NOLOG
SQL> CONNECT SYS AS SYSASM
Enter password: sys_password
Connected to an idle instance.

SQL> STARTUP
ASM instance started

Total System Global Area 71303168 bytes
Fixed Size 1069292 bytes
Variable Size 45068052 bytes
ASM Cache 25165824 bytes
ASM disk groups mounted




Creating Users with the SYSASM Privilege

When you are logged in to an ASM instance as SYSASM, you can use the combination of CREATE USER and GRANT SQL statements to create a new user who has the SYSASM privilege. These commands update the password file for the local ASM instance. Similarly, you can revoke the SYSASM privilege from a user using the REVOKE command, and you can drop a user from the password file using the DROP USER command. The following example describes how to perform these operations for the user identified as new_user:

REM create a new user, then grant the SYSASM privilege
SQL> CREATE USER new_user IDENTIFIED by new_user_passwd;
SQL> GRANT SYSASM TO new_user;

REM connect the user to the ASM instance
SQL> CONNECT new_user AS SYSASM;
Enter password:

REM revoke the SYSASM privilege, then drop the user
SQL> REVOKE SYSASM FROM new_user;
SQL> DROP USER new_user;





**********************************************************************************


Example: Creating a Disk Group

The following examples assume that the ASM_DISKSTRING initialization parameter is set to '/devices/*' and ASM disk discovery identifies the following disks in the /devices directory.

Controller 1:

/devices/diska1
/devices/diska2
/devices/diska3
/devices/diska4

Controller 2:
/devices/diskb1
/devices/diskb2
/devices/diskb3
/devices/diskb4

The SQL statement in Example 4-1 creates a disk group named dgroup1 with normal redundancy consisting of two failure groups controller1 or controller2 with four disks in each failure group.

Example 4-1 Creating a Disk Group

% SQLPLUS /NOLOG
SQL> CONNECT / AS SYSASM
Connected to an idle instance.
SQL> STARTUP NOMOUNT

CREATE DISKGROUP dgroup1 NORMAL REDUNDANCY
FAILGROUP controller1 DISK
'/devices/diska1' NAME diska1,
'/devices/diska2' NAME diska2,
'/devices/diska3' NAME diska3,
'/devices/diska4' NAME diska4
FAILGROUP controller2 DISK
'/devices/diskb1' NAME diskb1,
'/devices/diskb2' NAME diskb2,
'/devices/diskb3' NAME diskb3,
'/devices/diskb4' NAME diskb4
ATTRIBUTE 'au_size'='4M',
'compatible.asm' = '11.1',
'compatible.rdbms' = '11.1';

In Example 4-1, the NAME clauses enable you to explicitly assign names to the disks rather than the default system-generated names. The system-generated names are in the form diskgroupname_nnnn, where nnnn is the disk number for the disk in the disk group. For ASMLIB disks, the disk name defaults to the ASMLIB name that is the user label of the disk; for example, mydisk is the default ASM disk name for ORCL:mydisk.

When creating the disk group, the values of following disk group attributes were explicitly set:

*

AU_SIZE specifies the size of the allocation unit for the disk group. For information about allocation unit size and extents, see "Extents".
*

COMPATIBLE.ASM determines the minimum software version for any ASM instance that uses a disk group. For information about the COMPATIBLE.ASM attribute, see "COMPATIBLE.ASM".
*

COMPATIBLE.RDBMS determines the minimum software version for any database instance that uses a disk group. For information about the COMPATIBLE.RDBMS attribute, see "COMPATIBLE.RDBMS".


********************************************************************************



Adding Disks to a Disk Group

You can use the ADD clause of the ALTER DISKGROUP statement to add a disk or a failure group to a disk group. The same syntax that you use to add a disk or failure group with the CREATE DISKGROUP statement can be used with the ALTER DISKGROUP statement. For an example of the CREATE DISKGROUP SQL statement, refer to Example 4-1. After you add new disks, the new disks gradually begin to accommodate their share of the workload as rebalancing progresses.

ASM behavior when adding disks to a disk group is best illustrated through"Example: Adding Disks to a Disk Group". You can also add disks to a disk group with Oracle Enterprise Manager, described in "Adding Disks to Disk Groups".
Example: Adding Disks to a Disk Group

The statements presented in this example demonstrate the interactions of disk discovery with the ADD DISK operation.

Assume that disk discovery identifies the following disks in directory /devices:

/devices/diska1 -- member of dgroup1
/devices/diska2 -- member of dgroup1
/devices/diska3 -- member of dgroup1
/devices/diska4 -- member of dgroup1
/devices/diska5 -- candidate disk
/devices/diska6 -- candidate disk
/devices/diska7 -- candidate disk
/devices/diska8 -- candidate disk

/devices/diskb1 -- member of dgroup1
/devices/diskb2 -- member of dgroup1
/devices/diskb3 -- member of dgroup1
/devices/diskb4 -- member of dgroup2

/devices/diskc1 -- member of dgroup2
/devices/diskc2 -- member of dgroup2
/devices/diskc3 -- member of dgroup3
/devices/diskc4 -- candidate disk

/devices/diskd1 -- candidate disk
/devices/diskd2 -- candidate disk
/devices/diskd3 -- candidate disk
/devices/diskd4 -- candidate disk
/devices/diskd5 -- candidate disk
/devices/diskd6 -- candidate disk
/devices/diskd7 -- candidate disk
/devices/diskd8 -- candidate disk

You can query the V$ASM_DISK view to display the status of ASM disks. See "Using Views to Obtain ASM Information".

The following statement would fail because /devices/diska1 - /devices/diska4 already belong to dgroup1.

ALTER DISKGROUP dgroup1 ADD DISK
'/devices/diska*';

The following statement would successfully add disks /devices/diska5 through /devices/diska8 to dgroup1. Because no FAILGROUP clauses are included in the ALTER DISKGROUP statement, each disk is assigned to its own failure group. The NAME clauses assign names to the disks, otherwise they would have been assigned system-generated names.

ALTER DISKGROUP dgroup1 ADD DISK
'/devices/diska5' NAME diska5,
'/devices/diska6' NAME diska6,
'/devices/diska7' NAME diska7,
'/devices/diska8' NAME diska8,

The following statement would fail because the search string matches disks that are contained in other disk groups. Specifically, /devices/diska4 belongs to disk group dgroup1 and /devices/diskb4 belongs to disk group dgroup2.

ALTER DISKGROUP dgroup1 ADD DISK
'/devices/disk*4';

The following statement would successfully add /devices/diskd1 through /devices/diskd8 to disk group dgroup1. This statement runs with a rebalance power of 5, and does not return until the rebalance operation is complete.

ALTER DISKGROUP dgroup1 ADD DISK
'/devices/diskd*'
REBALANCE POWER 5 WAIT;

If /devices/diskc3 was previously a member of a disk group that no longer exists, then you could use the FORCE option to add them as members of another disk group. For example, the following use of the FORCE clause enables /devices/diskc3 to be added to dgroup2, even though it is a current member of dgroup3. For this statement to succeed, dgroup3 cannot be mounted.

ALTER DISKGROUP dgroup2 ADD DISK
'/devices/diskc3' FORCE;

Dropping Disks from Disk Groups

To drop disks from a disk group, use the DROP DISK clause of the ALTER DISKGROUP statement. You can also drop all of the disks in specified failure groups using the DROP DISKS IN FAILGROUP clause.

When a disk is dropped, the disk group is rebalanced by moving all of the file extents from the dropped disk to other disks in the disk group. A drop disk operation might fail if not enough space is available on the other disks. The best approach is to perform both the add and drop operation with the same ALTER DISKGROUP statement. This has the benefit of rebalancing data extents once and ensuring that there is enough space for the rebalance operation to succeed.

Caution:
The ALTER DISKGROUP...DROP DISK statement returns before the drop and rebalance operations are complete. Do not reuse, remove, or disconnect the dropped disk until the HEADER_STATUS column for this disk in the V$ASM_DISK view changes to FORMER. You can query the V$ASM_OPERATION view to determine the amount of time remaining for the drop/rebalance operation to complete. For more information, refer to the Oracle Database SQL Language Reference and the Oracle Database Reference.

If you specify the FORCE clause for the drop operation, the disk is dropped even if ASM cannot read or write to the disk. You cannot use the FORCE flag when dropping a disk from an external redundancy disk group.

Caution:
A DROP FORCE operation leaves data at reduced redundancy for as long as it takes for the subsequent rebalance operation to complete. This increases your exposure to data loss if there is a subsequent disk failure during rebalancing. DROP FORCE should be used only with great care.

You can also drop disks from a disk group with Oracle Enterprise Manager. See "Dropping Disks from Disk Groups".
Example: Dropping Disks from Disk Groups

The statements in this example demonstrate how to drop disks from the disk group dgroup1 described in "Example: Adding Disks to a Disk Group".

The following example drops diska5 from disk group dgroup1.

ALTER DISKGROUP dgroup1 DROP DISK diska5;

The following example drops diska5 from disk group dgroup1, and also illustrates how multiple actions are possible with one ALTER DISKGROUP statement.

ALTER DISKGROUP dgroup1 DROP DISK diska5
ADD FAILGROUP failgrp1 DISK '/devices/diska9' NAME diska9;

Resizing Disks in Disk Groups

The RESIZE clause of ALTER DISKGROUP enables you to perform the following operations:

*

Resize all disks in the disk group
*

Resize specific disks
*

Resize all of the disks in a specified failure group

If you do not specify a new size in the SIZE clause then ASM uses the size of the disk as returned by the operating system. The new size is written to the ASM disk header and if the size of the disk is increasing, then the new space is immediately available for allocation. If the size is decreasing, rebalancing must relocate file extents beyond the new size limit to available space below the limit. If the rebalance operation can successfully relocate all extents, then the new size is made permanent, otherwise the rebalance fails.
Example: Resizing Disks in Disk Groups

The following example resizes all of the disks in failure group failgrp1 of disk group dgroup1. If the new size is greater than disk capacity, the statement will fail.

ALTER DISKGROUP dgroup1
RESIZE DISKS IN FAILGROUP failgrp1 SIZE 100G;

Undropping Disks in Disk Groups

The UNDROP DISKS clause of the ALTER DISKGROUP statement enables you to cancel all pending drops of disks within disk groups. If a drop disk operation has already completed, then this statement cannot be used to restore it. This statement cannot be used to restore disks that are being dropped as the result of a DROP DISKGROUP statement, or for disks that are being dropped using the FORCE clause.
Example: Undropping Disks in Disk Groups

The following example cancels the dropping of disks from disk group dgroup1:

ALTER DISKGROUP dgroup1 UNDROP DISKS;

Manually Rebalancing Disk Groups

You can manually rebalance the files in a disk group using the REBALANCE clause of the ALTER DISKGROUP statement. This would normally not be required, because ASM automatically rebalances disk groups when their configuration changes. You might want to do a manual rebalance operation if you want to control the speed of what would otherwise be an automatic rebalance operation.

The POWER clause of the ALTER DISKGROUP...REBALANCE statement specifies the degree of parallelism, and thus the speed of the rebalance operation. It can be set to a value from 0 to 11. A value of 0 halts a rebalancing operation until the statement is either implicitly or explicitly re-run. The default rebalance power is set by the ASM_POWER_LIMIT initialization parameter. See "Tuning Rebalance Operations" for more information.

The power level of an ongoing rebalance operation can be changed by entering the rebalance statement with a new level.

The ALTER DISKGROUP...REBALANCE command by default returns immediately so that you can issue other commands while the rebalance operation takes place asynchronously in the background. You can query the V$ASM_OPERATION view for the status of the rebalance operation.

If you want the ALTER DISKGROUP...REBALANCE command to wait until the rebalance operation is complete before returning, you can add the WAIT keyword to the REBALANCE clause. This is especially useful in scripts. The command also accepts a NOWAIT keyword, which invokes the default behavior of conducting the rebalance operation asynchronously. You can interrupt a rebalance running in wait mode by typing CTRL-C on most platforms. This causes the command to return immediately with the message ORA-01013: user requested cancel of current operation, and then to continue the rebalance operation asynchronously.

Additional rules for the rebalance operation include the following:

*

An ongoing rebalance command will be restarted if the storage configuration changes either when you alter the configuration, or if the configuration changes due to a failure or an outage. Furthermore, if the new rebalance fails because of a user error, then a manual rebalance may be required.
*

The ALTER DISKGROUP...REBALANCE statement runs on a single node even if you are using Oracle Real Application Clusters (Oracle RAC).
*

ASM can perform one disk group rebalance at a time on a given instance. Therefore, if you have initiated multiple rebalances on different disk groups, then Oracle processes this operation serially. However, you can initiate rebalances on different disk groups on different nodes in parallel.
*

Rebalancing continues across a failure of the ASM instance performing the rebalance.
*

The REBALANCE clause (with its associated POWER and WAIT/NOWAIT keywords) can also be used in ALTER DISKGROUP commands that add, drop, or resize disks.

Note:
Oracle will restart the processing of an ongoing rebalance operation if the storage configuration changes. Furthermore, if the next rebalance operation fails because of a user error, then you may need to perform a manual rebalance.

Example: Manually Rebalancing a Disk Group

The following example manually rebalances the disk group dgroup2. The command does not return until the rebalance operation is complete.

ALTER DISKGROUP dgroup2 REBALANCE POWER 5 WAIT;

For more information about rebalancing operations, refer to "Tuning Rebalance Operations".
Tuning Rebalance Operations

If the POWER clause is not specified in an ALTER DISKGROUP statement, or when rebalance is implicitly run by adding or dropping a disk, then the rebalance power defaults to the value of the ASM_POWER_LIMIT initialization parameter. You can adjust the value of this parameter dynamically.

The higher the power limit, the more quickly a rebalance operation can complete. Rebalancing takes longer with lower power values, but consumes fewer processing and I/O resources which are shared by other applications, such as the database.

The default value of 1 minimizes disruption to other applications. The appropriate value is dependent on your hardware configuration, performance requirements, and availability requirements

If a rebalance is in progress because a disk is manually or automatically dropped, then increasing the power of the rebalance shortens the time frame during which redundant copies of that data on the dropped disk are reconstructed on other disks.

The V$ASM_OPERATION view provides information for adjusting ASM_POWER_LIMIT and the resulting power of rebalance operations. The V$ASM_OPERATION view also gives an estimate in the EST_MINUTES column of the amount of time remaining for the rebalance operation to complete. You can see the effect of changing the rebalance power by observing the change in the time estimate.

See Also:
"Manually Rebalancing Disk Groups" for more information.
ASM Disk Discovery

Disk discovery is the mechanism used to find the operating system names for disks ASM can access. It is used to find all the disks that comprise a disk group to be mounted, the disks an administrator wants to add to a disk group, or the disks the administrator might consider adding to a disk group. This section contains the following topics:

*

How A Disk is Discovered
*

Disk Discovery Rules
*

Improving Disk Discovery Time

For additional information about disk discovery and the ASM_DISKSTRING initialization parameter, refer to "ASM_DISKSTRING".
How A Disk is Discovered

While an ASM instance is initialized, ASM discovers and examines the contents of all of the disks that are in the paths that you designated with values in the ASM_DISKSTRING initialization parameter. Disk discovery also occurs when you:

*

Run the ALTER DISKGROUP...ADD DISK and ALTER DISKGROUP...RESIZE DISK commands
*

Query the V$ASM_DISKGROUP and V$ASM_DISK views

After ASM successfully discovers a disk, the disk appears in the V$ASM_DISK view. Disks that belong to a disk group, that is, disks that have a disk group name in the disk header, show a status of MEMBER. Disks that were discovered, but that have not yet been assigned to a disk group, have a status of either CANDIDATE or PROVISIONED.

The PROVISIONED status implies that an additional platform-specific action has been taken by an administrator to make the disk available for ASM. For example, on Windows computers, the administrator might have used asmtool or asmtoolg to stamp the disk with a header. On Linux computers, the administrator might have used ASMLIB to prepare the disk for ASM.

The following SQL query shows one candidate and six member disks:

SELECT name, header_status, path FROM V$ASM_DISK;


NAME HEADER_STATUS PATH
--------- ------------- ---------------------
CANDIDATE /dev/rdsk/disk07
DISK06 MEMBER /dev/rdsk/disk06
DISK05 MEMBER /dev/rdsk/disk05
DISK04 MEMBER /dev/rdsk/disk04
DISK03 MEMBER /dev/rdsk/disk03
DISK02 MEMBER /dev/rdsk/disk02
DISK01 MEMBER /dev/rdsk/disk01

7 rows selected.
Disk Discovery Rules

The rules for discovering ASM disks are as follows:

*

ASM can discover up to 10,000 disks. That is, if more than 10,000 disks match the ASM_DISKSTRING initialization parameter, then ASM discovers only the first 10,000.
*

ASM only discovers disks that contain a partition table.

Note:
ASM does not discover a disk that contains an operating system partition table, even if the disk is in an ASM disk string search path and ASM has read and write permission for the disk.
*

When adding a disk, the FORCE option must be used if ASM recognizes that the disk was managed by Oracle. Such a disk appears in the V$ASM_DISK view with a status of FOREIGN. In this case, you can only add the disk to a disk group by using the FORCE keyword.

In addition, ASM identifies the following configuration errors during discovery:

*

Multiple paths to the same disk

In this case, if the disk is part of a disk group, then disk group mount fails. If the disk is being added to a disk group with the ADD DISK or CREATE DISKGROUP command, then the command fails. To correct the error, adjust the ASM_DISKSTRING value so that ASM will not discover multiple paths to the same disk. Or if you are using multipathing software, then ensure that you include only the pseudo-device name in the ASM_DISKSTRING value. See "ASM and Multipathing".
*

Multiple ASM disks with the same disk header

This can be caused by having copied one disk onto another. In this case, the disk group mount operation fails.

Improving Disk Discovery Time

The value for the ASM_DISKSTRING initialization parameter is an operating system–dependent value that ASM uses to limit the set of paths that the discovery process uses to search for disks. When a new disk is added to a disk group, each ASM instance that has the disk group mounted must be able to discover the new disk using its ASM_DISKSTRING.

In many cases, the default value (NULL) is sufficient. Using a more restrictive value might reduce the time required for ASM to perform discovery, and thus improve disk group mount time or the time for adding a disk to a disk group. Oracle might need to dynamically change the ASM_DISKSTRING before adding a disk so that the new disk will be discovered through this parameter.

Note that the default value of ASM_DISKSTRING might not find all disks in all situations. If your site is using a third-party vendor ASMLIB, then the vendor might have discovery string conventions that you must use for ASM_DISKSTRING. In addition, if your installation uses multipathing software, then the software might place pseudo-devices in a path that is different from the operating system default. See "ASM and Multipathing" and consult the multipathing vendor documentation for details.
Managing Capacity in Disk Groups

When ASM provides redundancy, such as when you create a disk group with NORMAL or HIGH redundancy, you must have sufficient capacity in each disk group to manage a re-creation of data that is lost after a failure of one or two failure groups. After one or more disks fail, the process of restoring redundancy for all data requires space from the surviving disks in the disk group. If not enough space remains, then some files might end up with reduced redundancy.

Reduced redundancy means that one or more extents in the file are not mirrored at the expected level. For example, a reduced redundancy file in a high redundancy disk group has at least one file extent with two or fewer total copies of the extent instead of three. In the case of unprotected files, data extents could be missing altogether. Other causes of reduced redundancy files are disks running out of space or an insufficient number of failure groups. The REDUNDANCY_LOWERED column in the V$ASM_FILE view provides information about files with reduced redundancy.

The following guidelines help ensure that you have sufficient space to restore full redundancy for all disk group data after the failure of one or more disks.

*

In a normal redundancy disk group, it is best to have enough free space in your disk group to tolerate the loss of all disks in one failure group. The amount of free space should be equivalent to the size of the largest failure group.
*

In a high redundancy disk group, it is best to have enough free space to cope with the loss of all disks in two failure groups. The amount of free space should be equivalent to the sum of the sizes of the two largest failure groups.

Note:
When you lose multiple disks from multiple failure groups, then you could lose both the primary and the redundant copies of your data. In addition, if you do not have enough capacity to restore redundancy, then ASM can continue to operate. However, if another disk fails, then the system may not be able to tolerate additional failures.

The V$ASM_DISKGROUP view contains the following columns that contain information to help you manage capacity:

*

REQUIRED_MIRROR_FREE_MB indicates the amount of space that must be available in a disk group to restore full redundancy after the worst failure that can be tolerated by the disk group. The amount of space displayed in this column takes the effects of mirroring into account. The value is computed as follows:

For a normal redundancy disk group, the value is the total raw space for all of the disks in the largest failure group. The largest failure group is the one with the largest total raw capacity. For example, if each disk is in its own failure group, then the value would be the size of the largest capacity disk.

For a high redundancy disk group, the value is the total raw space for all of the disks in the two largest failure groups.
*

USABLE_FILE_MB indicates the amount of free space, adjusted for mirroring, that is available for new files to restore redundancy after a disk failure. USABLE_FILE_MB is computed by subtracting REQUIRED_MIRROR_FREE_MB from the total free space in the disk group and then adjusting the value for mirroring. For example, in a normal redundancy disk group where by default the mirrored files use disk space equal to twice their size, if 4 GB of actual usable file space remains, then USABLE_FILE_MB equals roughly 2 GB. You can then add a file that is up to 2 GB in size.
*

TOTAL_MB is the total usable capacity of a disk group in megabytes. The calculations for data in this column take the disk header overhead into consideration. The disk header overhead depends on the number of ASM disks and ASM files. This value is typically about 1% of the total raw storage capacity. For example, if the total LUN capacity provisioned for ASM is 100 GB, then the value in the TOTAL_MB column would be about 99 GB.
*

FREE_MB is the unused capacity of the disk group in megabytes, without considering any data imbalance. Therefore, there may be situations where the value in the FREE_MB column shows unused capacity but because one of the ASM disks is full, database writes fail because of the imbalance in the disk group. Make sure that you initiate a manual rebalance to force even data distribution which results in an accurate presentation of the values in the FREE_MB column.

With fine grain striping using 128 KB, the storage is preallocated to be eight times the AU size. Therefore, the datafile size may appear slightly larger on ASM than on a local file system because of the preallocation.

When you use ASM normal or high redundancy, the disk space utilization becomes more complex to measure because it depends on several variables.

Note:
The values in the TOTAL_MB and FREE_MB columns best describe space usage when you do not configure ASM mirroring, that is, when you use external redundancy.

The results from the following query show capacity metrics for a normal redundancy disk group that consists of six 1 GB (1024 MB) disks, each in its own failure group:

SELECT name, type, total_mb, free_mb, required_mirror_free_mb,
usable_file_mb FROM V$ASM_DISKGROUP;

NAME TYPE TOTAL_MB FREE_MB REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB
------------ ------ ---------- ---------- ----------------------- --------------
DISKGROUP1 NORMAL 6144 3768 1024 1372

The REQUIRED_MIRROR_FREE_MB column shows that 1 GB of extra capacity must be available to restore full redundancy after one or more disks fail. Note that the first three numeric columns in the query results are raw numbers. That is, they do not take redundancy into account. Only the last column is adjusted for normal redundancy. Note in the example that:

FREE_MB - REQUIRED_MIRROR_FREE_MB = 2 * USABLE_FILE_MB

3768 - 1024 = 2 * 1372 = 2744
Negative Values of USABLE_FILE_MB

Due to the relationship between FREE_MB, REQUIRED_MIRROR_FREE_MB, and USABLE_FILE_MB, USABLE_FILE_MB can become negative. Although this is not necessarily a critical situation, it does mean that:

*

Depending on the value of FREE_MB, you may not be able to create new files.
*

The next failure might result in files with reduced redundancy.

If USABLE_FILE_MB becomes negative, it is strongly recommended that you add more space to the disk group as soon as possible.
ASM Mirroring and Disk Group Redundancy

This section contains the following topics:

*

ASM Mirroring and Failure Groups
*

ASM Recovery from Read and Write I/O Errors
*

ASM Fast Mirror Resync
*

Preferred Read Failure Groups

ASM Mirroring and Failure Groups

If you specify mirroring for a file, then ASM automatically stores redundant copies of the file extents in separate failure groups. Failure groups apply only to normal and high redundancy disk groups. You can define the failure groups for each disk group when you create or alter the disk group.

There are three types of disk groups based on the ASM redundancy level. Table 4-1 lists the types with their supported and default mirroring levels. The default mirroring levels indicate the mirroring level with which each file is created unless a different mirroring level is designated.

Table 4-1 Mirroring Options for ASM Disk Group Types
Disk Group Type Supported Mirroring Levels Default Mirroring Level

External redundancy


Unprotected (none)


Unprotected

Normal redundancy

Two-way
Three-way
Unprotected (None)

Two-way

High redundancy


Three-way


Three-way

The redundancy level controls how many disk failures are tolerated without dismounting the disk group or losing data. Each file is allocated based on its own redundancy, but the default comes from the disk group. The redundancy levels are:

*

External redundancy

ASM does not provide mirroring redundancy and relies on the storage system to provide RAID functionality. Any write error cause a forced dismount of the disk group. All disks must be located to successfully mount the disk group.
*

Normal redundancy

ASM provides two-way mirroring. By default all files are mirrored so that there are two copies of every data extent. A loss of one ASM disk is tolerated.
*

High redundancy

ASM provides triple mirroring by default. A loss of two ASM disks in different failure groups is tolerated.

Failure groups enable the mirroring of metadata and user data. System reliability can diminish if your environment has an insufficient number of failure groups.

This section contains these topics:

*

ASM Failure Groups
*

How ASM Manages Disk Failures
*

Guidelines for Using Failure Groups
*

Failure Group Frequently Asked Questions

ASM Failure Groups

Failure groups are used to store mirror copies of data. When ASM allocates an extent for a normal redundancy file, ASM allocates a primary copy and a secondary copy. ASM chooses the disk on which to store the secondary copy so that it is in a different failure group than the primary copy. Each copy is on a disk in a different failure group so that the simultaneous failure of all disks in a failure group does not result in data loss.

A failure group is a subset of the disks in a disk group, which could fail at the same time because they share hardware. The failure of common hardware must be tolerated. Four drives that are in a single removable tray of a large JBOD array should be in the same failure group because the tray could be removed making all four drives fail at the same time. Drives in the same cabinet could be in multiple failure groups if the cabinet has redundant power and cooling so that it is not necessary to protect against failure of the entire cabinet. However, ASM mirroring is not intended to protect against a fire in the computer room that destroys the entire cabinet.

There are always failure groups even if they are not explicitly created. If you do not specify a failure group for a disk, then Oracle automatically creates a new failure group containing just that disk. A normal redundancy disk group must contain at least two failure groups. A high redundancy disk group must contain at least three failure groups. However, Oracle recommends using several failure groups. A small number of failure groups, or failure groups of uneven capacity, can create allocation problems that prevent full use of all of the available storage.
How ASM Manages Disk Failures

Depending on the redundancy level of a disk group and how you define failure groups, the failure of one or more disks could result in either of the following:

*

The disks are first taken offline and then automatically dropped. In this case, the disk group remains mounted and serviceable. In addition, because of mirroring, all of the disk group data remains accessible. After the disk drop operation, ASM performs a rebalance to restore full redundancy for the data on the failed disks.
*

The entire disk group is automatically dismounted, which means loss of data accessibility.

Guidelines for Using Failure Groups

The following are guidelines for using failure groups:

*

Each disk in a disk group can belong to only one failure group.
*

Failure groups should all be of the same size. Failure groups of different sizes may lead to reduced availability.
*

ASM requires at least two failure groups to create a normal redundancy disk group and at least three failure groups to create a high redundancy disk group.

Failure Group Frequently Asked Questions

This section discusses frequently asked questions about failure group under the following topics:

*

How Many Failure Groups Should I Create?
*

How are Multiple Failure Groups Recovered after Simultaneous Failures?
*

When Should External, Normal, or High Redundancy Be Used?

How Many Failure Groups Should I Create?

Choosing the number of failure groups to create depends on the types of failures that need to be tolerated without data loss. For small numbers of disks, such as fewer than 20, it is usually best to use the default failure group creation that puts every disk in its own failure group.

Using the default failure group creation for small numbers of disks is also applicable for large numbers of disks where your main concern is disk failure. For example, a disk group might be configured from several small modular disk arrays. If the system must continue operating when an entire modular array fails, then a failure group should consist of all of the disks in one module. If one module fails, then all of the data on that module will be relocated to other modules to restore redundancy. Disks should be placed in the same failure group if they depend on a common piece of hardware whose failure must be tolerated with no loss of availability.

How are Multiple Failure Groups Recovered after Simultaneous Failures?

A simultaneous failure can occur if there is a failure of a piece of hardware used by multiple failure groups. This type of failure usually forces a dismount of the disk group if all disks are unavailable.

When Should External, Normal, or High Redundancy Be Used?

ASM mirroring runs on the database server and Oracle recommends to off load this processing to the storage hardware RAID controller by using external redundancy. You can use normal redundancy in the following scenarios:

*

Storage system does not have RAID controller
*

Mirroring across storage arrays
*

Extended cluster configurations

In general, ASM mirroring is the Oracle alternative to third party logical volume managers. ASM mirroring eliminates the need to deploy additional layers of software complexity in your Oracle database environment.
ASM Recovery from Read and Write I/O Errors

Read errors can be the result of a loss of access to the entire disk or media corruptions on an otherwise a healthy disk. ASM tries to recover from read errors on corrupted sectors on a disk. When a read error by the database or ASM triggers the ASM instance to attempt bad block remapping, ASM reads a good copy of the extent and copies it to the disk that had the read error.

*

If the write to the same location succeeds, then the underlying allocation unit (sector) is deemed healthy. This might be because the underlying disk did its own bad block reallocation.
*

If the write fails, ASM attempts to write the extent to a new allocation unit on the same disk. If this write succeeds, the original allocation unit is marked as unusable. If the write fails, the disk is taken offline.

One unique benefit on ASM-based mirroring is that the database instance is aware of the mirroring. For many types of logical corruptions such as a bad checksum or incorrect System Change Number (SCN), the database instance proceeds through the mirror side looking for valid content and proceeds without errors. If the process in the database that encountered the read is in a position to obtain the appropriate locks to ensure data consistency, it writes the correct data to all mirror sides.

When encountering a write error, a database instance sends the ASM instance a disk offline message.

*

If database can successfully complete a write to at least one extent copy and receive acknowledgment of the offline disk from ASM, the write is considered successful.
*

If the write to all mirror side fails, database takes the appropriate actions in response to a write error such as taking the tablespace offline.

When the ASM instance receives a write error message from an database instance or when an ASM instance encounters a write error itself, ASM instance attempts to take the disk offline. ASM consults the Partner Status Table (PST) to see whether any of the disk's partners are offline. If too many partners are already offline, ASM forces the dismounting of the disk group. Otherwise, ASM takes the disk offline.

The ASMCMD remap command was introduced to address situations where a range of bad sectors exists on a disk and must be corrected before ASM or database I/O. For information on the remap command, see "remap Command".
ASM Fast Mirror Resync

Restoring the redundancy of an ASM disk group after a transient disk path failure can be time consuming. This is especially true if the recovery process requires rebuilding an entire ASM failure group. ASM fast mirror resync significantly reduces the time to resynchronize a failed disk in such situations. When you replace the failed disk, ASM can quickly resynchronize the ASM disk extents.

Note:
To use this feature, the disk group compatibility attributes must be set to 11.1 or higher. For more information, refer to "Disk Group Compatibility".

Any problems that make a failure group temporarily unavailable are considered transient failures that can be recovered by the ASM fast mirror resync feature. For example, transient failures can be caused by disk path malfunctions, such as cable failures, host bus adapter failures, controller failures, or disk power supply interruptions.

ASM fast resync keeps track of pending changes to extents on an OFFLINE disk during an outage. The extents are resynced when the disk is brought back online.

By default, ASM drops a disk in 3.6 hours after it is taken offline. You can set the DISK_REPAIR_TIME attribute to delay the drop operation by specifying a time interval to repair the disk and bring it back online. The time can be specified in units of minutes (m or M) or hours (h or H). If you omit the unit, then the default unit is hours.

If the attribute is not set explicitly, then the default value (3.6h) applies to disks that have been set to OFFLINE mode without an explicit DROP AFTER clause. Note that disks taken offline due to I/O errors do not have a DROP AFTER clause.

The default DISK_REPAIR_TIME attribute value is an estimate that should be adequate for most environments. However, make sure that the attribute value is set to the amount of time that you think is necessary in your environment to fix any transient disk error and that you are willing to tolerate reduced data redundancy.

The elapsed time (since the disk was set to OFFLINE mode) is incremented only when the disk group containing the offline disks is mounted. The REPAIR_TIME column of V$ASM_DISK shows the amount of time left (in seconds) before an offline disk is dropped. After the specified time has elapsed, ASM drops the disk. You can override this attribute with an ALTER DISKGROUP DISK OFFLINE statement and the DROP AFTER clause.

Note:
If a disk is offlined by ASM because of an I/O (write) error or is explicitly offlined using the ALTER DISKGROUP... OFFLINE statement without the DROP AFTER clause, then the value that is specified for the DISK_REPAIR_TIME attribute for the disk group is used. If this attribute value is changed with the ALTER DISKGROUP... SET ATTRIBUTE 'disk_repair_time' statement before this offlined disk is dropped, then the new (current) value of the attribute is used by the ASM disk offline functionality but the elapsed time is not reset. You can confirm this behavior by viewing the ASM alert log.

If an offline disk is taken offline for a second time, then the elapsed time is reset and restarted. If another time is specified with the DROP AFTER clause for this disk, the first value is overridden and the new value applies. A disk that is in OFFLINE mode cannot be dropped with an ALTER DISKGROUP DROP DISK statement; an error is returned if attempted. If for some reason the disk must be dropped (such as the disk cannot be repaired) before the repair time has expired, a disk can be dropped immediately by issuing a second OFFLINE statement with a DROP AFTER clause specifying 0h or 0m.

You can use ALTER DISKGROUP to set the DISK_REPAIR_TIME attribute to a specified hour or minute value, such as 4.5 hours or 270 minutes. For example:

ALTER DISKGROUP dg01 SET ATTRIBUTE 'disk_repair_time' = '4.5h'
ALTER DISKGROUP dg01 SET ATTRIBUTE 'disk_repair_time' = '270m'

After you repair the disk, run the SQL statement ALTER DISKGROUP DISK ONLINE. This statement brings a repaired disk group back online to enable writes so that no new writes are missed. This statement also starts a procedure to copy of all of the extents that are marked as stale on their redundant copies.

If a disk goes offline when the ASM instance is in rolling upgrade mode, the disk remains offline until the rolling upgrade has ended and the timer for dropping the disk is stopped until the ASM cluster is out of rolling upgrade mode. See "Using ASM Rolling Upgrades". Examples of taking disks offline and bringing them online follow.

The following example takes disk D3_0001 offline and drops it after five minutes.

ALTER DISKGROUP D3 OFFLINE DISK D3_0001 DROP AFTER 5m;

The next example takes the disk D3_0001 offline and drops it after the time period designated by DISK_REPAIR_TIME elapses:

ALTER DISKGROUP D3 OFFLINE DISK D3_0001;

This example takes all of the disk in failure group F2 offline and drops them after the time period designated by DISK_REPAIR_TIME elapses. IF you used a DROP AFTER clause, then the disks would be dropped after the specified time:

ALTER DISKGROUP D3 OFFLINE DISKS IN FAILGROUP F2;

The next example brings all of the disks in failure group F2 online:

ALTER DISKGROUP D3 ONLINE DISKS IN FAILGROUP F2;

This example brings only disk D3_0001 online:

ALTER DISKGROUP D3 ONLINE DISK D3_0001;

This example brings all of the disks in disk group D3 online:

ALTER DISKGROUP D3 ONLINE ALL;

Querying the V$ASM_OPERATION view while you are running any of these types of ALTER DISKGROUP ... ONLINE statements displays the name and state of the current operation that you are performing. For example, the query:

SELECT GROUP_NUMBER, OPERATION, STATE FROM V$ASM_OPERATION;

Displays output similar to the following:

GROUP_NUMBER OPERA STAT
------------ ----- ----
1 ONLIN RUN

Note that an OFFLINE operation is not displayed in a V$ASM_OPERATION view query.

See Also:
Oracle Database SQL Language Reference for information about ALTER DISKGROUP, CREATE DISKGROUP, and ASM disk group attributes
Preferred Read Failure Groups

When you configure ASM failure groups, it might be more efficient for a node to read from an extent that is closest to the node, even if that extent is a secondary extent. In other words, you can configure ASM to read from a secondary extent if that extent is closer to the node instead of ASM reading from the primary copy which might be farther from the node. Using preferred read failure groups is most useful in extended clusters.

To use this feature, Oracle recommends that you configure at least one mirrored extent copy from a disk that is local to a node in an extended cluster. However, a failure group that is preferred for one instance might be remote to another instance in the same Oracle RAC database. The parameter setting for preferred read failure groups is instance specific.

Note:
By default, when you create a disk group, every disk in the disk group belongs to one failure group. Oracle does not recommend that you configure more than one preferred read failure group for each instance in a disk group. If you configure more than one preferred read failure group for each instance, then Oracle writes messages to an alert log.

Note:
To use this feature, the disk group compatibility attributes must be set to 11.1 or higher. For more information, refer to "Disk Group Compatibility".

See Also:
Oracle Real Application Clusters Administration and Deployment Guide for information about configuring preferred read disks in extended clusters
Configuring and Administering Preferred Read Failure Groups

To configure this feature, set the ASM_PREFERRED_READ_FAILURE_GROUPS initialization parameter to specify a list of failure group names as preferred read disks. For more information about this initialization parameter, refer to "ASM_PREFERRED_READ_FAILURE_GROUPS".

Set the parameter where diskgroup_name is the name of the disk group and failure_group_name is the name of the failure group, separating these variables with a period. ASM ignores the name of a failure group that you use in this parameter setting if the failure group does not exist in the named disk group. You can append multiple values using commas as a separator as follows:

ASM_PREFERRED_READ_FAILURE_GROUPS = diskgroup_name.failure_group_name,...

In an extended cluster, the failure groups that you specify with settings for the ASM_PREFERRED_READ_FAILURE_GROUPS parameter should only contain disks that are local to the instance. For normal redundancy disk groups, there should be only one failure group on each site of the extended cluster.

If there is more than one mirrored copy and you have set a value for the ASM_PREFERRED_READ_FAILURE_GROUPS parameter, then ASM first reads the copy that resides on a preferred read disk. If that read fails, then ASM attempts to read from the next mirrored copy that might not be on a preferred read disk.

Having more than one failure group on one site can cause the loss of access to the disk group by the other sites if the site containing more than one failure group fails. In addition, by having more than one failure group on a site, an extent might not be mirrored to another site. This can diminish the read performance of the failure group on the other site.

For example, for a normal redundancy disk group, if a site contains two failure groups of a disk group, then ASM might put both mirror copies of an extent on the same site. In this configuration, ASM cannot protect against data loss from a site failure.

You should configure at most two failure groups on a site for a high redundancy disk group. If there are three sites in an extended cluster, for the same reason previously mentioned, then you should only create one failure group.

For a two-site extended cluster, a normal redundancy disk group only has two failure groups. In this case, you can only specify one failure group as a preferred read failure group for each instance.

You can use views to identify preferred read failure groups, such as the V$ASM_DISK view that shows whether a disk is a preferred read disk by the value in the PREFERRED_READ column. You can also use V$ASM_DISK to verify whether local disks in an extended cluster are preferred read disks. Use the ASM disk I/O statistics to verify that read operations are using the preferred read disks that you configured.

If a disk group is not optimally configured for an extended cluster, then ASM records warning messages in the alert logs. To identify specific performance issues with ASM preferred read failure groups, use the V$ASM_DISK_IOSTAT view. This view displays disk I/O statistics for each ASM client. You can also query the V$ASM_DISK_IOSTAT view on a database instance. However, this query only shows the I/O statistics for the database instance. In general, optimal preferred read extended cluster configurations balance performance with disk group availability.

See Also:
Oracle Database Reference for details about the V$ASM* dynamic performance views
Performance and Scalability Considerations for Disk Groups

This section discusses the following considerations for evaluating disk group performance:

*

Determining the Number of Disk Groups
*

Performance Characteristics When Grouping Disks
*

ASM Storage Limits

Determining the Number of Disk Groups

Use the following criteria to determine the number of disk groups to create:

*

Disks in a given disk group should have similar size and performance characteristics. If you have several different types of disks in terms of size and performance, then create several disk groups that contain similar characteristics.
*

Create separate disk groups for your database files and flash recovery area for backup files. This configuration allows fast recovery in case of a disk group failure.

Performance Characteristics When Grouping Disks

ASM load balances the file activity by uniformly distributing file extents across all of the disks in a disk group. For this technique to be effective it is important that disks in a disk group be of similar performance characteristics. For example, the newest and fastest disks might reside in a disk group reserved for the database work area, and slower drives could reside in a disk group reserved for the flash recovery area.

There might be situations where it is acceptable to temporarily have disks of different sizes and performance co-existing in a disk group. This would be the case when migrating from an old set of disks to a new set of disks. The new disks would be added and the old disks dropped. As the old disks are dropped, their storage is migrated to the new disks while the disk group is online.
ASM Storage Limits

ASM has the following limits:

*

63 disk groups in a storage system
*

10,000 ASM disks in a storage system
*

4 PB maximum storage for each ASM disk
*

40 exabyte maximum storage for each storage system
*

1 million files for each disk group

Oracle Database supports datafile sizes up to 128 TB. ASM supports file sizes greater than 128 TB in any redundancy mode. This provides near unlimited capacity for future growth. The ASM file size limits are as follows:

*

External redundancy - 140 PB
*

Normal redundancy - 42 PB
*

High redundancy - 15 PB

Disk Group Compatibility

This section describes disk group compatibility under the following topics:

*

Overview of Disk Group Compatibility
*

Disk Group Compatibility Attributes
*

Setting Disk Group Compatibility Attributes
*

Considerations When Setting Disk Group Compatibility
*

Considerations When Setting Disk Group Compatibility in Replicated Environments

Overview of Disk Group Compatibility

The disk group compatibility feature enables environments to interoperate when they use disk groups from both Oracle Database 10g and Oracle Database 11g. For example, disk group compatibility settings that are set to Oracle Database 10g enable a Database 10g database client to access a disk group created with Oracle Database 11g ASM.

The disk group attributes that determine compatibility are COMPATIBLE.ASM and COMPATIBLE.RDBMS. The COMPATIBLE.ASM and COMPATIBLE.RDBMS attribute settings determine the minimum Oracle Database software version numbers that a system can use for ASM and RDBMS instance types respectively. For example, if the ASM compatibility setting is 11.1, and RDBMS compatibility is set to 10.1, then the ASM software version must be at least 11.1, and the Oracle Database client software version must be at least 10.1.

When you create a disk group, you can specify the COMPATIBLE.ASM and COMPATIBLE.RDBMS attribute settings in the CREATE DISKGROUP SQL statement. The ALTER DISKGROUP SQL statement can update the compatible attribute settings for existing disk groups. If not specified, 10.1 is the default setting for both the COMPATIBLE.ASM and COMPATIBLE.RDBMS attributes for ASM in Oracle Database 11g. See Table 4-2 for valid combinations of compatible attribute settings.

Advancing the disk group RDBMS and ASM compatibility settings enables you to use the new ASM features that are available in a later release. For example, a disk group with the RDBMS and ASM compatibility set to 11.1 can take advantage of new Oracle 11g features, such as variable extent sizes and fast mirror resync. See Table 4-3 for the features enabled for combinations of compatibility attribute settings.

Note:

*

The compatible attribute settings for a disk group can only be advanced; you cannot revert to a lower compatibility setting.
*

The disk group compatibility settings determine whether your environment can use the latest ASM features.

Disk Group Compatibility Attributes

The COMPATIBLE.ASM and COMPATIBLE.RDBMS disk group attributes specify the compatibility settings for Oracle ASM and database instances. These attributes are described under the following topics:

*

COMPATIBLE.ASM
*

COMPATIBLE.RDBMS

COMPATIBLE.ASM

The value for the disk group COMPATIBLE.ASM attribute determines the minimum software version for an ASM instance that uses the disk group. This setting also determines the format of the data structures for the ASM metadata on the disk. The format of the file contents is determined by the database instance. For ASM in Oracle Database 11g, 10.1 is the default setting for the COMPATIBLE.ASM attribute.
COMPATIBLE.RDBMS

The value for the disk group COMPATIBLE.RDBMS attribute determines the minimum COMPATIBLE database initialization parameter setting for any database instance that uses the disk group. For example, if the database COMPATIBLE initialization parameter is set to 11.1.0, then COMPATIBLE.RDBMS can be set to any value between 10.1 and 11.1 inclusively. For ASM in Oracle Database 11g, 10.1 is the default setting for the COMPATIBLE.RDBMS attribute.

Caution:
If you advance the COMPATIBLE.RDBMS attribute, then you cannot revert to the previous setting. Before advancing the COMPATIBLE.RDBMS attribute, ensure that the values for the COMPATIBLE initialization parameter for all of the databases that use the disk group are set to at least the new setting for COMPATIBLE.RDBMS before you advance the attribute value.

Note:
The database initialization parameter COMPATIBLE enables you to use a new release of Oracle, while at the same time guaranteeing backward compatibility with an earlier release. See Oracle Database Reference for more information about the COMPATIBLE initialization parameter.
Setting Disk Group Compatibility Attributes

You can set disk group compatibility with the CREATE DISKGROUP or ALTER DISKGROUP SQL statement.

This section contains these topics:

*

Valid Combinations of Compatibility Attribute Settings
*

Using CREATE DISKGROUP with Compatibility Attributes
*

Using ALTER DISKGROUP with Compatibility Attributes
*

Viewing Compatibility Attribute Settings

When setting the values for the COMPATIBLE.RDBMS and COMPATIBLE.ASM attributes, specify at least the first two digits of a valid Oracle Database release number. For example, you can specify compatibility as '10.1' or '11.1'; Oracle assumes that any missing version number digits are zeros.

Note:
Advancing the values for on-disk compatibility attributes is an irreversible operation. To revert to the previous value, you must create a new disk group with the old compatibility attributes and then restore the database files that were in the disk group.

See Also:
Oracle Database SQL Language Reference for more information about the disk group compatibility SQL statements
Valid Combinations of Compatibility Attribute Settings

Table 4-2 shows the valid combinations of the COMPATIBLE.ASM and the COMPATIBLE.RDBMS attributes and the valid ASM and database instance versions for each combination.

Table 4-2 Disk Group Compatibility Attribute Settings Matrix
COMPATIBLE.ASM COMPATIBLE.RDBMS ASM Instance Version COMPATIBLE Setting for RDBMS Instance

10.1


10.1


>=10.1


>=10.1

11.1


10.1


>=11.1


>=10.1

11.1


10.2


>=11.1


>=10.2

11.1


11.1


>=11.1


>=11.0

Based on Table 4-2, these are some of the possible combinations of ASM and database releases:

*

The database release is 11.1 (COMPATIBLE set to 11.0) and the ASM release is 10g. The ASM functionality remains at 10g.
*

The database release is 10g and the ASM release is 11.1. Both the COMPATIBLE.ASM and the COMPATIBLE.RDBMS disk group attributes are set to the default value of 10.1. The ASM disk group functionality remains at 10g.
*

The database release is 10g and the ASM release is 11.1. COMPATIBLE.ASM is set to 11.1 and COMPATIBLE.RDBMS is set to 10.1. The ASM disk group attributes are displayed in the V$ASM_ATTRIBUTE view. The disk group functionality is described in Table 4-3.
*

The database release is 11.1 (COMPATIBLE set to 11.0) and the ASM release is 11.1. Both the COMPATIBLE.ASM and the COMPATIBLE.RDBMS disk group attributes are set to 11.1. The ASM disk group attributes are displayed in the V$ASM_ATTRIBUTE view. The disk group functionality is described in Table 4-3.

Note:
The V$ASM_ATTRIBUTE does not display any rows when running ASM release 10g or when the COMPATIBLE.ASM value is 10.1. Instead you can determine the values for the COMPATIBLE.ASM and COMPATIBLE.RDBMS disk group attributes with the COMPATIBILITY and DATABASE_COMPATIBILITY columns of the V$ASM_DISKGROUP view. The ALLOCATION_UNIT_SIZE column of the V$ASM_DISKGROUP view displays the value of the AU_SIZE disk group attribute.
Using CREATE DISKGROUP with Compatibility Attributes

You can specify the compatibility settings for a disk group with the CREATE DISKGROUP statement when creating the disk group.

The following example creates a normal redundancy disk group diskgrp1 with the ASM compatibility set to 11.1 and the RDBMS compatibility set to the default (assuming that the COMPATIBLE.RDBMS default is less than or equal to 11.1):

CREATE DISKGROUP diskgrp1 DISK '/dev/raw/*'
ATTRIBUTE 'compatible.asm' = '11.1';

The following example creates a normal redundancy disk group diskgrp2 with both the ASM and the RDBMS compatibility set to 11.1:

CREATE DISKGROUP diskgrp2 DISK '/dev/raw/*'
ATTRIBUTE 'compatible.rdbms' = '11.1', 'compatible.asm' = '11.1';

Using ALTER DISKGROUP with Compatibility Attributes

After a disk group has been created, you can use the ALTER DISKGROUP SQL statement to change the compatibility attributes. Using the ALTER DISKGROUP SQL statement ensures that Oracle can advance the compatibility of the specified disk group before committing the change.

All of the affected databases and file systems should be online when running ALTER DISKGROUP to ensure that advancing compatibility does not reduce the database and file system functionality. When advancing disk group compatibility, advance the COMPATIBLE.ASM attribute before the COMPATIBLE.RDBMS attribute to ensure a valid combination of compatible attribute settings as shown in Table 4-2.

The following example advances the ASM compatibility for disk group diskgrp3 to 11.1. An ASM instance must be at release 11.1 and higher to access the diskgrp3 disk group.

ALTER DISKGROUP diskgrp3 SET ATTRIBUTE 'compatible.asm' = '11.1'

The following example advances the RDBMS compatibility of the disk group diskgrp4 to 11.1. This example assumes that the ASM compatibility is already advanced to 11.1.

ALTER DISKGROUP diskgrp4 SET ATTRIBUTE 'compatible.rdbms' = '11.1'

Viewing Compatibility Attribute Settings

In addition to appearing in the V$ASM_ATTRIBUTE view, the compatibility attribute values also appear in the columns labeled DATABASE_COMPATIBILITY and COMPATIBILITY in the V$ASM_DISKGROUP view. See Example 4-2, "Viewing Disk Groups with Associated Attributes" for an example querying the V$ASM_ATTRIBUTE view.

See Also:

*

Oracle Database SQL Language Reference for information about disk group attributes
*

Oracle Database Reference for details on the V$ASM_DISKGROUP and V$ASM_ATTRIBUTE dynamic performance views

Considerations When Setting Disk Group Compatibility

When changing the disk group compatibility settings, there are some considerations that you should be aware of.

*

If a backup of a disk group was made with the ASMCMD md_backup command prior to changing the compatibility settings, that full backup file would be incorrect for the updated disk group. Restoring that the full previous backup would set the disk group to the previous compatibility settings.

You can still use the previous backup to restore some metadata. For example, you could create a new disk group and use the backup file to restore templates and alias directories metadata. For information about using md_backup and md_restore, refer to "md_backup Command" and "md_restore Command".
*

The disk group compatibility settings should be the same for all replication environments.
*

The disk group compatibility settings cannot be changed during a rolling upgrade.
*

The compatibility settings can only be advanced and the settings are irreversible.
*

Not all combinations of the disk group compatibility settings are valid and some features are not enabled in various combinations. See Table 4-2 for valid combinations of COMPATIBLE.ASM and COMPATIBLE.RDBMS settings. See Table 4-3 for the disk group features enabled by valid combinations of COMPATIBLE.ASM and COMPATIBLE.RDBMS settings.

Table 4-3 Features Enabled by Disk Group Compatibility Attribute Settings
Disk Group Features Enabled COMPATIBLE.ASM COMPATIBLE.RDBMS

Different AU sizes (1, 2, 4, or 8MB)


>= 10.1


=< COMPATIBLE.ASM setting

Attributes are displayed in the V$ASM_ATTRIBUTE view


11.1


=< COMPATIBLE.ASM setting

Support for larger AU sizes (16, 32, or 64MB)


11.1


11.1

Fast mirror resync


11.1


11.1

Variable size extents


11.1


11.1

Preferred read failure groups


11.1


11.1

ASM features not explicitly listed in Table 4-3 do not require advancing the disk group compatibility attribute settings.
Considerations When Setting Disk Group Compatibility in Replicated Environments

If you advance disk group compatibility, then you could enable the creation of files that are too large to be managed by a previous Oracle database release. You need to be aware of the file size limits because replicated sites cannot continue using the software from a previous release to manage these large files.

Table 4-4 shows the maximum ASM file sizes supported for COMPATIBLE.RDBMS settings. Note that memory consumption is identical in all cases: 280 MB. For Oracle Database 11g, the number of extent pointers for each size is 16800, with the largest size using the remainder. The RDBMS instance limits file sizes to a maximum of 128TB.

Table 4-4 Maximum ASM File Size
Redundancy COMPATIBLE.RDBMS = 10.1 COMPATIBLE.RDBMS = 11.1

External


35 TB


140 PB

Normal


5.8 TB


23 PB

High


3.9 TB


15 PB

Table 4-4 shows that Oracle Database 10g can only support a file size of up to 35 TB for external redundancy. If you advance the RDBMS compatibility to 11.1, then a file can grow beyond 35 TB. However, the larger size will make the file unusable in a replicated and disaster recovery site if the disaster recovery site has a disk group COMPATIBLE.RDBMS setting that is incompatible with the larger size.

See Also:

*

Oracle Database Upgrade Guide for information about database compatibility
*

Oracle Database Administrator's Guide for information about the COMPATIBLE initialization parameter and irreversible compatibility
*

Oracle Database Reference for information about the COMPATIBLE initialization parameter

Mounting and Dismounting Disk Groups

Disk groups that are specified in the ASM_DISKGROUPS initialization parameter are mounted automatically at ASM instance startup. This makes them available to all database instances running on the same node as ASM. The disk groups are dismounted at ASM instance shutdown. ASM also automatically mounts a disk group when you initially create it, and dismounts a disk group if you drop it.

There might be times that you want to mount or dismount disk groups manually. For these actions use the ALTER DISKGROUP...MOUNT or ALTER DISKGROUP...DISMOUNT statement. You can mount or dismount disk groups by name, or specify ALL.

If you try to dismount a disk group that contains open files, the statement will fail, unless you also specify the FORCE clause.

In a clustered ASM environment in RESTRICTED mode, a disk group is mounted in single-instance exclusive mode. No other ASM instance in that cluster can mount that disk group. In this mode the disk group is not usable by any ASM client. Use this mode to perform a fast rebalance.

The following SQL statement dismounts all disk groups that are currently mounted to the ASM instance:

ALTER DISKGROUP ALL DISMOUNT;

The following SQL statement mounts disk group dgroup1:

ALTER DISKGROUP dgroup1 MOUNT;

Mounting Disk Groups Using the FORCE Option

For normal and high redundancy disk groups, you can use the FORCE option of the ALTER DISKGROUP statement's MOUNT clause to mount disk groups if there are sufficient ASM disks available. The disk group mount succeeds if ASM finds at least one complete set of extents in a disk group. If ASM determines that one or more disks are not available, then ASM moves those disks off line and drops the disks after the DISK_REPAIR_TIME expires.

In clustered ASM environments, if an ASM instance is not the first instance to mount the disk group, then using the MOUNT FORCE statement fails. This is because the disks have been accessed by another instance and the disks are not locally accessible.

Use the FORCE option as in the following example where disk_group_name is the name of the disk group that you want to force mount:

ALTER DISKGROUP disk_group_name MOUNT FORCE

See Also:
The Oracle Database SQL Language Reference for additional information about the ALTER DISKGROUP statement and the FORCE option
Checking the Internal Consistency of Disk Group Metadata

You can check the internal consistency of disk group metadata using the ALTER DISKGROUP statement with the CHECK keyword. You can use this statement to check specific files in a disk group, specific disks or all disks in a disk group, or specific failure groups within a disk group. The disk group must be mounted to perform these checks.

By default, the CHECK DISK GROUP clause verifies all of the metadata directories. ASM displays summary errors and writes the details about the errors in an alert log. The CHECK keyword performs the following operations:

*

Verifies the consistency of the disk
*

Cross checks all of the file extent maps and allocation tables for consistency
*

Checks that the alias metadata directory and file directory are linked correctly
*

Verifies that the alias directory tree is linked correctly
*

Checks that ASM metadata directories do not have unreachable allocated blocks

The REPAIR | NOREPAIR clause specifies whether ASM should attempt to repair errors that are found during the check. The default is NOREPAIR. Use the NOREPAIR clause to receive alerts about inconsistencies and to suppress ASM from resolving the errors automatically. The following example statement checks for consistency in the metadata for all disks in the dgroup1 disk group:

ALTER DISKGROUP dgroup1 CHECK ALL;

See Also:
The Oracle Database SQL Language Reference for additional information about the CHECK clause syntax
Dropping Disk Groups

The DROP DISKGROUP statement enables you to delete an ASM disk group and optionally, all of its files. You can specify the INCLUDING CONTENTS clause if you also want to delete any files that might be contained in the disk group. The default is EXCLUDING CONTENTS, which provides syntactic consistency and prevents you from dropping the disk group if it has any contents

The ASM instance must be started and the disk group must be mounted with none of the disk group files open, in order for the DROP DISKGROUP statement to succeed. The statement does not return until the disk group has been dropped.

When you drop a disk group, ASM dismounts the disk group and removes the disk group name from the ASM_DISKGROUPS initialization parameter if a server parameter file is being used. If a text initialization parameter file is being used, and the disk group is mentioned in the ASM_DISKGROUPS initialization parameter, then you must remove the disk group name from the ASM_DISKGROUPS initialization parameter before the next time that you shut down and restart the ASM instance.

The following statement deletes dgroup1:

DROP DISKGROUP dgroup1;

After ensuring that none of the files contained in dgroup1 are open, ASM rewrites the header of each disk in the disk group to remove ASM formatting information. The statement does not specify INCLUDING CONTENTS, so the drop operation will fail if the disk group contains any files.

If you cannot mount a disk group but need to drop it, you can use the FORCE option of the DROP DISKGROUP statement. This command enables you to remove the headers on disks that belong to a disk group that cannot be mounted by any ASM instances as in the following example where disk_group_name is the name of the disk group:

DROP DISKGROUP disk_group_name FORCE

The disk group on which you perform this operation should not be mounted anywhere in the cluster. When you use the FORCE option, the ASM instance does not attempt to verify that a disk group is being used by another ASM instance in the same storage subsystem.

Note:
Only use the FORCE option with extreme caution.

You can also drop a disk group with Oracle Enterprise Manager. See "Dropping Disk Groups".
Using Views to Obtain ASM Information

You can use the views in Table 4-5 to obtain information about ASM:

Table 4-5 ASM Dynamic Views
View Description

V$ASM_ALIAS


In an ASM instance, contains one row for every alias present in every disk group mounted by the ASM instance.

In a DB instance, contains no rows.

V$ASM_ATTRIBUTE


Displays one row for each attribute defined. In addition to attributes specified by CREATE DISKGROUP and ALTER DISKGROUP statements, the view may show other attributes that are created automatically. Note that attributes are only displayed for disk groups where COMPATIBLE.ASM is set to 11.1 or higher.

V$ASM_CLIENT


In an ASM instance, identifies databases using disk groups managed by the ASM instance.

In a DB instance, contains information about the ASM instance if the database has any open ASM files.

V$ASM_DISK


In an ASM instance, contains one row for every disk discovered by the ASM instance, including disks that are not part of any disk group.

In a DB instance, contains rows only for disks in the disk groups in use by that DB instance.

This view performs disk discovery every time it is queried.

V$ASM_DISK_IOSTAT


Displays information about disk I/O statistics for each ASM client.

In a DB instance, only the rows for that instance are shown.

V$ASM_DISK_STAT


In an ASM instance, contains the same columns as V$ASM_DISK, but to reduce overhead, does not perform a discovery when it is queried. It does not return information about any disks that are new to the storage system. For the most accurate data, use V$ASM_DISK instead.

V$ASM_DISKGROUP


In an ASM instance, describes a disk group (number, name, size related info, state, and redundancy type).

In a DB instance, contains one row for every ASM disk group mounted by the local ASM instance.

This view performs disk discovery every time it is queried.

V$ASM_DISKGROUP_STAT


In an ASM instance, contains the same columns as V$ASM_DISKGROUP, but to reduce overhead, does not perform a discovery when it is queried. It does not return information about any disks that are new to the storage system. For the most accurate data, use V$ASM_DISKGROUP instead.

V$ASM_FILE


In an ASM instance, contains one row for every ASM file in every disk group mounted by the ASM instance.

In a DB instance, contains no rows.

V$ASM_OPERATION


In an ASM instance, contains one row for every active ASM long running operation executing in the ASM instance.

In a DB instance, contains no rows.

V$ASM_TEMPLATE


In an ASM or DB instance, contains one row for every template present in every disk group mounted by the ASM instance.

An example of the use of the V$ASM_ATTRIBUTE and V$ASM_DISKGROUP views is shown in Example 4-2. Note that COMPATIBLE.ASM must be set to 11.1 or higher for the disk group to display in the V$ASM_ATTRIBUTE view output.

Example 4-2 Viewing Disk Groups with Associated Attributes

SQL> SELECT dg.name AS diskgroup, SUBSTR(a.name,1,24) AS name,
SUBSTR(a.value,1,24) AS value FROM V$ASM_DISKGROUP dg, V$ASM_ATTRIBUTE a
WHERE dg.name = 'DGROUP1' AND dg.group_number = a.group_number;

DISKGROUP NAME VALUE
---------------------------- ------------------------ ------------------------
DGROUP1 compatible.rdbms 11.1.0.0.0
DGROUP1 compatible.asm 11.1.0.0.0
DGROUP1 au_size 1048576
DGROUP1 disk_repair_time 3.6h
...

An example of the use of the V$ASM_DISK and V$ASM_DISKGROUP views is shown in Example 4-3. This example displays the disks associated with a disk group, plus the minimum ASM and database software versions required to use the disk group.

Example 4-3 Viewing Disk Groups with Associated Disks

SQL> SELECT dg.name AS diskgroup, SUBSTR(d.name,1,16) AS asmdisk,
SUBSTR(dg.compatibility,1,12) AS asm_compat,
SUBSTR(dg.database_compatibility,1,12) AS db_compat,
FROM V$ASM_DISKGROUP dg, V$ASM_DISK d
WHERE dg.name LIKE 'DGROUP%' AND dg.group_number = d.group_number;

DISKGROUP ASMDISK ASM_COMPAT DB_COMPAT
------------------------------ ---------------- ------------ ------------
DGROUP1 DISK1A 11.1.0.0.0 11.0.0.0.0
DGROUP1 DISK1B 11.1.0.0.0 11.0.0.0.0
DGROUP1 DISK1C 11.1.0.0.0 11.0.0.0.0
...
DGROUP2 DISK2A 11.1.0.0.0 10.1.0.0.0
DGROUP2 DISK2B 11.1.0.0.0 10.1.0.0.0
DGROUP2 DISK2C 11.1.0.0.0 10.1.0.0.0
...

An example of the use of the V$ASM_CLIENT and V$ASM_DISKGROUP views on an ASM instance is shown in Example 4-4. This example displays disk groups with information about the connected database client instances.

Example 4-4 Viewing Disk Groups with Associated Client Version Settings

SQL> SELECT dg.name AS diskgroup, SUBSTR(c.instance_name,1,12) AS instance,
SUBSTR(c.db_name,1,12) AS dbname, SUBSTR(c.SOFTWARE_VERSION,1,12) AS software,
SUBSTR(c.COMPATIBLE_VERSION,1,12) AS compatible
FROM V$ASM_DISKGROUP dg, V$ASM_CLIENT c
WHERE dg.group_number = c.group_number;

DISKGROUP INSTANCE DBNAME SOFTWARE COMPATIBLE
------------------------------ ------------ -------- ------------ ------------
CONTROLFILE dblinux dblinux 11.1.0.6.0 11.0.0.0.0
DATAFILE dblinux dblinux 11.1.0.6.0 11.0.0.0.0
LOGFILE dblinux dblinux 11.1.0.6.0 11.0.0.0.0
...