So after fixing he broken ASM install in my last post i wanted to see how the disks/diskgroups should be removed 'cleanly'. First up lets try removing one of the devices i just added (this will just remove the disk from the disk group) any extents that contain data will be moved to other disks with free space for this.
SQL> alter diskgroup data drop disk '/dev/raw/raw3';
alter diskgroup data drop disk '/dev/raw/raw3'
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15054: disk "/DEV/RAW/RAW3" does not exist in diskgroup "DATA"
Hmm so it seems the dik name i used to add the device is not the same name i can use to drop it - slightly odd but lets use the 'ASM' name it was given.
SQL> alter diskgroup data drop disk DATA_0002;
Diskgroup altered.
SQL>
OK so that worked - lets try removing all the rest
SQL> alter diskgroup data drop disk DATA_0002;
Diskgroup altered.
SQL> c/2/1
1* alter diskgroup data drop disk DATA_0001
SQL> /
Diskgroup altered.
SQL> c/1/0
1* alter diskgroup data drop disk DATA_0000
SQL> /
Diskgroup altered.
SQL> c/DATA_0000/DATA_0003
1* alter diskgroup data drop disk DATA_0003
SQL> /
Diskgroup altered.
SQL> c/3/4
1* alter diskgroup data drop disk DATA_0004
SQL> /
alter diskgroup data drop disk DATA_0004
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15250: insufficient diskgroup space for rebalance completion
So all goes well until the last disk as there are no other disks to move its extents too - we know there is nothing on it anyway so lets go ahead and drop the whole diskgroup.
SQL> drop diskgroup data;
Diskgroup dropped.
Ok that's all tidied up - but i thought i had put my spfile inside ASM itself so how can that have dropped surely it would have stopped me - lets check what spfile is set to
SQL> sho parameter spfile
spfile string /oracle/product/12.1.0/grid/dbs/spfile+ASM.ora
Ah - so it seems when i thought my 'create spfile from pfile' command would auto create it in ASM it didn't if just put it in the default disk directory. If i want it inside ASM then i need to give a location of '+DATA' to the command.
This means we can just leave the spfile outside ASM - with single instance i don;t see much benefit of the file being inside ASM, but in a cluster of course it makes sense - otherwise you have an spfile on each node.
(as an aside - this whole chicken and egg scenario about the asm spfile being inside asm - there is a nice description here of how oracle is working http://blog.trivadis.com/b/robertbialek/archive/2012/07/04/oracle-asm-spfile-stored-in-an-asm-disk-group-how-it-works.aspx )
Lets now drop the FRA disk group in one shot
SQL> drop diskgroup fra;
Diskgroup dropped.
SQL>
OK - so now everything should be 'released' from ASM - lets see what the status in v$asm_disk is
SQL> l
1* select header_status,STATE,OS_MB,TOTAL_MB,FREE_MB,NAME,LABEL,PATH from v$asm_disk
SQL> /
FORMER NORMAL 61441 0 0 /dev/raw/raw3
FORMER NORMAL 61441 0 0 /dev/raw/raw2
FORMER NORMAL 61441 0 0 /dev/raw/raw6
FORMER NORMAL 61441 0 0 /dev/raw/raw7
FORMER NORMAL 61441 0 0 /dev/raw/raw4
FORMER NORMAL 61441 0 0 /dev/raw/raw1
FORMER NORMAL 61441 0 0 /dev/raw/raw5
So all the disks are back to how they were before i started - the only difference being they show with a header_status of 'FORMER' as the blocks have previously been formatted for use by ASM.
So far ASM is proving easier than i remember it being......
Comments
Post a Comment