Oracle

Tuve un comentario que me pareció muy interesante, se trataba de identificar un problema de soporte con un proceso que falló y generó un trace file. La idea detrás es la de interpretar un archivo de trace mediante un método que pudiera además hacer uso de la información que publiqué en el post Capas del Kernel de Oracle.

Con mucha frecuencia me encuentro en situaciones en las que hay que interpretar un archivo de dump de Oracle, muchas de estas veces el contenido del archivo tiene información de debug. También a menudo me encuentro con DBAs que aún teniendo estos archivos importantísimos no saben cómo interpretarlos.

Hoy compartire con ustedes una entrevista, inagurando esta sección, titulada "Entrevistando a un Profesional".

Redo Generation and Recoverability

The purpose of redo generation is to ensure recoverability. This is the reason why, Oracle does not give the DBA a lot of control over redo generation. If the instance crashes, then all the changes within SGA will be lost. Oracle will then use the redo entries in the online redo files to bring the database to a consistent state. The cost of maintaining the redolog records is an expensive operation involving latch management operations (CPU) and frequent write access to the redolog files (I/O). You can avoid redo logging for certain operations using the NOLOGGING feature.

Einführung

Die an mich meistgestellte Frage über NOLOGGING ist: Wenn ich eine Tabelle mit NOLOGGING erstelle, bedeutet das dass “Redo niemals erstellt wird” oder nur dass bei der Initialisierung kein Redo erstellt wird aber DML weiter hinten im Workflow Redo erstellt? Wie und wann kann man NOLOGGING implementieren?

Introduccion

La pregunta medular sobre NOLOGGING que escucho todo el tiempo es: ¿Crear una tabla con la opción NOLOGGING significa que “jamas habra generacion de redo”, o solo la operación inicial de creación no tiene generación de redo. Otras interrogantes como: ¿Que sentencias DML generan redo? ¿Cómo y cuando se puede emplear la opción NOLOGGING?