Renga@DBA

Oracle 19c ASM Rebalance Operations: Background Mechanics and Scenarios

Here is a table-format explanation of ASM background processes in Oracle 19c with their roles
and the specific operations they handle in real-time scenarios:

ASM
Backgrou
Role/Function Scenario Operation/Example
nd
Process
- Add Disk: When you execute
ALTER DISKGROUP ADD DISK,
GMON kicks off the rebalance
- Monitors disk groups for
GMON - process.
changes.
(Group Adding/Drop - Drop Disk: GMON ensures extents
- Initiates and manages
Monitor) ping a disk. from the dropped disk are relocated
rebalance operations.
to the remaining disks.
- Example: ALTER DISKGROUP
DATA DROP DISK DISK01;
- Rebalance Extents: When adding
a disk, ARBn redistributes data for
ARBn - Redistributes extents
- Rebalancing uniform allocation.
(Rebalanc across ASM disks.
after adding - Controlled by ASM Power Limit:
e - Multiple ARBn processes
or dropping a ALTER SYSTEM SET
Processes (e.g., ARB0, ARB1, ...) are
disk. asm_power_limit=16;.
) spawned as needed.
- Example: ALTER DISKGROUP
DATA REBALANCE POWER 8;
- Coordinate Rebalance: When a
- Coordinates all file extent - Disk disk is added or dropped, RBAL
RBAL
placement for ASM. rebalance or assigns tasks to ARBn.
(Rebalanc
- Allocates tasks to ARBn new disk - Example: During ALTER
e Master)
processes. addition. DISKGROUP ADD DISK, RBAL
calculates how extents will move.
- Metadata Update: During a DROP
MARK - Manages metadata - Dropping a DISK, MARK ensures metadata
(Metadata changes in ASM disk disk or disk entries are updated.
Remarker) groups. group. - Example: ALTER DISKGROUP
DATA DROP DISK FORCE; ensures
 Renga@DBA

- Marks disks as the disk metadata is marked

OFFLINE/ONLINE during "FORCE OFFLINE" before rebalance.
operations.
- Lock Management: Prevents
- Handles global locks for multiple nodes from modifying ASM
LMD (Lock ASM resources in RAC - RAC disk metadata simultaneously.
Manager environments. group access - Example: In a RAC setup, when
Daemon) - Manages inter-node issues. Node A adds a disk, LMD locks the
communication. resource to avoid concurrent
changes by Node B.
- Redo Allocation: Writes redo data
to ASM disks when redo logs are
LGWR - Disk groups stored in ASM.
- Handles redo log writing
(Log containing - Example: If redo logs are placed in
in ASM disk groups.
Writer) redo logs. the +DATA disk group, LGWR
ensures they are written to the
appropriate extents.
- Prevent Disk Corruption: Ensures
exclusive disk access by RAC
LCK0 - Manages ASM file and - RAC with instances.
(ASM Disk disk locking between multiple - Example: If Node A attempts to
Lock) instances. instances. mount a disk group already mounted
by Node B, LCK0 prevents duplicate
access.
- Diagnostic Data Collection:
- Gathers diagnostic Captures data during rebalance or
DIAG
information about ASM - ASM disk disk group operations.
(Diagnosti
operations. group issues - Example: Logs error messages if a
c
- Logs errors and warnings or failures. disk fails during rebalance in
Daemon)
for troubleshooting. $ORACLE_BASE/diag/asm
directory.
- Auxiliary Tasks: Updates headers
KSVx - Perform auxiliary tasks for for added disks or moves extents
- Disk group
(Slave ASM operations such as during rebalance.
creation or
Processes extent movement and disk - Example: During CREATE
rebalance.
) header updates. DISKGROUP, KSVx processes write
metadata to disk headers.
 Renga@DBA

- Metadata Updates: When adding

a disk, XDMG/XDWK update the disk
- Handles ASM disk
- Disk group metadata to include the new
metadata global updates
XDMG/XD addition or disk.
(XDMG).
WK drop - Example: After ALTER DISKGROUP
- Performs metadata tasks
operations. ADD DISK, XDWK ensures the disk's
(XDWK).
metadata is properly linked to the
disk group.
- Extent Map Retrieval: Database
ASMB - Manages communication requests for blocks or files are
(ASM between database - Database handled by ASMB.
Backgrou instances and ASM. connecting to - Example: If a database retrieves a
nd - Fetches extent maps ASM. datafile stored in ASM, ASMB
Process) from ASM metadata. ensures the database receives the
proper extent map.

ASM Operation and Associated Background Processes

Key
Operation Initiating Command Background Explanation
Processes
- GMON starts the rebalance process.
ALTER DISKGROUP - ARBn redistributes extents across the
GMON,
Add Disk DATA ADD new and existing disks.
ARBn, RBAL
DISK ...; - RBAL coordinates the placement of
extents.
- GMON moves data extents from the
ALTER DISKGROUP dropped disk to remaining disks.
GMON,
Drop Disk DATA DROP - MARK updates metadata to mark the
ARBn, MARK
DISK ...; disk OFFLINE.
- ARBn completes the rebalance.
- GMON restores extents to the
ALTER DISKGROUP
Undrop GMON, RBAL, undropped disk if the rebalance is
DATA UNDROP
Disk MARK incomplete.
DISKS;
- RBAL stops ongoing rebalance.
 Renga@DBA

- MARK updates the metadata for the

undropped disk.
- RBAL initializes the extents for the new
Create disk group.
CREATE DISKGROUP RBAL, KSVx,
Disk - KSVx writes headers and metadata to
DATA ...; MARK
Group each disk.
- MARK finalizes the metadata structure.
- GMON initiates rebalance across disks.
Rebalance ALTER DISKGROUP - ARBn performs extent movement in
GMON,
Disk DATA REBALANCE parallel.
ARBn, RBAL
Group POWER N; - RBAL ensures uniform extent
placement.
- GMON ensures no active files remain.
DROP DISKGROUP
Drop Disk GMON, - MARK clears metadata for all disks.
DATA INCLUDING
Group MARK, KSVx - KSVx updates headers to mark disks as
CONTENTS;
no longer part of ASM.

Rebalance Monitoring and Verification

1. View Rebalance Progress:

sql
****************
SELECT group_number, operation, state, power, sofar, est_work FROM
v$asm_operation;

2. View Disk Group Status:

sql
****************
SELECT name, state, type, total_mb, free_mb FROM v$asm_diskgroup;

3. Check Individual Disks:

sql
****************
 Renga@DBA

SELECT name, path, header_status, mode_status, state FROM v$asm_disk;

This table-based approach highlights each ASM background process with its specific role in real-
time scenarios.

Oracle 19c ASM Rebalance Operations: Background Mechanics and Scenarios

ASM rebalance operations are essential when performing disk group changes like adding,
dropping, or undropping disks. Below is a detailed explanation of what happens in the background
during each operation, with commands and scenarios.

1. Adding a Disk to an Existing Disk Group

Scenario: Adding a Disk to Increase Storage Capacity

sql
*******
ALTER DISKGROUP <diskgroup_name> ADD DISK '/dev/oracleasm/disks/DISK_NAME'
NAME <disk_name>;

• Background Process:
o GMON (Group Monitor): Initiates the rebalance operation.
o ARBn (ASM Rebalance Processes):
▪ Data is redistributed evenly across the new and existing disks.
▪ Rebalance happens online without downtime.
o I/O Distribution: ASM ensures uniform data distribution using its striping
mechanism.
• Steps:
o ASM checks the new disk's compatibility (size, speed, ASM disk header).
o Rebalance begins to spread existing extents to the new disk.
o Power limit determines the speed of rebalance (default is 1).
▪ You can adjust it: ALTER SYSTEM SET asm_power_limit=16;.
o Disk group status changes to "REBALANCE" during the operation.
 Renga@DBA

• Verification:
sql
*******
SELECT group_number, operation, state, power FROM v$asm_operation;

2. Adding a New Disk Group

Scenario: Creating a New Disk Group for a Separate Database

sql
*******
CREATE DISKGROUP <diskgroup_name> EXTERNAL REDUNDANCY
DISK '/dev/oracleasm/disks/DISK1', '/dev/oracleasm/disks/DISK2'
ATTRIBUTE 'compatible.asm'='19.0', 'au_size'='4M';

• Background Process:
o ASM allocates disk headers and metadata to each disk.
o Extents are mapped and metadata blocks are created for managing data
placement.
• Steps:
o Validate the disk paths and device permissions.
o Disk headers are written with unique ASM identifiers.
o Disk group metadata is initialized to manage extents and redundancy.
• Verification:
sql
*******
SELECT name, state, type FROM v$asm_diskgroup;

3. Dropping a Disk from a Disk Group

Scenario: Removing a Faulty or Unused Disk

sql
*******
 Renga@DBA

ALTER DISKGROUP <diskgroup_name> DROP DISK <disk_name>;

• Background Process:
o GMON: Initiates the disk drop process.
o ARBn: Rebalances extents from the dropped disk to remaining disks.
o Disk header metadata is updated to reflect "FORCE OFFLINE."
o After rebalance completion, the disk is removed from the disk group.

• Steps:
o ASM validates that the remaining disks can hold the data from the dropped disk.
o Extents are redistributed across the remaining disks.
o Disk is marked as "FORCED DROP" if unavailable (use FORCE option).
• Command for Forced Drop:
sql
*******
ALTER DISKGROUP <diskgroup_name> DROP DISK <disk_name> FORCE;

• Verification:
sql
*******
SELECT operation, state, group_number FROM v$asm_operation;

4. Dropping an Entire Disk Group

Scenario: Decommissioning a Disk Group

sql
*******
DROP DISKGROUP <diskgroup_name> INCLUDING CONTENTS;

• Background Process:
o Deletes all metadata and data extents within the disk group.
o ASM releases all disks associated with the disk group.
o Disk headers are cleared, making the disks available for reuse.
• Steps:
 Renga@DBA

o ASM ensures that no files in the disk group are in use.

o Disk headers and metadata are cleared.
o Disk group entry is removed from the ASM metadata.
• Verification:
sql
*******
SELECT name FROM v$asm_diskgroup WHERE state='MOUNTED';

5. Undropping a Disk

Scenario: Accidental Disk Drop

sql
*******
ALTER DISKGROUP <diskgroup_name> UNDROP DISKS;

• Background Process:
o Restores metadata for dropped disks, provided the rebalance operation has not
completed.
o GMON cancels ongoing rebalance processes related to the dropped disk.
• Steps:
o The UNDROP operation checks for the presence of dropped disks in the disk group
metadata.
o Metadata and data extents are re-synchronized.
o Disk group status is updated to reflect the undropped disk.
• Verification:
sql
*******
SELECT name, path FROM v$asm_disk WHERE state='ONLINE';

6. Manipulating ASM Power Limit

• The rebalance speed is governed by the ASM power limit:

o Default: 1 (slow but minimal I/O impact).
o Increase for faster rebalance: ALTER SYSTEM SET asm_power_limit=32;.
 Renga@DBA

Scenario: Performance Impact During Rebalance

• Symptom: Database performance slows down due to a rebalance.

• Solution:
o Lower the power limit to reduce resource contention.
sql
*******
ALTER SYSTEM SET asm_power_limit=2;

Key Workaround Solutions for Disk Group Issues

Scenario 1: Disk Group Fails to Mount

• Cause: Missing or inaccessible disks.

• Solution:
o Verify disk status:
sql
*******
SELECT path, header_status FROM v$asm_disk;

o Fix permissions:
bash
*******
chmod 660 /dev/oracleasm/disks/DISK1
chown grid:asmadmin /dev/oracleasm/disks/DISK1

o Mount manually:
sql
*******
ALTER DISKGROUP <diskgroup_name> MOUNT;

Scenario 2: Rebalance Hangs

• Cause: Insufficient resources or misconfigured ASM power.

• Solution:
o Increase power limit:
 Renga@DBA

sql
*******
ALTER SYSTEM SET asm_power_limit=16;

o Kill rebalance operation:

sql
*******
ALTER DISKGROUP <diskgroup_name> REBALANCE STOP;

Background Operations in ASM for ADD, DROP, UNDROP, and ALTER Commands

Oracle Automatic Storage Management (ASM) performs several background tasks when managing
disk groups with commands like ADD, DROP, UNDROP, and ALTER. These operations are managed by
background processes such as ARBx (ASM Rebalance processes) and ASMB (ASM Background
process).

📊 1. ADD DISK Operation

Purpose:

Add a new disk to an existing ASM disk group.

Background Operations:

1. Rebalance Operation (ARBx processes)

a. ASM redistributes data across all disks, including the newly added disk.
b. Rebalancing ensures an even data distribution.
2. Metadata Update
a. Disk group metadata is updated to reflect the new disk.
3. Space Reallocation
a. Free space is recalculated and redistributed.
 Renga@DBA

Key Processes Involved:

• ARBx – Handles rebalancing.

• GMON – Monitors disk group changes.

Key Parameter:

• ASM_POWER_LIMIT: Controls the speed of rebalancing operations.

📊 2. DROP DISK Operation

Purpose:

Remove a disk from an ASM disk group safely without data loss.

Background Operations:

1. Rebalancing Operation (ARBx processes)

a. Data from the disk being dropped is redistributed to other disks in the disk group.
2. Mark Disk as ‘DROPPING’
a. The disk is flagged as ‘DROPPING’ in the metadata.
3. Validation and Synchronization
a. ASM ensures all extents are copied to other disks before the disk is dropped.

Key Processes Involved:

• ARBx – Rebalances the data.

• GMON – Monitors the status of the drop operation.

Key Considerations:

• The disk remains in the group with the status DROPPING until rebalancing is complete.
 Renga@DBA

📊 3. UNDROP DISK Operation

Purpose:

Cancel a previously issued DROP DISK command before the rebalance is complete.

Background Operations:

1. Abort Rebalance on the Specific Disk

a. If the drop hasn’t completed, ASM stops the data redistribution.
2. Disk Status Reset
a. The disk is marked back to ‘NORMAL’ status.
3. Metadata Update
a. Disk group metadata is updated to remove the DROPPING status.

Key Processes Involved:

• GMON – Monitors and rolls back changes.

• ARBx – Aborts rebalance activities.

Key Condition:

• The UNDROP command must be issued before the disk is completely removed from the disk
group.

📊 4. ALTER DISKGROUP Operation

Purpose:

Modify disk group attributes, such as DISK_REPAIR_TIME, COMPATIBLE, or rebalance priority.

Background Operations:

1. Validation of Parameters
a. ASM validates the attributes being altered.
2. Immediate or Deferred Action
a. Some changes (e.g., REBALANCE) take effect immediately.
 Renga@DBA

b. Others might require a disk group dismount and remount.

3. Metadata Update
a. ASM updates the disk group metadata.
4. Rebalancing (if required)
a. If the REBALANCE keyword is specified, data redistribution is triggered.

Key Processes Involved:

• GMON – Oversees and validates the ALTER operation.

• ARBx – Handles rebalancing if triggered.

Common ALTER Scenarios:

• ALTER DISKGROUP … REBALANCE POWER <n>

• ALTER DISKGROUP … SET ATTRIBUTE

🚀 Summary Table

Operati Primary Background

Key Tasks
on Process
ADD ARBx, GMON Rebalance, Metadata Update, Space Redistribution

ARBx, GMON Rebalance, Metadata Update, Disk Marking

DROP

UNDR GMON, ARBx Abort Drop, Reset Disk Status, Metadata Update
OP
Validate Parameters, Metadata Update, Rebalance (if
ALTER GMON, ARBx
needed)

🛠️ Key ASM Processes Explained

• ARBx: Handles ASM rebalance operations.

• GMON: Monitors disk group operations and state changes.
• ASMB: Interfaces ASM with database instances.
 Renga@DBA

Conclusion

Each ASM operation—ADD, DROP, UNDROP, or ALTER—involves GMON and ARBn background
processes managing metadata and extent distribution. By understanding these background
mechanics and using the proper commands, administrators can troubleshoot and resolve
ASM-related issues effectively.