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

REFRESCAR PHYSICAL STANDBY A PARTIR DE BACKUP INCREMENTAL FROM SCN – Refresh Standby from backup incremental from SCN

¿Cuantas veces hemos perdido una secuencia de archivelog, o nos damos cuenta que nuestra BD standby esta desincronizada y al ver los archivelogs de la BD primaria con la intención de aplicarlos estos ya fueron borrados por la política de retención?.

El siguiente procedimiento describe el paso a paso para re-sincronizar nuestra base de datos standby, sin necesidad de volver a restaurar toda la BD, basta con aplicar las secuencias faltantes a partir del ultimo SCN disponible en que se haya quedado nuestra BD standby.

using_physical_standby_as_a_testing_and_reporting_database

Este método nos puede ahorrar mucho tiempo en la re-sincronización de nuestro standby, sobretodo en bases de datos de gran tamaño.

PASO A PASO:

1.-IDENTIFICAR EL ACTUAL SCN EN QUE SE QUEDO DESINCRONIZADO NUESTRO STANDBY DATABASE
SQL> select current_scn from v$database;

CURRENT_SCN
———————-
1719913113

2.-EN PRODUCCION GENERAR  BACKUP CONTROLFILE PARA STANDBY:
SQL> alter database create standby controlfile as ‘/tmp/backup/standby_control.ctl’;
Database altered.

 

3.-EN PRODUCCION GENERAR BACKUP INCREMENTAL FROM SCN, TOMANDO COMO INPUT EL SCN DEL PASO PREVIO(PASO 1).
[oracle@PR ~]$ rman target /
RMAN> backup device type disk incremental from scn 1719913113 database format ‘/tmp/backup/Inc_backup_%U’;
Starting backup at 13-MAY-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=34 device type=DISK
backup will be obsolete on date 20-MAY-16
archived logs will not be kept or backed up
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/RTS/system01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/RTS/sysaux01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/RTS/undotbs01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/RTS/users01.dbf
channel ORA_DISK_1: starting piece 1 at 13-MAY-16
……..

.

4.-TRANSFERIR LOS BACKUPIECES AL SERVIDOR STANDBY
cd /tmp/backup
-bash-4.2$ ls -ltr
total 3123304
-rw-r—– 1 oracle oinstall 12828672 May 18 12:11 standby_control.ctl
-rw-r—– 1 oracle oinstall 478183424 May 18 12:13 Inc_backup_r8t36sr4_1_1
-rw-r—– 1 oracle oinstall 1019928576 May 18 12:13 Inc_backup_r9t36srj_1_1
-rw-r—– 1 oracle oinstall 515129344 May 18 12:13 Inc_backup_rat36ss2_1_1
-rw-r—– 1 oracle oinstall 899063808 May 18 12:14 Inc_backup_rbt36ssa_1_1
-rw-r—– 1 oracle oinstall 260235264 May 18 12:14 Inc_backup_rct36ssp_1_1
-rw-r—– 1 oracle oinstall 12877824 May 18 12:14 Inc_backup_rdt36st0_1_1

-bash-4.2$ scp * oracle@fcrac05:/home/oracle/reco_sby_scn
oracle@fcrac05’s password:
Inc_backup_r8t36sr4_1_1 100% 456MB 152.0MB/s 00:03
Inc_backup_r9t36srj_1_1 100% 973MB 139.0MB/s 00:07
Inc_backup_rat36ss2_1_1 100% 491MB 98.3MB/s 00:05
Inc_backup_rbt36ssa_1_1 100% 857MB 171.5MB/s 00:05
Inc_backup_rct36ssp_1_1 100% 248MB 248.2MB/s 00:01
Inc_backup_rdt36st0_1_1 100% 12MB 12.3MB/s 00:00
standby_control.ctl 100% 12MB 12.2MB/s 00:01

5.-RESTAURAR INCREMENTAL BACKUP EN EL SERVIDOR STANDBY:

5.1.- Poner la BD en modo nomount

shutdown abort;
startup nomount;

5.2.- Restaurar el standby controlfile

[oracle@DR ~]$ rman target /
connected to target database: IRIS (not mounted)
RMAN> restore controlfile from ‘/home/oracle/reco_sby_scn/standby_control.ctl’;

Starting restore at 18-MAY-18
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=3421 instance=IRIS5 device type=DISK

channel ORA_DISK_1: copied control file copy
output file name=+DG_DATA11G_01/IRISSBY/CONTROLFILE/current.2206.972939175
Finished restore at 18-MAY-18

5.3.- Montar la base de datos
SQL> alter database mount;
Database altered.

5.4.- catalogar los backuppieces
[oracle@DR ~]$ rman target /
RMAN> catalog start with ‘/home/oracle/reco_sby_scn/’;

using target database control file instead of recovery catalog
searching for all files that match the pattern /home/oracle/reco_sby_scn/

List of Files Unknown to the Database
=====================================
File Name: /home/oracle/reco_sby_scn/Inc_backup_r9t36srj_1_1
File Name: /home/oracle/reco_sby_scn/Inc_backup_r8t36sr4_1_1
File Name: /home/oracle/reco_sby_scn/standby_control.ctl
File Name: /home/oracle/reco_sby_scn/Inc_backup_rat36ss2_1_1
File Name: /home/oracle/reco_sby_scn/Inc_backup_rbt36ssa_1_1
File Name: /home/oracle/reco_sby_scn/Inc_backup_rct36ssp_1_1
File Name: /home/oracle/reco_sby_scn/Inc_backup_rdt36st0_1_1

Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files…
cataloging done

List of Cataloged Files
=======================
File Name: /home/oracle/reco_sby_scn/Inc_backup_r9t36srj_1_1
File Name: /home/oracle/reco_sby_scn/Inc_backup_r8t36sr4_1_1
File Name: /home/oracle/reco_sby_scn/standby_control.ctl
File Name: /home/oracle/reco_sby_scn/Inc_backup_rat36ss2_1_1
File Name: /home/oracle/reco_sby_scn/Inc_backup_rbt36ssa_1_1
File Name: /home/oracle/reco_sby_scn/Inc_backup_rct36ssp_1_1
File Name: /home/oracle/reco_sby_scn/Inc_backup_rdt36st0_1_1

5.5.-Recover a partir del backup incremental from SCN.

RMAN> recover database;

Starting recover at 18-MAY-18
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=3901 instance=IRIS5 device type=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/18/2018 12:25:00
RMAN-06094: datafile 1 must be restored <—————ERROR

 

NOTA:Recordar que estamos volviendo a restaurar un nuevo standby controlfile que viene desde el origen donde no necesariamente los datafiles tienen la misma ruta que en el destino.En este caso los datafiles en el origen tienen diferente ruta que en el destino,
por lo tanto el recover fallará debido a que el controlfile no los conoce. Para decirle a controlfile que los reconozca, se tiene que catalogar el diskgroup o la ruta donde estos residen en el standby:
RMAN-06094: datafile 1 must be restored

Catalogamos la ruta de nuestros datafiles:

RMAN> catalog start with ‘+DG_DATA11G_01/IRISSBY/datafile’;

using target database control file instead of recovery catalog
searching for all files that match the pattern +DG_DATA11G_01/IRISSBY/datafile

List of Files Unknown to the Database
=====================================
File Name: +DG_DATA11G_01/IRISSBY/datafile/system.2119.972937765
File Name: +DG_DATA11G_01/IRISSBY/datafile/system.2259.972937789
File Name: +DG_DATA11G_01/IRISSBY/datafile/sysaux.2273.972937819
File Name: +DG_DATA11G_01/IRISSBY/datafile/sysaux.2204.972937847
File Name: +DG_DATA11G_01/IRISSBY/datafile/undotbs1.2270.972937873
File Name: +DG_DATA11G_01/IRISSBY/datafile/users.2205.972937923
File Name: +DG_DATA11G_01/IRISSBY/datafile/iris_data1.2255.972937939
File Name: +DG_DATA11G_01/IRISSBY/datafile/iris_data1.2240.972938015
File Name: +DG_DATA11G_01/IRISSBY/datafile/iris_data1.2239.972938077
File Name: +DG_DATA11G_01/IRISSBY/datafile/iris_data1.2254.972938139
File Name: +DG_DATA11G_01/IRISSBY/datafile/iris_data2.2165.972938205
File Name: +DG_DATA11G_01/IRISSBY/datafile/iris_data2.2114.972938265
File Name: +DG_DATA11G_01/IRISSBY/datafile/iris_data2.2160.972938421
File Name: +DG_DATA11G_01/IRISSBY/datafile/iris_data2.2269.972938503

Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files…
cataloging done

List of Cataloged Files
=======================
File Name: +DG_DATA11G_01/IRISSBY/datafile/system.2119.972937765
File Name: +DG_DATA11G_01/IRISSBY/datafile/system.2259.972937789
File Name: +DG_DATA11G_01/IRISSBY/datafile/sysaux.2273.972937819
File Name: +DG_DATA11G_01/IRISSBY/datafile/sysaux.2204.972937847
File Name: +DG_DATA11G_01/IRISSBY/datafile/undotbs1.2270.972937873
File Name: +DG_DATA11G_01/IRISSBY/datafile/users.2205.972937923
File Name: +DG_DATA11G_01/IRISSBY/datafile/iris_data1.2255.972937939
File Name: +DG_DATA11G_01/IRISSBY/datafile/iris_data1.2240.972938015
File Name: +DG_DATA11G_01/IRISSBY/datafile/iris_data1.2239.972938077
File Name: +DG_DATA11G_01/IRISSBY/datafile/iris_data1.2254.972938139
File Name: +DG_DATA11G_01/IRISSBY/datafile/iris_data2.2165.972938205
File Name: +DG_DATA11G_01/IRISSBY/datafile/iris_data2.2114.972938265
File Name: +DG_DATA11G_01/IRISSBY/datafile/iris_data2.2160.972938421
File Name: +DG_DATA11G_01/IRISSBY/datafile/iris_data2.2269.972938503

 

RMAN> switch database to copy;
datafile 1 switched to datafile copy “+DATA/ANARDBdr/datafile/system.274.903008331”
datafile 2 switched to datafile copy “+DATA/ANARDBdr/datafile/sysaux.272.903008327”
datafile 3 switched to datafile copy “+DATA/ANARDBdr/datafile/undotbs1.276.903008333”
datafile 4 switched to datafile copy “+DATA/ANARDBdr/datafile/users.273.903008327”
datafile 5 switched to datafile copy “+DATA/ANARDBdr/datafile/undotbs2.277.903008333”
datafile 6 switched to datafile copy “+DATA/ANARDBdr/datafile/data.2871.903008317”
datafile 7 switched to datafile copy “+DATA/ANARDBdr/datafile/data.3554.903008317”
datafile 8 switched to datafile copy “+DATA/ANARDBdr/datafile/data.256.903008315”
datafile 9 switched to datafile copy “+DATA/ANARDBdr/datafile/data.3751.903008327”
datafile 10 switched to datafile copy “+DATA/ANARDBdr/datafile/data.257.903008315”
datafile 11 switched to datafile copy “+DATA/ANARDBdr/datafile/indx.2630.903008327”
datafile 12 switched to datafile copy “+DATA/ANARDBdr/datafile/indx.2629.903008327”
datafile 13 switched to datafile copy “+DATA/ANARDBdr/datafile/data.275.903008333”

 

FINALMENTE:

RMAN> recover database;

Starting recover at 18-MAY-18
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=3481 instance=IRIS5 device type=DISK
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00005: +DG_DATA11G_01/IRISSBY/datafile/iris_data1.2254.972938139
destination for restore of datafile 00010: +DG_DATA11G_01/IRISSBY/datafile/iris_data1.2255.972937939
channel ORA_DISK_1: reading from backup piece /home/oracle/reco_sby_scn/Inc_backup_r9t36srj_1_1
channel ORA_DISK_1: piece handle=/home/oracle/reco_sby_scn/Inc_backup_r9t36srj_1_1 tag=TAG20180518T121324
…..
..
.
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:35
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00009: +DG_DATA11G_01/IRISSBY/datafile/iris_data1.2240.972938015
destination for restore of datafile 00012: +DG_DATA11G_01/IRISSBY/datafile/iris_data2.2114.972938265
channel ORA_DISK_1: reading from backup piece /home/oracle/reco_sby_scn/Inc_backup_rat36ss2_1_1
channel ORA_DISK_1: piece handle=/home/oracle/reco_sby_scn/Inc_backup_rat36ss2_1_1 tag=TAG20180518T121324
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:25

starting media recovery

archived log for thread 1 with sequence 6200 is already on disk as file +DG_DATA11G_01/IRISSBY/ARCHIVELOG/2018_05_18/thread_1_seq_6200.1684.976450999
archived log for thread 1 with sequence 6201 is already on disk as file +DG_DATA11G_01/IRISSBY/ARCHIVELOG/2018_05_18/thread_1_seq_6201.2211.976451359
archived log for thread 1 with sequence 6202 is already on disk as file +DG_DATA11G_01/IRISSBY/ARCHIVELOG/2018_05_18/thread_1_seq_6202.944.976451721
archived log for thread 1 with sequence 6203 is already on disk as file

…..
….
.
archived log file name=+DG_DATA11G_01/IRISSBY/ARCHIVELOG/2018_05_18/thread_1_seq_6205.2169.976452801 thread=1 sequence=6205
media recovery complete, elapsed time: 00:00:02
Finished recover at 18-MAY-18

6.-ACTIVAR EL STANDBY DATABASE

[oracle@fcrac05 reco_sby_scn]$ srvctl stop database -d IRISSBY
[oracle@fcrac05 reco_sby_scn]$ srvctl start database -d IRISSBY -o nomount
[oracle@fcrac05 reco_sby_scn]$ !sqlp
sqlplus ‘/as sysdba’

SQL*Plus: Release 12.1.0.2.0 Production on Fri May 18 13:01:01 2018

Copyright (c) 1982, 2014, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 – 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Advanced Analytics and Real Application Testing options

SQL> alter database mount standby database;
Database altered.

SQL> alter database open read only;
Database altered.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL 8 USING CURRENT LOGFILE DISCONNECT FROM SESSION;
Database altered.

7.-VALIDAR SINCRONIZACIÓN DE STANDBY
SQL> alter session set nls_date_format=’dd/mm/yyyy hh24:mi:ss’;
SELECT sequence#, first_time, next_time, applied, thread# FROM v$archived_log ORDER BY 1,2;
Session altered.

sincronizacion_standby

Finalmente tenemos nuestro standby database sincronizado nuevamente !!

REAL-TIME SQL MONITORING – PARTE I

Real-time SQL Monitor, es un excelente feature disponible desde Oracle 11.2 en adelante, y permite identificar problemas de performance en tiempo de ejecución, permitiendo facilmente diagnosticar sentencias con alto consumo de recursos, long queries, eventos de espera, y queries con paralelismo.

sqlmonitor2

Este feature es el reemplazo de la  antiguamente muy usada vista v$session_longops, la cual servía para monitorear querys de larga ejecución.

Requisitos para usar SQL Monitor:

  • Requiere licencia Diagnostic+Tuning pack, por lo cual el parámetro control_management_pack_access debe estar seteado a Diag+Tuning pack
  • El parámetro statistics_level debe estar seteado al menos en TYPICAL|ALL

¿Todas las sentencias ejecutadas en la Base de datos son Monitoreadas por SQL Monitor?

Como es obvio, por default, no todas las sentencias ejecutadas en la BD son monitoreadas por SQL Monitor, para que una sentencia sea monitoreada debe cumplirse alguno de los siguientes criterios:

  • Sentencias con paralelismo
  • Queries con tiempo de ejecución mayor a 5 segundos de CPU time
  • Queries con tiempo de ejecución mayor a 5 segundos de espera en I/O
  • Aquellas sentencias que explicitamente han sido seteadas con el hint /*+ MONITOR */

¿De donde podemos generar/consultar SQL Monitor report?
– Enterprise Manager
– EM Database Express
– SQL Developer
– Via command line

Vistas en las que esta basada:

En oracle 11g:  En esta version era posible consultar SQL Monitor a traves de las vistas [G]v$sql_monitor [G]v$sql_plan_monitor
En oracle 12c: A partir de esta versión tambien es posible consultar SQL monitor a través de las vistas [G]v$sql_monitor_sesstat, [G]v$sql_monitor_statname, dba_hist_reports(retención de SQL Monitor persistente en disco) y dba_hist_reports_details.

sql_monitor1

Limitaciones y parámetros ocultos (hidden parameters):

Existen limitantes a tener en cuenta si tenemos una BD con mucha carga de trabajo o complejos planes de ejecución.

  • Por default, Oracle limita el numero de sentencias SQL que seran monitoreadas a 20 x CPU_COUNT. Se puede incrementar el valor limite, seteando el parámetro oculto _sqlmon_max_plan pero se debe ser cuidadoso por que esto podría incrementar la cantidad de memoria total usada por SQL Monitor en el Shared Pool, teniendo como resultado que la información de  SQL Monitor sea obsoleta y fuera de memoria mas rápido.
  • SQL Monitor solo monitoreará aquellas sentencias SQL cuyo plan de ejecución tiene menos de 300 lineas, si queremos que SQL Monitor tome en cuenta nuestros planes de ejecución mayor a 300 lineas, podemos cambiar el parametro oculto _sqlmon_max_planlines y así incrementar este límite.Nuevamente se corre el riesgo que la información de  SQL Monitor sea obsoleta y fuera de memoria mas rápido.
  • Se puede incrementar o reducir el valor del umbral de 5 segundos, para que mas sentencias sean consideradas en el monitoreo de SQL Monitor.Esto puede ser cambiado seteando el parámetro oculto _sqlmon_threshold.

Debido a posibles efectos negativos de estos parámetros ocultos es recomendable setearlos a nivel de sesión hasta estar seguros de su impacto.