Maintaining Disk Groups
This section discusses maintenance operations performed on disk groups.
This section contains the following topics:
Mounting and Dismounting Disk Groups
Disk groups that are specified in the ASM_DISKGROUPS
initialization parameter are mounted automatically at Oracle ASM instance startup. This process makes the disk groups available to all database instances running on the same node as Oracle ASM. The disk groups are dismounted at Oracle ASM instance shutdown. Oracle ASM also automatically mounts a disk group when you initially create it, and dismounts a disk group if you drop it.
When a disk group is mounted, a disk group number is chosen. This number may change across disk group mounts. A disk group number is not recorded in any persistent structure, but the current value can be viewed in the GROUP_NUMBER
column of the V$ASM
views.
When you want to mount or dismount disk groups manually, use the ALTER DISKGROUP...MOUNT
or ALTER DISKGROUP...DISMOUNT
statement. You can mount or dismount disk groups by name, or specify ALL
. You can also specify the optional FORCE
option. For information about using the FORCE
option, refer to Mounting Disk Groups Using the FORCE Option.
If you try to dismount a disk group that contains open files, the statement fails, unless you also specify the FORCE
clause.
In a clustered Oracle ASM environment in RESTRICTED
mode, a disk group is mounted in single-instance exclusive mode. No other Oracle ASM instance in that cluster can mount that disk group. In this mode the disk group is not usable by any Oracle ASM client. Use this mode to perform a fast rebalance.
The following SQL statement dismounts all disk groups that are currently mounted to the Oracle ASM instance:
ALTER DISKGROUP ALL DISMOUNT;
The following SQL statement mounts disk group data1
:
ALTER DISKGROUP data1 MOUNT;
Mounting Disk Groups Using the FORCE Option
Oracle ASM provides a MOUNT
FORCE
option with ALTER
DISKGROUP
to enable Oracle ASM disk groups to be mounted in normal or high redundancy modes even though some Oracle ASM disks may be unavailable to the disk group at mount time.
The default behavior without the FORCE
option is to fail to mount a disk group that has damaged or missing disks.
The MOUNT
FORCE
option is useful in situations where a disk is temporarily unavailable and you want to mount the disk group with reduced redundancy while you correct the situation that caused the outage.
To successfully mount with the MOUNT
FORCE
option, Oracle ASM must be able to find at least one copy of the extents for all of the files in the disk group. In this case, Oracle ASM can successfully mount the disk group, but with potentially reduced redundancy.
The disks that Oracle ASM cannot access are placed in an offline mode. Oracle ASM then begins timing the period that these disks are in an offline mode. If the disk offline time period exceeds the timer threshold set by DISK_REPAIR_TIME
disk group attribute, then those disks are permanently dropped from the disk group. You can change the offline timer after a disk is put in an offline state by using the ALTER
DISKGROUP
OFFLINE
statement.
Note:
An Oracle ASM instance mounts an incomplete disk group differently depending on the specified compatibility.
In clustered Oracle ASM environments, if an Oracle ASM instance is not the first instance to mount the disk group, then using the MOUNT
FORCE
statement fails. This is because the disks have been accessed by another instance and the disks are not locally accessible.
If all disks are available, then using the FORCE
option causes the MOUNT
command to fail. This discourages unnecessary and improper use of the feature.
The following example shows how to use the FORCE
option to force the mount of the data1
disk group:
SQL> ALTER DISKGROUP data1 MOUNT FORCE;
See Also:
-
Oracle ASM Fast Mirror Resync for more information about setting the
DISK_REPAIR_TIME
disk group attribute -
Features Enabled By Disk Group Compatibility Attribute Settings for information features enabled by disk group compatibility attributes
-
Oracle Database SQL Language Reference for additional information about the
ALTER
DISKGROUP
statement and theFORCE
option
Checking the Internal Consistency of Disk Group Metadata
You can check the internal consistency of disk group metadata using the ALTER
DISKGROUP
statement with the CHECK
keyword. You can use this statement to check specific files in a disk group, specific disks or all disks in a disk group, or specific failure groups within a disk group. The disk group must be mounted to perform these checks.
By default, the CHECK
DISK
GROUP
clause verifies all of the metadata directories. Oracle ASM displays summary errors and writes the details about the errors in an alert log. The CHECK
keyword performs the following operations:
-
Verifies the consistency of the disk
-
Cross checks all of the file extent maps and allocation tables for consistency
-
Checks that the alias metadata directory and file directory are linked correctly
-
Verifies that the alias directory tree is linked correctly
-
Checks that Oracle ASM metadata directories do not have unreachable allocated blocks
The REPAIR
|
NOREPAIR
clause specifies whether Oracle ASM should attempt to repair errors that are found during the check. The default is NOREPAIR
. Use the NOREPAIR
clause to receive alerts about inconsistencies and to suppress Oracle ASM from resolving the errors automatically. The following example statement checks for consistency in the metadata for all disks in the data1
disk group:
ALTER DISKGROUP data1 CHECK ALL;
See Also:
The Oracle Database SQL Language Reference for additional information about the CHECK
clause syntax
Dropping Disk Groups
The DROP
DISKGROUP
statement enables you to delete an Oracle ASM disk group and optionally, all of its files.
You can specify the INCLUDING
CONTENTS
clause if you also want to delete all files that are contained in the disk group. The default is EXCLUDING
CONTENTS
, which provides syntactic consistency and prevents you from dropping the disk group if it has any contents
The Oracle ASM instance must be started and the disk group must be mounted with none of the disk group files open, in order for the DROP DISKGROUP
statement to succeed. The statement does not return until the disk group has been dropped.
When you drop a disk group, Oracle ASM dismounts the disk group and removes the disk group name from the ASM_DISKGROUPS
initialization parameter if a server parameter file is being used. If a text initialization parameter file is being used, and the disk group is mentioned in the ASM_DISKGROUPS
initialization parameter, then you must remove the disk group name from the ASM_DISKGROUPS
initialization parameter before the next time that you shut down and restart the Oracle ASM instance.
The following statement deletes data1
:
DROP DISKGROUP data1;
After ensuring that none of the files contained in data1
are open, Oracle ASM rewrites the header of each disk in the disk group to remove Oracle ASM formatting information. The statement does not specify INCLUDING CONTENTS
, so the drop operation fails if the disk group contains any files.
If an Oracle Automatic Storage Management Cluster File System (Oracle ACFS) file system is mounted on a volume contained in the disk group, then the file system must be dismounted. If the file system has been registered, then it must be deregistered. The INCLUDING
CONTENTS
clause must be used to drop this disk group. All data in the file system is destroyed. To view the volumes and mount paths associated with a disk group, you can query the V$ASM_VOLUME
view.
If you cannot mount a disk group but must drop it, you can use the FORCE
option of the DROP
DISKGROUP
statement. This command enables you to remove the headers on disks that belong to a disk group that cannot be mounted by any Oracle ASM instances as shown in the following example:
SQL> DROP DISKGROUP data1 FORCE;
The disk group on which you perform this operation should not be mounted anywhere in the cluster. When you use the FORCE
option, the Oracle ASM instance does not attempt to verify that a disk group is being used by another Oracle ASM instance in the same storage subsystem.
Note:
Use the FORCE
option with extreme caution.
You can also drop disks from a disk group with ASMCA.
See Also:
-
Example 12-9 for an example of a query on the
V$ASM_VOLUME
view -
Deregistering, Dismounting, and Disabling Volumes and Oracle ACFS File Systems for information about deregistering and dismounting Oracle ACFS file systems
-
Managing Disk Groups with ASMCA for information about ASMCA
Renaming Disks Groups
The renamedg
tool enables you to change the name of a cloned disk group. The disk group must be dismounted on all nodes in the cluster before running renamedg
on the disk group.
renamedg
renames a disk group using a two-step process:
-
Phase one
This phase generates a configuration file to be used in phase two.
-
Phase two
This phase uses the configuration file to perform the renaming of the disk group.
The syntax is:
renamedg {-help | help=true} renamedg [phase={one|two |both}] dgname=diskgroup newdgname=newdiskgroup [config=configfile] [asm_diskstring=discoverystring, discoverystring ...] [clean={true|false}] [check={true|false}] [confirm={true|false}] [verbose={ true|false}] [keep_voting_files={true|false}]
-
phase=
{one
|two
|both
}Specifies the phase to be run. Allowed values are
one
,two
, orboth
. This argument is optional. The default isboth
.Typically you would run both phases. If a problem occurs during the second phase, then you can rerun phase
two
using the generated configuration file. -
dgname=
diskgroup
Specifies the name of the disk group to be renamed.
-
newdgname=
newdiskgroup
Specifies the new name for the disk group.
-
config=
configfile
Specifies the path to the configuration file to be generated during phase one or specifies the path to the configuration file to be used during phase two.
This argument is optional. The default configuration file is named
renamedg_config
and is located in the directory in which the command is run. The single quotations may be required on some platforms. -
asm_diskstring=
discoverystring
,
discoverystring
...Specifies the Oracle ASM discovery strings. The
asm_diskstring
value must be specified if the Oracle ASM disks are not in the default location for the platform. The single quotations may be required on some platforms, usually when wildcard characters are specified. -
clean=
{true
|false
}Specifies whether to clean errors that are otherwise ignored. The default is
true
. -
check=
{true
|false
}Specifies a boolean value that is used in the second phase. If
true
, then the tool prints the list of changes that are to be made to the disks. No writes are issued. It is an optional parameter that defaults tofalse
. -
confirm=
{true
|false
}Specifies a boolean value that is used in the second phase. If
false
, then the tool prints the changes that are to be made and seeks confirmation before actually making the changes. It is an optional value that defaults tofalse
. If check is set totrue
, then the value of this parameter is redundant. -
verbose=
{true
|false
}Specifies verbose execution when
verbose=true
. The default isfalse
. -
keep_voting_files=
{true
|false
}Specifies whether voting files are kept in the renamed disk group. The default is
false
which deletes the voting files from the renamed disk group.
Note:
renamedg
does not update resources, nor does renamedg
update any file references within the database. Because of this behavior, the original disk group resource is not automatically deleted after the completion of phase two
. The status of the old disk group resource can be checked with the Oracle Clusterware Control (CRSCTL) crsctl
stat
res
-t
command and then manually deleted with the Server Control Utility (SRVCTL) srvctl
remove
diskgroup
command.
Example 4-12 shows several examples of the use of renamedg
. The first example renames the fra1
disk group to fra2
using a disk string to locate the disks and the verbose
option is enabled. The second example only creates a configuration file during the completion of phase one
of the renamedg
operation. The third example runs phase two
of the renamedg
operation using a configuration file generated from a phase one
execution of renamedg
.
After renaming a disk group, you can rename the disks in the disk group to match the new disk group name. For example:
SQL> ALTER DISKGROUP fra2 RENAME DISKS ALL;
For information about renaming disks, refer to Renaming Disks in Disk Groups.
Example 4-12 Using renamedg
$ renamedg dgname=fra1 newdgname=fra2 asm_diskstring='/devices/disk*' verbose=true $ renamedg phase=one dgname=fra1 newdgname=fra2 asm_diskstring='/devices/disk*' config=/tmp/fra2.conf verbose=true $ renamedg phase=two dgname=fra1 newdgname=fra2 config=/tmp/fra2.conf verbose=true