What’s Happening?
- ASM (Automatic Storage Management) doesn’t “mirror” data directly but ensures that data is stored redundantly across different disks for protection.
- If one disk fails, ASM ensures the database keeps working by using the copies of the data stored on other disks.
Imagine This Scenario:
You have a storage group (DATA1) configured with normal redundancy (2 failgroups: MIRROR1 and MIRROR2).
Data is spread (striped) across the disks in both failgroups, with copies stored in each group for redundancy.
- MIRROR1: Has 3 disks (each 512GB).
- MIRROR2: Also has 3 disks (each 512GB).
What Happens When a Disk Fails?
Disk 2 in MIRROR1 Fails:
ASM’s Repair Period:
Rebalancing Data:
- The database keeps running without noticing the failure because it uses the backup copies from MIRROR2.
- ASM gives you some time to fix or replace the failed disk.
- If you don’t fix it in time, ASM will force-drop the failed disk, meaning it removes it from the group permanently.
- ASM will then redistribute the data that was on the failed disk to the remaining 2 disks in MIRROR1.
- This ensures the data redundancy is still maintained, but now across 2 disks instead of 3.
What Are the Outcomes?
If there’s enough space on the remaining disks:
If there’s enough space on the remaining disks:
- The rebalance will complete successfully, and MIRROR1 will become operational again. However, it will have less total capacity (1TB instead of 1.5TB).
- The rebalance will fail because the remaining disks in MIRROR1 don’t have enough room for all the data. MIRROR1 will stay offline.
Recommended Solution:
- Add a new 512GB disk to MIRROR1.
- ASM will automatically rebalance the data across the 3 disks in MIRROR1, restoring its full capacity and redundancy.
Why This Is Important:
- ASM ensures the database continues running smoothly even when a disk fails.
- Replacing the failed disk promptly is crucial to maintaining full redundancy and preventing further issues if another disk fails.
No comments:
Post a Comment