La cláusula loggin/nologging añadida cuando creamos una tabla, índice, tablespace... determina si se crea registro de la sentencia en los redo log y su correcta restauración desde backup. Tiene guasa porque si creamos una tabla con opción nologging efectivamente no se crea registro pero de alguna manera esta si se tiene en cuenta en el diccionario de datos.
Ejemplo cronológico con malas consecuencias:
06:00 Hacemos backup con rman
09:00 Creamos tabla XXX (nologging)
09:45 Se pierde el datafile de la tabla
09:53 Recuperamos la base de datos (desde la copia, o desde la copia y archive)
Al terminar la recuperación los bloques correspondientes a la tabla/índice son marcados como corruptos y cuando intentemos acceder obtendremos un error como el siguiente:
ORA-01578: bloque de datos ORACLE corrupto (archivo número 43, bloque número 222806)
ORA-01110: archivo de datos 43: '/db/PROD/idatafiles/INDX3_20.dbf'
ORA-26040: Se ha cargado el bloque de datos utilizando la opción NOLOGGING
Casos como el anterior dan que pensar y debemos recapitular para tener más claro cuando hacerlo y cuando no. Debemos tener en cuenta:
- Recuperación/Standby
-Si la base de datos trabaja en modo archivelog. Si no es el caso tiene menos sentido usar la opción logging y por temas de rendimiento o volumen nos conviene más "probar suerte" y hacerlo con nologging.
-Si las copias las hacemos con rman. Si trabajamos en modo archivelog y usarmos rman para hacer backups lo más lógico sería hacerlo todo con la opción logging para reducir la perdida de datos al mínimo.
-Si tenemos una base de datos standby sincronizada mediante aplicación de archive logs. Es un caso como el anterior pero con más razón. Lo más lógico será hacer logging para que los objetos también se creen en el servidor en standby, tenemos que pensar que aquí podemos partir de una copia rman específica de hace tiempo y seguramente no estamos restaurandola cada semana ni cada mes.
-Velocidad de recuperación. En la creación de índices podemos precindir del logging pero debemos considerar que luego puede tocar recrearlos en la base de datos restaurada.
- Rendimiento
-El tiempo necesario para la creación de la tabla/índice. Obviamente si no dejamos log ganamos en velocidad pero aumentamos el riesgo.
-Lo asumible que es la pérdida de esa tabla índice mientras no sea recuperable. Si es una tabla que puede sobrar o prescindible (tabla de traza de cualquier aplicación) pues no pasa nada.
Con todo lo anterior y alguna cosa más que se queda en el tintero puede que nos decidamos a forzar el logging y quitarle ese poder de decisión al que ejecuta la sentencia de creación del objeto (más vale prevenir que curar, que luego vienen los llantos...). Aunque quizás no esté en sus manos, puede usar un ERP que es el intermediario en la creación de objetos de la base de datos y se los crea sin poder cambiar esa opción.
Mucho cuidado!! No vaya a ser que montemos una base de datos en standby y en el momento de la verdad cuando la vayamos a usar no tenga la mitad de las tablas.