Showing posts with label ASM. Show all posts
Showing posts with label ASM. Show all posts

Thursday, December 6, 2007

Installing Oracle Database 10g with Real Application Cluster (RAC) on Red Hat Enterprise Linux Advanced Server 3

The following procedure is a step-by-step guide (Cookbook) with tips and information for installing Oracle Database 10g with Real Application Cluster (RAC) on Red Hat Enterprise Linux Advanced Server 3. The primary objective of this article is to demonstrate a quick installation of Oracle 10g with RAC on RH AS 3. This article covers Oracle Cluster File System (OCFS), Oracle's Automatic Storage Management (ASM), and FireWire-based Shared Storage. Note that OCFS is not required for 10g 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.

If you have never installed Oracle10g on Linux before, then I'd recommend that you first try to install an Oracle Database 10g on Linux by following my other guide Installing Oracle Database 10g on Red Hat Linux.

I welcome emails from any readers with comments, suggestions, or corrections. You can find my email address at the bottom of this website.


This article covers the following subjects and steps:

Introduction

* General
* Important Notes
* Oracle 10g RAC Setup
* Shared Disks Storage
General
FireWire-based Shared Storage for Linux

Pre-Installation Steps for All Clustered RAC Nodes

* Downloading Oracle 10g Software and Burning Oracle 10g CDs
* Installing Red Hat Advanced Server
Installing Software Packages (RPMs)
* Upgrading the Linux Kernel
General
Upgrading the Linux Kernel for FireWire Shared Disks Only
* Configuring the Network
General
Setting Up the /etc/hosts File
Configuring the Network Interfaces (NICs)
* Configuring Shared Storage Devices
General
Configuring 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
Configuring and Loading OCFS
Creating OCFS File Systems
Mounting OCFS File Systems
Configuring the OCFS File Systems to Mount Automatically at Startup
Installing and Configuring Automatic Storage Management (ASM) and Disks
* Installing and Configuring Automatic Storage Management (ASM) and Disks
General
Installing ASM
Configuring and Loading ASM
Creating ASM Disks
* Configuring the "hangcheck-timer" Kernel Module
* Setting up RAC Nodes for Remote Access
* Checking Packages (RPMs)
* Adjusting Network Settings
* Sizing Swap Space
* Setting Shared Memory
* Checking /tmp Space
* Setting Semaphores
* Setting File Handles

Installing Cluster Ready Services (CRS)

* General
* Automating Authentication for oracle ssh Logins
* Checking OCFS and Oracle Environment Variables
Checking OCFSs
Checking Oracle Environment Variables
* Installing Oracle 10g Cluster Ready Services (CRS) R1 (10.1.0.2)

Installing Oracle Database 10g Software with Real Application Clusters (RAC)

* General
* Automating Authentication for oracle ssh Logins
* Checking Oracle Environment Variables
* Installing Oracle Database 10g Software R1 (10.1.0.2) with Real Application Clusters (RAC)

Installing Oracle Database 10g with Real Application Cluster (RAC)

* General
* Automating Authentication for oracle ssh Logins
* Setting Oracle Environment Variables
* Installing Oracle Database 10g with Real Application Cluster (RAC)

Post-Installation Steps

* Transparent Application Failover (TAF)
Introduction
Setup
Example of a Transparent Application Failover (TAF)
* Checking Automatic Storage Management (ASM)
* Oracle 10g RAC Issues, Problems and Errors
* References


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 a few important notes that might be useful to know before installing Oracle 10g RAC:

(*) If you want to install Oracle 10g with RAC using FireWire-base shared storage, make sure to read first FireWire-based Shared Storage for Linux!

(*) See also Oracle 10g RAC Issues, Problems and Errors


Oracle 10g RAC Setup
This article covers the installation of Oracle 10g with RAC on three RHELAS 3 servers (including the use of FireWire-based shared storage):
RAC node Database Name Oracle SID $ORACLE_BASE Oracle Datafile Directory
--------------- ------------- ---------- --------------- ----------------------------------
rac1pub/rac1prv orcl orcl1 /u01/app/oracle Automatic Storage Management (ASM)
rac2pub/rac2prv orcl orcl2 /u01/app/oracle Automatic Storage Management (ASM)
rac3pub/rac3prv orcl orcl3 /u01/app/oracle Automatic Storage Management (ASM)


For this documentation I used Oracle Cluster File System (OCFS) for Oracle's Cluster Ready Services (CRS) since some people want to know how to configure and use OCFS. However, OCFS is not required for 10g RAC. In fact, I never use OCFS for RAC systems. CRS requires two files, the "Oracle Cluster Registry (OCR)" file and the "CRS Voting Disk" file, which must be shared accross all RAC nodes. You can also use raw devices for these files. Note, however, that you cannot use ASM for the CRS files. These CRS files need to be available for any RAC instance to run. And for ASM to become available, the ASM instance needs to run first.

For Oracle's data files, control files, etc. I used Oracle's Automatic Storage Management (ASM).


Shared Disks Storage
General

A requirement for Oracle Database 10g 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 or ASM. This article will address Oracle's Cluster File System OCFS and ASM. Note that Oracle 10g 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 be expensive. If you just want to check out the features of Oracle10g RAC without spending too much on cost, I'd recommend to buy an external FireWire-based shared Storage for Oracle10g RAC.
NOTE: You can download a kernel from Oracle for FireWire-based shared storage for Oracle10g RAC, but Oracle does not provide support if you have problems. It is intended for testing and demonstration only! See Setting Up Linux with FireWire-based Shared Storage for Oracle Database 10g RAC for more information.

NOTE: It is very important to get an external FireWire drive 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 at Configuring FireWire-based Shared Storage.

For test purposes I used external 250 GB and 200 GB Maxtor hard drives which support a maximum of 3 concurrent logins. The technical specifications for these FireWire drives are:
- 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 Maxtor 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 adapters I'm using are StarTech 4 Port IEEE-1394 PCI Firewire Cards. 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!


Downloading Oracle 10g Software and Burning Oracle 10g CDs
To install Oracle 10g with RAC, you will need the images "ship.crs.cpio.gz" (Cluster Ready Services 10.1.0.2) and "ship.db.cpio.gz" (Oracle Database 10g 10.1.0.2).
For more information on downloading the images and burning CDs, see Downloading Oracle10g Software and Burning Oracle10g CDs.


Installing Red Hat Advanced Server
You can find the installation guide for installing Red Hat Linux Advanced Server at 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 can buy licenses 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 Oracle Database 10g with RAC on Red Hat Linux 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 Oracle 10g RAC, which are covered in this article.


Upgrading the Linux Kernel
General

It is recommended to use newer Red Hat Enterprise Linux kernels since newer kernels might fix known database performance problems and other issues. Unless you are using FireWire-based shared drives (see below), I recommend to download the latest RHELAS3 kernel from Red Hat Network and to use Upgrading the Linux Kernel as a guide for upgrading the kernel. However, you also need to make sure that the OCFS and ASM drivers are compatible with the kernel version!


Upgrading the Linux Kernel for FireWire Shared Disks ONLY

You can download a kernel from Oracle for FireWire-Based Shared Storage for Oracle Database 10g RAC, but Oracle does not support it. It is intended for testing and demonstration only! See Setting Up Linux with FireWire-based Shared Storage for Oracle10g RAC for more information.

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

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 kernel-2.4.21-15.ELorafw1.i686.rpm
Note that the above command does not upgrade your existing kernel. This is the preferred method since you always want the option to go back to the old kernel if 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 Enterprise Linux AS (2.4.21-15.ELorafw1)
root (hd0,0)
kernel /vmlinuz-2.4.21-15.ELorafw1 ro root=LABEL=/
initrd /initrd-2.4.21-15.ELorafw1.img
title Red Hat Enterprise Linux AS (2.4.21-4.EL)
root (hd0,0)
kernel /vmlinuz-2.4.21-4.EL ro root=LABEL=/
initrd /initrd-2.4.21-4.EL.img

In this example, the "default" attribute is set to "0" which means that the the experimental FireWire kernel 2.4.21-9.0.1.ELorafw1 will be booted. If the "default" attribute would be set to "1", the 2.4.21-9.EL 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 shouldn't have to update default parameter in the /etc/grub.conf file. However, I have seen cases where this didn't work. So I recommend to check the default setting after you removed the old kernel.


Configuring the Network
General

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 Oracle.

You might want to manage the network addresses using the /etc/hosts file. This avoids the problem of making DNS, NIS, etc. a single point of failure for the database cluster.

Make sure that no firewall is running or that it doesn't interfere with RAC, respectively.

Setting Up the /etc/hosts File

Here is an example how the /etc/hosts file could look like:
# Public hostnames for e.g. eth0 interfaces (public network)

192.168.1.1 rac1pub.puschitz.com rac1pub # RAC node 1
192.168.1.2 rac2pub.puschitz.com rac2pub # RAC node 2
192.168.1.3 rac3pub.puschitz.com rac3pub # RAC node 3

# Private hostnames, private network for e.g. eth1 interfaces (Interconnect)

192.168.2.1 rac1prv.puschitz.com rac1prv # RAC node 1
192.168.2.2 rac2prv.puschitz.com rac2prv # RAC node 2
192.168.2.3 rac3prv.puschitz.com rac3prv # RAC node 3

# Public virtual IP address for e.g. eth0 interfaces (public Virtual Internet Protocol (VIP))

192.168.1.51 rac1vip.puschitz.com rac1vip # RAC node 1
192.168.1.52 rac2vip.puschitz.com rac2vip # RAC node 2
192.168.1.53 rac3vip.puschitz.com rac3viv # RAC node 3


The public virtual IP addressess are configured automatically by Oracle when you run OUI, which starts Oracle's Virtual Internet Protocol Configuration Assistant (VIPCA), see Installing Oracle Database 10g Software R1 (10.1.0.2) with Real Application Clusters (RAC)


NOTE:

Make sure that the name of the RAC node is not listed for the loopback address in the /etc/hosts file similar to this example:
127.0.0.1 rac1pub localhost.localdomain localhost
The entry should look like this:
127.0.0.1 localhost.localdomain localhost


If the RAC node is listed for the loopback address, you might later get the following errors:
ORA-00603: ORACLE server session terminated by fatal error
or
ORA-29702: error occurred in Cluster Group Service operation
For more information, see Oracle 10g RAC Issues, Problems and Errors.


Configuring the Network Interfaces (NICs)

To configure the network interfaces (in this example eth0 and eth1), run the following command on each node.
su - root
redhat-config-network
NOTE: You do not have to configure the network alias names for the public VIP. This will be done by Oracle's Virtual Internet Protocol Configuration Assistant (VIPCA).

NOTE: When the network configuration is done, it is important to make sure that the name of the public RAC nodes is displayed when you execute the following command:
$ hostname
rac1pub


You can verify the new configured NICs by running the command:
/sbin/ifconfig


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 that the experimental kernel for FireWire drives was installed and that the server was rebooted (see Upgrading the Linux Kernel for FireWire Shared Disks Only):
# uname -r
2.4.21-15.ELorafw1


To load the kernel modules/drivers for the FireWire drive(s), add the following entry to the /etc/modules.conf file:
alias ieee1394-controller ohci1394
post-install ohci1394 modprobe sd_mod


The alias directive ieee1394-controller is used by Red Hat during the boot process. When you check the /etc/rc.d/rc.sysinit file, which is invoked by /etc/inittab during the boot process, you will find the following code that searches for the ieee1394-controller stanza in /etc/modules.conf:
if ! strstr "$cmdline" nofirewire ; then
aliases=`/sbin/modprobe -c | awk '/^alias ieee1394-controller/ { print $3 }'`
if [ -n "$aliases" -a "$aliases" != "off" ]; then
for alias in $aliases ; do
[ "$alias" = "off" ] && continue
action $"Initializing firewire controller ($alias): " modprobe $alias
done
LC_ALL=C grep -q "SBP2" /proc/bus/ieee1394/devices 2>/dev/null && \
modprobe sbp2 >/dev/null 2>&1
fi
fi
This means that all the kernel modules for the FireWire drive(s) will be loaded automatically during the next reboot and your drive(s) should be ready for use.

To load the modules or the firewire stack right away without rebooting the server, execute the following commands:
su - root
modprobe ieee1394-controller; modprobe sd_mod


If everything worked fine, the following modules should be loaded:
su - root
# lsmod |egrep "ohci1394|sbp2|ieee1394|sd_mod|scsi_mod"
sbp2 19724 0
ohci1394 28008 0 (unused)
ieee1394 62884 0 [sbp2 ohci1394]
sd_mod 13424 0
scsi_mod 104616 5 [sbp2 sd_mod sg sr_mod ide-scsi]
#


And when you run dmesg, you should see entries similar to this example:
# dmesg
...
ohci1394_0: OHCI-1394 1.0 (PCI): IRQ=[11] MMIO=[f2000000-f20007ff] Max Packet=[2048]
ieee1394: Device added: Node[00:1023] GUID[0010b9f70089de1c] [Maxtor]
scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices
blk: queue cf172e14, I/O limit 4095Mb (mask 0xffffffff)
ieee1394: ConfigROM quadlet transaction error for node 01:1023
ieee1394: Host added: Node[02:1023] GUID[00110600000032a0] [Linux OHCI-1394]
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]
Vendor: Maxtor Model: OneTouch Rev: 0200
Type: Direct-Access ANSI SCSI revision: 06
blk: queue cd0fb014, I/O limit 4095Mb (mask 0xffffffff)
Attached scsi disk sda at scsi1, channel 0, id 0, lun 0
SCSI device sda: 398295040 512-byte hdwr sectors (203927 MB)
sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 >


In this example, the kernel reported that the FireWire drive can be shared concurrently by 3 servers (see "Maximum concurrent logins supported:"). It is very important that you have a drive with a chipset and firmware that supports concurrent access for the nodes. The "Number of active logins:" shows how many servers are already sharing/using the drive before this server added the drive to its system.


If everything worked fine, you should be able to see now your FireWire drive(s):
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 6375 51207156 83 Linux
/dev/sda2 6376 12750 51207187+ 83 Linux
...
And if you power off or power on your FireWire drive(s), respectively, the drives should be removed and added to the system automatically, which can take about 5-10 seconds.

If everything worked fine without any errors or problems, I would recommend to reboot all RAC nodes to verify that all FireWire drive(s) are automatically added to the system during the next boot process:
su - root
reboot
And after the reboot, execute the fdisk command again to verify that the FireWire drive(s) were added to the system:
su - root
# fdisk -l

PROBLEMS:

Note that if you have a USB device attached, the system might not be able to recognice your FireWire drive!

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 fine:
# lspci
...
00:14.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46)
...


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 could either be "unowned", or they could 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
Since the Oracle Universal Installer (OUI) "runInstaller" is executed from the oracle account, some environment variables must be configured for the oracle account before OUI is started.

Note: 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, and so on.

If you use bash which is the default shell on Red Hat Linux (to verify your shell run: echo $SHELL), execute the following commands:
# Oracle Environment
export ORACLE_BASE=/u01/app/oracle
export ORACLE_SID=orcl1 # Each RAC node must have a unique Oracle SID! E.g. orcl1, orcl2,...
export LD_LIBRARY_PATH=$ORACLE_HOME/lib


NOTE: If ORACLE_BASE is used, then Oracle recommends that you don't set the ORACLE_HOME environment variable but that you choose the default path suggested by the OUI. You can set and use ORACLE_HOME after you finished installing the Oracle Database 10g Software with RAC, see Installing Oracle Database 10g Software R1 (10.1.0.2) with Real Application Clusters (RAC).

The environment variables ORACLE_HOME and TNS_ADMIN should not be set. If you already set these environment variables, you can unset them by executing the following commands:
unset ORACLE_HOME
unset TNS_ADMIN

To have these environment variables set automatically each time you login as oracle, you can add these environment variables to the ~oracle/.bash_profile file for the Bash shell on Red Hat Linux. To do this you could simply copy/paste the following commands to make these settings permanent for the oracle Bash shell:
su - oracle
cat >> ~oracle/.bash_profile << EOF
export ORACLE_BASE=/u01/app/oracle
export ORACLE_SID=orcl1 # Each RAC node must have a unique Oracle SID!
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
EOF


Sizing Oracle Disk Space for Database Software
You will need about 2.5 GB for the Oracle 10g RAC database software.

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.


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.

For Oracle10g you only need to create the directory for $ORACLE_BASE:
su - root
mkdir -p /u01/app/oracle
chown -R oracle.oinstall /u01


But if you want to comply with Oracle's Optimal Flexible Architecture (OFA), then you don't want to place the database files in the /u01 directory but in another directory like /u02. This is not a requirement but if you want to comply with OFA, then you might want to create the following directories as well:
su - root
mkdir -p /u02/oradata/orcl
chown -R oracle.oinstall /u02

Here I would recommend to take a quick look at Oracle's new Optimal Flexible Architecture (OFA).

NOTE: In my example I will not place the database files into the OCFS directory /u02/oradata/orcl since I will use Automatic Storage Management (ASM). However, I will use /u02/oradata/orcl for the cluster manager files, see Installing Cluster Ready Services (CRS).


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.

After you finished creating the partitions, inform the kernel of the partition table changes:
su - root
partprobe


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).


Creating Partitions for Raw Devices

If you want to use raw devices, see Creating Partitions for Raw Devices for more information. This article does not cover raw devices.


Installing and Configuring Oracle Cluster File Systems (OCFS)
Note that OCFS is not required for 10g 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 they will support Shared Oracle Home installs in the future. 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

NOTE: In my example I will use OCFS only for the cluster manager files since I will use ASM for datafiles.

Download the OCFS RPMs (drivers, tools) for RHEL3 from http://oss.oracle.com/projects/ocfs/files/RedHat/RHEL3/i386/. (you can use the same RPMs for FireWire shared disks).

To find out which OCFS driver you need for your server, run:
$ uname -a
Linux rac1pub 2.4.21-9.ELsmp #1 Thu Jan 8 17:24:12 EST 2004 i686 i686 i386 GNU/Linux


To install the OCFS RPMs for SMP kernels (including FireWire SMP kernels), execute:
su - root
rpm -Uvh ocfs-2.4.21-EL-smp-1.0.12-1.i686.rpm \
ocfs-tools-1.0.10-1.i386.rpm \
ocfs-support-1.0.10-1.i386.rpm


To install the OCFS RPMs for uniprocessor kernels (including FireWire UP kernels), execute:
su - root
rpm -Uvh ocfs-2.4.21-EL-1.0.12-1.i686.rpm \
ocfs-tools-1.0.10-1.i386.rpm \
ocfs-support-1.0.10-1.i386.rpm



Configuring and Loading OCFS

To generate the /etc/ocfs.conf file, you can run the ocfstool tool:
su - root
ocfstool
- Select "Task" - Select "Generate Config"
- Select the interconnect interface (private network interface)
In my example for rac1pub I selected: eth1, 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
ip_address = 192.168.2.1
ip_port = 7000
comm_voting = 1
guid = 84D43BC8FB7A2C1B88C3000D8821CC2C

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, execute:
su - root
# /sbin/load_ocfs
/sbin/insmod ocfs node_name=rac1prv ip_address=192.168.2.1 cs=1795 guid=84D43BC8FB7A2C1B88C3000D8821CC2C comm_voting=1 ip_port=7000
Using /lib/modules/2.4.21-EL-ABI/ocfs/ocfs.o
#
To verify if the ofcs module was loaded, execute:
# /sbin/lsmod |grep ocfs
ocfs 305920 0 (unused)


Note that the load_ocfs command doest not 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.


If you run load_ocfs on a system with the experimental FireWire kernel, you might get the following error message:
su - root
# load_ocfs
/sbin/insmod ocfs node_name=rac1prv ip_address=192.168.2.1 cs=1843 guid=AA12637FAABFB354371C000D8821CC2C comm_voting=1 ip_port=7000
insmod: ocfs: no module by that name found
load_ocfs: insmod failed
#
The ocfs.o module for the "FireWire kernel" can be found here:
su - root
# rpm -ql ocfs-2.4.21-EL-1.0.12-1
/lib/modules/2.4.21-EL-ABI/ocfs
/lib/modules/2.4.21-EL-ABI/ocfs/ocfs.o
#

So for the experimental kernel for FireWire drives, I manually created a link for the ocfs.o module 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 using the "FireWire kernel", and the output should look similar to this example:
su - root
# /sbin/load_ocfs
load_ocfs /sbin/insmod ocfs node_name=rac1prv ip_address=192.168.2.1 cs=1843 guid=AA12637FAABFB354371C000D8821CC2C comm_voting=1 ip_port=7000
Using /lib/modules/2.4.21-EL-ABI/ocfs/ocfs.o
Warning: kernel-module version mismatch
/lib/modules/2.4.21-EL-ABI/ocfs/ocfs.o was compiled for kernel version 2.4.21-4.EL
while this kernel is version 2.4.21-15.ELorafw1
Warning: loading /lib/modules/2.4.21-EL-ABI/ocfs/ocfs.o will taint the kernel: forced load
See http://www.tux.org/lkml/#export-tainted for information about tainted modules
Module ocfs loaded, with warnings
#
I would not worry about the above warning.

However, if you get the following error, then you have to upgrade the modutils RPM:
su - root
# /sbin/load_ocfs
/sbin/insmod ocfs node_name=rac2prv ip_address=192.168.2.2 cs=1761 guid=1815F1C57530339EA00E000D8825B058 comm_voting=1 ip_port=7000
Using /lib/modules/2.4.21-EL-ABI/ocfs/ocfs.o
/lib/modules/2.4.21-EL-ABI/ocfs/ocfs.o: kernel-module version mismatch
/lib/modules/2.4.21-EL-ABI/ocfs/ocfs.o was compiled for kernel version 2.4.21-4.EL
while this kernel is version 2.4.21-15.ELorafw1.
#
To remedy the "loading" problem, download the latest modutils RPM and enter e.g.:
rpm -Uvh modutils-2.4.25-11.EL.i386.rpm

To verify that the ofcs module was loaded, enter:
# /sbin/lsmod |grep ocfs
ocfs 305920 0 (unused)


Note that the load_ocfs command doest not 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.


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 /u02/oradata/orcl mount directory for the cluster manager files. In the following example I will create one OCFS filesystem and mount it on /u02/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 use the ocfstool:
su - root
ocfstool
- Select "Task" - Select "Format"

Alternatively, you can execute the "mkfs.ocfs" command to create the OCFS filesystems:
su - root
mkfs.ocfs -F -b 128 -L /u02/oradata/orcl -m /u02/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 an 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, I executed:
su - root
# mount -t ocfs /dev/sda1 /u02/oradata/orcl
or
# mount -t ocfs -L /u02/oradata/orcl /u02/oradata/orcl
Now run the ls command on all RAC nodes to check the ownership:
# ls -ld /u02/oradata/orcl
drwxrwxr-x 1 oracle oinstall 131072 Jul 4 23:25 /u02/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.


Configuring the OCFS File Systems to Mount Automatically at Startup

To ensure the OCFS filesystems are mounted automatically during reboots, 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 /u02/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, which provides access to the storage device (see mount(8)).

To make sure the ocfs.o kernel module is loaded and the OCFS file systems are mounted during the boot process, enter:
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.

At this point you might want to reboot all RAC nodes to ensure that the OCFS filesystems are mounted automatically after reboots:
su - root
reboot


Installing and Configuring Automatic Storage Management (ASM) and Disks
General

For information about what Automatic Storage Management is, see Configuring and Using Automatic Storage Management.
See also Installing Oracle ASMLib for Linux.

Installing ASM

Download the latest Oracle ASM RPMs from http://otn.oracle.com/tech/linux/asmlib/index.html.
Make sure that you download the right ASM driver for your kernel (UP or SMP).

To install the ASM RPMs on a UP server, run:
su - root
rpm -Uvh oracleasm-2.4.21-EL-1.0.0-1.i686.rpm \
oracleasm-support-1.0.2-1.i386.rpm \
oracleasmlib-1.0.0-1.i386.rpm
To install the ASM RPMs on a SMP server, run:
su - root
rpm -Uvh oracleasm-2.4.21-EL-smp-1.0.0-1.i686.rpm \
oracleasm-support-1.0.2-1.i386.rpm \
oracleasmlib-1.0.0-1.i386.rpm

Configuring and Loading ASM

To load the ASM driver oracleams.o and to mount the ASM driver filesystem, enter:
su - root
# /etc/init.d/oracleasm configure
Configuring the Oracle ASM library driver.

This will configure the on-boot properties of the Oracle ASM library
driver. The following questions will determine whether the driver is
loaded on boot and what permissions it will have. The current values
will be shown in brackets ('[]'). Hitting without typing an
answer will keep that current value. Ctrl-C will abort.

Default user to own the driver interface []: oracle
Default group to own the driver interface []: oinstall
Start Oracle ASM library driver on boot (y/n) [n]: y
Fix permissions of Oracle ASM disks on boot (y/n) [y]: y
Writing Oracle ASM library driver configuration [ OK ]
Creating /dev/oracleasm mount point [ OK ]
Loading module "oracleasm" [ OK ]
Mounting ASMlib driver filesystem [ OK ]
Scanning system for ASM disks [ OK ]
#


Creating ASM Disks

NOTE: Creating ASM disks is done on one RAC node! The following commands should only be executed on one RAC node!

I executed the following commands to create my ASM disks: (make sure to change the device names!)
(In this example I used partitions (/dev/sda2, /dev/sda3, /dev/sda5) instead of whole disks (/dev/sda, /dev/sdb, /dev/sdc,...))
su - root
# /etc/init.d/oracleasm createdisk VOL1 /dev/
Marking disk "/dev/sda2" as an ASM disk [ OK ]
# /etc/init.d/oracleasm createdisk VOL2 /dev/
Marking disk "/dev/sda3" as an ASM disk [ OK ]
# /etc/init.d/oracleasm createdisk VOL3 /dev/
Marking disk "/dev/sda5" as an ASM disk [ OK ]
#
# # Replace "sd??" with the name of your device. I used /dev/sda2, /dev/sda3, and /dev/sda5

To list all ASM disks, enter:
# /etc/init.d/oracleasm listdisks
VOL1
VOL2
VOL3
#

On all other RAC nodes, you just need to notify the system about the new ASM disks:
su - root
# /etc/init.d/oracleasm scandisks
Scanning system for ASM disks [ OK ]
#



Configuring the "hangcheck-timer" Kernel Module
Oracle uses the Linux kernel module hangcheck-timer to monitor the system health of the cluster and to reset a RAC node in case of failures. 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 very accurate time measurements since this register is updated by the hardware automatically.

The hangcheck-timer module comes now with the kernel:
find /lib/modules -name "hangcheck-timer.o"

The hangcheck-timer module has the following two parameters:
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, make entries to 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 -2
Jul 5 00:46:09 rac1pub kernel: Hangcheck: starting hangcheck timer 0.8.0 (tick is 180 seconds, margin is 60 seconds).
Jul 5 00:46:09 rac1pub kernel: Hangcheck: Using TSC.
#
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 ssh to copy Oracle software and data to other RAC nodes. Therefore, the oracle user on the RAC node where Oracle Installer is launched must be able to login to other RAC nodes without having to provide a password or passphrase.

The following procedure shows how ssh can be configured that no password is requested for oracle ssh logins.

To create an authentication key for oracle, enter the following command on all RAC node:
(the ~/.ssh directory will be created automatically if it doesn't exist yet)
su - oracle
$ ssh-keygen -t dsa -b 1024
Generating public/private dsa key pair.
Enter file in which to save the key (/home/oracle/.ssh/id_dsa): Press ENTER
Created directory '/home/oracle/.ssh'.
Enter passphrase (empty for no passphrase): Enter a passphrase
Enter same passphrase again: Etner a passphrase
Your identification has been saved in /home/oracle/.ssh/id_dsa.
Your public key has been saved in /home/oracle/.ssh/id_dsa.pub.
The key fingerprint is:
e0:71:b1:5b:31:b8:46:d3:a9:ae:df:6a:70:98:26:82 oracle@rac1pub


Copy the pulic key for oracle from each RAC node to all other RAC nodes.
For example, run the following commands on all RAC nodes:
su - oracle
ssh rac1pub cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
ssh rac2pub cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
ssh rac3pub cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys


Now verify that oracle on each RAC node can login to all other RAC nodes without a password. Make sure that ssh only asks for the passphrase. Note, however, that the first time you ssh to another server you will get a message stating that the authenticity of the host cannot be established. Enter "yes" at the prompt to continue the connection.
For example, run the following commands on all RAC nodes to verify that no password is asked:
su - oracle
ssh rac1pub hostname
ssh rac1pub hostname
ssh rac1prv hostname
ssh rac2pub hostname
ssh rac2prv hostname
ssh rac3pub hostname
ssh rac3prv hostname


And later, before runInstaller is launched, I will show how ssh can be configured that no passphrase has to be entered for oracle ssh logins.


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 are required:
rpm -q gcc glibc-devel glibc-headers glibc-kernheaders cpp compat-libstdc++
To install these RPMS, run:
su - root
rpm -ivh gcc-3.2.3-24.i386.rpm \
glibc-devel-2.3.2-95.6.i386.rpm \
glibc-headers-2.3.2-95.6.i386.rpm \
glibc-kernheaders-2.4-8.34.i386.rpm \
cpp-3.2.3-24.i386.rpm \
compat-libstdc++-7.3-2.96.123.i386.rpm
The opemotif RPM is also required, otherwise you won't pass Oracle's recommended operating system packages test. If it's not installed on your system, run
su - root
rpm -ivh openmotif-2.2.2-16.i386.rpm
I recommend using the latest RPM version.


Adjusting Network Settings
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.




Installing Cluster Ready Services (CRS)
General
Cluster Ready Services (CRS) contains cluster and database configuration information for RAC, and it provides many system management features. CRS accepts registration of Oracle instances to the cluster and it sends ping messages to other RAC nodes. If the heartbeat fails, CRS will use shared disk to distinguish between a node failure and a network failure.

Once CRS is running on all RAC nodes, OUI will automatically recognice all nodes on the cluster. This means that you can run OUI on one RAC node to install the Oracle software on all other RAC nodes.

Note that Automatic Storage Management (ASM) cannot be used for the "Oracle Cluster Registry (OCR)" file or for the "CRS Voting Disk" file. These files must be accessible before any Oracle instances are started. And for ASM to become available, the ASM instance needs to run first.

In the following example I will use OCFS for the "Oracle Cluster Registry (OCR)" file and for the "CRS Voting disk" file. The Oracle Cluster Registry file has a size of about 100 MB, and the CRS Voting Disk file has a size of about 20 MB. Tese files must reside on OCFS or on a shared raw device, or on any other clustered filesystem.


Automating Authentication for oracle ssh Logins
Make sure that the oracle user can ssh to all RAC nodes without ssh asking for a passphrase. This is very important because otherwise OUI won't be able to install the Oracle software on other RAC nodes. The following example shows how ssh-agent can do the authentication for you when the oracle account logs in to other RAC nodes using ssh.

Open a new terminal for the RAC node where you will execute runInstaller and use this terminal to login from your desktop using the following command:
$ ssh -X oracle@rac?pub
The "X11 forward" feature (-X option) of ssh will relink X to your local desktop. For more information, see Installing Oracle10g on a Remote Linux Server.

Now configure ssh-agent to handle the authentication for the oracle account:
oracle$ ssh-agent $SHELL
oracle$ ssh-add
Enter passphrase for /home/oracle/.ssh/id_dsa: Enter your passphrase
Identity added: /home/oracle/.ssh/id_dsa (/home/oracle/.ssh/id_dsa)
oracle$


Now make sure the oracle user can ssh into each RAC node. It is very important that NO text is displayed and that you are not asked for a passphrase. Only the server name of the remote RAC node should be displayed:
oracle$ ssh rac1pub hostname
rac1pub
oracle$ ssh rac1prv hostname
rac1pub
oracle$ ssh rac2pub hostname
rac2pub
oracle$ ssh rac2prv hostname
rac2pub
oracle$ ssh rac3pub hostname
rac3pub
oracle$ ssh rac3prv hostname
rac3pub


NOTE: Keep this terminal open since this is the terminal that will be used for running runInstaller!


Checking OCFS and Oracle Environment Variables
Checking OCFSs

Make sure the OCFS filesystem(s) are mounted on all RAC nodes:
oracle$ ssh rac1pub df |grep oradata
/dev/sda1 51205216 33888 51171328 1% /u02/oradata/orcl
oracle$ ssh rac2pub df |grep oradata
/dev/sda1 51205216 33888 51171328 1% /u02/oradata/orcl
oracle$ ssh rac3pub df |grep oradata
/dev/sda1 51205216 33888 51171328 1% /u02/oradata/orcl


Checking Oracle Environment Variables

Run the following command on all RAC nodes:
su - oracle
$ set | grep ORA
ORACLE_BASE=/u01/app/oracle
ORACLE_SID=orcl1
$
It is important that $ORACLE_SID is different on each RAC node!
It is also recommended that $ORACLE_HOME is not set but that OUI selects the home directory.


Installing Oracle 10g Cluster Ready Services (CRS) R1 (10.1.0.2)
In order to install the Cluster Ready Services (CRS) R1 (10.1.0.2) on all RAC nodes, OUI has to be launched on only one RAC node. In my example I will run OUI always on rac1pub.

To install CRS, insert the "Cluster Ready Services (CRS) R1 (10.1.0.2)" CD (downloadedd image name: "ship.crs.cpio.gz"), and mount it on e.g. rac1pub:
su - root
mount /mnt/cdrom


Use the oracle terminal that you prepared for ssh at Automating Authentication for oracle ssh Logins and execute runInstaller:
oracle$ /mnt/cdrom/runInstaller

- Welcome Screen: Click Next
- Inventory directory and credentials:
Click Next
- Unix Group Name: Use "oinstall".
- Root Script Window: Open another window, login as root, and run /tmp/orainstRoot.sh
on the node where you launched runInstaller.
After you've run the script, click Continue.
- File Locations: I used the recommended default values:
Destination Name: OraCr10g_home1
Destination Path: /u01/app/oracle/product/10.1.0/crs_1
Click Next
- Language Selection: Click Next
- Cluster Configuration:
Cluster Name: crs
Cluster Nodes: Public Node Name: rac1pub Private Node Name: rac1prv
Public Node Name: rac2pub Private Node Name: rac2prv
Public Node Name: rac3pub Private Node Name: rac3prv
Click Next
- Private Interconnect Enforcement:
Interface Name: eth0 Subnet: 192.168.1.0 Interface Type: Public
Interface Name: eth1 Subnet: 192.168.2.0 Interface Type: Private
Click Next
- Oracle Cluster Registry:
OCR Location: /u02/oradata/orcl/OCRFile
Click Next
- Voting Disk: Voting disk file name: /u02/oradata/orcl/CSSFile
Click Next
- Root Script Window:
Open another window, login as root, and execute
/u01/app/oracle/oraInventory/orainstRoot.sh on ALL RAC Nodes!

NOTE: For any reason Oracle does not create the log directory
"/u01/app/oracle/product/10.1.0/crs_1/log". If there are problems with
CRS, it will create log files in this directory, but only if it exists.
Therefore make sure to create this directory as oracle:
oracle$ mkdir /u01/app/oracle/product/10.1.0/crs_1/log

After you've run the script, click Continue.
- Setup Privileges Script Window:
Open another window, login as root, and execute
/u01/app/oracle/product/10.1.0/crs_1/root.sh on ALL RAC Nodes one by one!
Note that his can take a while. On the last RAC node, the output of the
script was as follows:
...
CSS is active on these nodes.
rac1pub
rac2pub
rac3pub
CSS is active on all nodes.
Oracle CRS stack installed and running under init(1M)
Click OK
- Summary: Click Install
- When installation is completed, click Exit.


One way to verify the CRS installation is to display all the nodes where CRS was installed:
oracle$ /u01/app/oracle/product/10.1.0/crs_1/bin/olsnodes -n
rac1pub 1
rac2pub 2
rac3pub 3




Installing Oracle Database 10g Software with Real Application Clusters (RAC)
General
The following procedure shows the installation of the software for Oracle Database 10g Software R1 (10.1.0.2) with Real Application Clusters (RAC).

Note that Oracle Database 10g R1 (10.1) OUI will not be able to discover disks that are marked as Linux ASMLib. Therefore it is recommended to complete the software installation and then to use dbca to create the database, see http://otn.oracle.com/tech/linux/asmlib/install.html#10gr1 for more information.


Automating Authentication for oracle ssh Logins
Before you install the Oracle Database 10g Software with Real Application Clusters (RAC) R1 (10.1.0.2), it is important that you followed the steps as outlined in Automating Authentication for oracle ssh Logins.


Checking Oracle Environment Variables
Run the following command on all RAC nodes:
su - oracle
$ set | grep ORA
ORACLE_BASE=/u01/app/oracle
ORACLE_SID=orcl1
$
It is important that $ORACLE_SID is different on each RAC node!
It is also recommended that $ORACLE_HOME is not set but that OUI selects the home directory.


Installing Oracle Database 10g Software R1 (10.1.0.2) with Real Application Clusters (RAC)
In order to install the Oracle Database 10g R1 (10.1.0.2) Software with Real Application Clusters (RAC) on all RAC nodes, OUI has to be launched on only one RAC node. In my example I will run OUI on rac1pub.

To install the RAC Database software, insert the Oracle Database 10g R1 (10.1.0.2) CD (downloaded image name: "ship.db.cpio.gz"), and mount it on e.g. rac1pub:
su - root
mount /mnt/cdrom


Use the oracle terminal that you prepared for ssh at Automating Authentication for oracle ssh Logins, and execute runInstaller:
oracle$ /mnt/cdrom/runInstaller

- Welcome Screen: Click Next
- File Locations: I used the default values:
Destination Name: raDb10g_home1
Destination Path: /u01/app/oracle/product/10.1.0/db_1
Click Next.
- Hardware Cluster Installation Mode:
Select "Cluster Installation"
Click "Select All" to select all servers: rac1pub, rac2pub, rac3pub
Click Next

NOTE: If it stops here and the status of a RAC node is "Node not reachable",
then perform the following checks:
- Check if the node where you launched OUI is able to do ssh without a
passphrase to the RAC node where the status is set to "Node not reachable".
- Check if the CRS is running this RAC node.
- Installation Type:
I selected "Enterprise Edition".
Click Next.
- Product-specific Prerequisite Checks:
Make sure that the status of each Check is set to "Succeeded".
Click Next
- Database Configuration:
I selected "Do not create a starter database" since we have to create the
database with dbca. Oracle Database 10g R1 (10.1) OUI will not be able to
discover disks that are marked as Linux ASMLib. For more information, see
http://otn.oracle.com/tech/linux/asmlib/install.html#10gr1
Click Next
- Summary: Click Install
- Setup Privileges Window:
Open another window, login as root, and execute
/u01/app/oracle/product/10.1.0/db_1/root.sh on ALL RAC Nodes one by one!
NOTE: Make also sure that X is relinked to your local desktop since this
script will launch the "VIP Configuration Assistant" tool which is a
GUI based utility!

VIP Configuration Assistant Tool:
(This Assistant tool will come up only once when root.sh is executed the
first time in your RAC cluster)
- Welcome Click Next
- Network Interfaces: I selected both interfaces, eth0 and eth1.
Click Next
- Virtual IPs for cluster nodes:
(for the alias names and IP address, see Setting Up the /etc/hosts File)
Node Name: rac1pub
IP Alias Name: rac1vip
IP address: 192.168.1.51
Subnet Mask: 255.255.255.0

Node Name: rac2pub
IP Alias Name: rac2vip
IP address: 192.168.1.52
Subnet Mask: 255.255.255.0

Node Name: rac3pub
IP Alias Name: rac3vip
IP address: 192.168.1.53
Subnet Mask: 255.255.255.0
Click Next
- Summary: Click Finish
- Configuration Assistant Progress Dialog:
Click OK after configuration is complete.
- Configuration Results:
Click Exit

Click OK to close the Setup Privilege Window.

- End of Installation:
Click Exit


If OUI terminates abnormally (happend to me several times), or if anything else goes wrong, remove the following files/directories and start over again:
su - oracle
rm -rf /u01/app/oracle/product/10.1.0/db_1




Installing Oracle Database 10g with Real Application Cluster (RAC)
General
The following steps show how to use dbca to create the database and its instances. Oracle recommends to use dbca to create the RAC database since the preconfigured databases are optimized for ASM, server parameter file, and automatic undo management. dbca also makes it much more easier to create new ASM disk groups etc.


Automating Authentication for oracle ssh Logins
Before you install a RAC database, it is important that you followed the steps as outlined in Automating Authentication for oracle ssh Logins.


Setting Oracle Environment Variables
Since the Oracle RAC software is already installed, $ORACLE_HOME can now be set to the home directory that was choosen by OUI.

The following steps should now be performed on all RAC nodes! It is very important that these environment variables are set permanently for oracle on all RAC nodes!

To make sure $ORACLE and $PATH are set automatically each time oracle logs in, add these environment variables to the ~oracle/.bash_profile file which is the user startup file for the Bash shell on Red Hat Linux. To do this you could simply copy/paste the following commands to make these settings permanent for your oracle's Bash shell (the path might differ on your system!):
su - oracle
cat >> ~oracle/.bash_profile << EOF
export ORACLE_HOME=$ORACLE_BASE/product/10.1.0/db_1
export PATH=$PATH:$ORACLE_HOME/bin
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
EOF



Installing Oracle Database 10g with Real Application Cluster (RAC)
To install the RAC database and the instances on all RAC nodes, OUI has to be launched on only one RAC node. In my example I will run OUI on rac1pub.

Use the oracle terminal that you prepared for ssh at Automating Authentication for oracle ssh Logins, and execute dbca. But before you execute dbca, make sure that $ORACLE_HOME and $PATH are set:
oracle$ . ~oracle/.bash_profile
oracle$ dbca

- Welcome Screen: Select "Oracle Real Application Clusters database"
Click Next
- Operations: Select "Create Database"
Click Next
- Node Selection: Click "Select All". Make sure all your RAC nodes show up and are selected!
If dbca hangs here, then you probably didn't follow the steps as outlined at
Automating Authentication for oracle ssh Logins
Click Next
- Database Templates: I selected "General Purpose".
Click Next
- Database Identification:
Global Database Name: orcl
SID Prefix: orcl
Click Next
- Management Option: I selected "Use Database Control for Database Management".
Click Next
- Database Credentials:
I selected "Use the Same Password for All Accounts". Enter the password and
make sure the password does not start with a digit number.
Click Next
- Storage Options: I selected "Automatic Storage Management (ASM)", see
Installing and Configuring Automatic Storage Management (ASM) and Disks
Click Next
- Create ASM Instance:
Enter the SYS password for the ASM instance.
I selected the default parameter file (IFILE):
"{ORACLE_BASE}/admin/+ASM/pfile/init.ora"
Click Next

At this point DBCA will create and start the ASM instance on all RAC nodes.
Click OK to create and start the ASM instance.

An error will come up that oratab can't be copied to /tmp. I ignored this error.

If you get "ORACLE server session terminated by fatal error", then you probably
didn't follow the steps at Setting Up the /etc/hosts File

- ASM Disk Groups: - Click "Create New"

Create Disk Group Window:
- Click "Change Disk Discovery Path".
- Enter "ORCL:VOL*" for Disk Discovery Path.
The discovery string for finding ASM disks must be prefixed with "ORCL:",
and in my example I called the ASM disks VOL1, VOL2, VOL3.
- I entered an arbitraty Disk Group Name: ORCL_DATA1
- I checked the candidate: "ORCL:VOL1" and "ORCL:VOL2" which have
together about 60 GB space in my configuration.
- Click OK.

- Check the new created disk group "ORCL_DATA1".
- Click Next
- Database File Locations:
Select "Use Oracle-Managed Files"
Database Area: +ORCL_DATA1
Click Next
- Recovery Configuration:
Using recovery options like Flash Recovery Area is out of scope for this article.
So I did not select any recovery options.
Click Next
- Database Content: I did not select Sample Schemas or Custom Scripts.
Click Next
- Database Services: Click "Add" and enter a Service Name: I entered "orcltest".
I selected TAF Policy "Basic".
Click Next
- Initialization Parameters:
Change settings as needed.
Click Next
- Database Storage: Change settings as needed.
Click Next
- Creation Options: Check "Create Database"
Click Finish
- Summary: Click OK

Now the database is being created.

The following error message came up:
"Unable to copy the file "rac2pub:/etc/oratab" to "/tmp/oratab.rac2pub".
I clicked "Ignore". I have to investigate this.



Your RAC cluster should now be up and running. To verify, try to connect to each instance from one of the RAC nodes:
$ sqlplus system@orcl1
$ sqlplus system@orcl2
$ sqlplus system@orcl3


After you connected to an instance, enter the following SQL command to verify your connection:
SQL> select instance_name from v$instance;




Post-Installation Steps


Transparent Application Failover (TAF)
Introduction

Processes external to the Oracle 10g 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.

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:
ORCLTEST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac3vip)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl)
(FAILOVER_MODE =
(TYPE = SELECT)
(METHOD = BASIC)
(RETRIES = 180)
(DELAY = 5)
)
)
)


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 (TAF)

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

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 rac1pub
SELECT BASIC NO

SQL>


The above SQL statement shows that I'm connected to "rac1pub" for instance "orcl1".
In this case, execute shutdown abort on "rac1pub" for instance "orcl1":
SQL> shutdown abort
ORACLE instance shut down.
SQL>



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 rac2pub
SELECT BASIC YES

SQL>


The SQL statement shows that the sessions has failed over to instance "orcl2". Note that this can take a few seconds.



Checking Automatic Storage Management (ASM)
Here are a couple SQL statements to verify ASM.

Run the following command to see which data files are in which disk group:
SQL> select name from v$datafile
2 union
3 select name from v$controlfile
4 union
5 select member from v$logfile;

NAME
--------------------------------------------------------------------------------
+ORCL_DATA1/orcl/controlfile/current.260.3
+ORCL_DATA1/orcl/datafile/sysaux.257.1
+ORCL_DATA1/orcl/datafile/system.256.1
+ORCL_DATA1/orcl/datafile/undotbs1.258.1
+ORCL_DATA1/orcl/datafile/undotbs2.264.1
+ORCL_DATA1/orcl/datafile/users.259.1
+ORCL_DATA1/orcl/onlinelog/group_1.261.1
+ORCL_DATA1/orcl/onlinelog/group_2.262.1
+ORCL_DATA1/orcl/onlinelog/group_3.265.1
+ORCL_DATA1/orcl/onlinelog/group_4.266.1

10 rows selected.

SQL>


Run the following command to see which ASM disk(s) belong to the disk group 'ORCL_DATA1':
(ORCL_DATA1 was specified in Installing Oracle Database 10g with Real Application Cluster)
SQL> select path from v$asm_disk where group_number in
2 (select group_number from v$asm_diskgroup where name = 'ORCL_DATA1');

PATH
--------------------------------------------------------------------------------
ORCL:VOL1
ORCL:VOL2

SQL>



Oracle 10g RAC Issues, Problems and Errors
This section describes other issues, problems and errors pertaining to installing Oracle 10g with RAC which has not been covered so far.


Gtk-WARNING **: libgdk_pixbuf.so.2: cannot open shared object file: No such file or directory

This error can come up when you run ocfstool. To fix this error, install the gdk-pixbuf RPM:
rpm -ivh gdk-pixbuf-0.18.0-8.1.i386.rpm


/u01/app/oracle/product/10.1.0/crs_1/bin/crs_stat.bin: error while loading shared libraries: libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory
/u01/app/oracle/product/10.1.0/crs_1/bin/crs_stat.bin: error while loading shared libraries: libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory
PRKR-1061 : Failed to run remote command to get node configuration for node rac1pup
PRKR-1061 : Failed to run remote command to get node configuration for node rac1pup


This error can come up when you run root.sh. To fix this error, install the compat-libstdc++ RPM and rerun root.sh:
rpm -ivh compat-libstdc++-7.3-2.96.122.i386.rpm


mount: fs type ocfs not supported by kernel

The OCFS kernel module was not loaded. See Configuring and Loading OCFS for more information.


ORA-00603: ORACLE server session terminated by fatal error
or
SQL> startup nomount
ORA-29702: error occurred in Cluster Group Service operation


If the trace file looks like this:
/u01/app/oracle/product/10.1.0/db_1/rdbms/log/orcl1_ora_7424.trc
...
kgefec: fatal error 0
*** 2004-03-13 20:50:28.201
ksedmp: internal or fatal error
ORA-00603: ORACLE server session terminated by fatal error
ORA-27504: IPC error creating OSD context
ORA-27300: OS system dependent operation:gethostbyname failed with status: 0
ORA-27301: OS failure message: Error 0
ORA-27302: failure occurred at: sskgxpmyip4
Current SQL information unavailable - no session.
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+493 call ksedst()+0 0 ? 0 ? 0 ? 1 ? 0 ? 0 ?
ksfdmp()+14 call ksedmp()+0 3 ? BFFF783C ? A483593 ?
BF305C0 ? 3 ? BFFF8310 ?


Make sure that the name of the RAC node is not listed for the loopback address in the /etc/hosts file similar to this example:
127.0.0.1 rac1pub localhost.localdomain localhost
The entry should rather look like this:
127.0.0.1 localhost.localdomain localhost

Using Automatic Storage Management

Using Automatic Storage Management
This chapter briefly discusses some of the concepts behind Automatic Storage Management and describes how to use it. It contains the following topics:

What Is Automatic Storage Management?

Administering an ASM Instance

Configuring the Components of Automatic Storage Management

Using Automatic Storage Management in the Database

Viewing Information About Automatic Storage Management

What Is Automatic Storage Management?
Automatic Storage Management (ASM) simplifies database administration. It eliminates the need for you, as a DBA, to directly manage potentially thousands of Oracle database files. It does this by enabling you to create disk groups, which are comprised of disks and the files that reside on them. You only need to manage a small number of disk groups.

In the SQL statements that you use for creating database structures such as tablespaces, redo log and archive log files, and control files, you specify file location in terms of disk groups. Automatic Storage Management then creates and manages the associated underlying files for you.

Automatic Storage Management extends the power of Oracle-managed files. With Oracle-managed files, files are created and managed automatically for you, but with Automatic Storage Management you get the additional benefits of features such as mirroring and striping.

Automatic Storage Management does not eliminate any existing database functionality. Existing databases are able to operate as they always have. Existing databases using file systems or with storage on raw devices can operate as they always have. New files can be created as ASM files while old ones are administered in the old way. Databases can have a mixture of ASM files, Oracle-managed files, and manually managed files all at the same time.

To create a database that uses storage managed by Automatic Storage Management, you must first start an ASM instance. However, an ASM instance does not require that a database instance is running

Automatic Storage Management is integrated into the database server; you do not need to install it as a separate product.


See Also:

Oracle Database Concepts for an overview of Automatic Storage Management


Overview of the Components of Automatic Storage Management
The primary component of Automatic Storage Management is the disk group. You configure Automatic Storage Management by creating disk groups, which, in your database instance, can then be specified as the default location for files created in the database. Oracle provides SQL statements that create and manage disk groups, their contents, and their metadata.

A disk group consists of a grouping of disks that are managed together as a unit. These disks are referred to as ASM disks. Files written on ASM disks are ASM files, whose names are automatically generated by Automatic Storage Management. You can specify user-friendly alias names for ASM files, but you must create a hierarchical directory structure for these alias names.

You can affect how Automatic Storage Management places files on disks by specifying failure groups. Failure groups define disks that share components, such that if one fails then other disks sharing the component might also fail. An example of what you might define as a failure group would be a set of SCSI disks sharing the same SCSI controller. Failure groups are used to determine which ASM disks to use for storing redundant data. For example, if two-way mirroring is specified for a file, then redundant copies of file extents must be stored in separate failure groups.

Templates are used to provide the attribute information about ASM files created in ASM disk groups. These templates simplify file creation by mapping complex file attribute specifications into a single name. For example, a template named ONLINELOG provides the file redundancy and striping attributes for all redo log files written to ASM disks. For each disk group, Automatic Storage Management provides a set of initial system templates, as shown in the table in "Managing Disk Group Templates", suitable for most needs, but you can modify the templates or create new ones to meet unique requirements.

Administering an ASM Instance

Note:

You can use Oracle Enterprise Manager (EM) or the Database Configuration Assistant (DBCA) for a GUI interface to Automatic Storage Management that replaces the use of SQL or SQL*Plus for configuring and altering disk groups and their metadata.
DBCA eases the configuring and creation of your database while EM provides an integrated approach for managing both your ASM instance and database instance.



The functionality of an ASM instance can be summarized as follows:

It manages groups of disks, called disk groups.

It protects the data within a disk group.

It provides near-optimal I/O balancing without any manual tuning.

It enables the user to manage database objects such as tablespaces without needing to specify and track filenames.

It supports large files.

This section discusses the administration of an ASM instance in terms of its startup and shutdown, and its behavior and interaction with the database instance. The major part of the administration of an ASM instance, once it is started, is the creation and maintenance of disk groups and their metadata. This is discussed in "Configuring the Components of Automatic Storage Management".

This section contains the following topics:

Installation of ASM

Authentication for Accessing an ASM Instance

Setting Initialization Parameters for an ASM Instance

Starting Up an ASM Instance

Shutting Down an ASM Instance

Disk Group Fixed Tables

Installation of ASM
Automatic Storage Management is always installed by the Oracle Universal Installer when you install your database software. The Database Configuration Assistant (DBCA) determines if an ASM instance already exists, and if not, then you are given the option of creating and configuring an ASM instance as part of database creation and configuration. If an ASM instance already exists, then it is used instead.

DBCA also configures your instance parameter file and password file.

Authentication for Accessing an ASM Instance
Automatic Storage Management security considerations derive from the fact that a particular ASM instance is tightly bound to one or more database instances operating on the same server. In effect, the ASM instance is a logical extension of these database instances. Both the ASM instance and the database instances must have equivalent operating system access rights (read/write) to the disk group member disks. For UNIX this is typically provided through shared UNIX group membership.

ASM instances do not have a data dictionary, so the only way to connect to one is as an administrator. This means you use operating system authentication and connect as SYSDBA or SYSOPER, or to connect remotely, use a password file.

Using operating system authentication, the authorization to connect with the SYSDBA privilege is granted through the use of an operating system group. On UNIX, this is typically the dba group. By default, members of the dba group are authorized to connect with the SYSDBA privilege on all instances on the node, including the ASM instance. Users who connect to the ASM instance with SYSDBA privilege have complete administrative access to all disk groups that are managed by that ASM instance.


See Also:

"Database Administrator Authentication" for information about OS and password file authentication as relating to connecting to a database instance. Administrators are similarly authenticated and connected for an ASM instance.


Setting Initialization Parameters for an ASM Instance
Some initialization parameters are specifically relevant to an ASM instance. Of those initialization parameters intended for a database instance, only a few are relevant to an ASM instance. You can set those parameters at database creation time using Database Configuration Assistant or later using Enterprise Manager. The remainder of this section describes setting the parameters manually by editing the initialization parameter file.

Initialization Parameters for ASM Instances
The following initialization parameters relate to an ASM instance. Parameters that start with ASM_ cannot be set in database instances.

Name Description
INSTANCE_TYPE Must be set to INSTANCE_TYPE = ASM.
Note: This is the only required parameter. All other parameters take suitable defaults for most environments.

DB_UNIQUE_NAME Unique name for this group of ASM instances within the cluster or on a node.
Default: +ASM (Needs to be modified only if trying to run multiple ASM instances on the same node)

ASM_POWER_LIMIT The maximum power on an ASM instance for disk rebalancing.
Default: 1

See Also: "Tuning Rebalance Operations"

ASM_DISKSTRING Limits the set of disks that Automatic Storage Management considers for discovery.
Default: NULL (This default causes ASM to find all of the disks in a platform-specific location to which it has read/write access.)

See Also: "Improving Disk Discovery Time"

ASM_DISKGROUPS Lists the names of disk groups to be mounted by an ASM instance at startup, or when the ALTER DISKGROUP ALL MOUNT statement is used.
Default: NULL (If this parameter is not specified, then no disk groups are mounted.)

Note: This parameter is dynamic and if you are using a server parameter file (SPFILE), then you should rarely need to manually alter this value. Automatic Storage Management automatically adds a disk group to this parameter when a disk group is successfully mounted, and automatically removes a disk group that is specifically dismounted. However, when using a traditional text initialization parameter file, remember to edit the initialization parameter file to add the name of any disk group that you want automatically mounted at instance startup, and remove the name of any disk group that you no longer want automatically mounted.



Tuning Rebalance Operations
Oracle Database can perform one rebalance at a time on a given instance. The rebalance power is constrained by the value of the ASM_POWER_LIMIT initialization parameter. You can adjust this parameter dynamically. The higher the limit, the faster a rebalance operation may complete. Lower values cause rebalancing to take longer, but consume fewer processing and I/O resources. If the POWER clause is not specified, or when rebalance is implicitly invoked by adding or dropping a disk, the power defaults to the ASM_POWER_LIMIT.

The V$ASM_OPERATION view provides information that can be used for adjusting ASM_POWER_LIMIT and the resulting power of rebalance operations. If the DESIRED_POWER column value is less than the ACTUAL_POWER column value for a given rebalance operation, then ASM_POWER_LIMIT is impacting the rebalance.

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

If a rebalance is in progress because a failed disk is being dropped, increasing the power of the rebalance shortens the window during which redundant copies on the failed disk are being reconstructed on other disks. Lowering ASM_POWER_LIMIT reduces the amount of CPU and I/O bandwidth that Automatic Storage Management consumes for a rebalance. This leaves these resources available for other applications, such as the database.

The default value errors on the side of minimizing disruption to other applications. The appropriate value is dependent upon your hardware configuration as well as performance and availability requirements.

Improving Disk Discovery Time
The value for the ASM_DISKSTRING initialization parameter is an operating system dependent value used by Automatic Storage Management to limit the set of disks considered for discovery. 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 is sufficient. Using a more restrictive value may reduce the time required for Automatic Storage Management to perform discovery, and thus improve disk group mount time or the time for adding a disk to a disk group. It may be necessary to dynamically change the ASM_DISKSTRING before adding a disk so that the new disk will be discovered through this parameter.

If your site is using a third-party vendor ASMLIB, that vendor may have discovery string conventions that should be used for ASM_DISKSTRING.

Behavior of Database Initialization Parameters in an ASM Instance
If you specify a database instance initialization parameter in an ASM initialization parameter file, it can have one of three effects:

If the parameter is not valid in the ASM instance, it produces a ORA-15021 error.

Some database parameters can be specified and are valid in an ASM instance, for example those relating to dump destinations and some buffer cache parameters. In general, Oracle will select appropriate defaults for any database parameters that are relevant to the ASM instance.

If you specify any of the ASM specific parameters (names start with ASM_) in a database instance parameter file, you will receive an ORA-15021 error.

Starting Up an ASM Instance
ASM instances are started similarly to Oracle database instances with some minor differences. These are:

The initialization parameter file, which can be a server parameter file, must contain:

INSTANCE_TYPE = ASM

This parameter signals the Oracle executable that an ASM instance is starting and not a database instance.

Using a server parameter file is recommended because it eliminates the need to make manual changes to a text initialization parameter file.

For ASM instances, STARTUP tries to mount the disk groups specified by the initialization parameter ASM_DISKGROUPS and not the database.

Further, the SQL*Plus STARTUP command parameters are interpreted by Automatic Storage Management as follows:

STARTUP Parameter Description
FORCE Issues a SHUTDOWN ABORT to the ASM instance before restarting it
MOUNT Mounts the disk groups specified in the ASM_DISKGROUPS initialization parameter
NOMOUNT Starts up the ASM instance without mounting any disk groups
OPEN Invalid for an ASM instance


The following is a sample SQL*Plus session where an ASM instance is started:

% sqlplus /nolog
SQL> CONNECT / AS sysdba
Connected to an idle instance.
SQL> STARTUP
ASM instance started
Total System Global Area 147936196 bytes
Fixed Size 324548 bytes
Variable Size 96468992 bytes
Database Buffers 50331648 bytes
Redo Buffers 811008 bytes
ASM diskgroups mounted
ASM Instance Memory Requirements
ASM instances are smaller than database instances. A 64 MB SGA should be sufficient for all but the largest ASM installations.

Disk Discovery
When an ASM instance initializes, ASM is able to discover and look at the contents of all of the disks in the disk groups that are pointed to by the ASM_DISKSTRING initialization parameter. This saves you from having to specify a path for each of the disks in the disk group.

Disk group mounting requires that an ASM instance doing disk discovery be able to access all the disks within the disk group that any other ASM instance having previously mounted the disk group believes are members of that disk group. It is vital that any disk configuration errors be detected before a disk group is mounted.

Automatic Storage Management attempts to identify the following configuration errors:

A single disk with different mount points is presented to an ASM instance. This can be caused by multiple paths to a single disk. In this case, if the disk in question is part of a disk group, disk group mount fails. If the disk is being added to a disk group with ADD DISK or CREATE DISKGROUP, the command fails. To correct the error, restrict the disk string so that it does not include multiple paths to the same disk.

Multiple ASM disks, with the same ASM label, passed to separate ASM instances as the same disk. In this case, disk group mount fails.

Disks that were not intended to be ASM disks are passed to an ASM instance by the discovery function. ASM does not overwrite a disk if it recognizes the header as that of an Oracle object.

Disk Group Recovery
When an ASM instance fails, then all Oracle database instances on the same node as that ASM instance and that use a disk group managed by that ASM instance also fail. In a single ASM instance configuration, if the ASM instance fails while ASM metadata is open for update, then after the ASM instance reinitializes, it reads the disk group log and recovers all transient changes.

With multiple ASM instances sharing disk groups, if one ASM instance should fail, another ASM instance automatically recovers transient ASM metadata changes caused by the failed instance. The failure of an Oracle database instance is not significant here because only ASM instances update ASM metadata.

Shutting Down an ASM Instance
Using SQL*Plus, Automatic Storage Management shutdown is initiated by issuing the SHUTDOWN command. For example:

% sqlplus /nolog
SQL> CONNECT / AS sysdba
Connected.
SQL> SHUTDOWN NORMAL

The table that follows lists the SHUTDOWN modes and describes the behavior of the ASM instance in each mode.

SHUTDOWN Mode Action Taken By Automatic Storage Management
NORMAL ASM waits for the connected ASM instances (and other ASM SQL sessions) to exit before shutting down the instance.
IMMEDIATE ASM waits for any in-progress SQL to complete before shutting down the ASM instance, but does not wait for database instances to disconnect.
TRANSACTIONAL Same as IMMEDIATE.
ABORT Automatic Storage Management immediately shuts down.


Disk Group Fixed Tables
A number of fixed tables, visible from both the ASM and database instances are provided for administrative and debugging purposes. These views are discussed in "Viewing Information About Automatic Storage Management".

Configuring the Components of Automatic Storage Management
This section starts by presenting a brief overview of the components of Automatic Storage Management and discusses some considerations and guidelines that you should be aware of as you configure your ASM instance. Then, specific operations that you use to configure and maintain the ASM instance are discussed.

If you have a database instance running and are actively using Automatic Storage Management, you can keep the database open and running while you reconfigure disk groups.

The SQL statements introduced in this section are only available in an ASM instance. You must first start the ASM instance. This is discussed in "Administering an ASM Instance".

The following topics are contained in this section:

Considerations and Guidelines for Configuring an ASM Instance

Creating a Disk Group

Altering the Disk Membership of a Disk Group

Mounting and Dismounting Disk Groups

Managing Disk Group Templates

Managing Disk Group Directories

Managing Alias Names for ASM Filenames

Dropping Files and Associated Aliases from a Disk Group

Checking Internal Consistency of Disk Group Metadata

Dropping Disk Groups

Considerations and Guidelines for Configuring an ASM Instance
The following are some considerations and guidelines to be aware of as you configure Automatic Storage Management.

Determining the Number of Disk Groups
The following criteria can help you determine the number of disk groups that you 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 it would be better to form several disk groups accordingly.

For recovery reasons, you might feel more comfortable having separate disk groups for your database files and flash recovery area files. Using this approach, even with the loss of one disk group, the database would still be intact.

Storage Arrays and Automatic Storage Management
With Automatic Storage Management, the definition of the logical volumes of a storage array is critical to database performance. Automatic Storage Management cannot optimize database data placement when the storage array disks are subdivided or aggregated. Aggregating and subdividing the physical volumes of an array into logical volumes can hide the physical disk boundaries from Automatic Storage Management. Consequently, careful consideration of storage array configuration is required.

Consider Performance Characteristics when Grouping Disks
Automatic Storage Management eliminates the need for manual disk tuning. However, to ensure consistent performance, you should avoid placing dissimilar disks in the same disk group. 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.

Automatic Storage Management load balances file activity by uniformly distributing file extents across all disks in a disk group. For this technique to be effective it is important that the disks used in a disk group be of similar performance characteristics.

There may 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 in online.

Effects of Adding and Dropping Disks from a Disk Group
Automatic Storage Management automatically rebalances--distributes file data evenly across all the disks of a disk group--whenever disks are added or dropped. ASM allocates files in such a way that rebalancing is not required when the number of disks is static. A disk is not released from a disk group until data is moved off of the disk through rebalancing. Likewise, a newly added disk cannot support its share of the I/O workload until rebalancing completes. It is more efficient to add or drop multiple disks at the same time so that they are rebalanced as a single operation. This avoids unnecessary movement of data.

You can add or drop disks without shutting down the database. However, a performance impact on I/O activity may result.

Failure Groups and Mirroring
Mirroring of metadata and user data is achieved through failure groups. ASM requires at least two failure groups for normal redundancy disk groups and at least three failure groups for high redundancy disk groups. System reliability can be hampered if an insufficient number of failure groups are provided. Consequently, failure group configuration is very important to creating a highly reliable system.

Scalability
ASM imposes the following limits:

63 disk groups in a storage system

10,000 ASM disks in a storage system

4 petabyte maximum storage for each ASM disk

40 exabyte maximum storage for each storage system

1 million files for each disk group

2.4 terabyte maximum storage for each file

Creating a Disk Group
You use the CREATE DISKGROUP statement to create disk groups. This statement enables you to assign a name to the disk group and to specify the disks that are to be formatted as ASM disks belonging to the disk group. You specify the disks as one or more operating system dependent search strings that Automatic Storage Management then uses to find the disks.

You can specify the disks as belonging to specific failure groups, and you can specify the redundancy level for the disk group. If you do not specify a disk as belonging to a failure group, that disk comprises its own failure group. The redundancy level can be specified as NORMAL REDUNDANCY or HIGH REDUNDANCY, as defined by the disk group templates. You can also specify EXTERNAL REDUNDANCY for external redundancy disk groups, which do not have failure groups. You might do this if you want to use storage array protection features instead.

Automatic Storage Management programmatically determines the size of each disk. If for some reason this is not possible, or if you want to restrict the amount of space used on a disk, you are able to specify a SIZE clause for each disk. Automatic Storage Management creates operating system independent names for the disks in a disk group that you can use to reference the disks in other SQL statements. Optionally, you can provide your own name for a disk using the NAME clause.

The ASM instance ensures that any disk being included in a disk group is addressable and usable. This requires reading the first block of the disk to determine if it already belongs in a disk group. If not, a header is written. It is not possible for a disk to be a member of multiple disk groups.

However, you can force a disk that is already a member of another disk group to become a member of the disk group you are creating by specifying the FORCE clause. For example, a disk with an ASM header might have failed temporarily, so that its header could not be cleared when it was dropped from its disk group. Once the disk is repaired, it is no longer part of any disk group, but it still has an ASM header. The FORCE flag is required to use the disk in a new disk group. The original disk group must not be mounted, and the disk must have a disk group header, otherwise the operation fails. Note that if you do this, you may cause another disk group to become unusable. If you specify NOFORCE, which is the default, you receive an error if you attempt to include a disk that already belongs to another disk group.

The CREATE DISKGROUP statement mounts the disk group for the first time, and adds the disk group name to the ASM_DISKGROUPS initialization parameter if a server parameter file is being used. If a text initialization parameter file is being used and you want the disk group to be automatically mounted at instance startup, then you must remember to add the disk group name to the ASM_DISKGROUPS initialization parameter before the next time that you shut down and restart the ASM instance.


Creating a Disk Group: Example

The following examples assume that the ASM_DISKSTRING is set to '/devices/*'. Assume the following:

ASM disk discovery identifies the following disks in directory /devices.

/devices/diska1
/devices/diska2
/devices/diska3
/devices/diska4
/devices/diskb1
/devices/diskb2
/devices/diskb3
/devices/diskb4
The disks diska1 - diska4 are on a separate SCSI controller from disks diskb1 - diskb4.

The following SQL*Plus session illustrates starting an ASM instance and creating a disk group named dgroup1.

% SQLPLUS /NOLOG
SQL> CONNECT / AS SYSDBA
Connected to an idle instance.
SQL> STARTUP NOMOUNT
SQL> CREATE DISKGROUP dgroup1 NORMAL REDUNDANCY
2 FAILGROUP controller1 DISK
3 '/devices/diska1',
4 '/devices/diska2',
5 '/devices/diska3',
6 '/devices/diska4',
7 FAILGROUP controller2 DISK
8 '/devices/diskb1',
9 '/devices/diskb2',
10 '/devices/diskb3',
11 '/devices/diskb4';

In this example, dgroup1 is composed of eight disks that are defined as belonging to either failure group controller1 or controller2. Since NORMAL REDUNDANCY level is specified for the disk group, then Automatic Storage Management provides redundancy for all files created in dgroup1 according to the attributes specified in the disk group templates.

For example, in the system default template shown in the table in "Managing Disk Group Templates", normal redundancy for the online redo log files (ONLINELOG template) is two-way mirroring. This means that when one copy of a redo log file extent is written to a disk in failure group controller1, a mirrored copy of the file extent is written to a disk in failure group controller2. You can see that to support normal redundancy level, at least two failure groups must be defined.

Since no NAME clauses are provided for any of the disks being included in the disk group, the disks are assigned the names of dgroup1_0001, dgroup1_0002, ..., dgroup1_0008.

Altering the Disk Membership of a Disk Group
At a later time after the creation of a disk group, you can change its composition by adding more disks, resizing disks, or dropping disks. You use clauses of the ALTER DISKGROUP statement to perform these actions. You can perform multiple operations with one ALTER DISKGROUP statement.

Automatic Storage Management automatically rebalances file extents when the composition of a disk group changes. Because rebalancing can be a long running operation, the ALTER DISKGROUP statement does not wait until the operation is complete before returning. To monitor progress of these long running operations, query the V$ASM_OPERATION dynamic performance view.

Adding Disks to a Disk Group
The ADD clause of the ALTER DISKGROUP statement lets you add disks to a disk group, or to add a failure group to the disk group. The ALTER DISKGROUP clauses that you can use when adding disks to a disk group are similar to those that can be used when specifying the disks to be included when initially creating a disk group. This is discussed in "Creating a Disk Group".

The new disks will gradually start to carry their share of the workload as rebalancing progresses.

Automatic Storage Management behavior when adding disks to a disk group is best illustrated through examples.


Adding Disks to a Disk Group: Example 1

The following statement adds disks to dgroup1:

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

Since no FAILGROUP clauses are included in the ALTER DISKGROUP statement, each disk is assigned to its own failgroup. The NAME clauses assign names to the disks, otherwise they would have been assigned system generated names.


Adding Disks to a Disk Group: Example 2

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

Assume that disk discovery now 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 dgroup1
/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

Issuing the following statement adds disks /devices/diska5 - /devices/diska8 to dgroup1. It ignores /devices/diska1 - /devices/diska4 because they already belong to dgroup1, but does not fail because the other disks that match the search string are not already members of any other disk group.

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

The following statement will fail, since the /devices/diska2 search string only matches a disk that already belongs to dgroup1:

ALTER DISKGROUP dgroup1 ADD DISK
'/devices/diska2',
'/devices/diskd4';

The following statement to add disks to dgroup1 will fail because the search string matches a disk that is contained in another disk group. Specifically, /devices/diskc1 belongs to disk group dgroup2.

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

The following statement succeeds in adding /devices/diskc4 and /devices/diskd1 - /devices/diskd4 to disk group dgroup1. It does not matter that /devices/diskd4 is included in both search strings (or that /devices/diska4 and /devices/diskb4 are already members of dgroup1).

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

The following use of the FORCE clause allows /devices/diskc3 to be added to dgroup2, even though it is a current member of dgroup3.

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

For this statement to succeed, dgroup3 cannot be mounted.

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. The header on the dropped disk is cleared. If you specify the FORCE clause for the drop operation, the disk is dropped even if Automatic Storage Management cannot read or write to the disk. You cannot use the FORCE flag when dropping a disk from an external redundancy disk group.


Dropping Disks from Disk Groups: Example 1

This example drops diska5 (the operating system independent name assigned to /devices/c0t4d0s2 in "Adding Disks to a Disk Group: Example 1") from disk group dgroup1.

ALTER DISKGROUP dgroup1 DROP DISK diska5;

Dropping Disks from Disk Groups: Example 2

This example also shows dropping diska5 from disk group dgroup1, but it 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 Automatic Storage Management uses the size of the disk as returned by the operating system. This could be a means of recovering disk space when you had previously restricted the size of the disk by specifying a size smaller than disk capacity.

The new size is written to the ASM disk header record 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.


Resizing Disks in Disk Groups: Example

The following example resizes all of the disks in failgroup 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.


Undropping Disks in Disk Groups: Example

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

ALTER DISKGROUP dgroup1 UNDROP DISKS;
Manually Rebalancing a Disk Group
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, since Automatic Storage Management automatically rebalances disk groups when their composition 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 parallelization, and thus the speed of the rebalance operation. It can be set to a value from 0 to 11, where a value of 0 stops rebalancing and a value of 11 (the default) causes rebalancing to occur as fast as possible. The power level of an ongoing rebalance operation can be changed by entering the rebalance statement with a new level. If you specify a power level of 0, rebalancing is halted until the statement is either implicitly or explicitly reinvoked.

The dynamic initialization parameter ASM_POWER_LIMIT specifies a limit on the degree of parallelization for rebalance operations. Even if you specify a higher value in the POWER clause, the degree of parallelization will not exceed the value specified by the ASM_POWER_LIMIT parameter.

The ALTER DISK GROUP ... REBALANCE statement uses the resources of the single node upon which it is started. ASM can perform one rebalance at a time on a given instance. The rebalance power is constrained by the value of the ASM_POWER_LIMIT initialization parameter.

You can query the V$ASM_OPERATION view for help adjusting ASM_POWER_LIMIT and the resulting power of rebalance operations. If the DESIRED_POWER column value is less than the ACTUAL_POWER column value for a given rebalance operation, then ASM_POWER_LIMIT is impacting the rebalance. The EST_MINUTES column indicates the amount of time remaining for the operation to complete. You can see the effect of changing the power of rebalance by observing the change in the time estimate.

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


See Also:

"Tuning Rebalance Operations"



Manually Rebalancing a Disk Group: Example

The following example manually rebalances the disk group dgroup2:

ALTER DISKGROUP dgroup2 REBALANCE POWER 5;
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 Automatic Storage Management. The disk groups are dismounted at ASM instance shutdown. Automatic Storage Management also automatically mounts a disk group when you initially create it, and dismounts a disk group if you drop it.

There may 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.


Dismounting Disk Groups: Example

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

ALTER DISKGROUP ALL DISMOUNT;

Mounting Disk Groups: Example

The following statement mounts disk group dgroup1:

ALTER DISKGROUP dgroup1 MOUNT;
Managing Disk Group Templates
A template is a named collection of attributes that are applied to files created within a disk group. Oracle provides a set of initial system default templates that Automatic Storage Management associates with a disk group when it is created. The table that follows lists the system default templates and the attributes they apply to the various file types that Automatic Storage Management supports.

You can add new templates to a disk group, change existing ones, or drop templates using clauses of the ALTER DISKGROUP statement. The V$ASM_TEMPLATE view lists all of the templates known to the ASM instance.

Table 12-1 Automatic Storage Management System Default File Group Templates

Template Name File Type External Redundancy Normal Redundancy High Redundancy Striped
CONTROL Control files Unprotected 2-way mirror 3-way mirror Fine
DATAFILE Datafiles and copies Unprotected 2-way mirror 3-way mirror Coarse
ONLINELOG Online logs Unprotected 2-way mirror 3-way mirror Fine
ARCHIVELOG Archive logs Unprotected 2-way mirror 3-way mirror Coarse
TEMPFILE Tempfiles Unprotected 2-way mirror 3-way mirror Coarse
BACKUPSET Datafile backup pieces, datafile incremental backup pieces, and archive log backup pieces Unprotected 2-way mirror 3-way mirror Coarse
PARAMETERFILE SPFILEs Unprotected 2-way mirror 3-way mirror Coarse
DATAGUARDCONFIG Disaster recovery configurations (used in standby databases) Unprotected 2-way mirror 3-way mirror Coarse
FLASHBACK Flashback logs Unprotected 2-way mirror 3-way mirror Fine
CHANGETRACKING Block change tracking data (used during incremental backups) Unprotected 2-way mirror 3-way mirror Coarse
DUMPSET Data Pump dumpset Unprotected 2-way mirror 3-way mirror Coarse
XTRANSPORT Cross-platform converted datafile Unprotected 2-way mirror 3-way mirror Coarse
AUTOBACKUP Automatic backup files Unprotected 2-way mirror 3-way mirror Coarse


Adding Templates to a Disk Group
To add a new template for a disk group use the ADD TEMPLATE clause of the ALTER DISKGROUP statement. You specify the name of the template, its redundancy attributes, and its striping attribute.


Adding Templates to a Disk Group: Example 1

The following statement creates a new template named reliable:

ALTER DISKGROUP dgroup2 ADD TEMPLATE reliable ATTRIBUTES (MIRROR FINE);

This statement creates a template that applies the following attributes to files:

Template Name External Redundancy Normal Redundancy High Redundancy Striping
RELIABLE You cannot specify RELIABLE for an external redundancy group 2-way mirror 3-way mirror Every 128 KB



Adding Templates to a Disk Group: Example 2

This statement creates a new template named unreliable that specifies files are to be unprotected (no mirroring). Oracle discourages the use of unprotected files; this example is presented only to further illustrate how the attributes for templates are set.

ALTER DISKGROUP dgroup2 ADD TEMPLATE unreliable
ATTRIBUTES (UNPROTECTED);

This statement creates a template that applies the following attributes to files:

Template Name External Redundancy Normal Redundancy High Redundancy Striping
UNRELIABLE Unprotected Unprotected You cannot specify UNRELIABLE for a high redundancy group. No


Modifying a Disk Group Template
The ALTER TEMPLATE clause of the ALTER DISKGROUP statement enables you to modify the attribute specifications of an existing system default or user-defined disk group template. Only specified template properties are changed. Unspecified properties retain their current value.

When you modify an existing template, only new files created by the template will reflect the attribute changes. Existing files maintain their attributes.


Modifying a Disk Group Template: Example

The following example changes the striping attribute specification of the reliable template for disk group dgroup2.

ALTER DISKGROUP dgroup2 ALTER TEMPLATE reliable
ATTRIBUTES (COARSE);
Dropping Templates from a Disk Group
Use the DROP TEMPLATE clause of the ALTER DISKGROUP statement to drop one or more templates from a disk group. You can only drop templates that are user-defined; you cannot drop system default templates.


Dropping Templates from a Disk Group: Example

This example drops the previously created unprotected template for dgroup2:

ALTER DISKGROUP dgroup2 DROP TEMPLATE unreliable;
Managing Disk Group Directories
Every ASM disk group contains a hierarchical directory structure consisting of the fully qualified names of the files in the disk group, along with alias filenames. A fully qualified filename, also called a system alias, is always generated automatically by Automatic Storage Management when a file is created.

You can create an additional (more user-friendly) alias for each ASM filename during file creation. You can also create an alias for an existing filename using clauses of the ALTER DISKGROUP statement as described in "Managing Alias Names for ASM Filenames". But you must first create a directory structure to support whatever alias file naming convention you choose to use.

This section describes how to use the ALTER DISKGROUP statement to create a directory structure for alias filenames. It also describes how you can rename a directory or drop a directory.


See Also:

"About ASM Filenames" for a discussion of ASM filenames and how they are formed


Creating a New Directory
Use the ADD DIRECTORY clause of the ALTER DISKGROUP statement to create a hierarchical directory structure for alias names for ASM files. Use the slash character (/) to separate components of the directory path. The directory path must start with the disk group name, preceded by a plus sign (+), followed by any subdirectory names of your choice.

The parent directory must exist before attempting to create a subdirectory or alias in that directory.


Creating a New Directory: Example 1

The following statement creates a hierarchical directory for disk group dgroup1, which can contain, for example, the alias name +dgroup1/mydir/control_file1:

ALTER DISKGROUP dgroup1 ADD DIRECTORY '+dgroup1/mydir';

Creating a New Directory: Example 2

Assume no subdirectory exists under the directory +dgoup1/mydir, then the following statement will fail:

ALTER DISKGROUP dgroup1
ADD DIRECTORY 'dgroup1/mydir/does_not_exist/second_dir;
Renaming a Directory
The RENAME DIRECTORY clause of the ALTER DISKGROUP statement enables you to rename a directory. System created directories (those containing system alias names) cannot be renamed.


Renaming a Directory: Example

The following statement renames a directory:

ALTER DISKGROUP dgroup1 RENAME DIRECTORY '+dgroup1/mydir'
TO '+dgroup1/yourdir';
Dropping a Directory
You can delete a directory using the DROP DIRECTORY clause of the ALTER DISKGROUP statement. You cannot drop a system created directory. You cannot drop a directory containing alias names unless you also specify the FORCE clause.


Dropping a Directory: Example

This statement deletes a directory along with its contents:

ALTER DISKGROUP dgroup1 DROP DIRECTORY '+dgroup1/yourdir' FORCE;
Managing Alias Names for ASM Filenames
After you have created the hierarchical directory structure for alias names, you can create alias names in the disk group. Alias names are intended to provide a more user-friendly means of referring to ASM files, rather than using the fully qualified names (system aliases) that Automatic Storage Management always generates when it creates a file.

As mentioned earlier, these alias names can be created when the file is created in the database, or by adding an alias or renaming existing alias names using the ADD ALIAS or RENAME ALIAS clauses of the ALTER DISKGROUP statement. You delete an alias using the DROP ALIAS clause. You cannot delete or rename a system alias.

The V$ASM_ALIAS view contains a row for every alias name known to the ASM instance. It contains a column, SYSTEM_CREATED, that specifies if the alias is system generated

Adding an Alias Name for an ASM Filename
Use the ADD ALIAS clause of the ALTER DISKGROUP statement to create an alias name for an ASM filename. The alias name must consist of the full directory path and the alias itself.


Adding an Alias Name for an ASM Filename: Example 1

The following statement adds a new alias name for a system generated file name:

ALTER DISKGROUP dgroup1 ADD ALIAS '+dgroup1/mydir/second.dbf'
FOR '+dgroupA/sample/datafile/mytable.342.3';

Adding an Alias Name for as ASM Filename: Example 2

This statement illustrates another means of specifying the ASM filename for which the alias is to be created. It uses the numeric form of the ASM filename, which is an abbreviated and derived form of the system generated filename.

ALTER DISKGROUP dgroup1 ADD ALIAS '+dgroup1/mydir/second.dbf'
FOR '+dgroupA.342.3';
Renaming an Alias Name for an ASM Filename
Use the RENAME ALIAS clause of the ALTER DISKGROUP statement to rename an alias for an ASM filename. The old and the new alias names must consist of the full directory paths of the alias names.


Renaming an Alias Name for an ASM Filename: Example

The following statement renames an alias:

ALTER DISKGROUP dgroup1 RENAME ALIAS '+dgroup1/mydir/datafile.dbf'
TO '+dgroupA/payroll/compensation.dbf';
Dropping an Alias Name for an ASM Filename
Use the DROP ALIAS clause of the ALTER DISKGROUP statement to drop an alias for an ASM filename. The alias name must consist of the full directory path and the alias itself. The underlying file to which the alias refers is unchanged.


Dropping an Alias Name for an ASM Filename: Example 1

The following statement deletes an alias:

ALTER DISKGROUP dgroup1 DELETE ALIAS '+dgroup1/payroll/compensation.dbf';

Dropping an Alias Name for an ASM Filename: Example 2

The following statement will fail because it attempts to delete a system alias. This is not allowed:

ALTER DISKGROUP dgroup1
DELETE ALIAS '+dgroup1/sample/datafile/mytable.342.3';
Dropping Files and Associated Aliases from a Disk Group
You can delete ASM files and their associated alias names from a disk group using the DROP FILE clause of the ALTER DISKGROUP statement. You must use a fully qualified filename, a numeric filename, or an alias name when specifying the file that you want to delete.

Some reasons why you might need to delete files include:

Files created using aliases are not Oracle-managed files. Consequently, they are not automatically deleted.

A point in time recovery of a database might restore the database to a time before a tablespace was created. The restore does not delete the tablespace, but there is no reference to the tablespace (or its datafile) in the restored database. You can manually delete the datafile.

Dropping an alias does not drop the underlying file on the file system.


Dropping Files and Associated Aliases from a Disk Group: Example 1

The following statement uses the alias name for the file to delete both the file and the alias:

ALTER DISKGROUP dgroup1 DROP FILE '+dgroup1/payroll/compensation.dbf';

Dropping Files and Associated Aliases from a Disk Group: Example 2

In this example the system generated filename is used to drop the file and any associated alias:

ALTER DISKGROUP dgroup1
DROP FILE '+dgroupA/sample/datafile/mytable.342.372642';
Checking Internal Consistency of Disk Group Metadata
You can check the internal consistency of disk group metadata using the ALTER DISKGROUP ... CHECK statement. Checking can be specified for 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 in order to perform these checks.

If any errors are detected, an error message is displayed and details of the errors are written to the alert log. Automatic Storage Management attempts to correct any errors, unless you specify the NOREPAIR clause in your ALTER DISKGROUP ... CHECK statement.

The following statement checks for consistency in the metadata for all disks in the dgroup1 disk group:

ALTER DISKGROUP dgroup1 CHECK ALL;
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 want any files that may still be contained in the disk group also to be deleted. The default is EXCLUDING CONTENTS, which provides syntactic consistency and prevents you from dropping the diskgroup 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, Automatic Storage Management 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 remember to 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, Automatic Storage Management 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 diskgroup contains any files.

Using Automatic Storage Management in the Database
This section discusses how you use Automatic Storage Management to manage database files for you. When you use Automatic Storage Management, Oracle database files are stored in ASM disk groups. These files are not visible to the operating system or its utilities, but are visible to RMAN and other Oracle supplied tools.

This following topics are contained in this section:

What Types of Files Does Automatic Storage Management Support?

About ASM Filenames

Starting the ASM and Database Instances

Creating and Referencing ASM Files in the Database

Creating a Database Using Automatic Storage Management

Creating Tablespaces Using Automatic Storage Management

Creating Redo Logs Using Automatic Storage Management

Creating a Control File Using Automatic Storage Management

Creating Archive Log Files Using Automatic Storage Management

Recovery Manager (RMAN) and Automatic Storage Management

What Types of Files Does Automatic Storage Management Support?
Automatic Storage Management supports most file types required by the database. However, most administrative files cannot be stored on a ASM disk group. These include trace files, audit files, alert logs, backup files, export files, tar files, and core files.

Table 12-2 lists file types, indicates if they are supported, and lists the system default template that provides the attributes for file creation. Some of the file types shown in the table are related to specific products or features, and are not discussed in this book.

Table 12-2 File Types Supported by Automatic Storage Management

File Type Supported Default Templates
Control files yes CONTROLFILE
Datafiles yes DATAFILE
Redo log files yes ONLINELOG
Archive log files yes ARCHIVELOG
Trace files no n/a
Temporary files yes TEMPFILE
Datafile backup pieces yes BACKUPSET
Datafile incremental backup pieces yes BACKUPSET
Archive log backup piece yes BACKUPSET
Datafile copy yes DATAFILE
Persistent initialization parameter file (SPFILE) yes PARAMETERFILE
Disaster recovery configurations yes DATAGUARDCONFIG
Flashback logs yes FLASHBACK
Change tracking file yes CHANGETRACKING
Data Pump dumpset yes DUMPSET
Auto backup yes AUTOBACKUP
Operating system files no n/a



See Also:

"Managing Disk Group Templates" for a description of the system default templates


About ASM Filenames
ASM filenames can take several forms. Some of the forms are used to create ASM files, others are used to reference them. The forms that you use to create files are alias names or incomplete file names, that basically point to a disk group wherein files are created and given fully qualified names by Automatic Storage Management.

When Automatic Storage Management creates a fully qualified name, an alert log message is written containing this ASM generated name. You can also find the generated name in database views displaying Oracle file names, such as V$DATAFILE, V$LOGFILE, and so forth. You can use this name, or an abbreviated form of it, if you later need to reference an ASM file in a SQL statement.

Like other Oracle database filenames, ASM filenames are kept in the control file and the RMAN catalog.

These are the forms of an ASM filename:

Fully Qualified ASM Filename

Numeric ASM Filename

Alias ASM Filenames

Alias ASM Filename with Template

Incomplete ASM Filename

Incomplete ASM Filename with Template

The following table specifies the valid contexts for each form of a filename. Single-file creation is relevant for file specifications. Multiple-file creation is relevant in a *_DEST parameter.

Filename Form Valid Context
Reference Single-File Creation Multiple-File Creation
Fully qualified filename Yes No No
Numeric filename Yes No No
Alias filename Yes Yes No
Alias with template filename No Yes No
Incomplete filename No Yes Yes
Incomplete filename with template No Yes Yes



Note:

Fully qualified and numeric filenames can be used in single-file create if you specify the REUSE flag, as described in "Using ASM Filenames in SQL Statements".


Fully Qualified ASM Filename
This form of ASM filename can be used for referencing existing ASM files. It is the filename that ASM always automatically generates when an ASM file is created. The fully qualified filename is also referred to as the system alias filename.

A fully qualified filename is derived by Automatic Storage Management and has the following form:

+group/dbname/file_type/file_type_tag.file.incarnation

Where:

+group is the disk group name.

dbname is the DB_UNIQUE_NAME of the database to which the file belongs.

file_type is the Oracle file type and can be one of the file types shown in the table that follows.

tag is type specific information about the file and can be one of the tags shown in the table that follows.

file.incarnation is the file/incarnation pair, used to ensure uniqueness.

An example of a fully qualified ASM filename is:

+dgroup2/sample/controlfile/CF.257.1

Table 12-3 Oracle File Types and Automatic Storage Management File Type Tags

Automatic Storage Management file_type Description Automatic Storage Management file_type_tag Comments
CONTROLFILE Control files and backup control files Current
Backup
--
DATAFILE Datafiles and datafile copies tsname Tablespace into which the file is added
ONLINELOG Online logs group_group# --
ARCHIVELOG Archive logs thread_thread#_seq_sequence# --
TEMPFILE Tempfiles tsname Tablespace into which the file is added
BACKUPSET Datafile and archive log backup pieces; datafile incremental backup pieces hasspfile_timestamp hasspfile can take one of two values: s indicates that the backup set includes the spfile; n indicates that the backup set does not include the spfile.
PARAMETERFILE Persistent parameter files spfile

DAATAGUARDCONFIG Data Guard configuration file db_unique_name Data Guard tries to use the service provider name if it is set. Otherwise the tag defaults to DRCname.
FLASHBACK Flashback logs log_log# --
CHANGETRACKING Block change tracking data ctf Used during incremental backups
DUMPSET Data Pump dumpset user_obj#_file# Dump set files encode the user name, the job number that created the dump set, and the file number as part of the tag.
XTRANSPORT Datafile convert tsname --
AUTOBACKUP Automatic backup files hasspfile_timestamp hasspfile can take one of two values: s indicates that the backup set includes the spfile; n indicates that the backup set does not include the spfile.


Numeric ASM Filename
The numeric ASM filename can be used for referencing existing files. It is derived from the fully qualified ASM filename and takes the form:

+group.file.incarnation

Numeric ASM filenames can be used in any interface that requires an existing file name.

An example of a numeric ASM filename is:

+dgroup2.257.8675309

Alias ASM Filenames
Alias ASM filenames can be used both for referencing existing ASM files and for creating new ASM files. Alias names start with the disk group name, after which you specify a name string of your choosing. Alias filenames are implemented using a hierarchical directory structure, with the slash (/) character separating name components. You must have already created the directory structure, using the ALTER DISKGROUP ... CREATE DIRECTORY statement as explained in "Managing Disk Group Directories ".

Alias ASM filenames are distinguished from fully qualified or numeric names because they do not end in a dotted pair of numbers. It is an error to attempt to create an alias that ends in a dotted pair of numbers. Examples of ASM alias filenames are:

+dgroup1/myfiles/control_file1
+dgroup2/mydir/second.dbf


Files created using an alias are not considered Oracle-managed files and may require manual deletion in the future if they are no longer needed.

An alias ASM filename is normally used in the CONTROL_FILES initialization parameter.

Alias ASM Filename with Template
An alias ASM filename with template is used only for ASM file creation operations. They are of the format:

+dgroup(template_name)/alias

The creation and maintenance of ASM templates is discussed in "Managing Disk Group Templates". The system default templates that can be specified and attributes that are assigned from these templates, are shown in the table in that section. You can also specify user-defined templates.

An example of an alias ASM filename with template is:

+dgroup1(spfile)/config1

Explicitly specifying a template name, as in this example, overrides the system default.

Incomplete ASM Filename
Incomplete ASM filenames are used only for file creation operations and are used for both single and multiple-file creation. They consist only of the disk group name. Automatic Storage Management uses a system default template to determine the ASM file redundancy and striping attributes. The system template that is used is determined by the file type that is being created. For example, if you are creating a datafile for a tablespace, then the datafile template is used.

An example of an incomplete ASM filename is:

+dgroup1

Incomplete ASM Filename with Template
Incomplete ASM filenames with templates are used only for file creation operations and are used for both single and multifile creation. They consist of the disk group name followed by the template name in parentheses. When you explicitly specify a template in a file name, ASM uses the specified template instead of the default template for that file type to determine redundancy and striping attributes for the file.

An example of an incomplete ASM filename with template is:

+dgroup1(datafile)
Starting the ASM and Database Instances
For you to use the functionality of Automatic Storage Management, a database instance requires that an ASM instance is running and that disk groups are configured. Specifically:

Start the ASM Instance.

You start the ASM instance on the same node as the database before you start the database instance. Starting an ASM instance is discussed in "Starting Up an ASM Instance"

Start the database instance

Consider the following before you start your database instance:

To start a database instance, you must have the INSTANCE_TYPE initialization parameter set as follows:

INSTANCE_TYPE = RDBMS

This the default.

Specify an ASM filename for any of the following initialization parameters for which you want Automatic Storage Management to automatically create and manage files (see "Creating ASM Files Using a Default Disk Group Specification":

DB_CREATE_FILE_DEST

DB_CREATE_ONLINE_LOG_DEST_n

DB_RECOVERY_FILE_DEST

CONTROL_FILES

LOG_ARCHIVE_DEST_n

LOG_ARCHIVE_DEST

STANDBY_ARCHIVE_DEST

Some additional initialization parameter considerations:

LOG_ARCHIVE_FORMAT is ignored if a disk group is specified for LOG_ARCHIVE_DEST (for example, LOG_ARCHIVE_DEST = +dgroup1).

DB_BLOCK_SIZE must be one of the standard block sizes (2K, 4K, 8K, 16K or 32K bytes).

LARGE_POOL_SIZE must be set to at least 8 MB.

Your database instance is now able to create ASM files. You can keep your database instance open and running when you reconfigure disk groups. When you add or remove disks from a disk group, Automatic Storage Management automatically rebalances file data in the reconfigured disk group to ensure a balanced I/O load, even while the database is running.

Creating and Referencing ASM Files in the Database
ASM files are Oracle-managed files unless you created the file using an alias. Any Oracle-managed file is automatically deleted when it is no longer needed. An ASM file is deleted if the creation fails.

Creating ASM Files Using a Default Disk Group Specification
Using the Oracle-managed files feature for operating system files, you can specify a directory as the default location for the creation of datafiles, tempfiles, redo log files, and control files. Using the Oracle-managed files feature for ASM, you can specify a disk group, in the form of an ASM filename, as the default location for creation of these files, and additional types of files, including archived log files. As for operating system files, the name of the default disk group is stored in an initialization parameter and is used whenever a file specification (for example, DATAFILE clause) is not explicitly specified during file creation.

The following initialization parameters accept the multifile creation context form of ASM filenames as a destination:

Initialization Parameter Description
DB_CREATE_FILE_DEST Specifies the default disk group location in which to create:
Datafiles

Tempfiles

If DB_CREATE_ONLINE _LOG_DEST_n is not specified, then also specifies the default disk group for:

Redo log files

Control file

DB_CREATE_ONLINE_LOG_DEST_n Specifies the default disk group location in which to create:
Redo log files

Control files

DB_RECOVERY_FILE_DEST If this parameter is specified and DB_CREATE_ONLINE_LOG_DEST_n and CONTROL_FILES are not specified, then specifies a default disk group for a flash recovery area that contains a copy of:
Control file

Redo log files

If no local archive destination is specified, then this parameter implicitly sets LOG_ARCHIVE_DEST_10 to USE_DB_RECOVERY_FILE_DEST.

CONTROL_FILES Specifies a disk group in which to create control files.


The following initialization parameters accept the multifile creation context form of the ASM filenames and ASM directory names as a destination:

Initialization Parameter Description
LOG_ARCHIVE_DEST_n Specifies a default disk group or ASM directory as destination for archiving redo log files
LOG_ARCHIVE_DEST Optional parameter to use to specify a default disk group or ASM directory as destination for archiving redo log files. Use when specifying only one destination.
STANDBY_ARCHIVE_DEST Relevant only for a standby database in managed recovery mode. It specifies a default disk group or ASM directory that is the location of archive logs arriving from a primary database. Not discussed in this book. See Oracle Data Guard Concepts and Administration.


The following example illustrates how an ASM file, in this case a datafile, might be created in a default disk group.


Creating a Datafile Using a Default Disk Group: Example

Assume the following initialization parameter setting:

DB_CREATE_FILE_DEST = '+dgroup1'

The following statement creates tablespace tspace1.

CREATE TABLESPACE tspace1;

Automatic Storage Management automatically creates and manages its datafile on ASM disks in the disk group dgroup1. File extents are stored using the attributes defined by the system default template for a datafile.

Using ASM Filenames in SQL Statements
You can specify ASM filenames in the file specification clause of your SQL statements. If you are creating a file for the first time, then use the creation form of an ASM filename. If the ASM file already exists, then the filename must be in a reference context form and, if trying to re-create the file, the REUSE clause specified. The space will be reused for the new file. This usage might occur when, for example, trying to re-create a control file, as shown in "Creating a Control File Using Automatic Storage Management".

If a reference context form is used with the REUSE clause, and the file does not exist, the numeric portion of the reference context form is ignored, and a new file is created as if the incomplete filename had been specified.

Partially created files resulting from system errors are automatically deleted.


Using an ASM Filename in a SQL Statement: Example

The following is an example of specifying an ASM filename in a SQL statement. In this case, it is used in the file creation context:

CREATE TABLESPACE tspace2 DATAFILE '+dgroup2' SIZE 200M AUTOEXTEND ON;

The tablespace tspace2 is created and is comprised of one datafile of size 200M contained in the disk group dgroup2. The datafile is set to auto-extensible with an unlimited maximum size. An AUTOEXTEND clause can be used to override this default.

Creating a Database Using Automatic Storage Management
The recommended method of creating your database is to use the Database Configuration Assistant (DBCA). However, if you choose to create your database manually using the CREATE DATABASE statement, then Automatic Storage Management enables you to create a database and all of its underlying files with a minimum of input from you.

The following is an example of using the CREATE DATABASE statement, where database files are created and managed automatically by Automatic Storage Management.


Creating a Database Using Automatic Storage Management: Example

This example creates a database with the following ASM files:

A SYSTEM tablespace datafile in disk group dgroup1.

A SYSAUX tablespace datafile in disk group dgroup1. The tablespace is locally managed with automatic segment-space management.

A multiplexed online redo log is created with two online log groups, one member of each in dgroup1 and dgroup2 (flash recovery area).

If automatic undo management mode is enabled, then an undo tablespace datafile in directory dgroup1.

If no CONTROL_FILES initialization parameter is specified, then two control files, one in drgoup1 and another in dgroup2 (flash recovery area). The control file in dgroup1 is the primary control file.

The following initialization parameter settings are included in the initialization parameter file:

DB_CREATE_FILE_DEST = '+dgroup1'
DB_RECOVERY_FILE_DEST = '+dgroup2'
DB_RECOVERY_FILE_DEST_SIZE = 10G

The following statement is issued at the SQL prompt:

SQL> CREATE DATABASE sample;
Creating Tablespaces Using Automatic Storage Management
When Automatic Storage Management creates a datafile for a permanent tablespace (or a tempfile for a temporary tablespace), the datafile is set to auto-extensible with an unlimited maximum size and 100 MB default size. You can use the AUTOEXTEND clause to override this default extensibility and the SIZE clause to override the default size.

Automatic Storage Management applies attributes to the datafile, as specified in the system default template for a datafile as shown in the table in "Managing Disk Group Templates". You can also create and specify your own template.

Files in a tablespace may be in both ASM files and non-ASM files as a result of the tablespace history. RMAN commands enable non-ASM files to be relocated to a ASM disk group and enable ASM files to be relocated as non-ASM files.

The following are some examples of creating tablespaces using Automatic Storage Management. The examples assume that disk groups have already been configured.


See Also:

Oracle Database Backup and Recovery Basics

Oracle Database Backup and Recovery Advanced User's Guide




Creating a Tablespace Using Automatic Storage Management: Example 1

This example illustrates "out of the box" usage of Automatic Storage Management. You let Automatic Storage Management create and manage the tablespace datafile for you, using Oracle supplied defaults that are adequate for most situations.

Assume the following initialization parameter setting:

DB_CREATE_FILE_DEST = '+dgroup2'

The following statement creates the tablespace and its datafile:

CREATE TABLESPACE tspace2;

Creating a Tablespace Using Automatic Storage Management: Example 2

The following statements create a tablespace that uses a user defined template (assume it has been defined) to specify the redundancy and striping attributes of the datafile:

SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = '+dgroup1(my_template)';
SQL> CREATE TABLESPACE tspace3;

Creating a Tablespace Using Automatic Storage Management: Example 3

The following statement creates an undo tablespace with a datafile that has an alias name and its attributes are set by the user defined template my_undo_temp. It assumes a directory has been created in disk group dgroup3 to contain the alias name and that the user defined template exists. Because an alias is used to create the datafile, the file is not an Oracle-managed file and will not be automatically deleted when the tablespace is dropped.

CREATE UNDO TABLESPACE myundo
DATAFILE '+dgroup3(my_undo_temp)/myfiles/my_undo_ts' SIZE 200M;

The following statement drops the file manually after the tablespace has been dropped:

ALTER DISKGROUP dgroup3 DROP FLE '+dgroup3/myfiles/my_undots';
Creating Redo Logs Using Automatic Storage Management
Online redo logs can be created in multiple disk groups, either implicitly in the initialization parameter file or explicitly in an ALTER DATABASE ... ADD LOGFILE statement. Each online log should have one log member in multiple disk groups. The filenames for log file members are automatically generated.

All partially created redo log files, created as a result of a system error, are automatically deleted.


Adding New Redo Log Files: Example

The following example creates a log file with a member in each of the disk groups dgroup1 and dgroup2.

The following parameter settings are included in the initialization parameter file:

DB_CREATE_ONLINE_LOG_DEST_1 = '+dgroup1'
DB_CREATE_ONLINE_LOG_DEST_2 = '+dgroup2'

The following statement is issued at the SQL prompt:

ALTER DATABASE ADD LOGFILE;
Creating a Control File Using Automatic Storage Management
Control files can be explicitly created in multiple disk groups. The filenames for control files are automatically generated. If an attempt to create a control file fails, partially created control files will be automatically be deleted.

There may be times when you need to specify a control file by name. Alias filenames are provided to allow administrators to reference ASM files with human-understandable names. The use of an alias in the specification of the control file during its creation allows the DBA to later refer to the control file with a human-meaningful name. Furthermore, an alias can be specified as a control file name in the CONTROL_FILES initialization parameter. Control files created without aliases can be given alias names at a later time. The ALTER DISKGROUP ... CREATE ALIAS statement is used for this purpose.

When creating a control file, datafiles and log files stored in an ASM disk group should be given to the CREATE CONTROLFILE command using the file reference context form of their ASM filenames. However, the use of the RESETLOGS option requires the use of a file creation context form for the specification of the log files.


Creating a Control File Using Automatic Storage Management: Example 1

The following CREATE CONTROLFILE statement is generated by an ALTER DATABASE BACKUP CONTROLFILE TO TRACE command for a database with datafiles and log files created on disk groups dgroup1 and dgroup2:

CREATE CONTROLFILE REUSE DATABASE "SAMPLE" NORESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 2
MAXDATAFILES 30
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 (
'+DGROUP1/db/onlinelog/group_1.258.3',
'+DGROUP2/db/onlinelog/group_1.256.3'
) SIZE 100M,
GROUP 2 (
'+DGROUP1/db/onlinelog/group_2.257.3',
'+DGROUP2/db/onlinelog/group_2.258.1'
) SIZE 100M
DATAFILE
'+DGROUP1/db/datafile/system.260.3',
'+DGROUP1/db/datafile/sysaux.259.3'
CHARACTER SET US7ASCII
;

Creating a Control File Using Automatic Storage Management: Example 2

This example is a CREATE CONTROLFILE statement for a database with datafiles, but uses a RESETLOGS clause, and thus uses the creation context form for log files:

CREATE CONTROLFILE REUSE DATABASE "SAMPLE" RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 2
MAXDATAFILES 30
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 (
'+DGROUP1',
'+DGROUP2'
) SIZE 100M,
GROUP 2 (
'+DGROUP1',
'+DGROUP2'
) SIZE 100M
DATAFILE
'+DGROUP1/db/datafile/system.260.3',
'+DGROUP1/db/datafile/sysaux.259.3'
CHARACTER SET US7ASCII
;
Creating Archive Log Files Using Automatic Storage Management
Disk groups can be specified as archive log destinations in the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DEST_n initialization parameters. When destinations are specified in this manner, the archive log filename will be unique, even if archived twice. Partially created archive operations resulting from a system error are deleted and do not leave a half written file.

If LOG_ARCHIVE_DEST is set to a disk group name, LOG_ARCHIVE_FORMAT is ignored. Unique filenames for archived logs are automatically created by the Oracle database. If LOG_ARCHIVE_DEST is set to a directory in a disk group, LOG_ARCHIVE_FORMAT has its normal semantics.

The following sample archive log names might be generated with DB_RECOVERY_FILE_DEST set to +dgroup2. SAMPLE is the value of the DB_UNIQUE_NAME parameter:

+DGROUP2/SAMPLE/ARCHIVELOG/2003_09_23/thread_1_seq_38.614.3
+DGROUP2/SAMPLE/ARCHIVELOG/2003_09_23/thread_4_seq_35.609.3
+DGROUP2/SAMPLE/ARCHIVELOG/2003_09_23/thread_2_seq_34.603.3
+DGROUP2/SAMPLE/ARCHIVELOG/2003_09_25/thread_3_seq_100.621.3
+DGROUP2/SAMPLE/ARCHIVELOG/2003_09_25/thread_1_seq_38.614.3
Recovery Manager (RMAN) and Automatic Storage Management
RMAN is critical to Automatic Storage Management and is responsible for tracking the ASM filenames and for deleting obsolete ASM files. Since ASM files cannot be accessed through normal operating system interfaces, RMAN is the preferred means of copying ASM files; you can also use FTP through XDB. RMAN is the only method for performing backups of a database containing ASM files.

RMAN can also be used for moving databases or files into ASM storage.


See Also:

Oracle Database Backup and Recovery Basics

Oracle Database Backup and Recovery Advanced User's Guide



Viewing Information About Automatic Storage Management
You can use these views to query information about Automatic Storage Management:

View Description
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.

V$ASM_CLIENT In an ASM instance, identifies databases using disk groups managed by the ASM instance.
In a DB instance, contains one row for 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.

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_TEMPLATE In an ASM instance, contains one row for every template present in every disk group mounted by the ASM instance.
In a DB instance, contains no rows

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_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.