ASM Abbas Practies

http://www.idevelopment.info/data/Oracle/DBA_tips/Automatic_Storage_Management/ASM_20.shtml

How to use Files in place of Real Disk Devices for ASM - (Linux)

Overview

This article provides the steps to create and configure blank files (instead of real disk devices) for use in testing Oracle's Automatic Storage Manager (ASM) on the Linux platform. This is a handy trick that can be used when the DBA needs to test ASM on a machine that has no free disk partitions or no free disk devices available. Please note that this is intended for testing purposes only!

Creating Files for use by ASM

The first step is to identify an already partitioned and formatted hard disk that contains enough space to contain the blank files to be used as ASM disk devices.

For the purpose of this example, I have enough room on my local hard disk (/dev/sda1) to create four files at 100MB each. I want to create one disk group that contains four disks. The disk group will contain two failure groups and each failure group will be created using two disks.

From within the Linux O/S platform, perform the following actions:

1. Create Files using "dd" 2. # mkdir /asmdisks3. # chown oracle:dba /asmdisks4. # su - oracle5.6. $ dd if=/dev/zero of=/asmdisks/_file_disk1 bs=1k count=1000007. $ dd if=/dev/zero of=/asmdisks/_file_disk2 bs=1k count=1000008. $ dd if=/dev/zero of=/asmdisks/_file_disk3 bs=1k count=100000

$ dd if=/dev/zero of=/asmdisks/_file_disk4 bs=1k count=100000

We now have four files to be used as virtual disks of 100MB each:

$ ls -l /asmdisks



total 400432-rw-r--r-- 1 oracle dba 102400000 Jun 8 15:30 _file_disk1-rw-r--r-- 1 oracle dba 102400000 Jun 8 15:31 _file_disk2-rw-r--r-- 1 oracle dba 102400000 Jun 8 15:31 _file_disk3-rw-r--r-- 1 oracle dba 102400000 Jun 8 15:31 _file_disk4

9. Associate Loop Device with the New Files

The next step is to use the losetup command to associate a loop device with a file. This needs to be performed as the root user account:

# losetup /dev/loop1 /asmdisks/_file_disk1# losetup /dev/loop2 /asmdisks/_file_disk2# losetup /dev/loop3 /asmdisks/_file_disk3# losetup /dev/loop4 /asmdisks/_file_disk4

10. Bind RAW Devices to Existing Block Devices

The next critical step is to use the raw utility to bind a RAW device to each of the block devices we already created. Again, this needs to be performed as the root user account:

# raw /dev/raw/raw1 /dev/loop1/dev/raw/raw1: bound to major 7, minor 1




11. Change Ownership of RAW Devices

Finally, let's change the ownership of all four RAW devices:

# chown oracle:dba /dev/raw/raw1# chown oracle:dba /dev/raw/raw2# chown oracle:dba /dev/raw/raw3# chown oracle:dba /dev/raw/raw4

# chmod 660 /dev/raw/raw1# chmod 660 /dev/raw/raw2# chmod 660 /dev/raw/raw3# chmod 660 /dev/raw/raw4

After completeting the above steps, the O/S will see four free 'devices' now available for ASM!

Manually Creating an ASM Instance

Overview

Automatic Storage Management (ASM) is a new feature in Oracle10g that alleviates the DBA from having to manually manage and tune disks used by Oracle databases. ASM provides the DBA with a file system and volume manager that makes use of an Oracle instance (referred to as an ASM instance) and can be managed using either SQL or Oracle Enterprise Manager.

Only one ASM instance is required per node. The same ASM instance can manage ASM storage for all 10g databases running on the node.

When the DBA installs the Oracle10g software and creates a new database, creating an ASM instance is a snap. The DBCA provides a simple check box and an easy wizard to create an ASM instance as well as an Oracle database that makes use of the new ASM instance for ASM storage. But, what happens when the DBA is migrating to Oracle10g or didn't opt to use ASM when a 10g database was first created. The DBA will need to know how to manually create an ASM instance and that is what this article provides.

Configuring Oracle Cluster Synchronization Services (CSS)

Automatic Storage Management (ASM) requires the use of Oracle Cluster Synchronization Services (CSS), and as such, CSS must be configured and running before attempting to use ASM. The CSS service is required to enable synchronization between an ASM instance and the database instances that rely on it for database file storage.

In a non-RAC environment, the Oracle Universal Installer will configure and start a single-node version of the CSS service. For Oracle Real Application Clusters (RAC) installations, the CSS service is installed with Oracle Cluster Ready Services (CRS) in a separate Oracle home directory (also called the CRS home directory). For single-node installations, the CSS service is installed in and runs from the same Oracle home as the Oracle database.

Because CSS must be running before any ASM instance or database instance starts, Oracle Universal Installer configures it to start automatically when the system starts. For Linux / UNIX platforms, the Oracle Universal Installer writes the CSS configuration tasks to the root.sh which is run by the DBA after the installation process.

With Oracle10g R1, CSS was always configured regardless of whether you chose to configure ASM or not. On the Linux / UNIX platform, CSS was installed and configured via the root.sh script. This caused a lot of problems since many did not know what this process was, and for most of them, didn't want the CSS process running since they were not using ASM.

Oracle listened carefully to the concerns (and strongly worded complaints) about the CSS process and in Oracle10g R2, will only configure this process when it is absolutely necessary. In Oracle10g R2, for example, if you don't choose to configure an ASM stand-alone instance or if you don't choose to configure a database that uses ASM storage, Oracle will not automatically configure CSS in the root.sh script.

In the case where the CSS process is not configured to run on the node (see above), you can make use of the $ORACLE_HOME/bin/localconfig script in Linux / UNIX or %ORACLE_HOME%\bin\localconfig.bat batch file in Windows. For example in Linux, run the following command as root to configure CSS outside of the root.sh script after the fact:

$ su# $ORACLE_HOME/bin/localconfig all

/etc/oracle does not exist. Creating it now.Successfully accumulated necessary OCR keys.Creating OCR keys for user 'root', privgrp 'root'..Operation successful.Configuration for local CSS has been initialized

Adding to inittabStartup will be queued to init within 90 seconds.Checking the status of new Oracle init process...Expecting the CRS daemons to be up within 600 seconds.

CSS is active on these nodes. linux3CSS is active on all nodes.Oracle CSS service is installed and running under init(1M)

Note that if you attempt to configure ASM after the fact, the Database Configuration Assistant (DBCA) detects whether CSS is configured on the node. If it does not detect CSS as configured (and running), the installer prompts the user to run 'localconfig add' as necessary.

When performing an Oracle10g Custom install, the issue can become a bit more confusing. During a custom install, Oracle will ask for any DB configuration questions during the install itself. It then invokes the DBCA at the end of the install in "custom" mode where the DBCA asks all the questions. As such, at the time Oracle prompts the user to run the root.sh script for a custom install, it does not know whether they will choose to configure ASM or not. Oracle will err on the side of what the majority of people would do. In this case, it means that Oracle will not configure CSS at

all in the root.sh script in the case of a custom install since the majority of users will not be using ASM anyway. Here, Oracle relies on the fact that if CSS is not configured, the DBCA will prompt the user to go run 'localconfig add' as root. Once this is done, then CSS will be configured and the DBCA will allow the user to proceed with the configuration of ASM.

Creating the ASM Instance

The following steps can be used to create a fully functional ASM instance named +ASM. The node I am using in this example also has a regular 10g database running named TESTDB. These steps should all be carried out by the oracle UNIX user account:

1. Create Admin Directories

We start by creating the admin directories from the ORACLE_BASE. The admin directories for the existing database on this node, (TESTDB), is located at $ORACLE_BASE/admin/TESTDB. The new +ASM admin directories will be created alongside the TESTDB database:

UNIX

mkdir -p $ORACLE_BASE/admin/+ASM/bdumpmkdir -p $ORACLE_BASE/admin/+ASM/cdumpmkdir -p $ORACLE_BASE/admin/+ASM/hdumpmkdir -p $ORACLE_BASE/admin/+ASM/pfilemkdir -p $ORACLE_BASE/admin/+ASM/udump

Microsoft Windows

mkdir %ORACLE_BASE%\admin\+ASM\bdumpmkdir %ORACLE_BASE%\admin\+ASM\cdumpmkdir %ORACLE_BASE%\admin\+ASM\hdumpmkdir %ORACLE_BASE%\admin\+ASM\pfilemkdir %ORACLE_BASE%\admin\+ASM\udump

2. Create Instance Parameter File

In this step, we will manually create an instance parameter file for the ASM instance. This is actually an easy task as most of the parameters that are used for a normal instance are not used for an ASM instance. Note that you should be fine by accepting the default size for the database buffer cache, shared pool, and many of the other SGA memory sructures. The only exception is the large pool. I like to manually set this value to at least 12MB. In most cases, the SGA memory footprint is less then 100MB. Let's start by creating the file init.ora and placing

that file in $ORACLE_BASE/admin/+ASM/pfile. The initial parameters to use for the file are:

UNIX

$ORACLE_BASE/admin/+ASM/pfile/init.ora

############################################ Automatic Storage Management############################################ _asm_allow_only_raw_disks=false# asm_diskgroups='TESTDB_DATA1'

# Default asm_diskstring values for supported platforms:# Solaris (32/64 bit) /dev/rdsk/*# Windows NT/XP \\.\orcldisk*# Linux (32/64 bit) /dev/raw/*# HPUX /dev/rdsk/*# HPUX(Tru 64) /dev/rdisk/*# AIX /dev/rhdisk/*# asm_diskstring=''

############################################ Diagnostics and Statistics###########################################background_dump_dest=/u01/app/oracle/admin/+ASM/bdumpcore_dump_dest=/u01/app/oracle/admin/+ASM/cdumpuser_dump_dest=/u01/app/oracle/admin/+ASM/udump

############################################ Miscellaneous###########################################instance_type=asmcompatible=10.1.0.4.0

############################################ Pools###########################################large_pool_size=12M

############################################ Security and Auditing###########################################remote_login_passwordfile=exclusive

Microsoft Windows

%ORACLE_BASE%\admin\+ASM\pfile\init.ora

############################################ Automatic Storage Management############################################ _asm_allow_only_raw_disks=false# asm_diskgroups='TESTDB_DATA1'

# Default asm_diskstring values for supported platforms:# Solaris (32/64 bit) /dev/rdsk/*# Windows NT/XP \\.\orcldisk*# Linux (32/64 bit) /dev/raw/*# HPUX /dev/rdsk/*# HPUX(Tru 64) /dev/rdisk/*# AIX /dev/rhdisk/*# asm_diskstring=''

############################################ Diagnostics and Statistics###########################################background_dump_dest=C:\oracle\product\10.1.0\admin\+ASM\bdumpcore_dump_dest=C:\oracle\product\10.1.0\admin\+ASM\cdumpuser_dump_dest=C:\oracle\product\10.1.0\admin\+ASM\udump

############################################ Miscellaneous###########################################instance_type=asmcompatible=10.1.0.4.0

############################################ Pools###########################################large_pool_size=12M

############################################ Security and Auditing###########################################remote_login_passwordfile=exclusive

After creating the $ORACLE_BASE/admin/+ASM/pfile/init.ora file, UNIX users should create the following symbolic link:

$ ln -s $ORACLE_BASE/admin/+ASM/pfile/init.ora $ORACLE_HOME/dbs/init+ASM.ora

Starting the ASM Instance

Once the instance parameter file is in place, it is time to start the ASM instance. It is important to note that an ASM instance never mounts an actual database. The ASM instance is responsible for mounting and managing disk groups.

Attention Windows Users!

If you are running in Microsoft Windows, you will need to manually create a new Windows service to run the new instance. This is done using the ORADIM utility which allows you to create both the instance and the service in one command.

UNIX

# su - oracle$ ORACLE_SID=+ASM; export ORACLE_SID$ sqlplus "/ as sysdba"

SQL> startupASM instance started

Total System Global Area 75497472 bytesFixed Size 777852 bytesVariable Size 74719620 bytesDatabase Buffers 0 bytesRedo Buffers 0 bytesORA-15110: no diskgroups mounted

SQL> create spfile from pfile='/u01/app/oracle/admin/+ASM/pfile/init.ora';

SQL> shutdownASM instance shutdown


Microsoft Windows

C:\> oradim -new -asmsid +ASM -syspwd change_on_install -pfile C:\oracle\product\10.1.0\admin\+ASM\pfile\init.ora -spfile -startmode manual -shutmode immediate

Instance created.

C:\> oradim -edit -asmsid +ASM -startmode a

C:\> set oracle_sid=+ASMC:\> sqlplus "/ as sysdba"

SQL> startup pfile='C:\oracle\product\10.1.0\admin\+ASM\pfile\init.ora';ASM instance started

Total System Global Area 125829120 bytesFixed Size 769268 bytesVariable Size 125059852 bytesDatabase Buffers 0 bytesRedo Buffers 0 bytesORA-15110: no diskgroups mounted

SQL> create spfile from pfile='C:\oracle\product\10.1.0\admin\+ASM\pfile\init.ora';File created.

SQL> shutdownASM instance shutdown


You will notice when starting the ASM instance, we received the error: ORA-15110: no diskgroups mounted

This error can be safely ignored.

Notice also that we created a server parameter file (SPFILE) for the ASM instance. This allows Oracle to automatically record new disk group names in the asm_diskgroups instance parameter, so that those disk groups can be automatically mounted whenever the ASM instance is started.

Now that the ASM instance is started, all other Oracle database instances running on the same node will be able to find it.

Verify RAW / Logical Disk Are Discovered

At this point, we have an ASM instance running, but no disk groups to speak of. ASM disk groups are created using from RAW (or logical) disks.

Available (candidate) disks for ASM are discovered by use of the asm_diskstring instance parameter. This parameter contains the path(s) that Oracle will use to discover (or see) these candidate disks. In most cases, you shouldn't have to set this value as the default value is set for the supported platform. The following table is a list of default values for asm_diskstring on supported platforms when the value of the instance parameter is set to NULL (the value is not set):

Operating System Default Search String

Solaris (32/64 bit) /dev/rdsk/*

Windows NT/XP \\.\orcldisk*

Linux (32/64 bit) /dev/raw/*

HP-UX /dev/rdsk/*

HP-UX(Tru 64) /dev/rdisk/*

AIX /dev/rhdisk/*

For the purpose of this article, I have four RAW devices setup on Linux:

# ls -l /dev/raw/raw[1234]crw-rw---- 1 oracle dba 162, 1 Jun 2 22:04 /dev/raw/raw1crw-rw---- 1 oracle dba 162, 2 Jun 2 22:04 /dev/raw/raw2crw-rw---- 1 oracle dba 162, 3 Jun 2 22:04 /dev/raw/raw3crw-rw---- 1 oracle dba 162, 4 Jun 2 22:04 /dev/raw/raw4

I now need to determine if Oracle can find these four disks. The view V$ASM_DISK can be queried from the ASM instance to determine which disks are being used or may potentially be used as ASM disks. Note that you must log into the ASM instance with SYSDBA privileges. Here is the query that I ran from the ASM instance: $ ORACLE_SID=+ASM; export ORACLE_SID$ sqlplus "/ as sysdba"

SQL> SELECT group_number, disk_number, mount_status, header_status, state, path 2 FROM v$asm_disk

GROUP_NUMBER DISK_NUMBER MOUNT_S HEADER_STATU STATE PATH------------ ----------- ------- ------------ -------- --------------- 0 0 CLOSED CANDIDATE NORMAL /dev/raw/raw1 0 1 CLOSED CANDIDATE NORMAL /dev/raw/raw2 0 2 CLOSED CANDIDATE NORMAL /dev/raw/raw3 0 3 CLOSED CANDIDATE NORMAL /dev/raw/raw4

Note the value of zero in the GROUP_NUMBER column for all four disks. This indicates that a disk is available but hasn't yet been assigned to a disk group. The next section details the steps for creating a disk group.

Creating Disk Groups

In this section, I will create a new disk group named TESTDB_DATA1 and assign all four discovered disks to it. The disk group will be configured for NORMAL REDUNDANCY which results in two-way mirroring of al files within the disk group. Within the disk group, I will be configuring two failure groups, which defines two independent sets of disk that should never contain more than one copy of mirrored data (mirrored extents).

For the purpose of this article, it is assumed that /dev/raw/raw1 and /dev/raw/raw2 are on one controller while /dev/raw/raw3 and /dev/raw/raw4 are on another controller. I want the ASM disk configuration so that any data files that are written to /dev/raw/raw1 and /dev/raw/raw2 will be mirrored to /dev/raw/raw3 and /dev/raw/raw4. I want ASM to guarantee that data on /dev/raw/raw1 is never mirrored to /dev/raw/raw2 and that data on /dev/raw/raw3 is never mirrored to /dev/raw/raw4. With this type of configuration, I can loose an entire controller and still have access to all of my data. When configuring failure groups, you should put all disks that share a controller (or any resource for that matter) into their own failure group. If that resource were to fail, you would still have access to the data as ASM guarantees that no mirrored data will exist in the same failure group.

The new disk group should be created from the ASM instance using the following SQL:

SQL> CREATE DISKGROUP testdb_data1 NORMAL REDUNDANCY 2 FAILGROUP controller1 DISK '/dev/raw/raw1', '/dev/raw/raw2'

3 FAILGROUP controller2 DISK '/dev/raw/raw3', '/dev/raw/raw4';

Diskgroup created.

Now, let's take a look at the new disk group and disk details:

SQL> select group_number, name, total_mb, free_mb, state, type 2 from v$asm_diskgroup;

GROUP_NUMBER NAME TOTAL_MB FREE_MB STATE TYPE------------ -------------- ---------- ---------- ----------- ------ 1 TESTDB_DATA1 388 282 MOUNTED NORMAL

SQL> select group_number, disk_number, mount_status, header_status, state, path, failgroup 2 from v$asm_disk;

GROUP_NUMBER DISK_NUMBER MOUNT_S HEADER_STATU STATE PATH FAILGROUP------------ ----------- ------- ------------ -------- --------------- ------------ 1 0 CACHED MEMBER NORMAL /dev/raw/raw1 CONTROLLER1 1 1 CACHED MEMBER NORMAL /dev/raw/raw2 CONTROLLER1 1 2 CACHED MEMBER NORMAL /dev/raw/raw3 CONTROLLER2 1 3 CACHED MEMBER NORMAL /dev/raw/raw4 CONTROLLER2

Using Disk Groups

Finally, let's start making use of the new disk group! Disk groups can be used in place of actual file names when creating database files, redo log members, control files, etc.

Let's now login to the database instance running on the node that will be making use of the new ASM instance. For this article, I have a database instance already created and running on the node named TESTDB. The database was created using the local file system for all database files, redo log members, and control files:

$ ORACLE_SID=TESTDB; export ORACLE_SID$ sqlplus "/ as sysdba"

SQL> @dba_files_all

Tablespace Name

File Class Filename File Size-------------------- ---------------------------------------------------------- --------------SYSAUX /u05/oradata/TESTDB/datafile/o1_mf_sysaux_19cv6mwk_.dbf 241,172,480SYSTEM /u05/oradata/TESTDB/datafile/o1_mf_system_19cv5rmv_.dbf 471,859,200TEMP /u05/oradata/TESTDB/datafile/o1_mf_temp_19cv6sy9_.tmp 24,117,248UNDOTBS1 /u05/oradata/TESTDB/datafile/o1_mf_undotbs1_19cv6c37_.dbf 214,958,080USERS /u05/oradata/TESTDB/datafile/o1_mf_users_19cv72yw_.dbf 5,242,880[ CONTROL FILE ] /u03/oradata/TESTDB/controlfile/o1_mf_19cv5m84_.ctl[ CONTROL FILE ] /u04/oradata/TESTDB/controlfile/o1_mf_19cv5msk_.ctl[ CONTROL FILE ] /u05/oradata/TESTDB/controlfile/o1_mf_19cv5n34_.ctl[ ONLINE REDO LOG ] /u03/oradata/TESTDB/onlinelog/o1_mf_1_19cv5n8d_.log 10,485,760[ ONLINE REDO LOG ] /u03/oradata/TESTDB/onlinelog/o1_mf_2_19cv5o6l_.log 10,485,760[ ONLINE REDO LOG ] /u03/oradata/TESTDB/onlinelog/o1_mf_3_19cv5pdy_.log 10,485,760[ ONLINE REDO LOG ] /u04/oradata/TESTDB/onlinelog/o1_mf_1_19cv5nbr_.log 10,485,760[ ONLINE REDO LOG ] /u04/oradata/TESTDB/onlinelog/o1_mf_2_19cv5oml_.log 10,485,760[ ONLINE REDO LOG ] /u04/oradata/TESTDB/onlinelog/o1_mf_3_19cv5pt4_.log 10,485,760[ ONLINE REDO LOG ] /u05/oradata/TESTDB/onlinelog/o1_mf_1_19cv5nsf_.log 10,485,760[ ONLINE REDO LOG ] /u05/oradata/TESTDB/onlinelog/o1_mf_2_19cv5p1b_.log 10,485,760[ ONLINE REDO LOG ] /u05/oradata/TESTDB/onlinelog/o1_mf_3_19cv5q8j_.log 10,485,760 --------------sum 1,051,721,728

Let's now create a new tablespace that makes use of the new disk group:

SQL> create tablespace users2 datafile '+TESTDB_DATA1' size 100m;

Tablespace created.

And that's it! The CREATE TABLESPACE command (above) uses a datafile named

+TESTDB_DATA1. Note that the plus sign (+) in front of the name TESTDB_DATA1 indicates to Oracle that this name is a disk group name, and not an operating system file name. In this example, the TESTDB instance queries the ASM instance for a new file in that disk group and uses that file for the tablespace data. Let's take a look at that new file name:

SQL> @dba_files_all

Tablespace NameFile Class Filename File Size-------------------- ---------------------------------------------------------- --------------SYSAUX /u05/oradata/TESTDB/datafile/o1_mf_sysaux_19cv6mwk_.dbf 241,172,480SYSTEM /u05/oradata/TESTDB/datafile/o1_mf_system_19cv5rmv_.dbf 471,859,200TEMP /u05/oradata/TESTDB/datafile/o1_mf_temp_19cv6sy9_.tmp 24,117,248UNDOTBS1 /u05/oradata/TESTDB/datafile/o1_mf_undotbs1_19cv6c37_.dbf 214,958,080USERS /u05/oradata/TESTDB/datafile/o1_mf_users_19cv72yw_.dbf 5,242,880USERS2 +TESTDB_DATA1/testdb/datafile/users2.256.560031579 104,857,600[ CONTROL FILE ] /u03/oradata/TESTDB/controlfile/o1_mf_19cv5m84_.ctl[ CONTROL FILE ] /u04/oradata/TESTDB/controlfile/o1_mf_19cv5msk_.ctl[ CONTROL FILE ] /u05/oradata/TESTDB/controlfile/o1_mf_19cv5n34_.ctl[ ONLINE REDO LOG ] /u03/oradata/TESTDB/onlinelog/o1_mf_1_19cv5n8d_.log 10,485,760[ ONLINE REDO LOG ] /u03/oradata/TESTDB/onlinelog/o1_mf_2_19cv5o6l_.log 10,485,760[ ONLINE REDO LOG ] /u03/oradata/TESTDB/onlinelog/o1_mf_3_19cv5pdy_.log 10,485,760[ ONLINE REDO LOG ] /u04/oradata/TESTDB/onlinelog/o1_mf_1_19cv5nbr_.log 10,485,760[ ONLINE REDO LOG ] /u04/oradata/TESTDB/onlinelog/o1_mf_2_19cv5oml_.log 10,485,760[ ONLINE REDO LOG ] /u04/oradata/TESTDB/onlinelog/o1_mf_3_19cv5pt4_.log 10,485,760[ ONLINE REDO LOG ] /u05/oradata/TESTDB/onlinelog/o1_mf_1_19cv5nsf_.log 10,485,760[ ONLINE REDO LOG ] /u05/oradata/TESTDB/onlinelog/o1_mf_2_19cv5p1b_.log 10,485,760[ ONLINE REDO LOG ] /u05/oradata/TESTDB/onlinelog/o1_mf_3_19cv5q8j_.log 10,485,760 --------------sum 1,156,579,328

Startup Scripts

Most Linux / UNIX users have a script used to start and stop Oracle services on system restart. On UNIX platforms, the convention is to put all start / stop commands in a single shell script named dbora. The dbora script may differ on every database server only slightly as each database server has different requirements for handling Apache, TNS listener and other services. The dbora script should be place in /etc/init.d.

In this section, I will provide a dbora shell script that can used to start all required Oracle services including the Oracle Cluster Synchronization Services (CSS), ASM instance, database server(s), and the Oracle TNS listener process. This script will utilize the Oracle supplied scripts $ORACLE_HOME/bin/dbstart and $ORACLE_HOME/bin/dbshut to handle starting and stopping the Oracle database(s). The dbora will be run by the UNIX init process, and reads the /etc/oratab file to dynamically determine which database(s) to start and stop.

Startup Scripts

Many of the above O/S commands will need to be put into a startup script that runs BEFORE the database starts. For my example, I use a file named /etc/init.d/dbora to start the database. I simply add the following command before starting the database: ...

/sbin/losetup /dev/loop1 /asmdisks/_file_disk1; sleep 2/sbin/losetup /dev/loop2 /asmdisks/_file_disk2; sleep 2/sbin/losetup /dev/loop3 /asmdisks/_file_disk3; sleep 2/sbin/losetup /dev/loop4 /asmdisks/_file_disk4; sleep 2

/usr/bin/raw /dev/raw/raw1 /dev/loop1; sleep 2/usr/bin/raw /dev/raw/raw2 /dev/loop2; sleep 2/usr/bin/raw /dev/raw/raw3 /dev/loop3; sleep 2/usr/bin/raw /dev/raw/raw4 /dev/loop4; sleep 2

/bin/chown oracle:dba /dev/raw/raw1/bin/chown oracle:dba /dev/raw/raw2/bin/chown oracle:dba /dev/raw/raw3/bin/chown oracle:dba /dev/raw/raw4

/bin/chmod 660 /dev/raw/raw1/bin/chmod 660 /dev/raw/raw2/bin/chmod 660 /dev/raw/raw3/bin/chmod 660 /dev/raw/raw4

sleep 120

su - $ORACLE_OWNER -c "$ORACLE_HOME/bin/dbstart"

su - $ORACLE_OWNER -c "lsnrctl start listener"

After the dbora shell script is in place, perform the following tasks as the root user:

# chmod 755 dbora# chown root:root dbora

# ln -s /etc/init.d/dbora /etc/rc5.d/S99dbora# ln -s /etc/init.d/dbora /etc/rc0.d/K10dbora# ln -s /etc/init.d/dbora /etc/rc6.d/K10dbora# exit

Modify oratab File

The next step is to edit the /etc/oratab file to allow the dbora script to automatically start and stop databases. Simply alter the final field in the +ASM and TESTDB entry from N to Y.

Ensure that the ASM instance is started BEFORE any databases that are making use of disk groups contained in it.

...+ASM:/u01/app/oracle/product/10.1.0/db_1:YTESTDB:/u01/app/oracle/product/10.1.0/db_1:Y...

Modify /etc/inittab File

The final step to manually edit the script /etc/inittab so that the entry to respawn init.cssd comes before running the runlevel 3.

Orignal /etc/inittab file: (...) # System initialization. si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 (...)

h1:35:respawn:/etc/init.d/init.cssd run >/dev/null 2>&1 </dev/null

Modified /etc/inittab file: (...) # System initialization.

si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 h1:35:respawn:/etc/init.d/init.cssd run >/dev/null 2>&1 </dev/null l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6

(...)

For Solaris users, you will need to manually edit the script /etc/inittab so that the entry for init.cssd comes before running the runlevel 3. As explained in Metalink Note ID: 264235.1, the fix is as follows:

Orignal /etc/inittab file: (...) s2:23:wait:/sbin/rc2 >/dev/msglog 2<>/dev/msglog </dev/console s3:3:wait:/sbin/rc3 >/dev/msglog 2<>/dev/msglog </dev/console s5:5:wait:/sbin/rc5 >/dev/msglog 2<>/dev/msglog </dev/console (...)

h1:3:respawn:/etc/init.d/init.cssd run >/dev/null 2>&1 </dev/null

Modified /etc/inittab file: (...) s2:23:wait:/sbin/rc2 >/dev/msglog 2<>/dev/msglog </dev/console h1:3:respawn:/etc/init.d/init.cssd run >/dev/null 2>&1 </dev/null s3:3:wait:/sbin/rc3 >/dev/msglog 2<>/dev/msglog </dev/console s5:5:wait:/sbin/rc5 >/dev/msglog 2<>/dev/msglog </dev/console

(...)

Bug: 3458327 - Automatic Startup On Reboot Fails When Database Uses ASM

This bug is "NOT" fixed in the 10.1.0.4.0 Patch Set!!!!!!

If you have been following this article and applied the 10.1.0.4 patchset (and modified the /etc/inittab file to force init.cssd to run (actually to respaen) before running runlevel 3), this bug should not affect you. If you are using 10.1.0.3 (and below), however, this bug may not allow the Oracle ASM instance to start, which will also prevent any other instances that have disk groups within that ASM instance to start. As they exist, the dbstart and dbshut scripts are not ASM aware with 10.1.0.3 and below. Even with patchset 10.1.0.4.0, we had to manually modify the /etc/inittab script. When the dbora script attempts to start the ASM database, even after the ocssd.bin is up and running, you will receive the error:

ORA-29701: unable to connect to Cluster Manager

The problem is simply a matter of ordering of when services are started and that is why we needed to modify the /etc/inittab file. Upon entering a certain runlevel

(e.g. runlevel 3), init starts all the 'respawn lines' AFTER the 'wait' lines have finished. It is important to understand that the S96init.cssd lines does not actually start the CSSD, it merely removes the 'NORUN' line. Then S99dbora tries to start the instances (and fails). Then, finally, init starts the CSSD.

Note that I used /etc/rc5.d/S99 to start the dbora script. You should make note that the dbora script MUST run after the /etc/init.d/init.cssd if you are starting an ASM instance. For Linux, the OUI (and manually running localconfig all) places the start for init.cssd as /etc/rc3.d/S96init.cssd.

You will also notice that I had to put a sleep 120 in the dbora script before starting any databases/instances. The dbora script will sleep for 120 seconds to ensure that ocssd.bin daemon is running before starting any ASM instances.

ASM Abbas Practies

Documents

Transcript of ASM Abbas Practies