Database Insider - Julio Ayapan

Oracle Real Application Clusters (Oracle RAC) es una versión en clúster de Oracle Database basada en una pila integral de alta disponibilidad que asegura escalabilidad y agilidad para cualquier aplicación. Para que una base de datos con arquitectura de cluster funcione, debe de estar conectada entre sus nodos para mantener comunicación eficaz y sincronizada. En el caso de un Oracle RAC, esta interconexión es administrada por el software de Oracle Clusterware. Oracle Clusterware es la base o los cimientos para la arquitectura de Oracle RAC. La comunicación entre nodos es una característica denominada CLUSTER INTERCONNECT. La función principal de esta red (privada: solo visible entre los nodos del cluster) es mantener un “Heartbeat” entre ellos y el cluster en general, en este caso Oracle Clusterware, mediante el cual cada uno de los nodos informara su estado y disposición dentro del cluster. En caso de falla de comunicación Oracle Clusterware tomara las medidas pertinentes...

El denominado snapshot controlfile es una copia exacta del Control File creada por RMAN. El objetivo de esta copia es tener una versión consistente del Control File cuando se ejecute un respaldo o una re sincronización del RECOVERY CATALOG (si usamos uno). En ambientes SINGLE, el snapshot Control File puede residir en cualquier ubicación física de nuestro servidor, siempre y cuando sea accesible desde RMAN. En un ambiente Oracle Rac, el Snapshot Control  File debe existir en una ubicación compartida por todos los miembros del clúster. Si el SCF no puede ser accedido por alguno de los miembros del Oracle RAC obtendremos el siguiente mensaje al intentar respaldar el Control File: RMAN-03009: failure of backup command on ch1 channel at 06/09/2016 13:09:12 ORA-00245: control file backup failed; target is likely on a local file system Para resolverlo podemos seguir los siguientes pasos: Paso 1: Averiguar la ubicación actual  del SCF (siempr...

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            ...

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...