Mirroring or Redundancy protects data integrity by storing copies of data on multiple disks. To achieve mirroring ,Oracle introduce concept of Diskgroup in Automatic Storage Management.
Oracle mirrors at the extent level, so you have a primary extent and a mirrored extent.When a disk fails, ASM rebuilds the failed disk using mirrored extents from the other disks within the group, this may have a slight impact on performance as the rebuild takes place.
A diskgorup is a group of fail groups together, a fail group is a group of disks together. So, disk is the minimum identity in this architecture.The disk group type determines the mirroring levels with which Oracle creates files in a disk group.In general, ASM supports three types of redundancy (mirroring*) options.When you create a disk group, you specify an Automatic Storage Management (ASM) disk group type based on one of the following three redundancy levels.The default mirroring levels indicate the mirroring level with which each file is created unless a different mirroring level is designated.
Mirroring Options for ASM Disk Group Types
External redundancy - doesn't have failure groups and thus is effectively a no-mirroring strategy, which is used when mirroring is provided by the disk subsystem such as RAID.Any write error cause a forced dismount of the disk group.
The redundancy level controls how many disk failures are tolerated without dismounting the diskgroup or losing data.There are always failure groups even if they are not explicitly created. If you do not specify a failure group for a disk, then Oracle automatically creates a new failure group containing just that disk. A normal redundancy disk group must contain at least two failure groups. A high redundancy disk group must contain at least three failure groups. However, Oracle recommends using several failure groups.
Below is an example of disk group,
Let's assume, we have two disk controllers at Hardware level .Controller 1 (have four disk connected from diska), Controller 2 (have four disk connected from diskb). If, controller will fail, all disks under it will be unavailable. So, we need to plan our Disk group to take case this as well.
Controller 1:
/devices/diska1
/devices/diska2
/devices/diska3
/devices/diska4
Controller 2:
/devices/diskb1
/devices/diskb2
/devices/diskb3
/devices/diskb4
creates a disk group named dgroup1 with normal redundancy consisting of two failure groups controller1 or controller2 with four disks in each failure group.
$SQLPLUS /NOLOG
SQL> CONNECT / AS SYSASM
Connected to an idle instance.
SQL> STARTUP NOMOUNT
SQL>CREATE DISKGROUP dgroup1 NORMAL REDUNDANCY
FAILGROUP controller1 DISK
'/devices/diska1' NAME diska1,
'/devices/diska2' NAME diska2,
'/devices/diska3' NAME diska3,
'/devices/diska4' NAME diska4
FAILGROUP controller2 DISK
'/devices/diskb1' NAME diskb1,
'/devices/diskb2' NAME diskb2,
'/devices/diskb3' NAME diskb3,
'/devices/diskb4' NAME diskb4
ATTRIBUTE 'au_size'='4M',
'compatible.asm' = '11.1',
'compatible.rdbms' = '11.1';
In the above example, We made a disk group dgroup1 with normal redundancy (2-way mirroring), So, we need two fail groups controller1 and controller2.
When Automatic Storage Management allocates an extent for a normal redundancy file, ASM allocates a primary copy and a secondary copy. Automatic Storage Management chooses the disk on which to store the secondary copy in a different failure group other than the primary copy. Failure groups are used to place mirrored copies of data so that each copy is on a disk in a different failure group. The simultaneous failure of all disks in a failure group does not result in data loss.
Failure Scenarios:
1. Single Disk failure: Suppose a disk failed in controller2 say(controller2.diskb4) data will remain intact, This disk either will have primary copy or secondary copy of extents. Since, we have two copies, so any how we will have another copy of failed disk into another disk group. So, I would say in this scenario, your data is 100% safe.
2. Multiple Disk Failure: This situation can further divide into two parts Multiple disk failure from Same disk group: In this case, you will not loos data, because another disk group will have all data. Multiple disk failure from different disk group: Here is the risk, Suppose you loose controller1.diska1 and controller2.diskb4 and unfortunately, extents in diska1 have their mirror copy into diskb4 and both disks are unavailable. So, you will end up loosing data.
3. Disk Controller Failure: Suppose you loose one of your disk controller Controller 1 that means all disks in a fail group. Even, in this case data will not lost because, each extant in fail groupfailgroup1 will have a copy in failgroup2.
You define the failure groups for a disk group when you create an ASM disk group. After a disk group is created, you cannot alter the redundancy level of the disk group. To change the redundancy level of a disk group, create another disk group with the appropriate redundancy and then move the files to the new disk group.
Note:- Disk groups with external redundancy do not use failure groups.
Oracle mirrors at the extent level, so you have a primary extent and a mirrored extent.When a disk fails, ASM rebuilds the failed disk using mirrored extents from the other disks within the group, this may have a slight impact on performance as the rebuild takes place.
A diskgorup is a group of fail groups together, a fail group is a group of disks together. So, disk is the minimum identity in this architecture.The disk group type determines the mirroring levels with which Oracle creates files in a disk group.In general, ASM supports three types of redundancy (mirroring*) options.When you create a disk group, you specify an Automatic Storage Management (ASM) disk group type based on one of the following three redundancy levels.The default mirroring levels indicate the mirroring level with which each file is created unless a different mirroring level is designated.
Mirroring Options for ASM Disk Group Types
| Disk Group Type | Supported Mirroring Levels | Default Mirroring Level |
|---|---|---|
External redundancy
|
Unprotected (none)
|
Unprotected
|
Normal redundancy
| Two-way Three-way Unprotected (None) |
Two-way
|
High redundancy
|
Three-way
|
Three-way
|
External redundancy - doesn't have failure groups and thus is effectively a no-mirroring strategy, which is used when mirroring is provided by the disk subsystem such as RAID.Any write error cause a forced dismount of the disk group.
Normal redundancy - provides two-way mirroring of all extents in a disk group, which result in two failure groups .A loss of one ASM disk is tolerated.
High redundancy - provides three-way mirroring of all extents in a disk group, which result in three failure groups.A loss of two ASM disks in different failure groups is tolerated.The redundancy level controls how many disk failures are tolerated without dismounting the diskgroup or losing data.There are always failure groups even if they are not explicitly created. If you do not specify a failure group for a disk, then Oracle automatically creates a new failure group containing just that disk. A normal redundancy disk group must contain at least two failure groups. A high redundancy disk group must contain at least three failure groups. However, Oracle recommends using several failure groups.
Below is an example of disk group,
Let's assume, we have two disk controllers at Hardware level .Controller 1 (have four disk connected from diska), Controller 2 (have four disk connected from diskb). If, controller will fail, all disks under it will be unavailable. So, we need to plan our Disk group to take case this as well.
Controller 1:
/devices/diska1
/devices/diska2
/devices/diska3
/devices/diska4
Controller 2:
/devices/diskb1
/devices/diskb2
/devices/diskb3
/devices/diskb4
creates a disk group named dgroup1 with normal redundancy consisting of two failure groups controller1 or controller2 with four disks in each failure group.
$SQLPLUS /NOLOG
SQL> CONNECT / AS SYSASM
Connected to an idle instance.
SQL> STARTUP NOMOUNT
SQL>CREATE DISKGROUP dgroup1 NORMAL REDUNDANCY
FAILGROUP controller1 DISK
'/devices/diska1' NAME diska1,
'/devices/diska2' NAME diska2,
'/devices/diska3' NAME diska3,
'/devices/diska4' NAME diska4
FAILGROUP controller2 DISK
'/devices/diskb1' NAME diskb1,
'/devices/diskb2' NAME diskb2,
'/devices/diskb3' NAME diskb3,
'/devices/diskb4' NAME diskb4
ATTRIBUTE 'au_size'='4M',
'compatible.asm' = '11.1',
'compatible.rdbms' = '11.1';
In the above example, We made a disk group dgroup1 with normal redundancy (2-way mirroring), So, we need two fail groups controller1 and controller2.
When Automatic Storage Management allocates an extent for a normal redundancy file, ASM allocates a primary copy and a secondary copy. Automatic Storage Management chooses the disk on which to store the secondary copy in a different failure group other than the primary copy. Failure groups are used to place mirrored copies of data so that each copy is on a disk in a different failure group. The simultaneous failure of all disks in a failure group does not result in data loss.
Failure Scenarios:
1. Single Disk failure: Suppose a disk failed in controller2 say(controller2.diskb4) data will remain intact, This disk either will have primary copy or secondary copy of extents. Since, we have two copies, so any how we will have another copy of failed disk into another disk group. So, I would say in this scenario, your data is 100% safe.
2. Multiple Disk Failure: This situation can further divide into two parts Multiple disk failure from Same disk group: In this case, you will not loos data, because another disk group will have all data. Multiple disk failure from different disk group: Here is the risk, Suppose you loose controller1.diska1 and controller2.diskb4 and unfortunately, extents in diska1 have their mirror copy into diskb4 and both disks are unavailable. So, you will end up loosing data.
3. Disk Controller Failure: Suppose you loose one of your disk controller Controller 1 that means all disks in a fail group. Even, in this case data will not lost because, each extant in fail groupfailgroup1 will have a copy in failgroup2.
You define the failure groups for a disk group when you create an ASM disk group. After a disk group is created, you cannot alter the redundancy level of the disk group. To change the redundancy level of a disk group, create another disk group with the appropriate redundancy and then move the files to the new disk group.
Note:- Disk groups with external redundancy do not use failure groups.
