ASM redundancy: Difference between revisions
Jump to navigation
Jump to search
Created page with "Category:Best Practices = Oracle ASM reduncancy = Because enterprise storage arrays have excellent data protection, even in the case of disk (SSD) failures or even compo..." |
No edit summary |
||
| Line 1: | Line 1: | ||
[[Category:Best Practices]] | [[Category:Best Practices]] | ||
= Oracle ASM reduncancy = | === Oracle ASM reduncancy === | ||
Because enterprise storage arrays have excellent data protection, even in the case of disk (SSD) failures or even component failures (CPU, storage nodes) there is usually no need to configure ASM normal or high redundancy. External redundancy is the recommended practice, with the exception of CRS (cluster resource) diskgroups. | Because enterprise storage arrays have excellent data protection, even in the case of disk (SSD) failures or even component failures (CPU, storage nodes) there is usually no need to configure ASM normal or high redundancy. External redundancy is the recommended practice, with the exception of CRS (cluster resource) diskgroups. | ||
Latest revision as of 14:10, 16 September 2021
Oracle ASM reduncancy
Because enterprise storage arrays have excellent data protection, even in the case of disk (SSD) failures or even component failures (CPU, storage nodes) there is usually no need to configure ASM normal or high redundancy. External redundancy is the recommended practice, with the exception of CRS (cluster resource) diskgroups.
Normal redundancy: Each chunk (ASM Allocation Unit) is copied to two different volumes.
High redundancy: Each chunk (ASM Allocation Unit) is copied to three different volumes.