AUTOMATIC KILL SNIPED SESSIONS IN RAC DATABASE

Muchas veces surge la necesidad de killear de manera automatica las sessiones en estado SNIPED basado en un periodo de tiempo, para lo cual podemos usar el siguiente procedure, el cual esta adaptado para BDs RAC.

1.-Procedure que killea todas las sessiones en estado SNIPED de una BD RAC.

CREATE OR REPLACE PROCEDURE KILL_SNIPED_SESSIONS AS
BEGIN
FOR cur_rec IN (select ‘alter system disconnect session ”’ || sid || ‘, ‘ || serial# || ‘, @’|| inst_id || ”’ immediate’ AS ddl
from gv$session
where status=’SNIPED’
)
LOOP
BEGIN
EXECUTE IMMEDIATE cur_rec.ddl;
EXCEPTION
WHEN OTHERS THEN
null;
RAISE;
END;
END LOOP;
END;
/

 

2.-Se schedula el procedure usando job scheduler para que se ejecute cada hora.

BEGIN
DBMS_SCHEDULER.create_job (
job_name => ‘KILL_SNIPED_SESSIONS_JOB’,
comments => ‘Mata sesiones en estado SNIPED cada hora by JP.’,
job_type => ‘PLSQL_BLOCK’,
job_action => ‘BEGIN sys.KILL_SNIPED_SESSIONS; END;’,
start_date => SYSTIMESTAMP,
repeat_interval => ‘freq=HOURLY;interval=1’,
enabled => TRUE);
END;
/

SQL_EXEC_ID/SQL_EXEC_START columns are empty in gv$active_session_history and gv$session

Primero algo de historia ..

A partir de Oracle database 11g, se introdujeron las columnas sql_exec_id y sql_exec_start a las vistas gv$session, gv$active_session_history ( también presente en otras vistas como dba_hist_active_sess_history y gv$sql_monitor). La documentación de Oracle nos dice esto a un nivel muy básico :

https://docs.oracle.com/database/121/REFRN/GUID-79E97A84-9C27-4A5E-AC0D-C12CB3E748E6.htm

sql_exec_id : identificador de ejecución SQL
sql_exec_start : tiempo en que la ejecución inició.

Como bien saben, es básico en todo enfoque de análisis de performance(AAS,Time Model Statistics,etc) investigar la cantidad de ejecuciones que tuvo un determinado sql_id en un periodo en el tiempo. La actividad registrada en ASH es muestral, 1 sample cada segundo, de tal modo que usando las columnas sql_exec_id y sql_exec_start es posible agrupar los registros en la gv$active_session_history de un determinado sql_id y agruparlo por las columnas sql_exec_id y sql_exec_start para determinar que pertenecen a una misma ejecución.

Ejemplo : En oracle 10g si tu ejecutas un sql_id 30 veces y cada ejecución dura 5 segundos tendrás 150 registros asociados a dicha sentencia en la [g]v$active_session_history y no tendrás ninguna columna que te permita distinguir si ese sql_id se ejecutó 150 veces o 30 veces con duración de 5 segundos cada ejecución. Desde 11g esto es posible simplemente por agrupar sql_id, sql_exec_id y sql_exect start, de esta manera podriamos tener algo asi para determinar cuantas veces se ejecutó el sql_id 3hq6ux9mxuq78 en el intervalo de 09:00 am a 10:30 am :

select sql_id,sql_exec_id,sql_exec_start,count(*) duration
from gv$active_session_history
where sample_time
between to_date(’21-02-2019 09:00:00′,’DD-MM-YYYY HH24:MI:SS’)
and to_date(’21-02-2019 10:30:00′,’DD-MM-YYYY HH24:MI:SS’)
group by sql_id,sql_exec_id,sql_exec_start

sql_exec_id7

Como se habrán podido dar cuenta en la imagen anterior ( y seguramente mas de uno se habrá percatado durante un análisis de performance), que consultando la gv$active_session_history hay registros que tienen las columnas sql_exec_id y sql_exec_start vacias. Lo cual puede complicar el análisis y causar cierta confusión

De hecho, gran cantidad de registros en la [g]v$active_session_history y gv$session tienen vacia la columna sql_exec_id y sql_exec_start.

select sql_id,sql_exec_id,sql_exec_start from gv$active_session_history where sql_exec_id is null;

sql_exec_id5

Bueno…en su momento Oracle aperturó un bug ( el cual finalmente fue cerrado como “no bug”), debido a que se llegó a la conclusión de que es el comportamiento esperado bajo ciertas circunstancias.

Bug 18468509 : SQL_EXEC_START AND SQL_EXEC_ID SOMETIMES ARE NULL IN V$SESSION

De acuerdo al bug Oracle nos dice que sql_exec_id puede ser null en los siguientes escenarios :

1. The SQL is waiting on an enq TM
2. During parse
3. During LOAD AS SELECT step of the execution plan
4. Often during the last step in the plan like SELECT STATEMENT, INSERT
STATEMENT

sql_exec_id6

Verifiquemos esto con un ejemplo …

TEST CASE :

Como se puede apreciar el sql_id f66wk4yqwyzas tiene 4 registros, de los cuales en 3 de ellos las columnas sql_exec_id y sql_exec_start estan vacias.

select sample_time,sql_id,sql_child_number,sql_exec_id,sql_exec_start,sql_plan_hash_value,in_parse,in_hard_parse
from gv$active_session_history where sql_id=’f66wk4yqwyzas’ order by sample_time asc;

 

sql_exec_id1

select sample_time,sql_id,sql_child_number as child_number,sql_exec_id,sql_exec_start,
sql_plan_hash_value as PHV,in_parse,in_hard_parse from gv$active_session_history
where sql_id=’f66wk4yqwyzas’ order by sample_time asc;

sql_exec_id3

Efectivamente!!! en este caso el sql_id : f66wk4yqwyzas durante los 3 primeros samples se encontraba realizando un hard parse y entró a la fase de execution en el 4to sample.

OEM 13c Deploy Agent en Windows – Modo Silent

 

Tenemos los siguientes 3 métodos para desplegar un agente oem en un Target Windows:

  1. Método push Clásico: Despliegue desde consola de Cloud Control, que tiene como restricción el instalar Cygwin o algun otro emulador de Linux en el servidor windows donde queremos desplegar el agente.
  2. Usando un Windows Staging Server -> Buena opción pero requiere tener un servidor centralizado para actuar como “pushing agent server”, mayor información en la nota técnica (Doc ID 2304834.1)
  3. Instalación en modo Silent -> Desde mi punto de vista la opción mas simple ya que no dependes de ningún sofware de terceros o servidor centralizado.

Ante esto se muestra como mejor método el despliegue de agente en modo silent, asi que lo primero es obtener el instalador del agente para Windows.Para esto podemos generar un “Agent Image” usando el utilitario EMCLI.

installagentwindows

Nos logeamos a la consola del utilitario EMCLI con SYSMAN o algún otro usuario con priviegios de agent deployment.

oracle@sun70l33:/u01/app/oemshared1/middleware13200/bin$ ./emcli login -username=sysman
Enter password :

Login successful

Sincronizamos EMCLI con el repositorio.

oracle@sun70l33:/u01/app/oemshared1/middleware13200/bin$ emcli sync
Synchronized successfully

Validamos los instaladores de agentes que tenemos disponibles de cada plataforma y validamos que tenemos disponible el instalador del agente oem para windows.

oracle@sun70l33:/u01/app/oemshared1/middleware13200/bin$ emcli get_supported_platforms
———————————————–
Version = 13.2.0.0.0
Platform = Linux x86-64
———————————————–
Version = 12.1.0.4.0
Platform = Microsoft Windows x64 (64-bit)
———————————————–
……….

.
———————————————–
Version = 13.2.0.0.0
Platform = Microsoft Windows x64 (64-bit)
———————————————–
Version = 13.2.0.0.0
Platform = HP-UX Itanium
———————————————–
Version = 12.1.0.2.0
Platform = Linux x86-64
———————————————–
Platforms list displayed successfully.

Generamos el Agent Image dentro de una ruta de nuestro servidor OMS (ejemplo : /u01/app/oemshared1/win_agent )

Para esto creamos el directorio donde se descargará el instalador dentro de nuestro servidor OMS y seteamos las variables de ambiente UNZIP_LOC y ZIP_LOC que el utilitario EMCLI necesita para empaquetar/desempaquetar el instalador

[oracle@em13c ~]$ mkdir /u01/app/oemshared1/win_agent
[oracle@em13c ~]$ export UNZIP_LOC=/usr/bin/unzip
[oracle@em13c ~]$ export ZIP_LOC=/usr/bin/zip

Procedemos a descargar el instalador

emcli get_agentimage -destination=/u01/app/oemshared1/win_agent -platform=”Microsoft Windows x64 (64-bit)” -version=13.2.0.0.0

insallagentoem

Se generó el agent image “13.2.0.0.0_AgentCore_233.zip”

installagentoem2

Copiamos el instalador en el servidor windows en el que queremos instalar el agente OEM, descomprimimos y editamos el archivo agent.rsp.

deploy agent

A continuación descomentar y llenar los siguientes parametros

OMS_HOST : full hostname del servidor OMS
EM_UPLOAD_PORT : puerto HTTPS de OMS
AGENT_REGISTRATION_PASSWORD: agent secure password registrador durante la instalación de Cloud Control (si no lo tienes no te alarmes, puedes registrar uno nuevo).
AGENT_PORT : Puerto de comunicación del agente por default 3872 (verificar que no este ocupado).
ORACLE_HOSTNAME : hostname del nuevo target donde estamos desplegando el agente oem.

installagentoem3

Antes de proceder con el despliegue del agente para evitar tipicos errores relacionados a falta de ddls perl como “the program can’t start because perl510.dll is missing from your computer“, debemos setear las siguientes variables :

SET PERL5LIB=
set PATH=%ORACLE_HOME%\perl\bin;%PATH%

Procedemos a desplegar el agente :

agentDeploy.bat AGENT_BASE_DIR=D:\oem_13c2 RESPONSE_FILE=D:\oracle\product\11.2.0\agent_install\agent_inst\13.2.0.0.0_AgentCore_233\agent.rsp

install oem agent

Finalmente después de unos cortos minutos, el agente fue desplegado sin problemas.

agent instalation finished

En los servicios de windows, se creó un nuevo servicio propio del agente.

deploy agent2

Ahora que el agente fue desplegado, procederemos a promoverlo a la consola de Cloud Control 13c.

Setup / add target / add targets manually

oem installation agent

Buscamos el nuevo target a monitorear.

install oem agent windows 5

install oem agent windows 6

install oem agent windows 7

Seteamos el password del usuario dbsnmp y realizamos un test de conexion

install oem agent windows 8

Procedemos a guardar los nuevos targets

install oem agent windows 10

install oem agent windows 11

Finalmente tenemos los targets registrados en Cloud Control siendo monitoreados 🙂

Corregir masivamente Corrective Action Jobs en estado Broken OEM 13C- Cleanup Broken Corrective Action jobs in Cloud Control 13c

Alguna vez se han encontrado en el escenario de tener bastantes jobs en Cloud Control en estado broken?.

oem_ca1

Como se puede apreciar, son jobs fallidos por credenciales invalidas, lo resaltante aqui es que si nos damos cuenta no tenemos opción de corregir todos masivamente, lo único que podriamos hacer es editar los jobs uno por uno e ingresar las credenciales.¿Engorroso verdad?.

oem_ca2

Solución -> OMS Repository

La vista mgmt_job, nos dice el detalle de todos los jobs de OEM.Haciendo un simple query podemos visualizar los mismos 528 jobs en estado broken que vimos desde la consola de Cloud Control.

select count(*) from sysman.mgmt_job where job_name like ‘%LIBERA_FRA%’ and broken=1;

oem_ca3

Viendo el detalle:

select JOB_ID, JOB_NAME,job_owner,job_type, JOB_DESCRIPTION,job_status,broken,broken_reason,expired
from sysman.mgmt_job where job_name like ‘%LIBERA_FRA%’ and broken=1;

oem_ca4

A continuación realizaremos la corrección realizando un update a sysman.mgmt_job donde broken=0.

update sysman.mgmt_job set broken=0 where job_name like ‘%LIBERA_FRA%’ and broken=1;
commit;

oem_ca5

Posterior al cambio volvemos a validar :

oem_ca6

Finalmente, podemos visualizar desde la consola de OEM que todos los Corrective Action jobs en estado broken han sido limpiados.

oem_ca7

 

 

 

 

 

 

CREACIÓN DE WORKSPACE EN ORACLE APEX 18.1 – WORKSPACE CREATION ORACLE APEX 18.1

Como parte de los primeros pasos para desarrollar nuestras aplicaciones usando Oracle Application Express, necesitamos crear y preparar nuestro entorno de trabajo.
A continuación detallaremos el paso a paso para crear un nuevo workspace en Oracle APEX 18.1.

El workspace, contiene una variedad de interesantes funcionalidades como :  Gestor de reportes, módulos de fuente web/application builder, módulos de Servicios REST (ORDS), reportes módulo para la gestión de usuarios programadores o usuarios que usarán la aplicación, entre otros.

1.- Primero nos logearemos a la interfaz gráfica de Oracle APEX como administrador, el workspace trabajará con un esquema de Base de datos, donde almacenará la metadata de sus objetos .

apex_workspace1

Seleccionar la opción “Create Workspace”.

apex_workspace2

Colocar un nombre al workspace, opcionalmente podemos colocar un workspace ID (en caso de no colocar este dato sera autogenerado), y una descripción.

apex_workspace3

 

Aqui crearemos un nuevo esquema de BD, el cual servirá para almacenar la metadata del workspace, en este caso le llamaremos DEV y  asignaremos una quota de 500MB que para fines prácticos es mas que suficiente.

apex_workspace4

Crearemos un usuario administrador del workspace, este usuario servirá para gestionar nuestro workspace, asi como tambien desarrollar nuevas aplicaciones.

apex_workspace5

Seguidamente nos muestra el resumen de las caracteristicas con las que nuestro workspace esta siendo creado.

 

apex_workspace6

 

Confirmamos la creación de nuestro workspace.
apex_workspace7

Buscamos nuestro nuevo workspace creado.

apex_workspace8

apex_workspace9

Finalmente validamos que nuestro workspace DEV_WORKSPACE ha sido creado, ya estamos listos para desarrollar nuestra primera app en Oracle APEX 🙂 !

INSTALACIÓN ORACLE APPLICATION EXPRESS 18.1 – Oracle Apex 18.1 Installation

Antes de iniciar con la instalación de Oracle Application Express 18.1 desde cero, es necesario aclarar el siguiente punto, el cual muchas veces causa confusión:

A partir de Oracle database 11g, la instalación de Oracle Application Express (Oracle APEX), se vuelve mucho mas sencilla, ya que se puede instalar Oracle Apex durante la creación de la Base de datos.

En este caso, como parte del demo, estoy creando una BD en un motor Oracle 12.1.0.2, dejando los features seleccionados por default.

install_apex1.jpg

install_apex3.jpg.png

Si validamos los esquemas de APEX creados durante la creación de la Base de datos, podemos apreciar un usuario APEX_040200, lo que significa que al crear una BD en un motor Oracle 12.1.0.2, la versión de Apex instalada por default es Oracle APEX 4.2

select username,account_status from dba_users where username like ‘%APEX%’;

install_apex5.jpg

Si has creado una Base de datos con los features seleccionados por default y quiere usar dicha versión de Oracle APEX, lo único que tienes que hacer, es tomar en cuenta este artículo desde el punto 4 en adelante(4.-Configurar Oracle APEX), en caso de querer usar otra versión, esta debe ser descargada e instalada.

 

En el siguiente tutorial instalaremos y configuraremos Oracle Application Express 18.1 desde cero.

Resumen de los pasos a realizar:

1- Instalación de BD repositorio pre-requisito
2- Descargar Oracle APEX
3- Instalar Oracle APEX 18.1
4- Configurar APEX
5- Ejecución de Oracle APEX

1.- La instalación requiere una Base de Datos repositorio.

Para instalar Oracle APEX 18.1, se requiere como mínimo una BD repositorio 11.2.0.4 o superior, en este caso usaremos una BD 12.1.0.2.

install_apex4.jpg

2.- Descargamos Oracle APEX

Para descargar Oracle Application Express 18.1, hacer click AQUI

install_apex7

 

install_apex9

Iniciamos la copia del instalador de APEX al servidor de BD.

install_apex10.jpg

 

3.- Instalacion Oracle APEX

Requerimos crear un tablespace dedicado, para que sirva como default tablespace de nuestra instalación.

SYS> create tablespace APEX datafile ‘/data/oracle/app/oracle/oradata/APEXBD/APEXBD/apex01.dbf’ size 5g;
Tablespace created.

install_apex6.jpg

Una vez terminada la copia del instalador, descomprimimos el instalador.

install_apex11

[oracle@limrescdrsv01 ~]$ ls -ltr
total 168500
drwxr-xr-x. 2 oracle oracle      4096 Oct 23  2015 oraInventory
drwxrwxr-x  2 oracle oracle      4096 Sep 11  2017 SQLLDR
drwxr-xr-x  4 oracle oracle      4096 Apr 11 21:49 sqlcl
-rw-rw-r–  1 oracle oracle  21733791 Apr 23 14:59 sqlcl-18.1.1.zip
drwxrwxr-x  6 oracle oracle      4096 May  9 08:58 apex
-rw-r—–  1 oracle oracle    909958 Jun 13 16:19 install2018-06-13_15-51-46.log
-rw-rw-r–  1 oracle oracle 149873345 Jun 13 16:46 apex_18.1.zip
[oracle@limrescdrsv01 ~]$ pwd
/home/oracle

install_apex12

Corremos el script apexins.sql, el cual según la documentación lleva los siguientes parámetros.
— Run script apexins.sql with parameters:

— @apexins.sql tablespace_apex tablespace_files tablespace_temp images

— Where:
— tablespace_apex is the name of the tablespace for the Oracle Application Express application user.
— tablespace_files is the name of the tablespace for the Oracle Application Express files user.
— tablespace_temp is the name of the temporary tablespace or tablespace group.
— images is the virtual directory for Oracle Application Express images.
— (To support future Oracle Application Express upgrades, define the virtual image directory as /i/.)
SQL> — @apexins.sql tablespace_apex tablespace_files tablespace_temp images
SQL>
SQL> @apexins.sql APEX APEX TEMP /i/

install_apex13

 

install_apex14

install_apex15

Después de 18 largos minutos, la instalación terminó.

Fases de la instalación :
timing for: Phase 1 (Installation)
Elapsed: 00:03:34.40
Phase 2 (Upgrade)
Session altered.

— Now beginning upgrade. This will take several minutes.——-‘)
timing for: Upgrade metadata 1
Elapsed: 00:02:04.49
Session altered.

PL/SQL procedure successfully completed.
— Upgrading new schema. ——-
PL/SQL procedure successfully completed.
timing for: Upgrade metadata 2
Elapsed: 00:00:43.76

timing for: Phase 3 (Switch)
Elapsed: 00:00:56.02
timing for: Complete Installation
Elapsed: 00:14:06.37

Validamos que posterior a la instalación se han creado 2 nuevo esquemas de BD.

install_apex16.jpg

Validamos la nueva versión instalada de Oracle APEX.

SELECT comp_name, version, status FROM dba_registry WHERE comp_id=’APEX’;
install_ape22

select * from apex_release;
install_ape23

4.- Configurar Oracle APEX

Ejecutar Embedded PL/SQL Gateway

[oracle@limrescdrsv01 apex]$ mkdir images
[oracle@limrescdrsv01 apex]$ cd images
[oracle@limrescdrsv01 apex]$ pwd
/home/oracle/apex/images
[oracle@limrescdrsv01 apex]$ cd images/

install_apex17

SQL> @apex_epg_config.sql /home/oracle

PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.

. Loading images directory: /home/oracle/apex/images
Directory created.

PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.

Commit complete.
Directory dropped.

timing for: Load Images
Elapsed: 00:01:48.54

PL/SQL procedure successfully completed.
Commit complete.

SQL> !pwd
/home/oracle/ápex

Desbloqueamos el usuario ANONYMOUS.

SQL> alter user ANONYMOUS account unlock;

install_apex18

Run script apexconf.sql

Ejecutar el script apexconf.sql  para configurar la contraseña del usuario ADMIN y realizar otras configuraciones de XDB http listener port.

— Running script: @apxconf.sql
— Setup password for ADMIN
— Configuring XDB Http Listener port

@apxconf.sql

install_apex19

[oracle@limrescdrsv01 apex]$ ls -ltr *conf*
-rw-r–r– 1 oracle oracle  2256 Aug 21  2012 apxconf.sql
-rw-r–r– 1 oracle oracle   878 Dec  4  2014 apex_epg_config_nocdb.sql
-rw-r–r– 1 oracle oracle  2205 Dec  4  2014 apex_epg_config_cdb.sql
-rw-r–r– 1 oracle oracle  9166 Mar  3  2015 apex_epg_config_core.sql
-rw-r–r– 1 oracle oracle  5054 Jan 19 11:07 apex_rest_config.sql
-rw-r–r– 1 oracle oracle  5177 Jan 19 11:07 apex_rest_config_nocdb.sql
-rw-r–r– 1 oracle oracle 13173 Jan 19 11:07 apex_rest_config_core.sql
-rw-r–r– 1 oracle oracle  2900 Jan 19 11:07 apex_rest_config_cdb.sql
-rw-r–r– 1 oracle oracle  1691 Jan 19 11:07 apex_epg_config.sql
-rw-r–r– 1 oracle oracle  4945 Apr  6 16:09 dbcsconf.sql
[oracle@limrescdrsv01 apex]$ pwd
/home/oracle/apex

install_apex20

To user, you can use ADMIN by default, and email can be skipped.
To password, the system requires you to enter a strong password:
Password does not conform to this site’s password complexity rules.

  1. Password must contain at least 6 characters.
  2. Password must contain at least one alphabetic character (abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ).
  3. Password must contain at least one punctuation character (!”#$%&()“*+,-/:;?_).
  4. Password must contain at least one upper-case alphabetic character.
  5. Password must contain at least one lower-case alphabetic character.

Port default is 8080:

install_apex21

5.- Ejecutando Oracle APEX

http://172.19.74.116:8080/apex/apex_admin

Nos logeamos como administrador.

install_ape26

install_ape27

Finalmente tenemos nuestro entorno APEX instalado, en un próximo artículo continuaremos con la creación de nuestro WORKSPACE y desarrollo de nuestra primera aplicación !!.

 

CONFIGURANDO DATAGUARD BROKER, ¿REALMENTE ES NECESARIO?

En el presente artículo, configuraremos dataguard Broker, sobre un ambiente Dataguard previamente configurado, sincronizado y totalmente funcional (primary + physical standby database). Antes de empezar con la configuración técnica discutiremos algunos puntos, los cuales nos aclararán el panorama, acerca de si debemos o no optar por usar Broker en nuestros ambientes Dataguard, personalmente pienso que la gente no lo usa por desconocimiento de sus beneficios.

¿Por que debemos configurar Dataguard Broker?.

En simples palabras, por que Dataguard Broker es la herramienta que automatiza y  centraliza la creación, mantenimiento y monitoreo de las configuraciones de todos los componentes de nuestra arquitectura Dataguard, captura información de diagnóstico, realiza reportes estadísticos y detecta rápidamente problemas,  permitiendo obtener de manera simple un panorama completo de toda nuestra configuración, ya sea a través de un entorno grafico Enterprise Manager o por linea de comandos usando el utilitario DGMGRL.

Recuerden que a partir de oracle 11g se pueden tener hasta 30 standby database y sería un poco complicada la administración si no se tiene un componente que los centralice.

dgbkr006

Oracle Dataguard Broker está disponible desde oracle 9.2.0, y es un componente opcional dentro de nuestra arquitectura Dataguard, que personalmente recomiendo configurar, ya que no requiere licenciamiento adicional, y nos proporciona lo siguientes extra beneficios :

  • Simplifica la adición de nuevos o existentes physical, lógical, snapshot, RAC o single instance standby a una ya existente configuración Dataguard.
  • Monitorea constantemente el estado de salud de todas las bases de datos en la configuración Dataguard.
  • Broker inicia el proceso de sincronización de manera automática, post reinicio o restablecimiento del standby, evitando la necesidad de activar el proceso MRP de manera manual, y ademas retoma de manera automática operaciones pendientes
  • Se puede configurar un automatic failover, para que este sea disparado inmediatamente, cuando el broker detecta la perdida de la BD primaria, sin intervención del DBA.
  • Simplifica las tareas de switch-over o failover, al ser invocadas de manera sencilla con un simple comando(en escenarios como este el tiempo es oro).
  • Monitoreo centralizado de el entorno primario y todos los standby de nuestra configuración, cambio de modo de protección y brinda información importante para troubleshooting.

¿Tu configuración Dataguard es mala si no usas Dataguard broker?.

Ciertamente nosotros podemos tener configurada y administrar nuestra arquitectura Dataguard sin necesidad de configurar el Dataguard broker y va a funcionar correctamente, sin embargo aun así es recomendable configurar Dataguard Broker por el simple hecho de que hace la vida del DBA mas fácil y reduce el tiempo dedicado a la administración, permitiéndonos emplear este valioso tiempo en otras labores que generen mas valor a nosotros mismos.

Adicional a los beneficios antes descritos, quiero profundizar en el punto en que agiliza el proceso de switchover/failover por el simple hecho de poder realizarlos con un simple comando versus toda la secuencia de comandos requerida cuando no usamos DG broker.

Ejemplo de failover con DG Broker: un  simple comando, 25 segundos aprox, incluyendo mensaje de validacion exitosa

Welcome to DGMGRL, type "help" for information.
Connected.
DGMGRL> FAILOVER TO IRISSBY;
Performing failover NOW, please wait...
Failover succeeded, new primary is "IRISSBY"
DGMGRL>

Ejemplo de Failover sin DG Broker(método tradicional): secuencia de comandos 1 minuto 15 segundos aprox

--Cancelar proceso de replicación MRP - 5 segundos
SQL> recover standby database until cancel;

--Promover standby como primaria - 10 segundos
SQL> alter database activate standby database;
Database altered.

--Reinicio de la BD para que inicie modo READ WRITE - 30 segundos
SQL> shut abort;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.

SQL> startup
ORACLE instance started.
Total System Global Area 755769344 bytes
Fixed Size 2217184 bytes
Variable Size 448793376 bytes
Database Buffers 301989888 bytes
Redo Buffers 2768896 bytes
Database mounted.
Database opened.
--Validación -10 segundos
SQL> select name,open_mode,database_role from v$database;
NAME OPEN_MODE DATABASE_ROLE
--------- ---------------------- ----------------
IRIS     READ WRITE PRIMARY

+ tiempo de digitar o copiar/pegar secuencia de comandos: 
Alrededor de 30 seg

*Aun les queda dudas, sobre si es necesario incluir Dataguard Broker en nuestra Arquitectura Dataguard?

 

IMPLEMENTACIÓN PASO A PASO:

1.-Habilitar broker en primary y standby database

–BD PRIMARY

SQL> alter system set dg_broker_start=true scope=both;
System altered.

–BD STANDBY (en este caso es rac)
SQL> alter system set dg_broker_start=true scope=both sid=’*’;
System altered.

Explicación:

Profundicemos un poco acerca del parámetro dg_broker_start, lo primero que debemos saber es que su valor por default es FALSE, y es el valor con el que debería quedarse así, si no se está pensando en usar Dataguard Broker.

SQL> show parameter dg_broker_start
NAME                    TYPE      VALUE
———————-   ————— ———-
dg_broker_start boolean    FALSE

el simple hecho de setearlo a TRUE, habilita un nuevo background process tanto en la BD primaria como en el standby, llamado DMON y a partir de ese momento este proceso existirá tanto tiempo como la instancia de BD se encuentra inciada, al reiniciarla durante el startup este background process volverá a ser iniciado

bd_process_dmon

Al mismo tiempo se crea automáticamente un Archivo de Configuración, que guarda la información del estado actual y las propiedades de cada Instancia en la configuración Dataguard.

config_file_broker

Opcionalmente la ubicación de este archivo de configuración puede ser cambiado y multiplexado:

# Directory
alter system set DG_BROKER_CONFIG_FILE1 = ‘<directory>/<file>’;
alter system set DG_BROKER_CONFIG_FILE2 = ‘<directory>/<file>’;

# ASM
alter system set DG_BROKER_CONFIG_FILE1 = ‘+DATA/IRIS/Broker/dr1IRIS.dat’;
alter system set DG_BROKER_CONFIG_FILE1 = ‘+FLASH/IRIS/Broker/dr2IRIS.dat’;

Cabe resaltar que Dataguard broker también tiene un log por cada instancia en la configuración, el archivo log se encuentra en el mismo directorio que el Alert log con el nombre: drc<ORACLE_SID>.log

2.-Crear las configuraciones del Dataguard broker 

2.1.-Crear la configuración en el servidor primario

[oracle@limirisdbf02 trace]$ dgmgrl sys/passwordseguro@IRIS
DGMGRL for Linux: Version 12.1.0.2.0 – 64bit Production
Copyright (c) 2000, 2013, Oracle. All rights reserved.

Welcome to DGMGRL, type “help” for information.
Connected as SYSDBA.

DGMGRL> CREATE CONFIGURATION my_dg_config AS PRIMARY DATABASE IS IRIS CONNECT IDENTIFIER IS IRIS;
Error: ORA-16698: LOG_ARCHIVE_DEST_n parameter set for object to be added <——ERROR!!!!

Failed.
DGMGRL> exit

Explicación:

Este error es por que el parámetro LOG_ARCHIVE_DEST_2 ya estaba seteado por la configuración previa del dataguard, debemos guardar el valor de este parámetro previamente y resetearlo para que el broker pueda ser configurado, posterior a la configuración del broker volveremos a setear el valor que antes tenia.

[oracle@limirisdbf02 trace]$ !sqlp
sqlplus sys/oracle@IRIS as sysdba

SQL> alter system set LOG_ARCHIVE_DEST_2=” scope=both;
System altered.

[oracle@limirisdbf02 trace]$ dgmgrl sys/oracle@IRIS
DGMGRL for Linux: Version 12.1.0.2.0 – 64bit Production

Copyright (c) 2000, 2013, Oracle. All rights reserved.

Welcome to DGMGRL, type “help” for information.
Connected as SYSDBA.
DGMGRL> CREATE CONFIGURATION my_dg_config AS PRIMARY DATABASE IS IRIS CONNECT IDENTIFIER IS IRIS;
Configuration “my_dg_config” created with primary database “iris”
DGMGRL>

2.2.-Agregar el physical standby a nuestra configuración en la BD Primaria
DGMGRL> ADD DATABASE IRISSBY AS CONNECT IDENTIFIER IS IRISSBY MAINTAINED AS PHYSICAL;
Error: ORA-16698: LOG_ARCHIVE_DEST_n parameter set for object to be added
Failed.

Sucederá lo mismo que en el punto 2.1 al intentar agregar la conexion al standby al dataguard broker, motivo por el cual tendremos que también resetear este parámetro en el standby

En standby:
SQL> alter system set log_archive_dest_2=” scope=both sid=’*’;
System altered.

–Posteriormente podemos agregar IRISSBY sin problema:
DGMGRL> ADD DATABASE IRISSBY AS CONNECT IDENTIFIER IS IRISSBY MAINTAINED AS PHYSICAL;
Database “irissby” added

3.-Habilitamos la configuración en la BD primaria

DGMGRL> ENABLE CONFIGURATION;
Enabled.

4.-Retonarmos los anteriores valores del parametro LOG_ARCHIVE_DEST_2 , en la BD primaria y standby:

primaria:
alter system set log_archive_dest_2=SERVICE=IRISSBY LGWR AFFIRM SYNC valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=IRISSBY’;

standby:
alter system set log_archive_dest_2=’service=IRIS ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=IRIS’;

5.-Validamos nuestra nueva configuración

 DGMGRL> SHOW CONFIGURATION;
Configuration - my_dg_config
Protection Mode: MaxAvailability
 Members:
 iris - Primary database
 Warning: ORA-16629: database reports a different protection level from the protection mode

irissby - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
status updated 4 seconds ago

 

Finalmente hemos añadido Dataguard Broker a nuestra configuración Dataguard!!!