Utilizar un Full Export para revisar la consistencia de la base de datos

Muchas veces, cuando realizamos una importación o recreación de una base de datos, realizamos un full export, para verificar que los respaldos, podrán ser realizados, sin problemas.

Pero un "Full Export", puede también ser utilizado, con algún grado de eficiencia, para verificar que una base de datos Oracle, esta consistente.

Como ya sabemos, un "export", realiza un full scan de todas las tablas de la base de datos, por tanto, podríamos afirmar, que al menos, todas las tablas de una instancia, pueden ser leídas, sin embargo, hay que tener claro también, que un "export", sólo lee aquellos bloques que estan antes de la marca de agua.

Ahora bien, un "export", no detecta lo siguiente:

1. Corrupciones de disco, arriba de la marca de agua en los objetos
2. Corrupción a nivel de indíces
3. Corrupciones en segmentos libres o temporales
4. Corrupciones de datos en columnas ( Como fechas inválidas )
5. El export no hace una lectura total para el diccionario de la base de datos, por tanto, no puede detectar corrupciones en el tablespaces SYSTEM.

Una vez, que vemos estas limitaciones del "export", nuevamente nos hacemos la pregunta:
Es un export una buena política de respaldos básica.?

La respuesta claramente en base a las cinco ( 5 ) limitaciones indicadas, es no, sin embargo, puede ser un método relativamente eficiente, para revisar consistencia lógica y detectar corrupción física en los bloques utilizados.

Si deseo utilizar la aplicación "export", para verificar la consistencia en los datos, pueden realizar el export, redireccionando el archivo de destino al dispositivo "NULO".

1. En Unix, /dev/null
2. En OpenVMS, NULL

Ejemplo: exp system/manager file=/dev/null full=yes