Diskgroup Cannot be Mounted

Diskgroups that have not been mounted result in relational database management system (RDBMS) instances not being able to start up. When diskgroups do not get 
mounted, this typically is a result of discovering an insufficient number of disks make up the diskgroup.
To troubleshoot unmounted diskgroup problems, check the following:

1.  Check on all nodes of an RAC cluster whether the ASM_DISKSTRING parameter matches the disk path.
2.  Perform. a query against the V$ASM_DISK view (on the ASM instance) to determine which disks were discovered and their respective states. 
3.  Make sure that the operating system (OS) permissions on the underlying device are both readable and writable by ASM on all nodes of an RAC cluster.
4.  Make sure that there are not duplicate paths or names that point to the same physical disk. Such duplication results in the following error message:
    ORA-15020: discovered duplicate ASM disk "DATA_0000"
    If there are duplicate paths, ASM reports them in the alert log but otherwise ignores them.
5.  Make sure that the disk device is on a valid OS partition that does not include the volume table of contents (VTOC).
6.  If you are using ASMLIB, make sure that the ASMLIB listdisks commands list all required disks. Also make sure that that ASMLIB 
    scandisk returns OK, and that the correct library-specific discovery 
    string is used––that is, the string should be left at its default value or set to 
    ORCL:*. See Chapter 6 for more details on ASMLIB.
7.  For Windows systems, ensure that ASM disk devices are visible by the Windows OS. It’s a best practice to enable automount using the diskpart
    utility so that Windows can see the disks upon reboot.
8.  Make sure to stamp the Windows disks with the asmtool.

    If  an ORA-15063 error is incurred, users will be unable to get the diskgroup 
    mounted or dropped, as in the following example:
SQL> ALTER DISKGROUP DATA mount; 
ALTER DISKGROUP DATA  mount 
*
ERROR at line 1: 
ORA-15032: not all alterations performed 
ORA-15063: diskgroup "DATA" lacks quorum of 1 PST disks; 0 found
The main issue here is that users need to get this diskgroup dropped so that they can use the disks in another diskgroup or repurpose them. In Oracle Database 10g,
a diskgroup must be mounted before it is dropped. If you are certain that the disk will not be needed again, then there are several ways to reclaim this disk:
1.  You can use dd to write a block of zeroes on the disk header in block 0.
2.  A safer option is  creating a new diskgroup using all the disks in the old 
diskgroup with the FORCE option. The following steps would be one way to accomplish this.
SQL > CREATE DISKGROUP DATA EXTERNAL REDUNDANCY
DISK 'ORCL:VOLUME1' FORCE
DISK 'ORCL:VOLUME2' FORCE;

For Oracle Database 11g, the diskgroup can be forcibly dropped using the DROP DISKGROUP FORCE command. For force drop to succeed, the diskgroup cannot be mounted anywhere in the cluster.

An ORA-15072 error message may be displayed for an external diskgroup, as in the following example:
SQL > CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK 'ORCL:VOLUME1' SIZE 34816M;
CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK 'ORCL:VOLUME1' SIZE 34816M
*
ERROR at line 1:
ORA-15018: diskgroup cannot be created
ORA-15072: command requires at least 1 failure groups, discovered only 0
SQL> SELECT STATE, HEADER_STATUS, SUBSTR (NAME,1,12) NAME, FREE_MB, SUBSTR(PATH,1,16) 
PATH FROM V$ASM_DISK;
STATE    HEADER_STATU NAME            FREE_MB PATH
-------- ------------ ------------ ---------- ----------------
NORMAL   PROVISIONED                        0 ORCL:VOLUME2
NORMAL   MEMBER       VOLUME1           34766 ORCL:VOLUME1
NODE2_SQL> SELECT STATE, HEADER_STATUS, SUBSTR(NAME,1,12) NAME, FREE_MB, 
SUBSTR (PATH,1,16) PATH FROM V$ASM_DISK;
STATE    HEADER_STATU NAME            FREE_MB PATH
-------- ------------ ------------ ---------- ----------------
NORMAL   UNKNOWN                            0 ORCL:VOLUME2
NORMAL   UNKNOWN                            0 ORCL:VOLUME1
If you see UNKNOWN in the HEADER_STATUS, then you have not discovered correctly. This is commonly because the scan order is not set up correctly for ASMLIB and multipathing.
Although initially the error message may seem misleading for an external redundancy diskgroup, the error message is accurate because you are creating a 
diskgroup with an unknown disk type––a null device––and you need at least one device to create a diskgroup.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/46907/viewspace-696145/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/46907/viewspace-696145/