Na miña experiencia, atopo que USABLE_FILE_MB é un valor que xera moita confusión, incluso entre os propios DBAs Oracle. Esta confusión alcanza o cumio cando atopamos datos coma os seguintes, con valores negativos:

[oracle@arumel ~]$ asmcmd lsdg
State    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name
MOUNTED  NORMAL  N         512   4096  4194304     61416     5608            10236           -2314              0             N  DESDATA/
MOUNTED  NORMAL  N         512   4096  4194304     61416      776            10236           -4730              0             N  DESFRA/
MOUNTED  NORMAL  N         512   4096  1048576     10230     9230             2046            3592              0             Y  VOTING/

Por que teño espacio usable para ficheiros en negativo? Quedei sen espacio no DG? Vou perder datos se perdo un disco?

REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB

O valor de USABLE_FILE_MB está directamente relacionado co de REQUIRED_MIRROR_FREE_MB.

REQUIRED_MIRROR_FREE_MB indica a cantidade de espacio que sería precisa, tras producirse o maior fallo ó que o DG ten tolerancia, para poder recuperar a redundancia do diskgroup. Visto doutro xeito, é o espacio que precisaremos para, en caso de fallo, manter a redundancia que temos configurada. Soportamos o fallo hardware coma se non ocorrese (0 risco de perda de datos ante un novo fallo).

USABLE_FILE_MB é simplemente o espacio que ASM considera que está realmente dispoñible para datos. É un valor derivado de REQUIRED_MIRROR_FREE e de FREE_MB.

Útil ou ruído?

Se non estamos traballando con Exadata ou con cabinas de disco sen protección RAID, estaremos no segundo caso, estes parámetros son ruído. Daquela, que sentido ten? Ben, movámonos a un contorno Exadata. Neste caso, simplificando, temos unha máquina onde o almacenamento non ten HA a nivel hardware (non existe RAID), é ASM quen xestiona os discos. Un fallo de disco hardware vai ser trasladado a un fallo de disco ASM, o hardware non implanta ningún tipo de RAID. Isto fai que o risco hardware sexa contido pola configuración software. Como? dando información de canto espacio necesitaría ASM para xestionar a perda dun disco, ou, tamén configurable, de toda unha celda ASM (múltiples discos).

Un escenario no que a redundancia ASM sen Exadata nos permite unha moi boa flexibilidade e incluso aforro de licencias hardware, é un contorno de RAC estendido ou de HA de cabina (dúas cabinas independentes) xestionadas por ASM. Neste caso, estamos dalgún modo empregando unha dobre redundancia externa, e ASM o que nos garante é a sincronización de datos entre as cabinas cunha axeitada configuración. Se falla un disco na cabina, ese erro non se propaga habitualmente a ASM. Ó igual que cando empregamos unha única cabina con redundancia EXTERNA, nestes escenarios non nos preocupa o fallo dun disco, delegamos esa responsabilidade na propia cabina. Deste xeito, non precisamos cubrir ese tipo de erros, é, de feito, as incidencias mais habituais neste tipo de contornos é a perda completa de todo un FG pola caída dunha cabina, un switch ou de todo un CPD.

Un pouco mais de información

Volvendo ó exemplo inicial, agora que vimos estes datos, centrémonos no DG DESDATA que ten un valor negativo de USABLE_FILE_MB. Neste caso, estamos nun escenario con ASM configurado con redundancia NORMAL para sincronizar LUNs entre dúas cabinas que sea topan en CPDs diferentes. As LUNs están polo tanto protexidas polos correspondentes RAIDs do hardware de almacenamento. Aínda así, de ónde sae o valor de REQUIRED_MIRROR_FREE_MB? Por que son 10GiBs concretamente? Vexamos a configuración dos discos deste DG:

[oracle@arumel ~]$ asmcmd lsdsk -pG desdata
Group_Num  Disk_Num      Incarn  Mount_Stat  Header_Stat  Mode_Stat  State   Path
        1         0  3916019171  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD101
        1         1  3916019172  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD102
        1         2  3916019173  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD103
        1         3  3916019174  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD201
        1         4  3916019175  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD202
        1         5  3916019176  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD203

Temos discos en dous CPDs (2 cabinas). Na nomenclatura dos discos está especificado, pero vexamos a configuración a nivel de FGs:

[oracle@apora01 ~]$ asmcmd lsdsk -kG desdata
Total_MB  Free_MB  OS_MB  Name           Failgroup   Failgroup_Type  Library                                               Label          UDID  Product  Redund   Path
   10236      944  10239  DESDATACPD101  DESDATAFG1  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD101                 UNKNOWN  ORCL:DESDATACPD101
   10236      936  10239  DESDATACPD102  DESDATAFG1  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD102                 UNKNOWN  ORCL:DESDATACPD102
   10236      924  10239  DESDATACPD103  DESDATAFG1  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD103                 UNKNOWN  ORCL:DESDATACPD103
   10236      896  10239  DESDATACPD201  DESDATAFG2  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD201                 UNKNOWN  ORCL:DESDATACPD201
   10236      952  10239  DESDATACPD202  DESDATAFG2  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD202                 UNKNOWN  ORCL:DESDATACPD202
   10236      956  10239  DESDATACPD203  DESDATAFG2  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD203                 UNKNOWN  ORCL:DESDATACPD203

Temos 2 FGs, un por cada cabina. Realmente estamos protexendo con esta configuración a perda dun CPD ou do acceso a unha cabina. Esta configuración garante que un dato estará sempre almacenado nas dúas cabinas. Os FGs son DESDATAFG1 e DESDATAFG2. Cada FG ten 3 discos de 10GiBs, polo que cada DG ten un total de 30GiBs. Destes 30 GiBs, aproximadamente 25GiBs están ocupados por datos. Daquela, se perdemos un FG, o noso peor escenario de supervivencia, de que nos serve ter reservado 10GiBs se temos que redundar 25GiBs? Esta pregunta non é menor se temos en conta a descrición da documentación Oracle de que é REQUIRED_MIRROR_FREE_MB (extraido de ):

REQUIRED_MIRROR_FREE_MB indicates the amount of space that must be available in a disk group to restore full redundancy after the worst failure that can be tolerated by the disk group without adding additional storage. This requirement ensures that there are sufficient failure groups to restore redundancy. Also, this worst failure refers to a permanent failure where the disks must be dropped, not the case where the disks go offline and then back online.

No noso caso, parece que o peor escenario tolerable é sen dúbida a perda dun FG completo, e xa vemos que non temos espacio, polo que neste escenario non se cumple esta definición. Non habería caída de BD, pero os datos non poderían volver a redistribuirse mantendo a redundancia (2 copias en FGs diferentes), sen engadir novos discos. ¿qué ocorre?

Non todo é Exadata

Na mesma nota 1459611.1, podemos ver que:

The amount of space displayed in this column takes the effects of mirroring into account. The value is computed as follows:

Normal redundancy disk group with more than two failure groups
The value is the total raw space for all of the disks in the largest failure group. The largest failure group is the one with the largest total raw capacity. For example, if each disk is in its own failure group, then the value would be the size of the largest capacity disk.

High redundancy disk group with more than three failure groups
The value is the total raw space for all of the disks in the two largest failure groups.

Importante destacar que nos dous casos, o cómputo ten a precondición de que dispoñemos de mais de 2 FGs en redundancia normal e mais de 3 FGs en redundancia HIGH. O noso escenario está utilizando xustamente 2 FGs, e aí está a diferencia. Pero para explicala pode resultar útil os conceptos de redundancia aplicados en Exadata. Para elo, é recomendable revisar a nota Understanding ASM Capacity and Reservation of Free Space in Exadata (Doc ID 1551288.1) e ver a diferencia entre tolerancia a fallo de disco e tolerancia a fallo de celda:

Disk failure coverage (DFC) will refer to having enough free space to allow data to be re-mirrored (rebalanced) after a single disk failure in a normal redundancy disk group, or single or dual disk failure in a high redundancy disk group. 

Cell failure coverage (CFC) will refer to having enough free space to allow data to be re-mirrored after the loss of one entire cell.

Introducimos un concepto que, cando menos eu, non se atopa na documentación estándar de Oracle. A configuración en ASM de Exadata pode planificarse para ser configurada para tolerar fallos de disco ou fallos de celda (múltiples discos). Se asociamos á nosa configuración celda a cabina e polo tanto a FG, estariamos falando de que podemos diferenciar tolerancia a fallos de disco ou a fallos de FG. Retomando o anterior apartado, a nosa configuración emprega só 2 FGs. Con isto é tecnicamente imposible ter tolerancia a un fallo de DG. Por que? Pois porque simplemente non temos redundancia de DGs, só temos 2. Cando dispoñemos de mais DGs, é cando o cálculo do espacio requerido cambia, porque temos a opción, sen engadir novos discos, de mover copias dos datos ós outros FGs. Aí si ten sentido computar todo o espazo dispoñible no DG. De feito, esto encaixa na definición de Oracle de como se calcula REQUIRED_MIRROR_FREE_MB, onde é explícito que o cálculo é, para un DG con redundancia NORMAL, cando se empregan mais de 2 FGs:

Normal redundancy disk group with more than two failure groups

The value is the total raw space for all of the disks in the largest failure group. The largest failure group is the one with the largest total raw capacity. For example, if each disk is in its own failure group, then the value would be the size of the largest capacity disk.

Isto non é o noso caso, polo que realmente o máximo fallo tolerable dende o punto de vista deste parámetro é o de 1 disco, e non de 1 FG. Así, con 2 FGs e un tamaño de LUN de 10GiBs, o espazo mirror requerido é 10GiBs, xusto o preciso para poder reubicar en FGs diferentes os datos que un único disco ASM puidera conter.

Conclusión

É moi importante, incluso crítico, monitorizar REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB nun contorno Exadata ou nu hipotético contorno con redundancia NORMAL onde non teñamos protección RAID a nivel de cabina hardware.

Non teñen importancia os datos destes valores cando empregamos configuracións baseadas en almacenamento con protección RAID. Especificamente, no caso de que empreguemos a redundancia NORMAL para facer un mirror de datos entre dúas cabinas diferentes a nivel de ASM, sen involucrar replicación hardware ou software adicional de cabina.

En ningún dos dous casos estamos nunha situación inmediata de risco de perda de datos se atopamos valores negativos de USABLE_FILE_MB, só que, en caso de fallo, non hai xeito de recuperar a redundancia (o RAID lóxico de ASM), até que se recupere o almacenamento ou engadamos novos discos.

«There’s more to the picture than meets the eye» Neil Young. Hey, hey, my, my

Referencias

Información interesante relacionada con este artigo en:

https://prutser.wordpress.com/2013/01/03/demystifying-asm-required_mirror_free_mb-and-usable_file_mb/

ASM Diskgroup shows USABLE_FILE_MB value in Negative

Here you can create the content that will be used within the module.

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]

Na miña experiencia, atopo que USABLE_FILE_MB é un valor que xera moita confusión, incluso entre os propios DBAs Oracle. Esta confusión alcanza o cumio cando atopamos datos coma os seguintes, con valores negativos:

[oracle@arumel ~]$ asmcmd lsdg
State    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name
MOUNTED  NORMAL  N         512   4096  4194304     61416     5608            10236           -2314              0             N  DESDATA/
MOUNTED  NORMAL  N         512   4096  4194304     61416      776            10236           -4730              0             N  DESFRA/
MOUNTED  NORMAL  N         512   4096  1048576     10230     9230             2046            3592              0             Y  VOTING/

Por que teño espacio usable para ficheiros en negativo? Quedei sen espacio no DG? Vou perder datos se perdo un disco?

REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB

O valor de USABLE_FILE_MB está directamente relacionado co de REQUIRED_MIRROR_FREE_MB.

REQUIRED_MIRROR_FREE_MB indica a cantidade de espacio que sería precisa, tras producirse o maior fallo ó que o DG ten tolerancia, para poder recuperar a redundancia do diskgroup. Visto doutro xeito, é o espacio que precisaremos para, en caso de fallo, manter a redundancia que temos configurada. Soportamos o fallo hardware coma se non ocorrese (0 risco de perda de datos ante un novo fallo).

USABLE_FILE_MB é simplemente o espacio que ASM considera que está realmente dispoñible para datos. É un valor derivado de REQUIRED_MIRROR_FREE e de FREE_MB.

Útil ou ruído?

Se non estamos traballando con Exadata ou con cabinas de disco sen protección RAID, estaremos no segundo caso, estes parámetros son ruído. Daquela, que sentido ten? Ben, movámonos a un contorno Exadata. Neste caso, simplificando, temos unha máquina onde o almacenamento non ten HA a nivel hardware (non existe RAID), é ASM quen xestiona os discos. Un fallo de disco hardware vai ser trasladado a un fallo de disco ASM, o hardware non implanta ningún tipo de RAID. Isto fai que o risco hardware sexa contido pola configuración software. Como? dando información de canto espacio necesitaría ASM para xestionar a perda dun disco, ou, tamén configurable, de toda unha celda ASM (múltiples discos).

Un escenario no que a redundancia ASM sen Exadata nos permite unha moi boa flexibilidade e incluso aforro de licencias hardware, é un contorno de RAC estendido ou de HA de cabina (dúas cabinas independentes) xestionadas por ASM. Neste caso, estamos dalgún modo empregando unha dobre redundancia externa, e ASM o que nos garante é a sincronización de datos entre as cabinas cunha axeitada configuración. Se falla un disco na cabina, ese erro non se propaga habitualmente a ASM. Ó igual que cando empregamos unha única cabina con redundancia EXTERNA, nestes escenarios non nos preocupa o fallo dun disco, delegamos esa responsabilidade na propia cabina. Deste xeito, non precisamos cubrir ese tipo de erros, é, de feito, as incidencias mais habituais neste tipo de contornos é a perda completa de todo un FG pola caída dunha cabina, un switch ou de todo un CPD.

Un pouco mais de información

Volvendo ó exemplo inicial, agora que vimos estes datos, centrémonos no DG DESDATA que ten un valor negativo de USABLE_FILE_MB. Neste caso, estamos nun escenario con ASM configurado con redundancia NORMAL para sincronizar LUNs entre dúas cabinas que sea topan en CPDs diferentes. As LUNs están polo tanto protexidas polos correspondentes RAIDs do hardware de almacenamento. Aínda así, de ónde sae o valor de REQUIRED_MIRROR_FREE_MB? Por que son 10GiBs concretamente? Vexamos a configuración dos discos deste DG:

[oracle@arumel ~]$ asmcmd lsdsk -pG desdata
Group_Num  Disk_Num      Incarn  Mount_Stat  Header_Stat  Mode_Stat  State   Path
        1         0  3916019171  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD101
        1         1  3916019172  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD102
        1         2  3916019173  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD103
        1         3  3916019174  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD201
        1         4  3916019175  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD202
        1         5  3916019176  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD203

Temos discos en dous CPDs (2 cabinas). Na nomenclatura dos discos está especificado, pero vexamos a configuración a nivel de FGs:

[oracle@apora01 ~]$ asmcmd lsdsk -kG desdata
Total_MB  Free_MB  OS_MB  Name           Failgroup   Failgroup_Type  Library                                               Label          UDID  Product  Redund   Path
   10236      944  10239  DESDATACPD101  DESDATAFG1  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD101                 UNKNOWN  ORCL:DESDATACPD101
   10236      936  10239  DESDATACPD102  DESDATAFG1  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD102                 UNKNOWN  ORCL:DESDATACPD102
   10236      924  10239  DESDATACPD103  DESDATAFG1  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD103                 UNKNOWN  ORCL:DESDATACPD103
   10236      896  10239  DESDATACPD201  DESDATAFG2  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD201                 UNKNOWN  ORCL:DESDATACPD201
   10236      952  10239  DESDATACPD202  DESDATAFG2  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD202                 UNKNOWN  ORCL:DESDATACPD202
   10236      956  10239  DESDATACPD203  DESDATAFG2  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD203                 UNKNOWN  ORCL:DESDATACPD203

Temos 2 FGs, un por cada cabina. Realmente estamos protexendo con esta configuración a perda dun CPD ou do acceso a unha cabina. Esta configuración garante que un dato estará sempre almacenado nas dúas cabinas. Os FGs son DESDATAFG1 e DESDATAFG2. Cada FG ten 3 discos de 10GiBs, polo que cada DG ten un total de 30GiBs. Destes 30 GiBs, aproximadamente 25GiBs están ocupados por datos. Daquela, se perdemos un FG, o noso peor escenario de supervivencia, de que nos serve ter reservado 10GiBs se temos que redundar 25GiBs? Esta pregunta non é menor se temos en conta a descrición da documentación Oracle de que é REQUIRED_MIRROR_FREE_MB (extraido de ):

REQUIRED_MIRROR_FREE_MB indicates the amount of space that must be available in a disk group to restore full redundancy after the worst failure that can be tolerated by the disk group without adding additional storage. This requirement ensures that there are sufficient failure groups to restore redundancy. Also, this worst failure refers to a permanent failure where the disks must be dropped, not the case where the disks go offline and then back online.

No noso caso, parece que o peor escenario tolerable é sen dúbida a perda dun FG completo, e xa vemos que non temos espacio, polo que neste escenario non se cumple esta definición. Non habería caída de BD, pero os datos non poderían volver a redistribuirse mantendo a redundancia (2 copias en FGs diferentes), sen engadir novos discos. ¿qué ocorre?

Non todo é Exadata

Na mesma nota 1459611.1, podemos ver que:

The amount of space displayed in this column takes the effects of mirroring into account. The value is computed as follows:

Normal redundancy disk group with more than two failure groups
The value is the total raw space for all of the disks in the largest failure group. The largest failure group is the one with the largest total raw capacity. For example, if each disk is in its own failure group, then the value would be the size of the largest capacity disk.

High redundancy disk group with more than three failure groups
The value is the total raw space for all of the disks in the two largest failure groups.

Importante destacar que nos dous casos, o cómputo ten a precondición de que dispoñemos de mais de 2 FGs en redundancia normal e mais de 3 FGs en redundancia HIGH. O noso escenario está utilizando xustamente 2 FGs, e aí está a diferencia. Pero para explicala pode resultar útil os conceptos de redundancia aplicados en Exadata. Para elo, é recomendable revisar a nota Understanding ASM Capacity and Reservation of Free Space in Exadata (Doc ID 1551288.1) e ver a diferencia entre tolerancia a fallo de disco e tolerancia a fallo de celda:

Disk failure coverage (DFC) will refer to having enough free space to allow data to be re-mirrored (rebalanced) after a single disk failure in a normal redundancy disk group, or single or dual disk failure in a high redundancy disk group. 

Cell failure coverage (CFC) will refer to having enough free space to allow data to be re-mirrored after the loss of one entire cell.

Introducimos un concepto que, cando menos eu, non se atopa na documentación estándar de Oracle. A configuración en ASM de Exadata pode planificarse para ser configurada para tolerar fallos de disco ou fallos de celda (múltiples discos). Se asociamos á nosa configuración celda a cabina e polo tanto a FG, estariamos falando de que podemos diferenciar tolerancia a fallos de disco ou a fallos de FG. Retomando o anterior apartado, a nosa configuración emprega só 2 FGs. Con isto é tecnicamente imposible ter tolerancia a un fallo de DG. Por que? Pois porque simplemente non temos redundancia de DGs, só temos 2. Cando dispoñemos de mais DGs, é cando o cálculo do espacio requerido cambia, porque temos a opción, sen engadir novos discos, de mover copias dos datos ós outros FGs. Aí si ten sentido computar todo o espazo dispoñible no DG. De feito, esto encaixa na definición de Oracle de como se calcula REQUIRED_MIRROR_FREE_MB, onde é explícito que o cálculo é, para un DG con redundancia NORMAL, cando se empregan mais de 2 FGs:

Normal redundancy disk group with more than two failure groups

The value is the total raw space for all of the disks in the largest failure group. The largest failure group is the one with the largest total raw capacity. For example, if each disk is in its own failure group, then the value would be the size of the largest capacity disk.

Isto non é o noso caso, polo que realmente o máximo fallo tolerable dende o punto de vista deste parámetro é o de 1 disco, e non de 1 FG. Así, con 2 FGs e un tamaño de LUN de 10GiBs, o espazo mirror requerido é 10GiBs, xusto o preciso para poder reubicar en FGs diferentes os datos que un único disco ASM puidera conter.

Conclusión

É moi importante, incluso crítico, monitorizar REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB nun contorno Exadata ou nu hipotético contorno con redundancia NORMAL onde non teñamos protección RAID a nivel de cabina hardware.

Non teñen importancia os datos destes valores cando empregamos configuracións baseadas en almacenamento con protección RAID. Especificamente, no caso de que empreguemos a redundancia NORMAL para facer un mirror de datos entre dúas cabinas diferentes a nivel de ASM, sen involucrar replicación hardware ou software adicional de cabina.

En ningún dos dous casos estamos nunha situación inmediata de risco de perda de datos se atopamos valores negativos de USABLE_FILE_MB, só que, en caso de fallo, non hai xeito de recuperar a redundancia (o RAID lóxico de ASM), até que se recupere o almacenamento ou engadamos novos discos.

«There’s more to the picture than meets the eye» Neil Young. Hey, hey, my, my

Referencias

Información interesante relacionada con este artigo en:

https://prutser.wordpress.com/2013/01/03/demystifying-asm-required_mirror_free_mb-and-usable_file_mb/

ASM Diskgroup shows USABLE_FILE_MB value in Negative

Here you can create the content that will be used within the module.

%d bloggers like this: