Por defecto Oracle Clusterware está configurado para levantar la VIP, el listener, la instancia, ASM, los servicios de base de datos y otros recursos durante el arranque del sistema (system boot). Es posible modificar este comportamiento configurando el parámetro AUTO_START. Para ello, a este parámetro hay que asignarle el valor 2 (AUTO_START=2). Cuando un nodo se reinicia o cuando se inicia Oracle Clusterware, los recursos que tengan asignado el parámetro AUTO_START en 2 no se levantarán. Si luego se desea levantarlos, habrá que hacerlo manualmente con Server Control (SRVCTL).
Si bien esto es posible hacerlo, sobre todo a la hora de hacer troubleshooting de problemas o mantenimiento del sistema; lo mejor es implementar Oracle Clusterware y Oracle Real Application Clusters de modo tal que todos los recursos se inicien automáticamente junto con el inicio del sistema (system boot).
Políticas manuales y automáticas
Cómo subir y bajar instancias Oracle RAC con Server Control
El comando SRVCTL START DATABASE levanta una base de datos Oracle en cluster junto con sus instancias.
El comando SRVCTL STOP DATABASE baja una base de datos Oracle, sus instancias y servicios.
El comando SRVCTL START INSTANCE levanta una instancia de una base de datos Oracle en cluster. Además, este comando, levanta todos los servicios habilitados.
El comando SRVCTL STOP INSTANCE baja instancias y todos los servicios habilitados en dicha instancia.
Si se pretende bajar un objeto y que no vuelva a levantarse es necesario deshabilitarlo.
Cómo subir y bajar instancias Oracle RAC con SqlPlus
Si se desea subir o bajar sólo una intancia estando conectado al nodo local, hay que asegurarse de que el ambiente esté configurado con el SID de la instancia local.
Para subier o bajar una instancia local con SqlpPlus es necesario iniciar una sesión conectándose como SYSDBA o SYSOPER y luego ejecutar el comando requerido (STARTUP o SHUTDOWN).
También es factible subir o bajar múltiples instancias desde una simple sesión de SqlPlus en un nodo a través de Net Services. Para lograr esto se puede, por ejemplo, utilizar SqlPlus desde uno de los nodos y subir (o bajar) un nodo en forma local y el otro en forma remota.
Cómo subir y bajar instancias en Oracle RAC
En un entorno Oracle RAC múltiples instancias pueden tener la misma base de datos abierta al mismo tiempo. Subir o bajar una instancia no interfiere con la operación del resto de las intancias que componen el cluster.
Los procedimientos para subir y bajar instancias en Oracle RAC son idénticos a los procedimientos que se utilizan en una configuración single instance. La única diferencia se da en el comando SHUTDOWN TRANSACTIONAL. El comando SHUTDOWN TRANSACTIONAL con la opción LOCAL permite bajar una instancia una vez que todas las transacciones activas de dicha instancia hicieron COMMIT o ROLLBACK. Las transacciones que se están ejecutando en otras instancias no interfieren sobre esta operación. Si se omite la opcion LOCAL, Oracle espera a que todas las transacciones de todas las instancias hagan COMMIT o ROLLBACK.}
Las herramientas que se pueden utilizar para bajar y subir instancias son:
- Enterprise Manager
- SqlPlus
- Server Control (srvctl)
Oracle RAC y Automatic Undo Management
Una base Oracle administra en forma automática los segmentos de undo dentro de un tablespace de undo asignado a una instancia. Sólo la instancia que tiene asignado dicho tablespace de undo puede modificar su contenido. Sin embargo, todas las instancias pueden leer todos los bloques de undo de los distintos tablespaces de undo de las diversas instancias que componen el cluster.
Para asignar un tablespace de undo a una instancia de Oracle RAC hay que especificar un valor diferente por intancia al parámetro UNDO_TABLESPACE
Oracle RAC y los archivos de redo log
En una configuración Oracle RAC, cada instancia escribe en su propio conjunto de archivos de redo. A dicho conjunto de archivos de redo propios de la instancia se lo denomina thread de redo o, directamente, thread. Cada grupo de archivos de redo utilizados por una instancia tiene asociado un mismo número de thread. Dicho número de thread es determinado por el valor del parámetro de inicialización llamado THREAD.
Dado que una instancia puede usar un thread apenas esté habilitado y disponible, es altamente recomendable que cada instancia tenga asignado un valor diferente en el parámetro THREAD.
Para asociar un número de thread a un grupo de archivos de redo se utiliza la sentencia
ALTER DATABASE ADD LOGFILE THREAD
Por ejemplo:
ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 4;
Para activar un thread se utiliza la sentencia
ALTER DATABASE ENABLE THREAD
Por ejemplo:
ALTER DATABASE ENABLE THREAD 2;
Por defecto la base Oracle es creada con un solo thread activado y público. Un thread público que está activado puede ser tomado por una instancia que tenga el parámetro THREAD seteado en cero. Por lo tanto, una vez instalado Oracle RAC es necesario crear y habilitar threads adicionales cuando se agregan instancias a la base.
¿Qué es ASM?
ASM es a la vez un file system y un volume manager integrado, creado específicamente para archivos de bases de datos Oracle.
ASM es una solución muy interesante que nos brinda Oracle ya que nos ofrece la alta performance de los raw devices y la facilidad de administración de un file system.
ASM permite dividir todo el storage disponible en diskgroups. Luego uno administra los diskgroups, y ASM automatiza la ubicación de los archivos dentro de los diskgroups.
Cuando utilizamos ASM en las sentencias SQL de creación de estructuras (tablespaces, control files, archive log files) se especifica la ubicación en términos de diskgroups. ASM crea y administra los archivos dentro de los diskgroups sin necesidad de intervención humana.
ASM brinda además, capacidades adicionales de mirroring y striping, dividiendo los archivos en extensiones de 1Mb. y distribuyéndolos entre los discos que componen un diskgroup. Estas capacidades adicionales optimizan el rendimiento del sistema y la utilización de disco, haciendo que el tuning manual de input-output sea prácticamente innecesario.
La forma en que ASM administra el mirroring (espejado) es incluso más flexible que el espejado vía sistema operativo ya que ASM permite especificar el nivel de redundancia a nivel de archivo. De este modo, dos archivos pueden compartir el mismo diskgroup estando uno espejado y el otro no. Oracle administra el espejado a nivel de extensión; si un archivo está espejado, cada extensión de dicho archivo tendrá una o más copias dependiendo del nivel de redundancia configurado para dicho archivo. Las copias espejadas siempre residen en diferentes discos de distintos diskgroups. ASM soporta tres opciones de espejado a nivel de archivo:
- 2-way mirroring: cada extensión tiene una copia
- 3-way mirroring: cada extensión tiene dos copias
- desprotegido: sin espejado. Se utiliza cuando el espejado es provisto por el propio subsistema de discos.
ASM se implementa como una instancia Oracle, con su propia SGA y procesos background. Una configuración «single instance» de ASM puede dar servicio a una o más bases de datos también single instance, todo residente en un solo servidor. Cada diskgroup ASM puede ser compartido por todas las bases de datos del servidor.
En un ambiente clusterizado, cada nodo corre una instancia ASM, y las instancias ASM se comunican entre ellas mediante una relación peer-to-peer. Esta arquitectura es válida tanto para un entorno RAC o no RAC (en el que múltiples bases de datos «single instance» residen en diversos nodos compartiendo el mismo storage administrado por ASM.
Oracle RAC notes 
