What is the implication of the results of the query?

As the DBA, you run the following query on your ASM instance. What is the implication of
the results of the query? (Choose two.)
SQL> select group_number, name, state from v$ASM_DISKGROUP;
GROUP_NUMBER NAME STATE
============ ======= ==========
0 DGROUP1 DISMOUNTED
2 DGROUP2 MOUNTED
3 DGROUP3 MOUNTED

As the DBA, you run the following query on your ASM instance. What is the implication of
the results of the query? (Choose two.)
SQL> select group_number, name, state from v$ASM_DISKGROUP;
GROUP_NUMBER NAME STATE
============ ======= ==========
0 DGROUP1 DISMOUNTED
2 DGROUP2 MOUNTED
3 DGROUP3 MOUNTED

A.
The DGROUP1 disk group was unmounted by another DBA.

B.
A datafile has been lost, causing the ASM disk group DGROUP1 to go into the
DISMOUNTED state

C.
One of the redundant disks (DGROUP1) has been lost in a disk group.

D.
This query has no meaning in an ASM instance.

E.
A disk associated with a disk group was discovered after the ASM instance initially
opened.



Leave a Reply 2

Your email address will not be published. Required fields are marked *


Eamon

Eamon

In my opinion, the correct answers are A and E.

I am sure that anyone could prove that answer A is correct by taking a look at the documentation.

usually “disks discovery” is run via the ASM_DISKSTRING init parameter at ASM startup.
However if you query V$ASM_DISK or V$ASM_DISKGROUP ASM does another “disks discovery”. In this case it could find a disk that is associated with another disk group (that somebody just plugge d in). Hence I can only assume that E is also correct.

Eamon

Eamon

By the way the explanation given by the book where this question is set is as follows

COrrect answers are A and E. Apparently, for some reason DGROUP1 was not mounted when the ASM instance was started, or the disk was missing and then reappeared (hardware failure perhaps) after the ASM instance was started. ASM will discover new disks, even after the ASM instance is opened.