Oracle proporciona diferentes métodos para detectar y corregir la corrupción de bloques de datos. Un método es soltar y recrear un objeto después de que se detecta la corrupción; sin embargo, esto no siempre es posible o deseable. Si la corrupción del bloque de datos está limitada a un subconjunto de filas, otra opción es reconstruir la tabla seleccionando todos los datos excepto las filas corruptas.
Otra forma de gestionar la corrupción de bloques de datos es utilizar el paquete DBMS_REPAIR. Puede usar DBMS_REPAIR para detectar y reparar bloques dañados en tablas e índices. Con este enfoque, puede abordar las corrupciones cuando sea posible, y también continuar usando objetos mientras intenta reconstruirlos o repararlos. DBMS_REPAIR utiliza el siguiente enfoque para abordar las corrupciones:
- Paso 1: Detectar y reportar Corrupciones
- Paso 2: Evaluar los Costos y Beneficios de Usar DBMS_REPAIR
- Paso 3: Hacer Objetos utilizables
- Paso 4: Reparar Corrupciones y Reconstruir Datos perdidos
Nota:
Cualquier corrupción que implique la pérdida de datos requiere el análisis y la comprensión de cómo esos datos encajan en el sistema de base de datos en general. Por lo tanto, DBMS_REPAIR no es una varita mágica, aún debe determinar si el enfoque de reparación proporcionado por este paquete es la herramienta adecuada para cada problema de corrupción específico. Dependiendo de la naturaleza de la reparación, puede perder datos y se pueden introducir inconsistencias lógicas; por lo tanto, debe sopesar las ganancias y pérdidas asociadas con el uso de DBMS_REPAIR.
Contenido del paquete DBMS_REPAIR
La tabla 19-1 describe los procedimientos que componen el paquete DBMS_REPAIR.
Tabla 19-1 DBMS_REPAIR Procedimientos
| Nombre del Procedimiento | Descripción |
|---|---|
|
|
Detecta e informa de las corrupciones en una tabla o índice. |
|
|
Marca bloques (que fueron identificados previamente por el procedimiento |
|
|
Los informes indexan entradas que apuntan a filas en bloques de datos dañados. |
|
|
Reconstruye un objeto freelists. |
|
|
Cuando se usa, ignora los bloques marcados como corruptos durante los análisis de tablas e índices. Si no se usa, se obtiene el error ORA-1578 al encontrar bloques marcados como corruptos. |
|
|
Proporciona funciones administrativas (crear, soltar, purgar) para tablas de reparación de DBMS_REPAIR y claves huérfanas. Nota: Estas tablas siempre se crean en el esquema SYS. |
Paso 1: Detectar y reportar Corrupciones
Su primera tarea, antes de usar DBMS_REPAIR, debe ser la detección y notificación de corrupciones. Los informes no solo indican qué está mal con un bloque, sino que también identifican la directiva de reparación asociada. Tiene varias opciones, además de DBMS_REPAIR, para detectar corrupciones. En el cuadro 19-2 se describen las diferentes metodologías de detección.
Cuadro 19-2 Comparación de los Métodos de Detección de Corrupción
| Método de detección | Descripción |
|---|---|
|
REPARACIÓN DE DBM |
Realiza la comprobación de bloques para una tabla, partición o índice especificados. Rellena una tabla de reparación con resultados. |
|
DB_VERIFY |
Utilidad de línea de comandos externa que realiza la comprobación de bloques en una base de datos sin conexión. |
|
ANALIZAR |
Utilizado con la opción VALIDAR ESTRUCTURA, verifica la integridad de la estructura de un índice, tabla o clúster; comprueba o verifica que las tablas e índices estén sincronizados. |
|
DB_BLOCK_CHECKING |
Identifica corruptos bloques antes de que realmente están marcados corruptos. Las comprobaciones se realizan cuando se realizan cambios en un bloque. |
DBMS_REPAIR: Usando los procedimientos check_object y admin_tables
Los controles e informes de procedimiento check_object bloquean los daños de un objeto especificado. Similar al ANÁLISIS…Declaración de VALIDACIÓN de ESTRUCTURA para índices y tablas, la comprobación de bloques se realiza para bloques de índice y datos, respectivamente.
No solo informa de los daños check_object, sino que también identifica las correcciones que se producirían si fix_corrupt_blocks se ejecuta posteriormente en el objeto. Esta información está disponible rellenando una tabla de reparación, que primero debe crearse mediante el procedimiento admin_tables.
Después de ejecutar el procedimiento check_object , una simple consulta en la tabla de reparación muestra las directivas de daños y reparación del objeto. Con esta información, puede evaluar la mejor manera de abordar los problemas reportados.
DB_VERIFY: Realizar una comprobación de base de datos sin conexión
Normalmente, se utiliza DB_VERIFY como una utilidad de diagnóstico sin conexión cuando se producen problemas de corrupción de datos.
Véase También: Para obtener más información sobre DB_VERIFY, consulte Utilidades Oracle8i.
ANALIZAR: Informes de corrupción
La TABLA ANALIZAR…La instrucción VALIDATE STRUCTURE valida la estructura del objeto analizado. Si Oracle valida correctamente la estructura, se le devuelve un mensaje de confirmación de su validación. Si Oracle encuentra daños en la estructura del objeto, se le devuelve un mensaje de error. En este caso, soltaría y recrearía el objeto.
Consulte También: Para obtener más información sobre la instrucción ANALYZE, consulte la Referencia SQL de Oracle8i.
DB_BLOCK_CHECKING (Parámetro de inicialización de Comprobación de bloques)
Puede establecer la comprobación de bloques para instancias a través del parámetro DB_BLOCK_CHECKING (el valor predeterminado es TRUE); esto comprueba los bloques de datos e índices cada vez que se modifican. DB_BLOCK_CHECKING es un parámetro dinámico, modificable mediante la instrucción ALTER SYSTEM SET.
Paso 2: Evaluar los Costos y Beneficios de usar DBMS_REPAIR
Antes de usar DBMS_REPAIR, debe sopesar los beneficios de su uso en relación con las responsabilidades; también debe examinar otras opciones disponibles para abordar objetos corruptos.
Un primer paso es responder a las siguientes preguntas:
- ¿Cuál es el alcance de la corrupción?
Para determinar si hay daños y acciones de reparación, ejecute el procedimiento
check_objecty consulte la tabla de reparación. - ¿Qué otras opciones están disponibles para abordar la corrupción de bloques?
Suponiendo que los datos estén disponibles de otra fuente, suelte, vuelva a crear y vuelva a llenar el objeto. Otra opción es emitir la TABLA CREATE…COMO instrucción SELECT de la tabla corrupta para crear una nueva.
Puede ignorar la corrupción excluyendo filas corruptas de las instrucciones select.
Realice la recuperación de medios.
- ¿Qué corrupciones lógicas o efectos secundarios se introducirán cuando utilice DBMS_REPAIR para hacer que un objeto sea utilizable? ¿Se pueden abordar? ¿Cuál es el esfuerzo necesario para hacerlo?
Es posible que no tenga acceso a filas en bloques marcados como corruptos. Sin embargo, un bloque puede estar marcado como corrupto aunque todavía haya filas a las que pueda acceder de forma válida.
Las restricciones de integridad referencial pueden romperse cuando los bloques están marcados como corruptos. Si esto ocurre, deshabilite y vuelva a habilitar la restricción; se informará de cualquier inconsistencia. Después de solucionar todos los problemas, debería poder volver a habilitar la restricción con éxito.
La corrupción lógica puede ocurrir cuando hay desencadenadores definidos en la tabla. Por ejemplo, si se vuelven a insertar filas, ¿deberían activarse o no los disparadores de inserción? Puede resolver estos problemas solo si comprende los disparadores y su uso en la instalación.
Los bloques Freelist pueden ser inaccesibles. Si un bloque corrupto está a la cabeza o a la cola de un freelist, la administración de espacio reinicia al freelist. Entonces puede haber bloques que deberían estar en un freelist, que no lo están. Puede resolver esto ejecutando el procedimiento
rebuild_freelists.Es posible que los índices y las tablas no estén sincronizados. Puede resolver esto ejecutando primero el procedimiento
dump_orphan_keys(para obtener información de las claves que podría ser útil para reconstruir datos dañados). A continuación, emita la instrucción ALTER INDEX REBUILD ONLINE para volver a sincronizar la tabla y sus índices. - Si la reparación implica la pérdida de datos, ¿se pueden recuperar estos datos?
Puede recuperar datos del índice cuando un bloque de datos está marcado como corrupto. Los procedimientos
dump_orphan_keyspueden ayudarlo a recuperar esta información. Por supuesto, la recuperación de datos de esta manera depende de la cantidad de redundancia entre los índices y la tabla.
Paso 3: Hacer que los objetos sean utilizables
En este paso DBMS_REPAIR hace que el objeto sea utilizable ignorando las corrupciones durante los análisis de tablas e índices.
Reparación de corrupción: Con los procedimientos fix_corrupt_blocks y skip_corrupt_blocks
Puede hacer que un objeto corrupto sea utilizable estableciendo un entorno que omita las corrupciones que permanecen fuera del alcance de las capacidades de reparación de DBMS_REPAIR.
Si las corrupciones implican una pérdida de datos, como una fila incorrecta en un bloque de datos, todos estos bloques se marcan como corruptos mediante el procedimiento fix_corrupt_blocks. A continuación, puede ejecutar el procedimiento skip_corrupt_blocks, que omitirá los bloques marcados como corruptos para el objeto. Cuando se establece skip, los análisis de tablas e índices omiten todos los bloques marcados como corruptos. Esto se aplica tanto a los bloques corruptos de medios como de software.
Implicaciones al Omitir bloques corruptos
Si un índice y una tabla no están sincronizados, una TRANSACCIÓN de SOLO LECTURA de TRANSACCIÓN ESTABLECIDA puede ser inconsistente en situaciones en las que una consulta sondea solo el índice, y luego una consulta posterior sondea tanto el índice como la tabla. Si el bloque de tabla está marcado como corrupto, las dos consultas devolverán resultados diferentes, rompiendo así las reglas de una transacción de solo lectura. Una forma de abordar esto es no omitir corrupciones cuando se está en una TRANSACCIÓN de SOLO LECTURA ESTABLECIDA.
Se produce un problema similar al seleccionar filas encadenadas. Esencialmente, una consulta de la misma fila puede o no acceder a la corrupción, lo que da resultados diferentes.
Paso 4: Reparar Daños y Reconstruir Datos perdidos
Después de hacer que un objeto sea utilizable, puede realizar las siguientes actividades de reparación.
Recupere datos Utilizando los Procedimientos dump_orphan_keys
El procedimiento dump_orphan_keys informa sobre entradas de índice que apuntan a filas en bloques de datos dañados. Todas estas entradas de índice se insertan en una tabla de claves huérfanas que almacena la clave y el rowid de la corrupción.
Después de recuperar la información de entrada de índice, puede reconstruir el índice utilizando la instrucción ALTER INDEX REBUILD ONLINE.
Repara Freelists Utilizando el Procedimiento rebuild_freelists
Cuando se encuentra un bloque marcado como «corrupto» en la cabeza o cola de un freelist, el freelist se reinicia y se devuelve un error. Aunque esto elimina el bloque ofensivo del freelist, hace que pierdas el acceso de freelist a todos los bloques que siguieron al bloque corrupto.
Puede utilizar el procedimiento rebuild_freelists para reiniciar los freelists. El objeto se escanea, y si es apropiado que un bloque esté en el freelist, se agrega al freelist maestro. Los grupos de freelance se manejan montando los bloques de una manera equitativa, un bloque a la vez. Cualquier bloque marcado como «corrupto» en el objeto se ignora durante la reconstrucción.
Limitaciones y restricciones
Los procedimientos DBMS_REPAIR tienen las siguientes limitaciones:
- Se admiten tablas con LÓBULOS, tablas anidadas y VARRAYS, pero se ignoran las columnas fuera de línea. Los clústeres
- se admiten en los procedimientos
skip_corrupt_blocksyrebuild_freelist, pero no en el procedimientocheck_object. - Las tablas organizadas por índice y los índices LOB no son compatibles.
- El procedimiento
dump_orphan_keysno funciona en índices de mapa de bits ni en índices basados en funciones. - El procedimiento
dump_orphan_keysprocesa claves que tienen, como máximo, 3.950 bytes de longitud.
Procedimientos DBMS_REPAIR
Esta sección contiene descripciones detalladas de los procedimientos DBMS_REPAIR.
check_object
El procedimiento check_object comprueba los objetos especificados y rellena la tabla de reparación con información sobre corrupciones y directivas de reparación. La validación consiste en comprobar todos los bloques del objeto. Opcionalmente, puede especificar un rango, un nombre de partición o un nombre de subpartición cuando desee verificar una parte de un objeto.
procedure check_object(schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', flags IN binary_integer DEFAULT NULL, relative_fno IN binary_integer DEFAULT NULL, block_start IN binary_integer DEFAULT NULL, block_end IN binary_integer DEFAULT NULL, corrupt_count OUT binary_integer)
Tabla 19-3 La check_object Procedimiento
| Argumento | Descripción |
|---|---|
|
|
nombre del Esquema del objeto a comprobar. |
|
|
Nombre de la tabla o el índice para ser revisados. |
|
|
Nombre de la partición o subpartición a verificar. Si se trata de un objeto con particiones y no se especifica |
|
|
Tipo de objeto para ser procesados. Debe ser TABLE_OBJECT o INDEX_OBJECT. El valor predeterminado es TABLE_OBJECT. |
|
|
Nombre de la reparación de la tabla a ser poblada. La tabla debe existir en el esquema SYS. Utilice el procedimiento |
|
|
Reservado para uso futuro. |
|
|
Relación del número de archivo. Se usa cuando se especifica un rango de bloques. |
|
|
El primer bloque a procesar si se especifica un rango de bloques. Solo se puede especificar si el objeto es una sola tabla, partición o subpartición. |
|
|
El último bloque a procesar si se especifica un rango de bloques. Solo se puede especificar si el objeto es una sola tabla, partición o subpartición. Si solo se especifica uno de los bloques block_start o block_end, el otro valor predeterminado es el primer o el último bloque del archivo, respectivamente. |
|
|
El número de daños reportados. |
fix_corrupt_blocks
Utilice este procedimiento para corregir los bloques dañados de objetos especificados en función de la información de la tabla de reparación generada previamente por el procedimiento check_object. Antes de efectuar cualquier cambio en un bloque, el bloque se comprueba para asegurarse de que el bloque sigue corrupto. Los bloques corruptos se reparan marcando el software de bloques dañado. Cuando se realiza una reparación, la fila asociada en la tabla de reparaciones se actualiza con una marca de tiempo fija.
procedure fix_corrupt_blocks( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', flags IN boolean DEFAULT NULL, fix_count OUT binary_integer)
Tabla 19-4 La fix_corrupt_blocks Procedimiento
| Argumento | Descripción |
|---|---|
|
|
nombre de Esquema. |
|
|
Nombre del objeto con el corrupto bloques fijos. |
|
|
Nombre de la partición o subpartición que se procesará. Si se trata de un objeto con particiones y no se especifica |
|
|
Tipo de objeto para ser procesados. Debe ser TABLE_OBJECT o INDEX_OBJECT. El valor predeterminado es TABLE_OBJECT. |
|
|
Nombre de la tabla de reparación con las directivas de reparación. Debe existir en el esquema SYS. |
|
|
Reservado para uso futuro. |
|
|
El número de bloques fijos. |
dump_orphan_keys
Informa sobre entradas de índice que apuntan a filas en bloques de datos dañados. Para cada entrada de índice encontrada, se inserta una fila en la tabla huérfana especificada.
Si se especifica la tabla de reparación, los bloques dañados asociados a la tabla base se gestionan además de todos los bloques de datos marcados como software dañado. De lo contrario, solo se manejan los bloques marcados como corruptos.
Esta información puede ser útil para reconstruir filas perdidas en la tabla y para fines de diagnóstico.
procedure dump_orphan_keys( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT INDEX_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', orphan_table_name IN varchar2 DEFAULT 'ORPHAN_KEY_TABLE', key_count OUT binary_integer)
Tabla 19-5 La dump_orphan_keys Procedimiento
| Argumento | Descripción |
|---|---|
|
|
nombre de Esquema. |
|
|
nombre de Objeto. |
|
|
Nombre de la partición o subpartición que se procesará. Si se trata de un objeto con particiones y no se especifica |
|
|
Tipo de objeto para ser procesados. El valor predeterminado es INDEX_OBJECT. |
|
|
Nombre de la tabla de reparación que contiene información sobre bloques dañados en la tabla base. La tabla especificada debe existir en el esquema SYS. El procedimiento |
|
|
Nombre de la tabla de claves huérfanas que se rellenará con información sobre cada entrada de índice que haga referencia a una fila de un bloque de datos dañado. La tabla especificada debe existir en el esquema SYS. El procedimiento |
|
|
Número de entradas de índice procesados. |
rebuild_freelists
Reconstruye la freelists para el objeto especificado. Todos los bloques libres se colocan en el freelist maestro. Todos los demás trabajadores independientes están a cero. Si el objeto tiene varios grupos de freelists, los bloques libres se distribuyen entre todos los freelists, asignándose a los diferentes grupos de forma conjunta.
procedure rebuild_freelists( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT);
Tabla 19-6 El Procedimiento rebuild_freelists
| Argumento | Descripción |
|---|---|
|
|
Nombre del esquema. |
|
|
Nombre del objeto cuya freelists son para ser reconstruido. |
|
|
Nombre de partición o subpartición cuyos freelists se van a reconstruir. Si se trata de un objeto con particiones y no se especifica |
|
|
Tipo de objeto para ser procesados. Debe ser TABLE_OBJECT o INDEX_OBJECT. El valor predeterminado es TABLE_OBJECT. |
skip_corrupt_blocks
Habilita o deshabilita el salto de bloques dañados durante el escaneo de índices y tablas del objeto especificado. Cuando el objeto es una tabla, skip se aplica a la tabla y a sus índices. Cuando el objeto es un clúster, se aplica a todas las tablas del clúster y a sus respectivos índices.
procedure skip_corrupt_blocks( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, flags IN boolean DEFAULT SKIP_FLAG);
Tabla 19-7 La skip_corrupt_blocks Procedimiento
| Argumento | Descripción |
|---|---|
|
|
nombre del Esquema del objeto a procesar. |
|
|
Nombre del objeto. |
|
|
Nombre de la partición o subpartición que se procesará. Si se trata de un objeto con particiones y no se especifica |
|
|
Tipo de objeto para ser procesados. Debe ser TABLE_OBJECT o CLUSTER_OBJECT. El valor predeterminado es TABLE_OBJECT. |
|
|
Si se especifica SKIP_FLAG, activa el salto de bloques corruptos de software para el objeto durante el análisis de índices y tablas. Si se especifica NOSKIP_FLAG, las exploraciones que encuentran bloques corruptos de software devuelven un ORA-1578. |
admin_tables
Proporciona funciones administrativas para tablas de claves huérfanas y de reparación.
procedure admin_tables( table_name IN varchar2, table_type IN binary_integer, action IN binary_integer, tablespace IN varchar2 DEFAULT NULL);
Tabla 19-8 La admin_tables Procedimiento
| Argumento | Descripción |
|---|---|
|
|
Nombre de la tabla para ser procesados. El valor predeterminado es ‘ORPHAN_KEY_TABLE ‘ o’ REPAIR_TABLE ‘ basado en el tipo de tabla especificado. Cuando se especifique, el nombre de la tabla debe tener el prefijo apropiado, ‘ORPHAN_’ o ‘REPAIR_’. |
|
|
Tipo de tabla, debe ser uno de ORPHAN_TABLE o REPAIR_TABLE. |
|
|
Indica qué acción administrativa para llevar a cabo. Debe ser CREATE_ACTION, PURGE_ACTION, o DROP_ACTION. Si la tabla ya existe y se especifica CREATE_ACTION, se devuelve un error. PURGE_ACTION indica que se deben eliminar todas las filas de la tabla asociadas a objetos inexistentes. Si la tabla no existe y se especifica DROP_ACTION, se devuelve un error. Cuando se especifican CREATE_ACTION y DROP_ACTION, se crea y se suelta una vista asociada denominada DBA_<nombre_delatable>, respectivamente. La vista se define de modo que se eliminen las filas asociadas con objetos inexistentes. Creado en el esquema SYS. |
|
|
Indica el espacio que se utilizará para crear una tabla. De forma predeterminada, se utiliza el espacio de tabla predeterminado de SYS. Se devuelve un error si se especifica el espacio de tabla y la acción no es CREATE_ACTION. |
DBMS_REPAIR Excepciones
| 942 | reparación de la tabla no existe |
| 1418 | índice especificado no existe |
| 24120 | parámetro no válido |
| 24121 | no se puede especificar el CASCADE_FLAG y una gama de bloques de |
| 24122 | no válido gama de bloques de |
| 24124 | acción no válido parámetro especificado |
| 24126 | CASCADE_FLAG especificado y el objeto no es una tabla |
| 24127 | espacio de tabla especificado y la acción no es CREATE_ACTION |
| 24128 | partición especificada para objeto sin particiones |
| 24129 | nombre de tabla de claves huérfanas inválidas-debe tener el prefijo ‘ORPHAN_’ |
| 24129 | la tabla de reparación especificada no comienza con el prefijo ‘REPAIR_’ |
| 24131 | la tabla de reparación tiene columnas incorrectas |
| 24132 | el nombre de la tabla de reparación es demasiado largo |