{"id":6363,"date":"2017-02-10T20:51:26","date_gmt":"2017-02-10T19:51:26","guid":{"rendered":"http:\/\/arumel.com\/?p=6363\/"},"modified":"2020-06-01T23:18:56","modified_gmt":"2020-06-01T21:18:56","slug":"usable_file_mb-failure-groups-exadata-e-worst-failure","status":"publish","type":"post","link":"https:\/\/arumel.com\/en\/usable_file_mb-failure-groups-exadata-e-worst-failure\/","title":{"rendered":"REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB negativo"},"content":{"rendered":"<\/p>

<\/p>

<\/p>

Na mi\u00f1a experiencia, atopo que USABLE_FILE_MB \u00e9 un valor que xera moita confusi\u00f3n, incluso entre os propios DBAs Oracle. Esta confusi\u00f3n alcanza o cumio cando atopamos datos coma os seguintes, con valores negativos:<\/p>

[oracle@arumel ~]$ asmcmd lsdg\r\nState    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name\r\nMOUNTED  NORMAL  N         512   4096  4194304     61416     5608            10236           -2314              0             N  DESDATA\/\r\nMOUNTED  NORMAL  N         512   4096  4194304     61416      776            10236           -4730              0             N  DESFRA\/\r\nMOUNTED  NORMAL  N         512   4096  1048576     10230     9230             2046            3592              0             Y  VOTING\/\r\n<\/pre>
Por que te\u00f1o espacio usable para ficheiros en negativo? Quedei sen espacio no DG? Vou perder datos se perdo un disco?<\/p>
REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB
<\/span><\/strong><\/h3>
O valor de USABLE_FILE_MB est\u00e1 directamente relacionado co de REQUIRED_MIRROR_FREE_MB.<\/p>
REQUIRED_MIRROR_FREE_MB indica a cantidade de espacio que ser\u00eda precisa, tras producirse o maior fallo \u00f3 que o DG ten tolerancia, para poder recuperar a redundancia do diskgroup. Visto doutro xeito, \u00e9 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).<\/p>
USABLE_FILE_MB \u00e9 simplemente o espacio que ASM considera que est\u00e1 realmente dispo\u00f1ible para datos. \u00c9 un valor derivado de REQUIRED_MIRROR_FREE e de FREE_MB.<\/p>
\u00datil ou ru\u00eddo?<\/strong><\/span><\/h3>
Se non estamos traballando con Exadata ou con cabinas de disco sen protecci\u00f3n RAID, estaremos no segundo caso, estes par\u00e1metros son ru\u00eddo. Daquela, que sentido ten? Ben, mov\u00e1monos a un contorno Exadata. Neste caso, simplificando, temos unha m\u00e1quina onde o almacenamento non ten HA a nivel hardware (non existe RAID), \u00e9 ASM quen xestiona os discos. Un fallo de disco hardware vai ser trasladado a un fallo de disco ASM, o hardware non implanta ning\u00fan tipo de RAID. Isto fai que o risco hardware sexa contido pola configuraci\u00f3n software. Como? dando informaci\u00f3n de canto espacio necesitar\u00eda ASM para xestionar a perda dun disco, ou, tam\u00e9n configurable, de toda unha celda ASM (m\u00faltiples discos).<\/p>
Un escenario no que a redundancia ASM sen Exadata nos permite unha moi boa flexibilidade e incluso aforro de licencias hardware, \u00e9 un contorno de RAC estendido ou de HA de cabina (d\u00faas cabinas independentes) xestionadas por ASM. Neste caso, estamos dalg\u00fan modo empregando unha dobre redundancia externa, e ASM o que nos garante \u00e9 a sincronizaci\u00f3n de datos entre as cabinas cunha axeitada configuraci\u00f3n. Se falla un disco na cabina, ese erro non se propaga habitualmente a ASM. \u00d3 igual que cando empregamos unha \u00fanica 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, \u00e9, de feito, as incidencias mais habituais neste tipo de contornos \u00e9 a perda completa de todo un FG pola ca\u00edda dunha cabina, un switch ou de todo un CPD.<\/p>
Un pouco mais de informaci\u00f3n<\/strong><\/span><\/h3>
Volvendo \u00f3 exemplo inicial, agora que vimos estes datos, centr\u00e9monos 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\u00faas cabinas que sea topan en CPDs diferentes. As LUNs est\u00e1n polo tanto protexidas polos correspondentes RAIDs do hardware de almacenamento. A\u00ednda as\u00ed, de \u00f3nde sae o valor de REQUIRED_MIRROR_FREE_MB? Por que son 10GiBs concretamente? Vexamos a configuraci\u00f3n dos discos deste DG:<\/p>
[oracle@arumel ~]$ asmcmd lsdsk -pG desdata\r\nGroup_Num  Disk_Num      Incarn  Mount_Stat  Header_Stat  Mode_Stat  State   Path\r\n        1         0  3916019171  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD101\r\n        1         1  3916019172  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD102\r\n        1         2  3916019173  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD103\r\n        1         3  3916019174  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD201\r\n        1         4  3916019175  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD202\r\n        1         5  3916019176  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD203<\/pre>
Temos discos en dous CPDs (2 cabinas). Na nomenclatura dos discos est\u00e1 especificado, pero vexamos a configuraci\u00f3n a nivel de FGs:<\/p>
[oracle@apora01 ~]$ asmcmd lsdsk -kG desdata\r\nTotal_MB  Free_MB  OS_MB  Name           Failgroup   Failgroup_Type  Library                                               Label          UDID  Product  Redund   Path\r\n   10236      944  10239  DESDATACPD101  DESDATAFG1  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD101                 UNKNOWN  ORCL:DESDATACPD101\r\n   10236      936  10239  DESDATACPD102  DESDATAFG1  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD102                 UNKNOWN  ORCL:DESDATACPD102\r\n   10236      924  10239  DESDATACPD103  DESDATAFG1  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD103                 UNKNOWN  ORCL:DESDATACPD103\r\n   10236      896  10239  DESDATACPD201  DESDATAFG2  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD201                 UNKNOWN  ORCL:DESDATACPD201\r\n   10236      952  10239  DESDATACPD202  DESDATAFG2  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD202                 UNKNOWN  ORCL:DESDATACPD202\r\n   10236      956  10239  DESDATACPD203  DESDATAFG2  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD203                 UNKNOWN  ORCL:DESDATACPD203\r\n<\/pre>
Temos 2 FGs, un por cada cabina. Realmente estamos protexendo con esta configuraci\u00f3n a perda dun CPD ou do acceso a unha cabina. Esta configuraci\u00f3n garante que un dato estar\u00e1 sempre almacenado nas d\u00faas 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\u00e1n 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?<\/strong> Esta pregunta non \u00e9 menor se temos en conta a descrici\u00f3n da documentaci\u00f3n Oracle de que \u00e9 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.<\/span><\/span><\/em><\/p><\/blockquote>
No noso caso, parece que o peor escenario tolerable \u00e9 sen d\u00fabida a perda dun FG completo, e xa vemos que non temos espacio, polo que neste escenario non se cumple esta definici\u00f3n. Non haber\u00eda ca\u00edda de BD, pero os datos non poder\u00edan volver a redistribuirse mantendo a redundancia (2 copias en FGs diferentes), sen engadir novos discos. \u00bfqu\u00e9 ocorre?<\/p>
Non todo \u00e9 Exadata<\/strong><\/span><\/h3>
Na mesma nota 1459611.1, podemos ver que:<\/p>
The amount of space displayed in this column takes the effects of mirroring into account. The value is computed as follows:<\/span><\/span><\/em><\/p>
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.<\/p>
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.<\/p><\/blockquote>
Importante destacar que nos dous casos, o c\u00f3mputo ten a precondici\u00f3n de que dispo\u00f1emos de mais de 2 FGs en redundancia normal e mais de 3 FGs en redundancia HIGH. O noso escenario est\u00e1 utilizando xustamente 2 FGs, e a\u00ed est\u00e1 a diferencia. Pero para explicala pode resultar \u00fatil os conceptos de redundancia aplicados en Exadata. Para elo, \u00e9 recomendable revisar a nota Understanding ASM Capacity and Reservation of Free Space in Exadata (Doc ID 1551288.1)<\/b> e ver a diferencia entre tolerancia a fallo de disco e tolerancia a fallo de celda:<\/span><\/p>
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.\u00a0<\/em><\/p>
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.<\/em><\/p><\/blockquote>
Introducimos un concepto que, cando menos eu, non se atopa na documentaci\u00f3n est\u00e1ndar de Oracle. A configuraci\u00f3n en ASM de Exadata pode planificarse para ser configurada para tolerar fallos de disco ou fallos de celda (m\u00faltiples discos). Se asociamos \u00e1 nosa configuraci\u00f3n 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\u00f3n emprega s\u00f3 2 FGs. Con isto \u00e9 tecnicamente imposible ter tolerancia a un fallo de DG<\/strong>. Por que? Pois porque simplemente non temos redundancia de DGs, s\u00f3 temos 2. Cando dispo\u00f1emos de mais DGs, \u00e9 cando o c\u00e1lculo do espacio requerido cambia, porque temos a opci\u00f3n, sen engadir novos discos, de mover copias dos datos \u00f3s outros FGs. A\u00ed si ten sentido computar todo o espazo dispo\u00f1ible no DG. De feito, esto encaixa na definici\u00f3n de Oracle de como se calcula REQUIRED_MIRROR_FREE_MB, onde \u00e9 expl\u00edcito que o c\u00e1lculo \u00e9, para un DG con redundancia NORMAL, cando se empregan mais de 2 FGs:<\/p>
Normal redundancy disk group with more than two failure groups<\/span><\/span><\/em><\/p>
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.<\/em><\/p><\/blockquote>
Isto non \u00e9 o noso caso, polo que realmente o m\u00e1ximo fallo tolerable dende o punto de vista deste par\u00e1metro \u00e9 o de 1 disco, e non de 1 FG. As\u00ed, con 2 FGs e un tama\u00f1o de LUN de 10GiBs, o espazo mirror requerido \u00e9 10GiBs, xusto o preciso para poder reubicar en FGs diferentes os datos que un \u00fanico disco ASM puidera conter.<\/p>
Conclusi\u00f3n<\/strong><\/span><\/h3>
\u00c9 moi importante, incluso cr\u00edtico, monitorizar REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB nun contorno Exadata ou nu hipot\u00e9tico contorno con redundancia NORMAL onde non te\u00f1amos protecci\u00f3n RAID a nivel de cabina hardware.<\/p>
Non te\u00f1en importancia os datos destes valores cando empregamos configuraci\u00f3ns baseadas en almacenamento con protecci\u00f3n RAID. Especificamente, no caso de que empreguemos a redundancia NORMAL para facer un mirror de datos entre d\u00faas cabinas diferentes a nivel de ASM, sen involucrar replicaci\u00f3n hardware ou software adicional de cabina.<\/p>
En ning\u00fan dos dous casos estamos nunha situaci\u00f3n inmediata de risco de perda de datos se atopamos valores negativos de USABLE_FILE_MB, s\u00f3 que, en caso de fallo, non hai xeito de recuperar a redundancia (o RAID l\u00f3xico de ASM), at\u00e9 que se recupere o almacenamento ou engadamos novos discos.<\/p>
“There’s more to the picture than meets the eye” Neil Young. Hey, hey, my, my
<\/em><\/p><\/blockquote>
Referencias<\/h4>
Informaci\u00f3n interesante relacionada con este artigo en:<\/p>
https:\/\/prutser.wordpress.com\/2013\/01\/03\/demystifying-asm-required_mirror_free_mb-and-usable_file_mb\/<\/a><\/p>
ASM Diskgroup shows USABLE_FILE_MB value in Negative<\/a><\/p>
<\/p><\/div>
Here you can create the content that will be used within the module.<\/p><\/div><\/div><\/div>\r\n\r\n[\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section bb_built=”1″ inner_width=”auto” inner_max_width=”1080px”][et_pb_row][et_pb_column type=”4_4″ custom_padding__hover=”|||” custom_padding=”|||”][et_pb_text _builder_version=”4.4.7″ text_text_shadow_horizontal_length=”text_text_shadow_style,%91object Object%93″ text_text_shadow_horizontal_length_tablet=”0px” text_text_shadow_vertical_length=”text_text_shadow_style,%91object Object%93″ text_text_shadow_vertical_length_tablet=”0px” text_text_shadow_blur_strength=”text_text_shadow_style,%91object Object%93″ text_text_shadow_blur_strength_tablet=”1px” link_text_shadow_horizontal_length=”link_text_shadow_style,%91object Object%93″ link_text_shadow_horizontal_length_tablet=”0px” link_text_shadow_vertical_length=”link_text_shadow_style,%91object Object%93″ link_text_shadow_vertical_length_tablet=”0px” link_text_shadow_blur_strength=”link_text_shadow_style,%91object Object%93″ link_text_shadow_blur_strength_tablet=”1px” ul_text_shadow_horizontal_length=”ul_text_shadow_style,%91object Object%93″ ul_text_shadow_horizontal_length_tablet=”0px” ul_text_shadow_vertical_length=”ul_text_shadow_style,%91object Object%93″ ul_text_shadow_vertical_length_tablet=”0px” ul_text_shadow_blur_strength=”ul_text_shadow_style,%91object Object%93″ ul_text_shadow_blur_strength_tablet=”1px” ol_text_shadow_horizontal_length=”ol_text_shadow_style,%91object Object%93″ ol_text_shadow_horizontal_length_tablet=”0px” ol_text_shadow_vertical_length=”ol_text_shadow_style,%91object Object%93″ ol_text_shadow_vertical_length_tablet=”0px” ol_text_shadow_blur_strength=”ol_text_shadow_style,%91object Object%93″ ol_text_shadow_blur_strength_tablet=”1px” quote_text_shadow_horizontal_length=”quote_text_shadow_style,%91object Object%93″ quote_text_shadow_horizontal_length_tablet=”0px” quote_text_shadow_vertical_length=”quote_text_shadow_style,%91object Object%93″ quote_text_shadow_vertical_length_tablet=”0px” quote_text_shadow_blur_strength=”quote_text_shadow_style,%91object Object%93″ quote_text_shadow_blur_strength_tablet=”1px” header_text_shadow_horizontal_length=”header_text_shadow_style,%91object Object%93″ header_text_shadow_horizontal_length_tablet=”0px” header_text_shadow_vertical_length=”header_text_shadow_style,%91object Object%93″ header_text_shadow_vertical_length_tablet=”0px” header_text_shadow_blur_strength=”header_text_shadow_style,%91object Object%93″ header_text_shadow_blur_strength_tablet=”1px” header_2_text_shadow_horizontal_length=”header_2_text_shadow_style,%91object Object%93″ header_2_text_shadow_horizontal_length_tablet=”0px” header_2_text_shadow_vertical_length=”header_2_text_shadow_style,%91object Object%93″ header_2_text_shadow_vertical_length_tablet=”0px” header_2_text_shadow_blur_strength=”header_2_text_shadow_style,%91object Object%93″ header_2_text_shadow_blur_strength_tablet=”1px” header_3_text_shadow_horizontal_length=”header_3_text_shadow_style,%91object Object%93″ header_3_text_shadow_horizontal_length_tablet=”0px” header_3_text_shadow_vertical_length=”header_3_text_shadow_style,%91object Object%93″ header_3_text_shadow_vertical_length_tablet=”0px” header_3_text_shadow_blur_strength=”header_3_text_shadow_style,%91object Object%93″ header_3_text_shadow_blur_strength_tablet=”1px” header_4_text_shadow_horizontal_length=”header_4_text_shadow_style,%91object Object%93″ header_4_text_shadow_horizontal_length_tablet=”0px” header_4_text_shadow_vertical_length=”header_4_text_shadow_style,%91object Object%93″ header_4_text_shadow_vertical_length_tablet=”0px” header_4_text_shadow_blur_strength=”header_4_text_shadow_style,%91object Object%93″ header_4_text_shadow_blur_strength_tablet=”1px” header_5_text_shadow_horizontal_length=”header_5_text_shadow_style,%91object Object%93″ header_5_text_shadow_horizontal_length_tablet=”0px” header_5_text_shadow_vertical_length=”header_5_text_shadow_style,%91object Object%93″ header_5_text_shadow_vertical_length_tablet=”0px” header_5_text_shadow_blur_strength=”header_5_text_shadow_style,%91object Object%93″ header_5_text_shadow_blur_strength_tablet=”1px” header_6_text_shadow_horizontal_length=”header_6_text_shadow_style,%91object Object%93″ header_6_text_shadow_horizontal_length_tablet=”0px” header_6_text_shadow_vertical_length=”header_6_text_shadow_style,%91object Object%93″ header_6_text_shadow_vertical_length_tablet=”0px” header_6_text_shadow_blur_strength=”header_6_text_shadow_style,%91object Object%93″ header_6_text_shadow_blur_strength_tablet=”1px” box_shadow_horizontal_tablet=”0px” box_shadow_vertical_tablet=”0px” box_shadow_blur_tablet=”40px” box_shadow_spread_tablet=”0px” vertical_offset_tablet=”0″ horizontal_offset_tablet=”0″ z_index_tablet=”0″]\r\n\r\n
<\/p>
<\/p>
<\/p>
Na mi\u00f1a experiencia, atopo que USABLE_FILE_MB \u00e9 un valor que xera moita confusi\u00f3n, incluso entre os propios DBAs Oracle. Esta confusi\u00f3n alcanza o cumio cando atopamos datos coma os seguintes, con valores negativos:<\/p>
[oracle@arumel ~]$ asmcmd lsdg\r\nState    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name\r\nMOUNTED  NORMAL  N         512   4096  4194304     61416     5608            10236           -2314              0             N  DESDATA\/\r\nMOUNTED  NORMAL  N         512   4096  4194304     61416      776            10236           -4730              0             N  DESFRA\/\r\nMOUNTED  NORMAL  N         512   4096  1048576     10230     9230             2046            3592              0             Y  VOTING\/\r\n<\/pre>
Por que te\u00f1o espacio usable para ficheiros en negativo? Quedei sen espacio no DG? Vou perder datos se perdo un disco?<\/p>
REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB
<\/span><\/strong><\/h3>
O valor de USABLE_FILE_MB est\u00e1 directamente relacionado co de REQUIRED_MIRROR_FREE_MB.<\/p>
REQUIRED_MIRROR_FREE_MB indica a cantidade de espacio que ser\u00eda precisa, tras producirse o maior fallo \u00f3 que o DG ten tolerancia, para poder recuperar a redundancia do diskgroup. Visto doutro xeito, \u00e9 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).<\/p>
USABLE_FILE_MB \u00e9 simplemente o espacio que ASM considera que est\u00e1 realmente dispo\u00f1ible para datos. \u00c9 un valor derivado de REQUIRED_MIRROR_FREE e de FREE_MB.<\/p>
\u00datil ou ru\u00eddo?<\/strong><\/span><\/h3>
Se non estamos traballando con Exadata ou con cabinas de disco sen protecci\u00f3n RAID, estaremos no segundo caso, estes par\u00e1metros son ru\u00eddo. Daquela, que sentido ten? Ben, mov\u00e1monos a un contorno Exadata. Neste caso, simplificando, temos unha m\u00e1quina onde o almacenamento non ten HA a nivel hardware (non existe RAID), \u00e9 ASM quen xestiona os discos. Un fallo de disco hardware vai ser trasladado a un fallo de disco ASM, o hardware non implanta ning\u00fan tipo de RAID. Isto fai que o risco hardware sexa contido pola configuraci\u00f3n software. Como? dando informaci\u00f3n de canto espacio necesitar\u00eda ASM para xestionar a perda dun disco, ou, tam\u00e9n configurable, de toda unha celda ASM (m\u00faltiples discos).<\/p>
Un escenario no que a redundancia ASM sen Exadata nos permite unha moi boa flexibilidade e incluso aforro de licencias hardware, \u00e9 un contorno de RAC estendido ou de HA de cabina (d\u00faas cabinas independentes) xestionadas por ASM. Neste caso, estamos dalg\u00fan modo empregando unha dobre redundancia externa, e ASM o que nos garante \u00e9 a sincronizaci\u00f3n de datos entre as cabinas cunha axeitada configuraci\u00f3n. Se falla un disco na cabina, ese erro non se propaga habitualmente a ASM. \u00d3 igual que cando empregamos unha \u00fanica 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, \u00e9, de feito, as incidencias mais habituais neste tipo de contornos \u00e9 a perda completa de todo un FG pola ca\u00edda dunha cabina, un switch ou de todo un CPD.<\/p>
Un pouco mais de informaci\u00f3n<\/strong><\/span><\/h3>
Volvendo \u00f3 exemplo inicial, agora que vimos estes datos, centr\u00e9monos 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\u00faas cabinas que sea topan en CPDs diferentes. As LUNs est\u00e1n polo tanto protexidas polos correspondentes RAIDs do hardware de almacenamento. A\u00ednda as\u00ed, de \u00f3nde sae o valor de REQUIRED_MIRROR_FREE_MB? Por que son 10GiBs concretamente? Vexamos a configuraci\u00f3n dos discos deste DG:<\/p>
[oracle@arumel ~]$ asmcmd lsdsk -pG desdata\r\nGroup_Num  Disk_Num      Incarn  Mount_Stat  Header_Stat  Mode_Stat  State   Path\r\n        1         0  3916019171  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD101\r\n        1         1  3916019172  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD102\r\n        1         2  3916019173  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD103\r\n        1         3  3916019174  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD201\r\n        1         4  3916019175  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD202\r\n        1         5  3916019176  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD203<\/pre>
Temos discos en dous CPDs (2 cabinas). Na nomenclatura dos discos est\u00e1 especificado, pero vexamos a configuraci\u00f3n a nivel de FGs:<\/p>
[oracle@apora01 ~]$ asmcmd lsdsk -kG desdata\r\nTotal_MB  Free_MB  OS_MB  Name           Failgroup   Failgroup_Type  Library                                               Label          UDID  Product  Redund   Path\r\n   10236      944  10239  DESDATACPD101  DESDATAFG1  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD101                 UNKNOWN  ORCL:DESDATACPD101\r\n   10236      936  10239  DESDATACPD102  DESDATAFG1  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD102                 UNKNOWN  ORCL:DESDATACPD102\r\n   10236      924  10239  DESDATACPD103  DESDATAFG1  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD103                 UNKNOWN  ORCL:DESDATACPD103\r\n   10236      896  10239  DESDATACPD201  DESDATAFG2  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD201                 UNKNOWN  ORCL:DESDATACPD201\r\n   10236      952  10239  DESDATACPD202  DESDATAFG2  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD202                 UNKNOWN  ORCL:DESDATACPD202\r\n   10236      956  10239  DESDATACPD203  DESDATAFG2  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD203                 UNKNOWN  ORCL:DESDATACPD203\r\n<\/pre>
Temos 2 FGs, un por cada cabina. Realmente estamos protexendo con esta configuraci\u00f3n a perda dun CPD ou do acceso a unha cabina. Esta configuraci\u00f3n garante que un dato estar\u00e1 sempre almacenado nas d\u00faas 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\u00e1n 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?<\/strong> Esta pregunta non \u00e9 menor se temos en conta a descrici\u00f3n da documentaci\u00f3n Oracle de que \u00e9 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.<\/span><\/span><\/em><\/p><\/blockquote>
No noso caso, parece que o peor escenario tolerable \u00e9 sen d\u00fabida a perda dun FG completo, e xa vemos que non temos espacio, polo que neste escenario non se cumple esta definici\u00f3n. Non haber\u00eda ca\u00edda de BD, pero os datos non poder\u00edan volver a redistribuirse mantendo a redundancia (2 copias en FGs diferentes), sen engadir novos discos. \u00bfqu\u00e9 ocorre?<\/p>
Non todo \u00e9 Exadata<\/strong><\/span><\/h3>
Na mesma nota 1459611.1, podemos ver que:<\/p>
The amount of space displayed in this column takes the effects of mirroring into account. The value is computed as follows:<\/span><\/span><\/em><\/p>
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.<\/p>
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.<\/p><\/blockquote>
Importante destacar que nos dous casos, o c\u00f3mputo ten a precondici\u00f3n de que dispo\u00f1emos de mais de 2 FGs en redundancia normal e mais de 3 FGs en redundancia HIGH. O noso escenario est\u00e1 utilizando xustamente 2 FGs, e a\u00ed est\u00e1 a diferencia. Pero para explicala pode resultar \u00fatil os conceptos de redundancia aplicados en Exadata. Para elo, \u00e9 recomendable revisar a nota Understanding ASM Capacity and Reservation of Free Space in Exadata (Doc ID 1551288.1)<\/b> e ver a diferencia entre tolerancia a fallo de disco e tolerancia a fallo de celda:<\/span><\/p>
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.\u00a0<\/em><\/p>
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.<\/em><\/p><\/blockquote>
Introducimos un concepto que, cando menos eu, non se atopa na documentaci\u00f3n est\u00e1ndar de Oracle. A configuraci\u00f3n en ASM de Exadata pode planificarse para ser configurada para tolerar fallos de disco ou fallos de celda (m\u00faltiples discos). Se asociamos \u00e1 nosa configuraci\u00f3n 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\u00f3n emprega s\u00f3 2 FGs. Con isto \u00e9 tecnicamente imposible ter tolerancia a un fallo de DG<\/strong>. Por que? Pois porque simplemente non temos redundancia de DGs, s\u00f3 temos 2. Cando dispo\u00f1emos de mais DGs, \u00e9 cando o c\u00e1lculo do espacio requerido cambia, porque temos a opci\u00f3n, sen engadir novos discos, de mover copias dos datos \u00f3s outros FGs. A\u00ed si ten sentido computar todo o espazo dispo\u00f1ible no DG. De feito, esto encaixa na definici\u00f3n de Oracle de como se calcula REQUIRED_MIRROR_FREE_MB, onde \u00e9 expl\u00edcito que o c\u00e1lculo \u00e9, para un DG con redundancia NORMAL, cando se empregan mais de 2 FGs:<\/p>
Normal redundancy disk group with more than two failure groups<\/span><\/span><\/em><\/p>
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.<\/em><\/p><\/blockquote>
Isto non \u00e9 o noso caso, polo que realmente o m\u00e1ximo fallo tolerable dende o punto de vista deste par\u00e1metro \u00e9 o de 1 disco, e non de 1 FG. As\u00ed, con 2 FGs e un tama\u00f1o de LUN de 10GiBs, o espazo mirror requerido \u00e9 10GiBs, xusto o preciso para poder reubicar en FGs diferentes os datos que un \u00fanico disco ASM puidera conter.<\/p>
Conclusi\u00f3n<\/strong><\/span><\/h3>
\u00c9 moi importante, incluso cr\u00edtico, monitorizar REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB nun contorno Exadata ou nu hipot\u00e9tico contorno con redundancia NORMAL onde non te\u00f1amos protecci\u00f3n RAID a nivel de cabina hardware.<\/p>
Non te\u00f1en importancia os datos destes valores cando empregamos configuraci\u00f3ns baseadas en almacenamento con protecci\u00f3n RAID. Especificamente, no caso de que empreguemos a redundancia NORMAL para facer un mirror de datos entre d\u00faas cabinas diferentes a nivel de ASM, sen involucrar replicaci\u00f3n hardware ou software adicional de cabina.<\/p>
En ning\u00fan dos dous casos estamos nunha situaci\u00f3n inmediata de risco de perda de datos se atopamos valores negativos de USABLE_FILE_MB, s\u00f3 que, en caso de fallo, non hai xeito de recuperar a redundancia (o RAID l\u00f3xico de ASM), at\u00e9 que se recupere o almacenamento ou engadamos novos discos.<\/p>
“There’s more to the picture than meets the eye” Neil Young. Hey, hey, my, my
<\/em><\/p><\/blockquote>
Referencias<\/h4>
Informaci\u00f3n interesante relacionada con este artigo en:<\/p>
https:\/\/prutser.wordpress.com\/2013\/01\/03\/demystifying-asm-required_mirror_free_mb-and-usable_file_mb\/<\/a><\/p>
ASM Diskgroup shows USABLE_FILE_MB value in Negative<\/a><\/p>
<\/p><\/div>
Here you can create the content that will be used within the module.<\/p><\/div><\/div><\/div>\r\n\r\n[\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section]","protected":false},"excerpt":{"rendered":"
  <\/p>\n","protected":false},"author":3,"featured_media":7328,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"on","_et_pb_old_content":"\r\n
\r\n
\r\n
\r\n
\r\n
Na mi\u00f1a experiencia, atopo que USABLE_FILE_MB \u00e9 un valor que xera moita confusi\u00f3n, incluso entre os propios DBAs Oracle. Esta confusi\u00f3n alcanza o cumio cando atopamos datos coma os seguintes, con valores negativos:<\/p>\r\n
[oracle@arumel ~]$ asmcmd lsdg\r\nState    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name\r\nMOUNTED  NORMAL  N         512   4096  4194304     61416     5608            10236           -2314              0             N  DESDATA\/\r\nMOUNTED  NORMAL  N         512   4096  4194304     61416      776            10236           -4730              0             N  DESFRA\/\r\nMOUNTED  NORMAL  N         512   4096  1048576     10230     9230             2046            3592              0             Y  VOTING\/\r\n<\/pre>\r\n
Por que te\u00f1o espacio usable para ficheiros en negativo? Quedei sen espacio no DG? Vou perder datos se perdo un disco?<\/p>\r\n
REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB
<\/span><\/strong><\/h3>\r\n
O valor de USABLE_FILE_MB est\u00e1 directamente relacionado co de REQUIRED_MIRROR_FREE_MB.<\/p>\r\n
REQUIRED_MIRROR_FREE_MB indica a cantidade de espacio que ser\u00eda precisa, tras producirse o maior fallo \u00f3 que o DG ten tolerancia, para poder recuperar a redundancia do diskgroup. Visto doutro xeito, \u00e9 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).<\/p>\r\n
USABLE_FILE_MB \u00e9 simplemente o espacio que ASM considera que est\u00e1 realmente dispo\u00f1ible para datos. \u00c9 un valor derivado de REQUIRED_MIRROR_FREE e de FREE_MB.<\/p>\r\n
\u00datil ou ru\u00eddo?<\/strong><\/span><\/h3>\r\n
Se non estamos traballando con Exadata ou con cabinas de disco sen protecci\u00f3n RAID, estaremos no segundo caso, estes par\u00e1metros son ru\u00eddo. Daquela, que sentido ten? Ben, mov\u00e1monos a un contorno Exadata. Neste caso, simplificando, temos unha m\u00e1quina onde o almacenamento non ten HA a nivel hardware (non existe RAID), \u00e9 ASM quen xestiona os discos. Un fallo de disco hardware vai ser trasladado a un fallo de disco ASM, o hardware non implanta ning\u00fan tipo de RAID. Isto fai que o risco hardware sexa contido pola configuraci\u00f3n software. Como? dando informaci\u00f3n de canto espacio necesitar\u00eda ASM para xestionar a perda dun disco, ou, tam\u00e9n configurable, de toda unha celda ASM (m\u00faltiples discos).<\/p>\r\n
Un escenario no que a redundancia ASM sen Exadata nos permite unha moi boa flexibilidade e incluso aforro de licencias hardware, \u00e9 un contorno de RAC estendido ou de HA de cabina (d\u00faas cabinas independentes) xestionadas por ASM. Neste caso, estamos dalg\u00fan modo empregando unha dobre redundancia externa, e ASM o que nos garante \u00e9 a sincronizaci\u00f3n de datos entre as cabinas cunha axeitada configuraci\u00f3n. Se falla un disco na cabina, ese erro non se propaga habitualmente a ASM. \u00d3 igual que cando empregamos unha \u00fanica 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, \u00e9, de feito, as incidencias mais habituais neste tipo de contornos \u00e9 a perda completa de todo un FG pola ca\u00edda dunha cabina, un switch ou de todo un CPD.<\/p>\r\n
Un pouco mais de informaci\u00f3n<\/strong><\/span><\/h3>\r\n
Volvendo \u00f3 exemplo inicial, agora que vimos estes datos, centr\u00e9monos 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\u00faas cabinas que sea topan en CPDs diferentes. As LUNs est\u00e1n polo tanto protexidas polos correspondentes RAIDs do hardware de almacenamento. A\u00ednda as\u00ed, de \u00f3nde sae o valor de REQUIRED_MIRROR_FREE_MB? Por que son 10GiBs concretamente? Vexamos a configuraci\u00f3n dos discos deste DG:<\/p>\r\n
[oracle@arumel ~]$ asmcmd lsdsk -pG desdata\r\nGroup_Num  Disk_Num      Incarn  Mount_Stat  Header_Stat  Mode_Stat  State   Path\r\n        1         0  3916019171  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD101\r\n        1         1  3916019172  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD102\r\n        1         2  3916019173  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD103\r\n        1         3  3916019174  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD201\r\n        1         4  3916019175  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD202\r\n        1         5  3916019176  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DESDATACPD203<\/pre>\r\n
Temos discos en dous CPDs (2 cabinas). Na nomenclatura dos discos est\u00e1 especificado, pero vexamos a configuraci\u00f3n a nivel de FGs:<\/p>\r\n
[oracle@apora01 ~]$ asmcmd lsdsk -kG desdata\r\nTotal_MB  Free_MB  OS_MB  Name           Failgroup   Failgroup_Type  Library                                               Label          UDID  Product  Redund   Path\r\n   10236      944  10239  DESDATACPD101  DESDATAFG1  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD101                 UNKNOWN  ORCL:DESDATACPD101\r\n   10236      936  10239  DESDATACPD102  DESDATAFG1  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD102                 UNKNOWN  ORCL:DESDATACPD102\r\n   10236      924  10239  DESDATACPD103  DESDATAFG1  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD103                 UNKNOWN  ORCL:DESDATACPD103\r\n   10236      896  10239  DESDATACPD201  DESDATAFG2  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD201                 UNKNOWN  ORCL:DESDATACPD201\r\n   10236      952  10239  DESDATACPD202  DESDATAFG2  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD202                 UNKNOWN  ORCL:DESDATACPD202\r\n   10236      956  10239  DESDATACPD203  DESDATAFG2  REGULAR         ASM Library - Generic Linux, version 2.0.4 (KABI_V2)  DESDATACPD203                 UNKNOWN  ORCL:DESDATACPD203\r\n<\/pre>\r\n
Temos 2 FGs, un por cada cabina. Realmente estamos protexendo con esta configuraci\u00f3n a perda dun CPD ou do acceso a unha cabina. Esta configuraci\u00f3n garante que un dato estar\u00e1 sempre almacenado nas d\u00faas 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\u00e1n 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?<\/strong> Esta pregunta non \u00e9 menor se temos en conta a descrici\u00f3n da documentaci\u00f3n Oracle de que \u00e9 REQUIRED_MIRROR_FREE_MB (extraido de 
\r\n
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.<\/span><\/span><\/em><\/p>\r\n<\/blockquote>\r\n
No noso caso, parece que o peor escenario tolerable \u00e9 sen d\u00fabida a perda dun FG completo, e xa vemos que non temos espacio, polo que neste escenario non se cumple esta definici\u00f3n. Non haber\u00eda ca\u00edda de BD, pero os datos non poder\u00edan volver a redistribuirse mantendo a redundancia (2 copias en FGs diferentes), sen engadir novos discos. \u00bfqu\u00e9 ocorre?<\/p>\r\n
Non todo \u00e9 Exadata<\/strong><\/span><\/h3>\r\n
Na mesma nota 1459611.1, podemos ver que:<\/p>\r\n
\r\n
The amount of space displayed in this column takes the effects of mirroring into account. The value is computed as follows:<\/span><\/span><\/em><\/p>\r\n
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.<\/p>\r\n
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.<\/p>\r\n<\/blockquote>\r\n
Importante destacar que nos dous casos, o c\u00f3mputo ten a precondici\u00f3n de que dispo\u00f1emos de mais de 2 FGs en redundancia normal e mais de 3 FGs en redundancia HIGH. O noso escenario est\u00e1 utilizando xustamente 2 FGs, e a\u00ed est\u00e1 a diferencia. Pero para explicala pode resultar \u00fatil os conceptos de redundancia aplicados en Exadata. Para elo, \u00e9 recomendable revisar a nota Understanding ASM Capacity and Reservation of Free Space in Exadata (Doc ID 1551288.1)<\/b> e ver a diferencia entre tolerancia a fallo de disco e tolerancia a fallo de celda:<\/span><\/p>\r\n
\r\n
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.\u00a0<\/em><\/p>\r\n
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.<\/em><\/p>\r\n<\/blockquote>\r\n
Introducimos un concepto que, cando menos eu, non se atopa na documentaci\u00f3n est\u00e1ndar de Oracle. A configuraci\u00f3n en ASM de Exadata pode planificarse para ser configurada para tolerar fallos de disco ou fallos de celda (m\u00faltiples discos). Se asociamos \u00e1 nosa configuraci\u00f3n 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\u00f3n emprega s\u00f3 2 FGs. Con isto \u00e9 tecnicamente imposible ter tolerancia a un fallo de DG<\/strong>. Por que? Pois porque simplemente non temos redundancia de DGs, s\u00f3 temos 2. Cando dispo\u00f1emos de mais DGs, \u00e9 cando o c\u00e1lculo do espacio requerido cambia, porque temos a opci\u00f3n, sen engadir novos discos, de mover copias dos datos \u00f3s outros FGs. A\u00ed si ten sentido computar todo o espazo dispo\u00f1ible no DG. De feito, esto encaixa na definici\u00f3n de Oracle de como se calcula REQUIRED_MIRROR_FREE_MB, onde \u00e9 expl\u00edcito que o c\u00e1lculo \u00e9, para un DG con redundancia NORMAL, cando se empregan mais de 2 FGs:<\/p>\r\n
\r\n
Normal redundancy disk group with more than two failure groups<\/span><\/span><\/em><\/p>\r\n
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.<\/em><\/p>\r\n<\/blockquote>\r\n
Isto non \u00e9 o noso caso, polo que realmente o m\u00e1ximo fallo tolerable dende o punto de vista deste par\u00e1metro \u00e9 o de 1 disco, e non de 1 FG. As\u00ed, con 2 FGs e un tama\u00f1o de LUN de 10GiBs, o espazo mirror requerido \u00e9 10GiBs, xusto o preciso para poder reubicar en FGs diferentes os datos que un \u00fanico disco ASM puidera conter.<\/p>\r\n
Conclusi\u00f3n<\/strong><\/span><\/h3>\r\n
\u00c9 moi importante, incluso cr\u00edtico, monitorizar REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB nun contorno Exadata ou nu hipot\u00e9tico contorno con redundancia NORMAL onde non te\u00f1amos protecci\u00f3n RAID a nivel de cabina hardware.<\/p>\r\n
Non te\u00f1en importancia os datos destes valores cando empregamos configuraci\u00f3ns baseadas en almacenamento con protecci\u00f3n RAID. Especificamente, no caso de que empreguemos a redundancia NORMAL para facer un mirror de datos entre d\u00faas cabinas diferentes a nivel de ASM, sen involucrar replicaci\u00f3n hardware ou software adicional de cabina.<\/p>\r\n
En ning\u00fan dos dous casos estamos nunha situaci\u00f3n inmediata de risco de perda de datos se atopamos valores negativos de USABLE_FILE_MB, s\u00f3 que, en caso de fallo, non hai xeito de recuperar a redundancia (o RAID l\u00f3xico de ASM), at\u00e9 que se recupere o almacenamento ou engadamos novos discos.<\/p>\r\n
\r\n
\"There's more to the picture than meets the eye\" Neil Young. Hey, hey, my, my
<\/em><\/p>\r\n<\/blockquote>\r\n
Referencias<\/h4>\r\n
Informaci\u00f3n interesante relacionada con este artigo en:<\/p>\r\n
https:\/\/prutser.wordpress.com\/2013\/01\/03\/demystifying-asm-required_mirror_free_mb-and-usable_file_mb\/<\/a><\/p>\r\n
https:\/\/aprakash.wordpress.com\/2014\/09\/17\/asm-diskgroup-shows-usable_file_mb-value-in-negative\/<\/p>\r\n<\/div>\r\n<\/div>\r\n<\/div>\r\n<\/div>\r\n","_et_gb_content_width":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[58,25,44],"tags":[31,34,33,35,30,32],"class_list":["post-6363","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oracle-2","category-portada","category-slider-post","tag-asm","tag-faiure","tag-rac","tag-redundancy","tag-required_mirror_free_mb","tag-usable_file_mb"],"yoast_head":"\nREQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB negativo - Arumel<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB negativo - Arumel\" \/>\n<meta property=\"og:description\" content=\"  \" \/>\n<meta property=\"og:url\" content=\"https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/\" \/>\n<meta property=\"og:site_name\" content=\"Arumel\" \/>\n<meta property=\"article:published_time\" content=\"2017-02-10T19:51:26+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2020-06-01T21:18:56+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/i0.wp.com\/arumel.com\/wp-content\/uploads\/2017\/02\/elsur01.png?fit=943%2C576&ssl=1\" \/>\n\t<meta property=\"og:image:width\" content=\"943\" \/>\n\t<meta property=\"og:image:height\" content=\"576\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Alberto Pereiro\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Alberto Pereiro\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"12 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/arumel.com\\\/usable_file_mb-failure-groups-exadata-e-worst-failure\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/arumel.com\\\/usable_file_mb-failure-groups-exadata-e-worst-failure\\\/\"},\"author\":{\"name\":\"Alberto Pereiro\",\"@id\":\"http:\\\/\\\/arumel.com\\\/#\\\/schema\\\/person\\\/1cdc5947f4270801792b02ec92332edc\"},\"headline\":\"REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB negativo\",\"datePublished\":\"2017-02-10T19:51:26+00:00\",\"dateModified\":\"2020-06-01T21:18:56+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/arumel.com\\\/usable_file_mb-failure-groups-exadata-e-worst-failure\\\/\"},\"wordCount\":2278,\"commentCount\":0,\"image\":{\"@id\":\"https:\\\/\\\/arumel.com\\\/usable_file_mb-failure-groups-exadata-e-worst-failure\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/i0.wp.com\\\/arumel.com\\\/wp-content\\\/uploads\\\/2017\\\/02\\\/elsur01.png?fit=943%2C576&ssl=1\",\"keywords\":[\"ASM\",\"faiure\",\"RAC\",\"redundancy\",\"REQUIRED_MIRROR_FREE_MB\",\"USABLE_FILE_MB\"],\"articleSection\":[\"Oracle\",\"portada\",\"slider-post\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/arumel.com\\\/usable_file_mb-failure-groups-exadata-e-worst-failure\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/arumel.com\\\/usable_file_mb-failure-groups-exadata-e-worst-failure\\\/\",\"url\":\"https:\\\/\\\/arumel.com\\\/usable_file_mb-failure-groups-exadata-e-worst-failure\\\/\",\"name\":\"REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB negativo - Arumel\",\"isPartOf\":{\"@id\":\"http:\\\/\\\/arumel.com\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/arumel.com\\\/usable_file_mb-failure-groups-exadata-e-worst-failure\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/arumel.com\\\/usable_file_mb-failure-groups-exadata-e-worst-failure\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/i0.wp.com\\\/arumel.com\\\/wp-content\\\/uploads\\\/2017\\\/02\\\/elsur01.png?fit=943%2C576&ssl=1\",\"datePublished\":\"2017-02-10T19:51:26+00:00\",\"dateModified\":\"2020-06-01T21:18:56+00:00\",\"author\":{\"@id\":\"http:\\\/\\\/arumel.com\\\/#\\\/schema\\\/person\\\/1cdc5947f4270801792b02ec92332edc\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/arumel.com\\\/usable_file_mb-failure-groups-exadata-e-worst-failure\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/arumel.com\\\/usable_file_mb-failure-groups-exadata-e-worst-failure\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/arumel.com\\\/usable_file_mb-failure-groups-exadata-e-worst-failure\\\/#primaryimage\",\"url\":\"https:\\\/\\\/i0.wp.com\\\/arumel.com\\\/wp-content\\\/uploads\\\/2017\\\/02\\\/elsur01.png?fit=943%2C576&ssl=1\",\"contentUrl\":\"https:\\\/\\\/i0.wp.com\\\/arumel.com\\\/wp-content\\\/uploads\\\/2017\\\/02\\\/elsur01.png?fit=943%2C576&ssl=1\",\"width\":943,\"height\":576},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/arumel.com\\\/usable_file_mb-failure-groups-exadata-e-worst-failure\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Portada\",\"item\":\"http:\\\/\\\/arumel.com\\\/en\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB negativo\"}]},{\"@type\":\"WebSite\",\"@id\":\"http:\\\/\\\/arumel.com\\\/#website\",\"url\":\"http:\\\/\\\/arumel.com\\\/\",\"name\":\"Arumel\",\"description\":\"Outro sitio WordPress m\u00e1is\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"http:\\\/\\\/arumel.com\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"http:\\\/\\\/arumel.com\\\/#\\\/schema\\\/person\\\/1cdc5947f4270801792b02ec92332edc\",\"name\":\"Alberto Pereiro\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a375a0c812714ad00388e6453d01b2231aa1ebc4e50587c1cf7eeee09e04eb64?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a375a0c812714ad00388e6453d01b2231aa1ebc4e50587c1cf7eeee09e04eb64?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a375a0c812714ad00388e6453d01b2231aa1ebc4e50587c1cf7eeee09e04eb64?s=96&d=mm&r=g\",\"caption\":\"Alberto Pereiro\"},\"url\":\"https:\\\/\\\/arumel.com\\\/en\\\/author\\\/alberto\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB negativo - Arumel","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/","og_locale":"en_US","og_type":"article","og_title":"REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB negativo - Arumel","og_description":"  ","og_url":"https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/","og_site_name":"Arumel","article_published_time":"2017-02-10T19:51:26+00:00","article_modified_time":"2020-06-01T21:18:56+00:00","og_image":[{"width":943,"height":576,"url":"https:\/\/i0.wp.com\/arumel.com\/wp-content\/uploads\/2017\/02\/elsur01.png?fit=943%2C576&ssl=1","type":"image\/png"}],"author":"Alberto Pereiro","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Alberto Pereiro","Est. reading time":"12 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/#article","isPartOf":{"@id":"https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/"},"author":{"name":"Alberto Pereiro","@id":"http:\/\/arumel.com\/#\/schema\/person\/1cdc5947f4270801792b02ec92332edc"},"headline":"REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB negativo","datePublished":"2017-02-10T19:51:26+00:00","dateModified":"2020-06-01T21:18:56+00:00","mainEntityOfPage":{"@id":"https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/"},"wordCount":2278,"commentCount":0,"image":{"@id":"https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/#primaryimage"},"thumbnailUrl":"https:\/\/i0.wp.com\/arumel.com\/wp-content\/uploads\/2017\/02\/elsur01.png?fit=943%2C576&ssl=1","keywords":["ASM","faiure","RAC","redundancy","REQUIRED_MIRROR_FREE_MB","USABLE_FILE_MB"],"articleSection":["Oracle","portada","slider-post"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/","url":"https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/","name":"REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB negativo - Arumel","isPartOf":{"@id":"http:\/\/arumel.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/#primaryimage"},"image":{"@id":"https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/#primaryimage"},"thumbnailUrl":"https:\/\/i0.wp.com\/arumel.com\/wp-content\/uploads\/2017\/02\/elsur01.png?fit=943%2C576&ssl=1","datePublished":"2017-02-10T19:51:26+00:00","dateModified":"2020-06-01T21:18:56+00:00","author":{"@id":"http:\/\/arumel.com\/#\/schema\/person\/1cdc5947f4270801792b02ec92332edc"},"breadcrumb":{"@id":"https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/#primaryimage","url":"https:\/\/i0.wp.com\/arumel.com\/wp-content\/uploads\/2017\/02\/elsur01.png?fit=943%2C576&ssl=1","contentUrl":"https:\/\/i0.wp.com\/arumel.com\/wp-content\/uploads\/2017\/02\/elsur01.png?fit=943%2C576&ssl=1","width":943,"height":576},{"@type":"BreadcrumbList","@id":"https:\/\/arumel.com\/usable_file_mb-failure-groups-exadata-e-worst-failure\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Portada","item":"http:\/\/arumel.com\/en\/"},{"@type":"ListItem","position":2,"name":"REQUIRED_MIRROR_FREE_MB e USABLE_FILE_MB negativo"}]},{"@type":"WebSite","@id":"http:\/\/arumel.com\/#website","url":"http:\/\/arumel.com\/","name":"Arumel","description":"Outro sitio WordPress m\u00e1is","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"http:\/\/arumel.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"http:\/\/arumel.com\/#\/schema\/person\/1cdc5947f4270801792b02ec92332edc","name":"Alberto Pereiro","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/a375a0c812714ad00388e6453d01b2231aa1ebc4e50587c1cf7eeee09e04eb64?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/a375a0c812714ad00388e6453d01b2231aa1ebc4e50587c1cf7eeee09e04eb64?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/a375a0c812714ad00388e6453d01b2231aa1ebc4e50587c1cf7eeee09e04eb64?s=96&d=mm&r=g","caption":"Alberto Pereiro"},"url":"https:\/\/arumel.com\/en\/author\/alberto\/"}]}},"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p9uvW6-1ED","jetpack_likes_enabled":true,"jetpack-related-posts":[{"id":7900,"url":"https:\/\/arumel.com\/en\/stored-outlines-en-standard-edition\/","url_meta":{"origin":6363,"position":0},"title":"Stored Outlines en Standard Edition","author":"Alberto Pereiro","date":"12 July, 2017","format":false,"excerpt":"","rel":"","context":"In "Oracle"","block_context":{"text":"Oracle","link":"https:\/\/arumel.com\/en\/oracle-en\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/arumel.com\/wp-content\/uploads\/2017\/07\/IMX0083.jpg?fit=1200%2C795&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/arumel.com\/wp-content\/uploads\/2017\/07\/IMX0083.jpg?fit=1200%2C795&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/arumel.com\/wp-content\/uploads\/2017\/07\/IMX0083.jpg?fit=1200%2C795&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/arumel.com\/wp-content\/uploads\/2017\/07\/IMX0083.jpg?fit=1200%2C795&ssl=1&resize=700%2C400 2x, https:\/\/i0.wp.com\/arumel.com\/wp-content\/uploads\/2017\/07\/IMX0083.jpg?fit=1200%2C795&ssl=1&resize=1050%2C600 3x"},"classes":[]}],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/arumel.com\/wp-content\/uploads\/2017\/02\/elsur01.png?fit=943%2C576&ssl=1","_links":{"self":[{"href":"https:\/\/arumel.com\/en\/wp-json\/wp\/v2\/posts\/6363","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/arumel.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/arumel.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/arumel.com\/en\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/arumel.com\/en\/wp-json\/wp\/v2\/comments?post=6363"}],"version-history":[{"count":32,"href":"https:\/\/arumel.com\/en\/wp-json\/wp\/v2\/posts\/6363\/revisions"}],"predecessor-version":[{"id":9938,"href":"https:\/\/arumel.com\/en\/wp-json\/wp\/v2\/posts\/6363\/revisions\/9938"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/arumel.com\/en\/wp-json\/wp\/v2\/media\/7328"}],"wp:attachment":[{"href":"https:\/\/arumel.com\/en\/wp-json\/wp\/v2\/media?parent=6363"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/arumel.com\/en\/wp-json\/wp\/v2\/categories?post=6363"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/arumel.com\/en\/wp-json\/wp\/v2\/tags?post=6363"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}