Cluster Health Advisor Graphical User Interface - CHAG

Con la versión 12 de Oracle Database se introdujo  Oracle Cluster Health Advisor (CHA). Esta herramienta para ambientes de alta disponibilidad, monitorea continuamente  los nodos de un clúster y las bases de datos de un RAC para detectar  problemas insipientes relacionados a  performance y disponibilidad, y de esta manera  proporcionar advertencias tempranas sobre determinados  problemas antes que estos se vuelvan críticos.
Oracle Cluster Health Advisor está integrado con el Insident Manager de Oracle Enterprise Manager Cloud Control (EMCC) y puede llevar adelante las siguientes acciones:

• Detectar problemas de rendimiento a nivel de nodo y base de datos
• Proporcionar alertas tempranas  y sugerir acciones correctivas
• Soportar la  calibración “on-site”  para mejorar la sensibilidad del análisis

En Oracle Database 12c versión 2, Oracle Cluster Health Advisor soporta el monitoreo de los dos subsistemas más críticos e importantes  de Oracle Real Application Clusters (Oracle RAC): 
    • La instancia de la base de datos
    • El sistema host  
Oracle Cluster Health Advisor verifica y hace un seguimiento del  “estado de salud” del sistema monitoreado, para esto muestra periódicamente una amplia variedad de mediciones clave del mismo.
Ejecuta varias veces por minuto un análisis y estima un valor adecuado para  una entrada observada,  basándose en el modelo predeterminado. Luego realiza detección de anomalías para cada entrada, en función de la diferencia entre los valores observados y los esperados. Si detecta  suficientes  entradas “anormales” asociadas con un problema específico, emite una advertencia (“warning”) y genera inmediatamente un diagnóstico del “target”  junto con las acciones correctivas correspondientes.

Utilitario "raccli" de linea de comando para depliegues de ODCS con RAC

La utilidad "raccli" es proporcionada en despliegues de Oracle Database Cloud Service con Oracle Real Application Clusters (RAC), para realizar una variedad de operaciones de tanto de gestión de ciclo de vida como administración de base de datos.

Utilizando la utilidad raccli, se pueden realizar operaciones como:

• Copia de seguridad de la base de datos.
• Recuperación de la base de datos desde una copia de seguridad.
• Cambio de la configuración de backups automáticos.
• Aplicación de parche de la base de datos Oracle, la infraestructura de la red y el software de "Cloud Tooling".
• Cambiar la configuración de las funciones de seguridad.
• Seguimiento del progreso y finalización de las operaciones de larga duración realizadas como trabajos asincrónicos.

Copia de templates "dbca" entre nodos de RAC

Este procedimiento es valido para cuando creamos un template en un sólo nodo de RAC y queremos tenerlo disponible en los otros o  para distribuir el tamplate entre diferentes instalaciones y servidores.

En este ejemplo tenemos dos servidores que forman parte de un mismo RAC:

server01 y server02
Y un template llamado "MyTEMPLATE"

Si creamos nuestro template en uno de los nodo del RAC (server01) y luego ejecutamos dbca en otro nodo (server02), podemos ver que no lo tenemos disponible:

Oracle Goldengate With Oracle Real Application Clusters Configuration

Oracle White Paper
Oracle Goldengate With Oracle Real Application Clusters Configuration

Executive Overview
Oracle Real Application Clusters (Oracle RAC) and Oracle Clusterware allow Oracle Database to run any packaged or custom application across a set of clustered servers. This capability provides the best availability for node and instance failures and most planned maintenance activities, and the most flexible scalability. If a clustered node fails, the Oracle database continues running on the surviving nodes. When more processing power is needed, another node can be added without interrupting user access to data.

Oracle Clusterware is a cluster manager that is designed specifically for the Oracle database. In an Oracle RAC environment, Oracle Clusterware monitors all Oracle resources (such as database instances and listeners). If a failure occurs, then Oracle Clusterware automatically attempts to restart the failed resource. During outages, Oracle Clusterware relocates the processing performed by the inoperative resource to a backup resource. For example, if a node fails, then Oracle Clusterware relocates the database services being used by the application to a surviving node in the cluster. 
This white paper describes best practices for configuring Oracle GoldenGate to work with Oracle RAC, Oracle Clusterware and Oracle Database File System (DBFS). Oracle GoldenGate is instrumental for many reasons, including the following:

• To migrate to an Oracle Database, incurring minimal downtime
•  As part of an application architecture that requires Oracle RAC plus the flexible availability features provided by Oracle GoldenGate, such as active-active database for data distribution and continuous availability, and zero or minimal downtime during planned outages for system migrations, upgrades, and maintenance
• To implement a near real-time data warehouse or consolidated database on Oracle RAC, sourced from various, possibly heterogeneous source databases, populated by Oracle GoldenGate
• To capture from an OLTP application running on Oracle RAC to support further downstreamconsumption such as a SOA type integration

This paper focuses on configuring Oracle GoldenGate to run on Oracle RAC, which can act asthe source database, as the target database, or in some cases as both source and target databases for Oracle GoldenGate processing.

http://www.oracle.com/technetwork/database/features/availability/maa-goldengate-rac-2007111.pdf

Oracle Database 12c: Real Application Testing Overview (White Paper)

Oracle White Paper
Oracle Database 12c: Real Application Testing Overview

Introduction

The Oracle database is the market-leader and the preferred database for hundreds of thousands of enterprises as well as application developers and database administrators worldwide. Over the years, enterprises have come  to rely on the Oracle database to provide unparalleled performance and reliability. Oracle continues to raise the bar with Oracle Database 12c with extensive support for consolidation. Designed for data center environments that are rapidly evolving and changing to keep up with the demands of the business, Oracle Database 12c allows businesses to adopt new technologies quickly while minimizing risk. 

http://www.oracle.com/technetwork/database/manageability/real-application-testing-wp-12c-1896131.pdf

Flashback de una base en RAC a un Guarantee Restore Point (GRP)

Vamos a ver un ejemplo de como crear un GRP (Guarantee Restore Point) y como realizar el flashback de una base en RAC a este restore point.
Para asegurar el exito de la operación de Flashback y GRP debemos tener en cuenta algunas configuraciones previas:

Requisitos:

• La base de datos debe estar configurada en modo archivelog (los archivelogs son usados para las operaciones de flashback database)
• Debe estar activada la FRA ya que los falshback logs solo pueden ser almacenados en la flash/fast recoevry area. 
• En bases de datos en RAC (Real Application Clusters), la FRA debe estar configurada en ASM o en un cluster filesystem que pueda ser accedido por todos los nodos del RAC.

1) Chequeamos que la base este configurada en modo Archive Log:

Nos conectamos a una de las instancias con SQL*Plus y corremos el siguiente comando:


SQL> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     24
Next log sequence to archive   25
Current log sequence           25

Activación de flashback en un RAC

Requisitos:

Antes de poder activar flashback database debemos asegurarnos dos cosas:

• La base debe estar configurada en modo archivelog.
• Debe tener habilitada la FRA (flash/fast recovery area) ya que los flashback logs solamente pueden ser almacenados en la alli.

Para habilitar flashback debemos seguir los siguientes pasos (caso de un RAC):

1- Abrir una de las instancias del RAC en modo mount:  

Desde linea de comando bajamos todas la instancias y luego montamos solo una:

[oracle@server01]$ srvctl stop database -d ORCL
[oracle@server01]$ srvctl start instance -d ORCL -i ORCL1 -o mount;


2- Configurar el parametro DB_FLASHBACK_RETENTION_TARGET (ventana de flashback requerida expresada en minutos)
   Por defecto es un 1 dia (1440 minutos)

Nos conectamos a la instancia:

[oracle@server01]$ sqlplus / as sysdba

Verificamos el parametro:

SQL> show parameter db_flashback_retention_target

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target        integer     1440


Lo seteamos en dos dias (2880 minutos)


SQL> alter system set db_flashback_retention_target=2880 sid='*';

System altered.

3- Habilitamos el flashback en la base de datos:

Verificamos antes que ya no este habilitada:

SQL> select * from v$flashback_database_log;

no rows selected

No hay info de flashback logs

SQL>  select LOG_MODE,FORCE_LOGGING,CURRENT_SCN,FLASHBACK_ON from v$database;

LOG_MODE     FOR CURRENT_SCN FLASHBACK_ON
------------ --- ----------- -------------
ARCHIVELOG   NO      4527627 NO

Acá vemos FLASHBACK_ON en NO

Corremos el comando para habilitar flashback:

SQL> alter database flashback on;

Database altered.


Volvemos a comprobar:

SQL> col OLDEST_FLASHBACK_SCN format 9999999999999;
SQL> col FLASHBACK_SIZE format 9999999999999;
SQL> select * from v$flashback_database_log;

OLDEST_FLASHBACK_SCN OLDEST_FL RETENTION_TARGET FLASHBACK_SIZE ESTIMATED_FLASHBACK_SIZE
-------------------- --------- ---------------- -------------- ------------------------
             4624876 06-JAN-14             2880      104857600                   147456




SQL> select LOG_MODE,FORCE_LOGGING,CURRENT_SCN,FLASHBACK_ON from v$database;

LOG_MODE     FOR CURRENT_SCN FLASHBACK_ON
------------ --- ----------- ------------------
ARCHIVELOG   NO            0 YES


Ahora si vemos info flashback logs y el campo  FLASHBACK_ON en YES.

Una vez activada la flashback.

Desde linea de comando reiniciamos todas las instancias:

[oracle@server01]$ srvctl stop database -d ORCL

[oracle@server01]$ srvctl start database -d ORCL

[oracle@server01]$ srvctl status database -d ORCL
Instance ORCL1 is running on node server01
Instance ORCL2 is running on node server02

Gestión de servicios de base de datos (creación, modificación y borrado)

Para verificar que servicios están corriendo para una base de datos:

[oracle@server01 ~]$ srvctl status service -d ORCL

No nos devuelve nada, no hay servicios corriendo en la base ORCL.

Creamos un nuevo servicio:

[oracle@server01 ~]$ srvctl add service -d ORCL -s SRVTST -r ORCL1,ORCL2 -P BASIC -e SELECT -m BASIC

(ver más abajo las opción que podemos utilizar en la creación)
En este ejemplo usamos:
-d  Base de datos
-s  Nombre del servicio
-r  Instancias disponibles
-P, -e y -m Caracteristicas del tipo de conexión.

Verificamos la configuración del nuevo servicio:

[oracle@server01 ~]$ srvctl config service -d ORCL
Service name: SRVTST
Service is enabled
Server pool: ORCL_SRVTST
Cardinality: 2
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Failover type: SELECT
Failover method: BASIC
TAF failover retries: 0
TAF failover delay: 0
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: BASIC
Edition:
Preferred instances: ORCL1,ORCL2
Available instances:

Activar archivelog en RAC Database (10gR2 y 11g)

Nos conectamos a una de las instancias de la base de datos que queremos pasar a modo archivelog.

[oracle@server01] export ORACLE_SID=ORCL1

[oracle@server01] sqlplus / as sysdba


Verificamos que la base efectivamente NO este ya en modo archivelog:

SQL> archive log list
Database log mode              No Archive Mode
Automatic archival             Disabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     420
Current log sequence           421

Verificamos la configuración del destino de logs:
(podemos usar la FRA o un filesystem compartido por todos los nodos)

Si lo deseamos podemos modificar al tamaño del destino (db_recovery_file_dest_size).

En este ejemplo utilizamos la FRA.

SQL> show parameter recovery_file_dest

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      +FRA
db_recovery_file_dest_size           big integer 4407M


Ana vez hechas estas verificaciones y configuraciones, paramos la base de datos desde linea de comandos utilizando srvctl:

[oracle@server01] srvctl stop database -d ORCL

[oracle@server01] srvctl status database -d ORCL
Instance ORCL1 is not running on node server01
Instance ORCL2 is not running on node server02

Una vez baja en todos los nodos, luego la montamos:

[oracle@server01] srvctl start database -d ORCL -o mount

[oracle@server01] srvctl status database -d ORCL
Instance ORCL1 is running on node server01
Instance ORCL2 is running on node server02


Nos conectamos a una de las instancias y corremos el comando SQL para activar el modo archivelog:

[oracle@server01] sqlplus / as sysdba

SQL> ALTER DATABASE ARCHIVELOG;

Database altered.


Verificamos que el modo archivelog efectivamente haya sido activado:

SQL> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     420
Next log sequence to archive   421
Current log sequence           421

Nuevamente desde linea de comandos, paramos la base de datos en todos los nodos.

[oracle@server01] srvctl stop database -d ORCL

Volvemos a levantar la base en todos los nodos:

[oracle@server01]$ srvctl start database -d ORCL

[oracle@server01] srvctl status database -d ORCL
Instance ORCL1 is running on node server01
Instance ORCL2 is running on node server02


Nos conectamos para probar que las instancias hayan quedado abiertas y disponibles. 

Listo. Nuestra base de datos ya quedó configurada en modo archivelog.

Creación de servicios de base de datos en RAC 11G

A continuación vamos a ver como crear un servicio para una base de datos en particular, en un RAC 11G de dos nodos. Crear servicios resulta muy útil entre otras cosas para gestionar la base de datos, focalizandonos, por ejemplo, en diferentes aplicaciones.

Vemos que la base ORCL no tiene servicios creados:
[oracle@server01]$ srvctl status service -d ORCL

Creamos el servicio con srvctl:
[oracle@server01]$ srvctl add service -d ORCL -s MYAPP -r ORCL1,ORCL2 -P BASIC -e SELECT -m BASIC

Vemos la configuración del servicio:
[oracle@server01]$ srvctl config service -d ORCL -s MYAPP
Service name: MYAPP
Service is enabled
Server pool: ORCL_MYAPP
Cardinality: 2
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Failover type: SELECT
Failover method: BASIC
TAF failover retries: 0
TAF failover delay: 0
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: BASIC
Edition:
Preferred instances: ORCL1,ORCL2
Available instances:

Switcheando redologs (Opción ALL LOGFILE)

La sentencia SWITCH LOGFILE nos permite explicitamente forzar a que la base de datos comience a escribir en un nuevo grupo de archivos de redo log, por mas que,  el corriente aún no se haya completado. Al forzar un cambio de log (SWITCH LOGFILE) se lanza un proceso de "checkpoint" que nos devuelve inmediatamente el control una vez concluido, este tipo se checkpoint se denomina LOG SWITCH CHECKPOINT. 

Una opción "semi-documentada" que resulta bastante útlil en ambientes de RAC  (particularmente cuando se utiliza "dataguard") es utilizar "ALL LOGFILE" para realizar el cambio de grupo de redo en todos los threads de la base, de una vez y desde una unica instancia:

Dos formas de obtener nuestros datos de sesión en un Oracle RAC

A continuación vemos dos maneras de obtener el SID, SERIAL y número de instancia para nuestra propia sesión en un RAC:


select
    sid,
    serial#,
    inst_id
  from gv$session
  where sid = (select sid from v$mystat where rownum = 1);

       SID    SERIAL#   INST_ID
---------- ---------- ---------
       139      24875         1

Executed in 0,39 seconds

Script para testear el balanceo de conexiones en un RAC (9i-10g)

El siguiente script lo utilizo para testear el balanceo entre nodos de un RAC.



export NUM=1
export CANT=$2
let CANT=CANT-1
while [ $NUM -le $CANT ]; do
    let NUM=$NUM+1
    sqlplus  -s user/password@$1<<!
    set heading off
    select '$NUM)  Instancia: '||instance_name from v\$instance;
    exit
!
done


Se invoca pasandole el nombre de alias "tnsnames" y la cantidad de veces que intenta establecer la conexión.


[oracle@server1 scripts]$ ./testcon.sh ORCL 20

testcon.sh [SID] [veces]


La salida que muestra es la siguiente:
(probado en bases RAC 9i y 10g):


1)  Instancia: ORCL2

2)  Instancia: ORCL1

3)  Instancia: ORCL1

4)  Instancia: ORCL2

5)  Instancia: ORCL1

6)  Instancia: ORCL2

7)  Instancia: ORCL1

8)  Instancia: ORCL2

9)  Instancia: ORCL1

10)  Instancia: ORCL2

11)  Instancia: ORCL1

12)  Instancia: ORCL2

13)  Instancia: ORCL1

14)  Instancia: ORCL2

15)  Instancia: ORCL1

16)  Instancia: ORCL2

17)  Instancia: ORCL2

18)  Instancia: ORCL2

19)  Instancia: ORCL2

20)  Instancia: ORCL2


La entrada en el TNSNAMES.ora es:

ORCL = 
  (DESCRIPTION= 
    (LOAD_BALANCE=ON)
    (FAILOVER=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=server01)(PORT=1521))
    (ADDRESS=(PROTOCOL=TCP)(HOST=server02)(PORT=1521)) 
    (CONNECT_DATA=
      (SERVICE_NAME=ORCL)
      (FAILOVER_MODE=
          (TYPE=SELECT) 
          (METHOD=BASIC)
          (RETRIES=20)
          (DELAY=15)
      )
    )
  )