DOYENSYS Knowledge Portal




We Welcome you to visit our DOYENSYS KNOWLEDGE PORTAL : Doyensys Knowledge Portal




Saturday, June 30, 2018

Adding new diskgroup in ASM

GOAL
Before you add the disk(s) to your production diskgroup, you can use the next steps to validate whether the candidate disk(s) is/are in good shape and can be accessed from each node (without harm the existing production diskgroups), as follow:

SOLUTION

1) As Oracle or Grid OS user, run the next commands on each node (if ASMLIB API is used):
# /etc/init.d/oracleasm  scandisks  #(only this command needs to be executed as root user)
$> id
$> /etc/init.d/oracleasm  listdisks
$> /etc/init.d/oracleasm  querydisk <each disk from previous output>
Note: All the disks must be visible from each node.

2) Confirm the disks are visible (I/O) at OS level (as oracle or grid OS user) from each node:
$> id
$> ls -l  <disk name>
$> dd if=<raw/character or block partition device in  question> of=/dev/null count=100 bs=8192
Example:
$> dd if=/dev/raw/raw1 of=/dev/null count=100 bs=8192  # raw device
$> dd if=/dev/oracleasm/disks/PRODA07 of=/dev/null count=100 bs=8192  # ASMLIB device
$> dd if=/dev/rdsk/c1t3d0s6 of=/dev/null count=100 bs=8192 # raw device

3) Verify that kfed can read on the candidate disk(s) at OS level (as oracle or grid OS user) from each node
$> kfed read  <raw/character or block partition device in question>

Example:
$> kfed read /dev/raw/raw1
$> kfed read /dev/oracleasm/disks/PRODA07
$> kfed read /dev/rdsk/c1t3d0s6

Note: If the disk is not a FORMER disk, then kfed on new disks will return:    kfbh.type: 0 ; 0x002: KFBTYP_INVALID and that is expected.

 4) Create a new temporary diskgroup:
SQL> CREATE DISKGROUP TEST EXTERNAL REDUNDANCY DISK '<YOUR CANDIDATE DISK>';

5) Check if the diskgroup is created and mounted:
SQL> SELECT STATE, NAME FROM V$ASM_DISKGROUP;

6) If so, then manually mount it on the other ASM instance(s):
SQL> ALTER DISKGROUP TEST MOUNT;
SQL> SELECT STATE, NAME FROM V$ASM_DISKGROUP;

7) If the previous steps had success and the TEST diskgroup can be successfully mounted (on each ASM instance), then drop the TEST diskgroup as follow:
SQL> alter diskgroup test dismount; --(from all the ASM instances, except from one).
SQL> DROP DISKGROUP TEST; --(from the ASM instance, which the diskgroup is still mounted).

8) Then the candidate disk is ready to be added to the desired diskgroup:
SQL> ALTER DISKGROUP <my production diskgroup> ADD DISK '<your candidate disk>';

Note: The same disks validation steps are also required for ASM Standalone configurations.

No comments: