Posts

Showing posts from May, 2016

Migrando el UNDO_TABLESPACE en un Oracle RAC

Cambiar el TABLESPACE UNDO en una instancia dentro de un Oracle Rac es un proceso sencillo, el único paso que debemos considerar es hacer referencia a la instancia que estamos modificando cuando cambiamos el valor del parámetro UNDO_TABLESPACE. A continuación pasos sencillos para realizar esta tarea: Paso 1: Crearemos nuestro nuevo UNDO_TABLESPACE hacia la nueva dirección: SQL> create undo tablespace UNDOTBS1_1 datafile '+DATA_SERTEC' size 2G; Tablespace created. Paso 2: Verificando los parámetros actuales: SQL> show parameter undo_tablespace NAME                                 TYPE        VALUE ------------------------------------ ----------- ---------------- undo_tablespace                      string      UNDOTBS1 Paso 3: Asignando el nuevo tablespace al nodo 1 del RAC SQL> ALTER SYSTEM SET UNDO_TABLESPACE=UNDOTBS1_1 SCOPE=MEMORY SID='PINCENTP1'; System altered. Paso 4: Verifiquemos nuevam

Archivo de parámetros en Oracle Rac

Image
Días atrás, recibí un requerimiento: debía cambiar el UNDO TABLESPACE de una base de datos hacia una nueva ubicación en el almacenamiento donde se aloja. La razón, simplemente tener un mejor orden en las rutas de los datafiles. La tarea era algo de rutina que ya había hecho varias veces y que no requiere más que el tiempo en que la base de datos deja de utilizar los segmentos UNDO anteriores y comienza a utilizar los nuevos. Sin embargo, no había tomado algo en cuenta. Esta base de datos no era una instancia única, era parte de un RAC. En un ambiente RAC, cada nodo (instancia) trabaja de manera independiente y se comunica con una misma base de datos. La lógica nos dice que: cómo cada instancia es independiente, las transacciones que se ejecuten dentro de cada una son independientes también, por lo tanto, requieren de un UNDO TABLESPACE individual. La estructura sería algo similar a esto: El parámetro UNDO_TABLESPACE indica el nombre de tablespace que se utilizara para

Ejemplo práctico con SQL Tuning Advisor y SQL Access Advisor

Parte del perfil de un administrador de base de datos es el afinamiento de sentencias SQL, el afinamiento (o tuning) nos ayuda a mejorar el rendimiento de sentencias SQL dentro de nuestras bases de datos, mejorando: tiempos de respuesta de aplicaciones, tiempo de respuesta de procesos batch, consumo de recursos del sistema, escalabilidad de las aplicaciones. En Oracle, la ejecución de una sentencia SQL requiere tres fases: parseo, enlace y ejecución ( parse, bind and execute ). La parte de parseo es la que nos interesa para fines de este artículo. En esta, nuestro servidor interpreta lo que la sentencia significa y cuál es la mejor manera de ejecutarla. El parseo involucra interacción con el segmento de memoria SHARED POOL dentro de la instancia de la base de datos. Las estructuras del SHARED POOL convierten el SQL en algo ejecutable mediante un plan de ejecución. Plan de ejecución: es el resultado de la fase de parseo, indica la forma en cómo se va a acceder a los datos solici