93 The ORACLE_SID environment variable is set to +ASM. ASMLIB is not used in the configuration. You

93
The ORACLE_SID environment variable is set to +ASM. ASMLIB is not used in the configuration. You
executed the following command to startup the Automatic Storage Management (ASM) instance. SQL>
STARTUP;
Which two activities are performed during a successful start up operation? (Choose two.)
A. The databases configured to use the ASM instance are mounted
B. The disk groups are mounted as per the ASM_DISKGROUPS initialization parameter
C. ASM starts the Oracle Cluster Synchronization Services (CSS) daemon if it is not started
D. ASM discovers and examines the contents of all files that are in the paths specified in the

ASM_DISKGROUPS initialization parameters

Correct Answer: BC
Section: (none)
Explanation

Explanation/Reference:

Explanation:
There is only 1 good answer.. D would be correct if ASM_DISKGROUPS is replaced with
ASM_DISKSTRING ASM does not start CSS it may prompt user to run local config add to start CSS
service.
http://download.oracle.com/docs/cd/B14117_01/server.101/b10739/storeman.htm#i1013975
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:
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.