Archive

Posts Tagged ‘filesystem’

vxfs extendfs: Invocation of the fsck program terminated abnormally

September 20th, 2009 2 comments

You will see this message in case you interrupt the extendfs command. I my case I passed block device as an argument to the extendfs command and waited for several minutes (usually it takes one or two) then I remembered that the command expects character device. I read some opinions in Internet and some of them were really horrifying, like: “Well, when you passed block device to extendfs you have to format it and  restore the filesystem from backup“.

Yes, it was stupid to press Ctrl-C, but when people panic they don’t think normally.
root@host:/# extendfs -F vxfs /dev/vg00/lvora

vxfs extendfs: Invocation of the fsck program terminated abnormally.
The file system is marked bad.  Run full fsck manually.
(e.g. fsck -F vxfs /dev/vg00/lvora)

Next step was to make a normal filesystem check:
root@host:/# fsck /dev/vg00/lvora
log replay in progress
log replay failed to clean file system
file system is not clean, full fsck required
full file system check required, exiting …

Mount also says that the filesystem is corrupted:
root@host:/# mount /oracle

vxfs mount: /dev/vg00/lvora is corrupted. needs checking

After reading some manuals and opinions I saw that in this version of HP-UX it doesn”t matter what device is passed because extendfs accepts both. Luckily fsck fixes the problem:
root@host:/root# fsck -y -F vxfs /dev/vgora/lvtest
log replay in progress
log replay failed to clean file system
file system is not clean, full fsck required
pass0 – checking structural files
pass1 – checking inode sanity and blocks
pass2 – checking directory linkage
pass3 – checking reference counts
pass4 – checking resource maps
au 0 summary incorrect – fix? (ynq)y
au 1 summary incorrect – fix? (ynq)y
au 2 summary incorrect – fix? (ynq)y
au 3 summary incorrect – fix? (ynq)y
au 4 summary incorrect – fix? (ynq)y
au 5 summary incorrect – fix? (ynq)y
………………….
au 3500 summary incorrect – fix? (ynq)y
au 3501 summary incorrect – fix? (ynq)y
au 3502 summary incorrect – fix? (ynq)y
au 3503 summary incorrect – fix? (ynq)y
au 3504 summary incorrect – fix? (ynq)y
au 3505 emap incorrect – fix? (ynq)y
au 3505 summary incorrect – fix? (ynq)y
au 3506 emap incorrect – fix? (ynq)y
au 3506 summary incorrect – fix? (ynq)y
au 3507 emap incorrect – fix? (ynq)y
au 3507 summary incorrect – fix? (ynq)y
…………………
au 4653 summary incorrect – fix? (ynq)y
au 4654 emap incorrect – fix? (ynq)y
au 4654 summary incorrect – fix? (ynq)y
au 4655 emap incorrect – fix? (ynq)y
au 4655 summary incorrect – fix? (ynq)y
free block count incorrect 1292071477 expected 39009935 fix? (ynq)y
free extent vector incorrect fix? (ynq)y
OK to clear log? (ynq)y
set state to CLEAN? (ynq)y

After fsck finishes the filesystem is extended and it can be mounted:
root@host:/root# mount /dev/vgora/lvtest /mnt
root@host:/root#

Next step was to make a normal filesystem check:
root@isengard:/# extendfs -F vxfs /dev/vg00/lvora
Categories: hp-ux Tags:

Changing physical path of ASM disk group

August 11th, 2009 3 comments

The purpose of this document is to show that changing the psyhical path of ASM disk MEMBERS is possible and there is no risk.

For the purpose of the test, we create one logical volume called lvora and we grant ownership of this file to oracle:
root@node1:/# lvcreate -n lvora -L 1024 vg00
root@node1:/# chown oracle:dba /dev/vg00/rlvora

Start DBCA and create ASM instance:
– set sys password
– set data group name to DATA
– set redundancy to External
– set Disk Discovery Path to /dev/vg00/rlv*

At this stage only /dev/vg00/rlvora is CANDIDATE disk for disk group with size of 1 Gb.
Select the disk and create the disk group. Now we have one mounted disk group called DATA with external redundancy and
using /dev/vg00/rlvora as a MEMBER of the disk group.

To simulate changing (or failure) of the physical disk or even moving data from one physical disk to another we used dd
to copy raw data from /dev/vg00/rlvora to /dev/rdsk/c0t2d0 and then we delete the logical volume.

We shutdown the ASM instance and copy the contents of the logical volume to the raw physical disk using dd:

oracle@node1:/home/oracle$ export ORACLE_HOME=/oracle/ora10g
oracle@node1:/home/oracle$ export ORACLE_SID=+ASM
oracle@node1:/home/oracle$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Thu Dec 13 01:50:38 2007

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Connected to:
Oracle Database 10g Release 10.2.0.1.0 - 64bit Production
With the Real Application Clusters option

SQL> select GROUP_NUMBER, NAME, STATE, TYPE from v$asm_diskgroup;

GROUP_NUMBER NAME                           STATE       TYPE
------------ ------------------------------ ----------- ------
1 DATA                           MOUNTED     EXTERN

SQL> select GROUP_NUMBER, DISK_NUMBER, MODE_STATUS, STATE, NAME, PATH from v$asm_disk;

GROUP_NUMBER DISK_NUMBER MODE_ST STATE    NAME      PATH
------------ ----------- ------- -------- --------- ----------------
1             0          ONLINE  NORMAL   DATA_0000 /dev/vg00/rlvora

SQL> shutdown immediate
ASM diskgroups dismounted
ASM instance shutdown
SQL>  exit

oracle@node1:/home/oracle$ exit

root@node1:/root# chown oracle:dba /dev/rdsk/c0t2d0

root@node1:/root# dd if=/dev/vg00/rlvora of=/dev/rdsk/c0t2d0 bs=1024k
1024+0 records in
1024+0 records out
root@node1:/root#  lvremove /dev/vg00/lvora
The logical volume "/dev/vg00/lvora" is not empty;
do you really want to delete the logical volume (y/n) : y
Logical volume "/dev/vg00/lvora" has been successfully removed.
Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg00.conf

We have moved data to /dev/rdsk/c0t2d0 and we have removed the logical volume.

Now if you try to mount the disk group or start the instance you will get the following error:

oracle@node1:/home/oracle$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Thu Dec 13 02:05:48 2007

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup
ASM instance started

Total System Global Area  130023424 bytes
Fixed Size                  1991968 bytes
Variable Size             102865632 bytes
ASM Cache                  25165824 bytes
ORA-15032: not all alterations performed
ORA-15063: ASM discovered an insufficient number of disks for diskgroup "DATA"

SQL> select GROUP_NUMBER, NAME, STATE, TYPE from v$asm_diskgroup;

no rows selected

SQL> select GROUP_NUMBER, DISK_NUMBER, MODE_STATUS, STATE, NAME, PATH from v$asm_disk;

no rows selected

SQL> show parameter diskstring

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
asm_diskstring                       string      /dev/vg00/rlv*

As you can seen the discovery path is still pointing to /dev/vg00/rlv*, now we will change disk discovery path by pointing asm_diskstring parameter to the new location of the disk and we will mount the ASM instance:

SQL> alter system set asm_diskstring='/dev/rdsk/*' scope=both;

System altered.

SQL> select GROUP_NUMBER, DISK_NUMBER, MODE_STATUS, STATE, NAME, PATH from v$asm_disk;

GROUP_NUMBER DISK_NUMBER MODE_ST STATE    NAME      PATH
------------ ----------- ------- -------- --------- ----------------
0            0           ONLINE  NORMAL             /dev/rdsk/c0t2d0

SQL> alter diskgroup data mount;

Diskgroup altered.

SQL> select GROUP_NUMBER, DISK_NUMBER, MODE_STATUS, STATE, NAME, PATH from v$asm_disk;

GROUP_NUMBER DISK_NUMBER MODE_ST STATE    NAME      PATH
------------ ----------- ------- -------- --------- ----------------
1            0           ONLINE  NORMAL   DATA_0000 /dev/rdsk/c0t2d0

SQL> select GROUP_NUMBER, NAME, STATE, TYPE from v$asm_diskgroup;

GROUP_NUMBER NAME                           STATE       TYPE
------------ ------------------------------ ----------- ------
1 DATA                           MOUNTED     EXTERN

SQL> show parameter diskstring;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
asm_diskstring                       string      /dev/rdsk/*

Final test to show that the changes are applied:

SQL> shutdown immediate
ASM diskgroups dismounted
ASM instance shutdown
SQL> startup
ASM instance started

Total System Global Area  130023424 bytes
Fixed Size                  1991968 bytes
Variable Size             102865632 bytes
ASM Cache                  25165824 bytes
ASM diskgroups mounted
SQL> exit
Disconnected from Oracle Database 10g Release 10.2.0.1.0 - 64bit Production
With the Real Application Clusters option
oracle@node1:/home/oracle$

Conclusion
ASM does not keep track of the physical disks of the data groups. Said in other way it does not matter the path or the mminor, major numbers of the physical disks, because the metadata is kept on the disk itself and there is nothing in the dictionary. When you start ASM instance it scans the disks based on the parameter asm_diskstring and reads the header information of the discovered disks.

Categories: hp-ux, oracle Tags: , ,