Oracle 11g ASM is capable of repairing
broken blocks on the fly when reading them. When Oracle
finds a broken block, it attempts to read it from the mirror
copy of the respective extent and repairs the broken version
automatically. This can only happen on disk groups with at
least normal redundancy and it only happens for those blocks
which are read.
The new remap command of
asmcmd can be used to recover a range of unreadable
blocks. ASM would read a bad block from the good copy and
restore it to a new location on the disk. This can
also be run from the enterprise manager interface.
ASM Disk Group Checks Enhanced
The check command was already available
in Oracle ASM 10g. It was necessary there to specify what to
check with the check command. As of Oracle ASM 11g, this
command has been simplified. It is not necessary to specify
any more what to check because the command makes all
available checks in one go now. The CHECK keyword performs
the following operations without the need for
Checks if the disk is consistent
Cross checks the file extent maps and
allocation tables for consistency
Checks if the metadata of the
directories for alias and files are linked correctly
Checks if the directory tree of the
aliases is linked correctly.
Checks that ASM metadata directories do
not have unreadable allocated blocks.
AS SYSDBA @ +ASM SQL> ALTER DISKGROUP data CHECK;
The above as well as the below command
issued in an ASM instance would check all disks in the disk
group and add a message into the ASM instance's alert log
file with information about the successful run of the check
and about found broken blocks. In addition, these commands
would also recover the bad blocks. The repair option is the
DEFAULT for the check command.
SYSDBA @ +ASM SQL> ALTER DISKGROUP data CHECK REPAIR;
The next command would only check for
bad blocks but not recover them.
AS SYSDBA @ +ASM SQL> ALTER DISKGROUP data CHECK NOREPAIR;
[oracle@rhas4 ~]$ tail -f /u01/app/oracle/diag/asm/+asm/+ASM/alert/log.xml
The below listing shows the message in
the xml version of the alter log of the ASM instance:
<txt>SUCCESS: check of
diskgroup DATA found no errors
<msg time='2007-10-22T10:26:33.700+02:00' org_id='oracle'
client_id='' type='UNKNOWN' level='16'
<txt>SUCCESS: ALTER DISKGROUP DATA CHECK
The full check for all metadata packages
into one single command makes the checks easier, but the
drawback is the additional overhead which is burdening the
I/O subsystem now and might slow down performance.
ASM storage is described in a number
of so called fixed tables. It is possible to view
important parts of this metadata via (g)v$views
which, in fact, read the information from these
x$tables. In 11gR1, there are 28 x$tables which
fully describe the ASM storage and there are 22 v$views
which show information about ASM.
Some important x$tables are:
x$kffxpi: mapping between files
and allocation units
relationship of two disks
of a given ASM diskgroup which hold a mirror copy of the
x$kfdat: details of all free
and used allocation units
List of Dynamic Performance Views
related to ASM:
SYS AS SYSDBA @ +ASM SQL> select view_name from
2 where view_name like '%ASM%';
22 rows selected.
List of Fixed Tables related to ASM:
SYS AS SYSDBA @ +ASM SQL> select name from v$fixed_table
where name like 'X$KF%';
28 rows selected.