Introduction
On peut parfois retrouver, lorsqu’on regarde l’état de ses diskgroups, une valeur dans la colonne usable_file_mb négative.
Exemple :
select name, state, type, total_mb, free_mb, required_mirror_free_mb req_free, usable_file_mb use_mb from v$asm_diskgroup where name = 'DATA1';
NAME STATE TYPE TOTAL_MB FREE_MB REQ_FREE USE_MB
---------- ------ ------ ---------- ------- --------
DATA1 MOUNTED NORMAL 15342 9454 5114 -386
On peut aussi obtenir l’information du usable_file_mb via la commande asmcmd lsdg.
Le but de cet article est de comprendre ce que cela veut dire et le risque que l’on prend si on le laisse en négatif.
Explication des termes
Type de redondance possible :
- External redundancy : pas de miroir
- Normal redundancy : deux copies des données
- High redundancy : trois copies des données
FAILGROUP : Un failgroup correspond à un ensemble de un à plusieurs disques. Par défaut on a un disque par failure group. Un failgroup n’appartient qu’à un et un seul diskgroup.
TOTAL_MB : La taille totale utilisable des disques qui composent le diskgroup. Nous n’avons donc pas exactement la taille totale des disques parce qu’une partie est réservée pour les metadata ASM, qui représente généralement 1% de l’espace total.
FREE_MB : L’espace libre total sans prendre en compte la notion de miroir.
REQUIRED_MIRROR_FREE_MB : Indique la place libre nécessaire pour pouvoir reconstruire le miroir sans ajout de stockage en cas de perte d’un failgroup. Voici comment elle est calculée :
Mode NORMAL : la valeur totale de tous les disques du plus gros failure group (par exemple si on a deux failgroups de 30G et un de 40G, il faut avoir 40G de libre).
Mode HIGH : la valeur totale de tous les disques des deux plus gros failure groups (par exemple si on a deux failgroups de 30G et un de 40G, il faut avoir 70G de libre).
USABLE_FILE_MB : c’est la place réelle restante que l’on peut utiliser tout en respectant le miroir. Il se calcule via la formule suivante :
- Mode NORMAL : usable_file_mb = (free_mb – required_free_mb)/2
- Mode HIGH : usable_file_mb = (free_mb – required_free_mb)/3
Quelques points d’attention :
1) à partir de la version 12, il n’est plus possible d’avoir des failgroups de taille différente dans un même DISKGROUP.
2) la reconstruction n’est possible que s’il y a au moins un Failure Group de plus que le niveau de redondance exigée. Donc pour une redondance normale, au moins 3 failures groups.
3) le calcul du required_free_mb peut varier d’un environnement à un autre, d’une version à une autre. Egalement, si votre diskgroup n’est pas utilisé (pas de données dessus) le required_free_mb sera à 0.
Exemple 1 : sur un ExaCC Gen 2 avec une couche Grid en 19.11 redondance NORMAL
-- Required Free Mb
SQL> select GROUP_NUMBER, REQUIRED_MIRROR_FREE_MB from v$asm_diskgroup;
GROUP_NUMBER REQUIRED_MIRROR_FREE_MB
------------ -----------------------
1 409600
2 3686400
-- Taille du plus gros disque par diskgroup
SQL> select max(TOTAL_MB)*2, GROUP_NUMBER from v$asm_disk group by GROUP_NUMBER;
MAX(TOTAL_MB)*2 GROUP_NUMBER
--------------- ------------
409600 1
3686400 2
-- Taille du plus gros failgroup par disque
SQL> select GROUP_NUMBER, max(SUM_TOTAL_MB) from (select GROUP_NUMBER, FAILGROUP, sum(TOTAL_MB) SUM_TOTAL_MB from v$asm_disk group by GROUP_NUMBER, FAILGROUP order by GROUP_NUMBER, FAILGROUP) group by GROUP_NUMBER;
GROUP_NUMBER MAX(SUM_TOTAL_MB)
------------ -----------------
1 204800
2 1228800
-- REQUIRED_MIRROR_FREE_MB = la taille du plus gros disque
-- et non pas la taille du plus gros failgroup
Exemple 2 : sur RAC 19C (hors ExaData, ODA, ExaCC) redondance NORMAL
-- Required Free Mb
SQL> select GROUP_NUMBER, REQUIRED_MIRROR_FREE_MB from v$asm_diskgroup;
GROUP_NUMBER REQUIRED_MIRROR_FREE_MB
------------ -----------------------
1 417792
2 628736
-- Taille du plus gros disque par diskgroup
SQL> select max(TOTAL_MB)*2, GROUP_NUMBER from v$asm_disk group by GROUP_NUMBER;
MAX(TOTAL_MB)*2 GROUP_NUMBER
--------------- ------------
417792 1
628736 2
-- Taille du plus gros failgroup par disque
SQL> select GROUP_NUMBER, max(SUM_TOTAL_MB) from (select GROUP_NUMBER, FAILGROUP, sum(TOTAL_MB) SUM_TOTAL_MB from v$asm_disk group by GROUP_NUMBER, FAILGROUP order by GROUP_NUMBER, FAILGROUP) group by GROUP_NUMBER;
GROUP_NUMBER MAX(SUM_TOTAL_MB)
------------ -----------------
1 2506752
2 3772416
-- REQUIRED_MIRROR_FREE_MB = la taille du plus gros failgroup
Explication du usable file mb négatif
Nous allons suivre un exemple, ici en redondance normale.
Pour la simplicité de l’exercice nous allons négliger la partie du stockage réservée aux metadata ASM et partir sur la règle Required_Free_Mb = taille du plus gros failgroup.
Nous avons un diskgroup DATA qui contient les failgroups suivants :
- FG1 = 400G au total
- FG2 = 400G au total
- FG3 = 400G au total
Etape initiale (le diskgroup est vide) :
- TOTAL_MB = 1200G
- FREE_MB = 1200G
- REQUIRED_FREE_MB = 0G (parce que le diskgroup est vide)
- USABLE_FILE_MB = (1200 – 0)/2 = 600G
Etape 1 : on ajoute un datafile de 300G :
Nous sommes en redondance normale, donc on répartit deux copies des extents qui composent le datafile sur les trois FG (donc 300G + 300G = 600G à répartir) :
- FG1 = 400G – 200G = 200G restant
- FG2 = 400G – 200G = 200G restant
- FG3 = 400G – 200G = 200G restant
- TOTAL_MB = 1200G
- FREE_MB = 1200G – 600G = 600G
- REQUIRED_FREE_MB = 400G
- USABLE_FILE_MB = (600 – 400)/2 = 100G
Exemple de répartition :
La répartition se fait réellement par unité d’allocation (par défaut 1M) et dépend aussi du content type (système, data ou reco).
Ici les extents sont rassemblés par groupe par simplicité de schéma.
Cela veut dire que je peux pour le moment ajouter un datafile de 100G sans mettre en péril mon miroir.
Dans cette situation, si je venais à perdre le FG3, un rebalance se ferait pour répartir les copies d’extent sur les autres FG, soit 200G à répartir :
On aurait alors les valeurs suivantes :
- FG1 = 400G – 300G = 100G restant
- FG2 = 400G – 300G = 100G restant
- FG3 perdu
- TOTAL_MB = 800G
- FREE_MB = 800G – 600G = 200G
- REQUIRED_FREE_MB = 400G
- USABLE_FILE_MB = (200 – 400)/2 = -100G
Cette fois, on est en négatif, cela veut dire que si on venait à perdre un autre failgroup dans la foulée on ne pourrait pas reconstruire le miroir.
On aurait seulement :
Et donc, cette fois, si on venait à perdre celui-ci également on aurait une perte de données.
A noter que même si le usable_file_mb est négatif on peut continuer à écrire du moment qu’il reste de l’espace libre dans free_mb et qu’il n’y a pas un disque full sans possibilité de rebalance (ce qui peut arriver en cas de gros incident de stockage avec une perte de la majorité des disques). Cela permet, en cas de perte de stockage que la base puisse continuer à fonctionner le temps que la situation soit rétablie.
A noter que même si le usable_file_mb n’avait pas été négatif nous n’aurions pas eu de FG où répartir notre copie d’extent. Toutefois, il peut y avoir plus que trois failgroups dans un même diskgroup en mode normal et donc on peut, en ayant assez de place dans le usable_file_mb, assurer la reconstruction du miroir à plusieurs reprises.
Conclusion
Une valeur de usable_file_mb en négatif veut dire perte de la possibilité de reconstruire le miroir attendu (double copie pour NORMAL, triple copie en HIGH) en cas de perte d’un failgroup équivalent au plus gros failgroup du diskgroup.
Oracle recommande trois failgroups minimum en redondance normal et cinq en redondance high.
En effet, même si le usable_mb est positif, si on a que deux failgroups en redondance normal, on ne pourra de toute manière pas reconstruire le miroir si on en perd un puisqu’on aura qu’un seul failgroup restant.
Quand on est en redondance normal ou high, il faut toujours regarder la valeur de usable_file_mb et pas de free_mb pour savoir l’espace qui nous reste.
En espérant que ça a pu vous être utile 
.
