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:
Here you can create the content that will be used within the module.
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:
Here you can create the content that will be used within the module.