1. ASM – Automatic Storage Management
Rastislav Hudák

2. ASM - motivácia Problémy so správou DB Rekonfigurácia diskov Hot spots
Fragmentácia
„Management gap“
Prístup
Enterprise manager
DBCA (Database Configuration Assistant)
SQL*Plus
ASM Command Line Interface (od v10.2)
ASMLib (API pre dodávateľov HW)

3. ASM - overwiev Riešenie ASM (od verzie 10g)
File systém a volume manager v jednom, špecificky navrhnutý pre oracle databázové súbory
Snaha o rovnaké a jednoduché rozhranie nad server a storage platformami
Virtualizuje databázové úložisko do tzv. disk groups
Administrátor spravuje disk groups
v rámci nich ASM samo rozkladá a pomenuváva databázové súbory
rozkladá ich rovnomerne aby sa rozložila záťaž a zlepšila odozva
online prehadzuje súbory ak sa nejaký disk pridá alebo odstraňuje (nemá taký striktný striping ako RAID, netreba všetky údaje „prestripovať“)
podpora redundancie

4. ASM - vlastnosti I/O optimalizácia
Súbory rozdelené na 1MB časti (veda!), tie sú rovnomerne rozložené na diskoch
Umiestnenie súborov neudáva matematická funkcia (závislá na počte diskov) ale pointer => jednoduchá relokácia častí v prípade pridania- odobratia disku
Fine-grained striping pre I/O-náročné súbory ako log, vo všeobecnosti špecifické pre typ súboru – nastavuje sa v disk group templates
Mirroring
žiadny - externý, dvojcestný, trojcestný
Zrkadlí sa každá časť súboru (teda typicky každý 1MB)
Možnosť vytvárať failure groups

5. ASM - internals ASM je samostatný proces
Spravuje najmä mapu častí súborov – extent map
Potrebuje asi 64MB priestoru
63 disk groups, diskov, ml súborov, 35TB súbor
V architektúre RAC (Real Application Cluster) beží na každom uzle a spravuje všetky jeho disk groups, v koordinácii s ostatnými uzlami
Keď databáza otvorí database file...
ASM poskytne extent map pre daný súbor, DB potom pracuje priamo s časťami súboru na diskoch, ak sa mapa nemení
Mapa sa mení iba ak: sa otvára nový súbor, pridáva alebo odoberá disk, zväčšuje tablespace
Teda ASM musí bežať skôr než inštancia DB
Jeden ASM môže obsluhovať viac databáz

6. ASM - administrácia Stav
Môžme kontrolovať buď cez Enterprise manager-a alebo cez V$views
Automatic...
Málo nastaviteľných parametrov
Při inštalácii je povinný iba INSTANCE_TYPE = ASM
Stupeň mirroringu
Failure groups
Power limit (0-off, 1-low speed – 11-full throttle)
Discovery string
Na disky ktoré sú tu uvedené sa ASM pozerá aby z ich hlavičiek zistil, ktorý patrí do ktorej skupiny
Napríklad v rozsiahlych systémoch nechceme kontrolovať každý disk
Závislé na operačnom systéme

7. ASM - detaily Mirroring a Failure groups
Keď raz vytvoríme disk groups s určitým stupňom mirroringu, nemôžeme ho dynamicky zmeniť. Musíme vytvoriť novú disk group, a údaje preniesť pomocou RMAN restore alebo DBMS_FILE_TRANSFER
Príklad: máme diskové pole s dvoma trays, chceme aby výpadok jedného nebol kritický
SQL> create diskgroup DATA_NRML normal redundancy
Failure group flgrp1 disk
‘/dev/rdsk/c3t19d3s4’,‘/dev/rdsk/c3t19d4s4’,‘/dev/rdsk/c3t19d5s4’
Failure group flgrp2 disk
‘/dev/rdsk/c4t20d3s4’,‘/dev/rdsk/c4t20d4s4’,‘/dev/rdsk/c4t20d5s4’

8. ASM - detaily Mirroring a Failure groups
Vždy sa číta primárny extent (sekundárne – mirrorované iba ak sa primárny prečítať nedá)
Rozloženie primárnych a sekundárnych extentov je rovnomerné cez disky (kontra iné managery, ktoré majú primárny disk a sekundárny, na ktoromsú iba zrkadlené údaje) teda vyvažuje sa záťaž – číta sa rovnomerne zo všetkých diskov.
Ak nevieme ako rozložiť failure groups necháme to na ASM (z best practices) – každý disk bude samostatná failure group, partnerské disky (so sekundárnymi extentmi) vyberie ASM

9. ASM - detaily Mirroring a Failure groups
Rebalancing – ASM sleduje I/O chyby. Ak je situácia vážna, odpojí disk. Následne vytvára zo sekundárnych extentov primárne, medzičasom DB číta sekundárne, po skončení rebalancingu začne opäť čítať primárne.
Ak strata disku spôsobí stratu dát, odpojí ASM celú disk group, aby ochránil integritu dát.
Vo V$ASM_DISKGROUP sú stĺpce USABLE_FREE_SPACE (koľko máme miesta ak započítame mirroring) a REQUIRED_MB_FREE (koľko potrebujeme miesta na restore ak vypadne disk)

10. ASM - detaily Internals
3 podporné procesy: RBAL (balancing), ASMB (štatistiky), O001 – O0010 (process pool na komunikáciu DB s ASM – aby sa nezdržovalo při krátkych požiadavkách)
Shutdown ASM bude čakať kým skončia všetky connections z DB. Ak dáme IMMEDIATE tak pustí SHUTDOWN IMMEDIATE aj na DB, ale vždy sa vypína až po DB.
Ak ASM spadne, vykoná sa před štartom recovery z logov jednotlivých disk groups
Allocation units a coarse vs fine grained distibution
Rebalancing vykonávajú procesy ARBx, každý proces realokuje AU sériovo (drahá operácia). ARB procesov je presne toľko koľko udáva power limit (teda môže sa realokovať 11 AU paralelne). Radšej robiť off-peak.
ASM allocates space in units called allocation units or AU. ASM always creates one-allocation-unit (AU)
extents across all of the disks in a disk group19. For a diskgroup with similarly sized disks, there should be
an equal number of AU extents on every disk. A database file is broken up into file extents. There are two
types of file extent distributions: coarse and fine. For coarse distribution, each coarse grain extent file
extent is mapped to a single allocation unit. With fine grain distribution, each grain is interleaved 128K
across groups of 8 AUs. Fine distribution breaks up large sized I/O operations, into multiple 128K I/O
operations that can execute in parallel, which benefits sequential I/Os. Coarse and fine grain attributes are
pre-defined, as part of system templates, for all system related files; e.g., redo and archive log files are
defined as fine grain, whereas, datafiles are coarse.
The Rebalance process examines each file extent map, and the new extents are re-plotted on to the new
storage configuration. For example, consider an 8-disk diskgroup, with a datafile with 40 extents (each
disk will house 5 extents). When 2 new drives of same size are added, that datafile is rebalanced and
spread across 10 drives, with each drive containing 4 extents. Only 8 extents need to move to complete the
rebalance; i.e., a complete redistribution of extents is not necessary, only the minimum number of extents
are moved to reach equal distribution
The following is a typical process flow for ASM rebalancing:
1. On the ASM instance, a DBA adds (or drops) a disk to (from) a diskgroup.
2. This invokes the RBAL process to create the rebalance plan and then begin coordination of the
redistribution
3. RBAL will calculate estimation time and work required to perform the task and then message the
ARBx processes to actually handle the request. The number of ARBx processes invoked is
directly determined by the asm_power_limit.
4. The Continuing Operations Directory (metadata) will be updated to reflect a rebalance activity.
5. Each extent to be relocated is assigned to an ARBx process.
6. ARBx performs rebalance on these extents. Each extent is locked, relocated, and unlocked. This
is shown as Operation REBAL in V$ASM_OPERATION..

11. ASM - detaily Príklad: Môžme sledovať postup rebalancingu
“Session1 SQL”> alter diskgroup DATA add disk '/dev/rdsk/c3t19d39s4' rebalance power 11
Môžme sledovať postup rebalancingu
“Session2 SQL”> select * from v$asm_operation
Rebalancing beží na pozadí, ale niekedy je lepšie/nutné počkať kým skončí (ak pridáme 100GB, nemôžme počas rebalancingu vytvoriť 80GB tablespace)
Vďaka rebalancingu je pridávanie a odoberanie diskov iba otázkou naplánovania rebalancingu, ale pri použití failure groups sa treba aj zamyslieť
ASM allocates space in units called allocation units or AU. ASM always creates one-allocation-unit (AU)
extents across all of the disks in a disk group19. For a diskgroup with similarly sized disks, there should be
an equal number of AU extents on every disk. A database file is broken up into file extents. There are two
types of file extent distributions: coarse and fine. For coarse distribution, each coarse grain extent file
extent is mapped to a single allocation unit. With fine grain distribution, each grain is interleaved 128K
across groups of 8 AUs. Fine distribution breaks up large sized I/O operations, into multiple 128K I/O
operations that can execute in parallel, which benefits sequential I/Os. Coarse and fine grain attributes are
pre-defined, as part of system templates, for all system related files; e.g., redo and archive log files are
defined as fine grain, whereas, datafiles are coarse.
The Rebalance process examines each file extent map, and the new extents are re-plotted on to the new
storage configuration. For example, consider an 8-disk diskgroup, with a datafile with 40 extents (each
disk will house 5 extents). When 2 new drives of same size are added, that datafile is rebalanced and
spread across 10 drives, with each drive containing 4 extents. Only 8 extents need to move to complete the
rebalance; i.e., a complete redistribution of extents is not necessary, only the minimum number of extents
are moved to reach equal distribution
The following is a typical process flow for ASM rebalancing:
1. On the ASM instance, a DBA adds (or drops) a disk to (from) a diskgroup.
2. This invokes the RBAL process to create the rebalance plan and then begin coordination of the
redistribution
3. RBAL will calculate estimation time and work required to perform the task and then message the
ARBx processes to actually handle the request. The number of ARBx processes invoked is
directly determined by the asm_power_limit.
4. The Continuing Operations Directory (metadata) will be updated to reflect a rebalance activity.
5. Each extent to be relocated is assigned to an ARBx process.
6. ARBx performs rebalance on these extents. Each extent is locked, relocated, and unlocked. This
is shown as Operation REBAL in V$ASM_OPERATION..

12. ASM - detaily Vďaka za pozornosť
ASM allocates space in units called allocation units or AU. ASM always creates one-allocation-unit (AU)
extents across all of the disks in a disk group19. For a diskgroup with similarly sized disks, there should be
an equal number of AU extents on every disk. A database file is broken up into file extents. There are two
types of file extent distributions: coarse and fine. For coarse distribution, each coarse grain extent file
extent is mapped to a single allocation unit. With fine grain distribution, each grain is interleaved 128K
across groups of 8 AUs. Fine distribution breaks up large sized I/O operations, into multiple 128K I/O
operations that can execute in parallel, which benefits sequential I/Os. Coarse and fine grain attributes are
pre-defined, as part of system templates, for all system related files; e.g., redo and archive log files are
defined as fine grain, whereas, datafiles are coarse.
The Rebalance process examines each file extent map, and the new extents are re-plotted on to the new
storage configuration. For example, consider an 8-disk diskgroup, with a datafile with 40 extents (each
disk will house 5 extents). When 2 new drives of same size are added, that datafile is rebalanced and
spread across 10 drives, with each drive containing 4 extents. Only 8 extents need to move to complete the
rebalance; i.e., a complete redistribution of extents is not necessary, only the minimum number of extents
are moved to reach equal distribution
The following is a typical process flow for ASM rebalancing:
1. On the ASM instance, a DBA adds (or drops) a disk to (from) a diskgroup.
2. This invokes the RBAL process to create the rebalance plan and then begin coordination of the
redistribution
3. RBAL will calculate estimation time and work required to perform the task and then message the
ARBx processes to actually handle the request. The number of ARBx processes invoked is
directly determined by the asm_power_limit.
4. The Continuing Operations Directory (metadata) will be updated to reflect a rebalance activity.
5. Each extent to be relocated is assigned to an ARBx process.
6. ARBx performs rebalance on these extents. Each extent is locked, relocated, and unlocked. This
is shown as Operation REBAL in V$ASM_OPERATION..