Oracle Database 11g: "Client Failover" en "Standby Databases" ( Part I )

Oracle Database 11g: "Client Failover" en "Standby Databases" ( Part I )

Por Joel Pérez  & Mahir M. Quluzade
Publicado en Septiembre 2015

Reciban estimados tecnólogos Oracle un cordial saludo. A través del presente artículo, tendremos la oportunidad de tratar un tema de gran importancia como lo es el concepto de “Client Failover” en ambientes de bases de datos “Standby”
Introducción
En repetidas ocasiones cuando analizamos infraestructuras e implantaciones de clientes, una de las primeras actividades que realizamos es el chequeo de cómo las buenas practicas están implementadas o si realmente lo están.
Al momento de realizarlo en materia de “Standby Databases”. Siempre hacemos una pregunta típica: ¿Cual es procedimiento o método que aplican/usan para manejar las conexiones de aplicaciones al momento en que se ha llevado a cabo un “Switchover” o “Failover”?
Las respuestas son diversas, la más típica en muchos casos es:
“...como casi nunca realizamos “Switchover” y mucho menos “Failover” es poco común que tengamos que re-direccionar las conexiones de nuestras aplicaciones.. por lo tanto dado el momento en que tengamos que realizar dicha operación, nos dirigimos al servidor de aplicaciones, allí editamos de forma manual el “Tnsentry” que direcciona a nuestra base de datos de producción, y lo cambiaremos para que direccione posteriormente al servidor “Standby”... en el cual estará operando la base de datos con rol primario”
En líneas generales muchos clientes aplican métodos manuales para re-direccionar sus aplicaciones hacia servidores con bases de datos “Standby”, una vez efectuada una operación de tipo “Switchover” o “Failover”.
Antes de ir mas allá en este tema hay una pregunta que deberían hacerse todos los DBAs que implantan soluciones de “Standby Databases”/”Data Guard”. Los productos Oracle gozan de un nivel elevado en tecnicismo y mas aun cuando estos poseen diversas versiones de desarrollo tal como el tema relacionado con “Standby Databases”/”Data Guard”. La pregunta seria la siguiente: Si las soluciones mencionadas poseen alto tecnicismo para realizar operaciones de “Switchover”/”Failover” y mas, ¿“Oracle Corp.” dejaría de lado el desarrollo o disponibilidad de un modo para que las aplicaciones puedan estar en alta escalabilidad con lo mencionado anteriormente?
La respuesta para el caso es: Si, “Oracle Corp” posee solución y modo para ello, lo mismo es denominado “Client Failover” para conexiones de aplicaciones. El concepto referido a “Client Failover” no está basado solo para el contexto de “Data Guard”.
Para mayor información al respecto les dejamos acá unos enlaces en cual podrán abarcar en forma profunda toda la información al respecto:
Client Failover Best Practices for Highly Available Oracle Databases: Oracle Database 11g Release 2
http://www.oracle.com/technetwork/database/features/availability/maa-wp-11gr2-client-failover-173305.pdf
Client Failover Best Practices for Highly Available Oracle Databases Oracle Database 12c
http://www.oracle.com/technetwork/database/availability/client-failover-2280805.pdf
How To Configure Client Failover For Dataguard Connections Using Database Services
El objetivo de este artículo es exponer de forma breve y efectiva una de las principales técnicas para conseguir implementar “Client Failover” en solución “Data Guard”. A través de los enlaces proporcionados, usted podrá abarcar el tema en un contexto general.
Iniciemos…
En la siguiente figura se expone una configuración típica de una solución “Data Guard”

Los primeros cambios a ser aplicados serán para los archivos “tnsnames.ora” & “sqlnet.ora” de servidores y clientes. En la figura podemos visualizar un servidor con IP: 192.168.56.146 el cual funge conceptualmente como servidor primario y el segundo con dirección IP: 192.168.56.136 como servidor “Standby”. En la descripción del “Tnsentry” encontrara la inclusión de ambos servidores. En el archivo “sqlnet.ora” la inclusión del parámetro “SQLNET.INBOUND_CONNECT_TIMEOUT”

Para mayor información del uso del parámetro “SQLNET.INBOUND_CONNECT_TIMEOUT”, colocamos acá la referencia textual de su descripción proveniente de la documentación oficial Oracle.
http://docs.oracle.com/cd/B28359_01/network.111/b28317/sqlnet.htm#CIHCCCHD

El objetivo principal del articulo y de la técnica que estamos exponiendo es presentar una configuración en la que sea posible que el cliente pueda conectarse indistintamente a la base de datos primaria independientemente de que esta se encuentre en cualquiera de los servidores sin modificar los archivos del cliente para cuando ocurra alguna transición ocasionada por un “Switchover” o “Failover”.
En la figura tenemos como ejemplo la ejecución de una operación de “Failover”. Internamente en la base de datos de producción y por consiguiente de forma replicada en la base de datos “Standby”, tendremos un servicio que para el presente caso lleva por nombre “ADMAPP”. El mismo estará iniciado “started” solo en la base de datos primaria, en la base de datos “Standby” el mismo estará detenido. El control para lo mencionado lo establecernos a través de un disparador en evento “Startup on Database”. Tal como podrán visualizar el código es bastante sencillo, si el rol que ejecuta dicha base de datos en ese momento es de tipo “Primary” entonces se procederá a su inicio en caso contrario permanecerá detenido como es su condición por defecto al momento del inicio de la base de datos.


Ubiquémonos en el escenario en el cual ya se ha llevado a cabo una operación de “Swithover” o “Failover”. Como resultado de la misma la base de datos primaria transformo su rol a “Standby Database” y viceversa para la original “Standby Database”, la cual para el momento desempeñaría rol como base de datos primaria.
Para el caso descrito, los clientes podrán establecer conexión sin problema alguno bajo esta nueva configuración debido a que el servicio “ADMAPP” se encuentra iniciado en la base de datos primaria que se encuentra trabajando en el servidor ( 192.168.56.136 ). Analizando la configuración “tnsentry” descrita, observara que la misma soporta la conexión descrita.

Entonces de esta sencilla manera podemos establecer “Client Failover” para bases de datos “Standby”. Lo mostrado acá es solo el concepto principal. Hay información adicional que conocer con respecto a que pasaría con el funcionamiento del “Observer” en caso de estar configurado, como aplicar TAF y sus efectos.. etc .. todo ello lo abarcaremos en la próxima entrega.
Para concluir el presente artículo mostremos un ejemplo de “tnsentry” para soportar el modelo descrito para ambiente RAC. Tal como puede apreciarse, poseemos una entrada para una configuración RAC, para dicho caso seria la solución típica que conforma el primario ( Base de datos de producción en RAC ) y el lado “Standby” configurado para el presente caso con un servidor con base de datos “Single Instance”. Descripción de la figura:
*  “LOAD_BALANCE” & “FAILOVER” para los 2 elementos de la lista ( Configuración RAC & “Single Instance” )
* Como es de forma natural y habitual, “LOAD_BALANCE” para la configuración interna de la solución RAC.

Estimados lectores hemos llegado al final de esta entrega, esperando que el presente artículo sea de utilidad. Nos despedimos hasta la próxima entrega.
Saludos!

PURGE AUDITORIA 11G - 12C

Como decíamos al principio, vamos ha configurar la base de datos para que se borren los registros anteriores a 100 días.

Lo primero que tendremos que hacer es inicializar el paquete con  DBMS_AUDIT_MGMT.init_cleanup

 En nuestro caso lo lanzaremos sobre AUDIT_TRAIL_AUD_STD Ya que lo que queremos limpiar son los registros de las tablas de auditoria de la base de datos, si quisiéramos limpiar otro (por ejemplo los del S.O seguiríamos la tabla Audit Trail Types)

BEGIN
 DBMS_AUDIT_MGMT.init_cleanup(
 audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
 default_cleanup_interval => 24 /* horas*/);
END;

Tras esto, con la propiedad SET_LAST_ARCHIVE_TIMESTAMP indicamos cual es la fecha del ultimo registro que queremos guardar.(en nuestro caso borraremos todo lo anterior a 100 días)

BEGIN
  DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP(
    audit_trail_type  => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
    last_archive_time => SYSTIMESTAMP-100 /*100 días*/);
END;

-- Set the Maximum age of XML audit files to 10 days.

BEGIN
  DBMS_AUDIT_MGMT.set_audit_trail_property(
    audit_trail_type           => DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML,
    audit_trail_property       => DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE,
    audit_trail_property_value => 10);
END;
/

Antes de ejecutar el trabajo, vamos a ver cual es el registro más antiguo:

SQL> select min(ntimestamp#) from sys.aud$;
-------------------------------------------
17/10/13 00:00:50,119000

Ejecutamos el purgado con la llamada

BEGIN
  DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
   audit_trail_type=> DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
   use_last_arch_timestamp => TRUE);
END;

Tras ejecutar esto, el último registro debería de corresponderse con la fecha SYSDATE-100.
Si lo comprobamos tendremos que

SQL> select to_date(SYSTIMESTAMP-100) from dual 
--------
11/11/13
SQL> select min(ntimestamp#) from sys.aud$;
------------------------------------------
11/11/13 16:46:08,889000

Con lo que, efectivamente, habremos borrado todos los registros anteriores a 100 días.
A partir de ahora, podemos, o bien llevar a cabo los borrados de manera puntual con la llamada anterior, o planificarlos con en un job de purgado con la llamada

BEGIN
  DBMS_AUDIT_MGMT.CREATE_PURGE_JOB(
    audit_trail_type  => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
    audit_trail_purge_interval => 24 /* horas */,  
    audit_trail_purge_name => 'PURGADO_DE_TABLAS_AUDITORIA',
    use_last_arch_timestamp=> TRUE);
END;

Generando reportes AWR, ASH y ADDM

Generando reportes AWR, ASH y ADDM

En algún momento durante el monitoreo de nuestra base de datos Oracle será necesario obtener información detallada en reportes, estos podrían ser los de AWR, AHR y/o ADDM. Este post se enfocará en realizar las mismas utilizando scripts, una manera alternativa a lo que nos ofrece con la interfaz gráfica de Enterprise Manager. A continuación se detalla los pasos para obtener los reportes.

A) Reporte AWR (awrrpt.sql)

El utilitario de informes AWR proporciona una visión general del rendimiento de bases de datos en un determinado tiempo. En esencia, calcula la variación de la actividad de la base de datos en el intervalo de tiempo elegido. el script "awrrpt.sql" se encuentra en el directorio $ORACLE_HOME/RDBMS/admin.

La salida del archivo es ubicada en el directorio actual. Para una mejor comprensión de dicho informe seleccionar el formato HTML.

1. Ingresamos al directorio donde se generará el Informe AWR.

bash-3.2$ cd /u01/informes/
bash-3.2$ pwd
/u01/informes
bash-3.2$ ls
bash-3.2$

2 Nos conectamos vía sqlplus con usuario de provilegios de DBA.

bash-3.2$ sqlplus pticona

SQL*Plus: Release 11.2.0.3.0 Production on Sun Jun 22 23:58:15 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Enter password:

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options

SQL>

3. Ejecutamos awrrpt.sql y nos aparecerá los datos actuales de la instancia.

SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql

Current Instance
~~~~~~~~~~~~~~~~

   DB Id    DB Name      Inst Num Instance
----------- ------------ -------- ------------
  798387748 PRMY                1 prmy

3.1. Elegimos la opción para que el informe se genere en formato "html".

Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Would you like an HTML report, or a plain text report?
Enter 'html' for an HTML report, or 'text' for plain text
Defaults to 'html'
Enter value for report_type:html

Type Specified:  html


Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   DB Id     Inst Num DB Name      Instance     Host
------------ -------- ------------ ------------ ------------
* 798387748         1 PRMY         prmy         primario

Using  798387748 for database Id
Using          1 for instance number

3.2. Para encontrar todos los AWR de la base de datos solo damos enter sin escribir nada.

Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed.  Pressing  without
specifying a number lists all completed snapshots.

Enter value for num_days:

Listing all Completed Snapshots

                                                        Snap
Instance     DB Name        Snap Id    Snap Started    Level
------------ ------------ --------- ------------------ -----
prmy         PRMY                 1 18 Jun 2014 01:30      1
                                  2 18 Jun 2014 11:13      1
                                  3 18 Jun 2014 12:00      1
                                  4 22 Jun 2014 15:04      1
                                  5 22 Jun 2014 16:00      1
                                  6 22 Jun 2014 17:00      1
                                  7 22 Jun 2014 18:00      1
                                  8 22 Jun 2014 19:00      1
                                  9 22 Jun 2014 20:00      1
                                 10 22 Jun 2014 21:00      1
                                 11 22 Jun 2014 22:00      1
                                 12 22 Jun 2014 23:00      1
                                 13 23 Jun 2014 00:01      1

3.3. Con el listado desplegado, elegimos el intervalo de tiempo.

Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 10
Begin Snapshot Id specified: 10

Enter value for end_snap: 11
End   Snapshot Id specified: 11

3.4. Asignamos el nombre para el reporte.

Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is awrrpt_1_10_11.html.  To use this name,
press  to continue, otherwise enter an alternative.

Enter value for report_name: reporte_awr.html
.
.
Report written to reporte_awr.html

3.5. Salimos de sqlplus.

SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options
bash-3.2$

4 Finalmente verificamos el archivo creado.

bash-3.2$ pwd
/u01/informes
bash-3.2$ ls
reporte_awr.html
bash-3.2$

5 Para realizar una comparativa de reportes AWR, utilizar el siguiente script.

SQL> @$ORACLE_HOME/rdbms/admin/awrddrpt.sql

B) Reporte ASH (ashrpt.sql)

El reporte ASH es útil para determinar la cantidad de sesiones activas, lo que estaban haciendo, y que sentencias SQL son las más activas durante el período de tiempo seleccionado. Especialmente es muy útil para el análisis de problemas de rendimiento transitoria. El script "ashrpt.sql" se encuentra en el directorio $ORACLE_HOME/RDBMS/admin.

La salida del archivo es ubicada en el directorio actual. Para una mejor comprension de dicho informe seleccionar el formato HTML. 

1. Ingresamos al directorio donde se generará el Informe ASH.

bash-3.2$ cd /u01/informes/
bash-3.2$ pwd
/u01/informes
bash-3.2$ ls
bash-3.2$

2 Nos conectamos vía sqlplus con usuario de provilegios de DBA.

bash-3.2$ sqlplus pticona

SQL*Plus: Release 11.2.0.3.0 Production on Sun Jun 22 23:58:15 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Enter password:

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options

SQL>

3. Ejecutamos ashrpt.sql y nos aparecerá los datos actuales de la instancia.

SQL> @$ORACLE_HOME/rdbms/admin/ashrpt.sql

Current Instance
~~~~~~~~~~~~~~~~

   DB Id    DB Name      Inst Num Instance
----------- ------------ -------- ------------
  798387748 PRMY                1 prmy

3.1. Elegimos la opción para que el informe se genere en formato "html".

Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Enter 'html' for an HTML report, or 'text' for plain text
Defaults to 'html'
Enter value for report_type: html

Type Specified:  html

Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   DB Id     Inst Num DB Name      Instance     Host
------------ -------- ------------ ------------ ------------
* 798387748         1 PRMY         prmy         primario

Defaults to current database

Using database id: 798387748

Enter instance numbers. Enter 'ALL' for all instances in a
RAC cluster or explicitly specify list of instances (e.g., 1,2,3).
Defaults to current instance.

Using instance number(s): 1

3.2. Ingresamos la hora de inicio y el intervalo de tiempo de duracion para el reporte ASH.

ASH Samples in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Oldest ASH sample available:  18-Jun-14 01:19:24   [   7150 mins in the past]
Latest ASH sample available:  23-Jun-14 00:29:06   [      0 mins in the past]


Specify the timeframe to generate the ASH report
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter begin time for report:

--    Valid input formats:
--      To specify absolute begin time:
--        [MM/DD[/YY]] HH24:MI[:SS]
--        Examples: 02/23/03 14:30:15
--                  02/23 14:30:15
--                  14:30:15
--                  14:30
--      To specify relative begin time: (start with '-' sign)
--        -[HH24:]MI
--        Examples: -1:15  (SYSDATE - 1 Hr 15 Mins)
--                  -25    (SYSDATE - 25 Mins)

Defaults to -15 mins
Enter value for begin_time: 06/22/14 21:05
Report begin time specified: 06/22/14 21:05

Enter duration in minutes starting from begin time:
Defaults to SYSDATE - begin_time
Press Enter to analyze till current time
Enter value for duration: 60
Report duration specified:   60

Using 22-Jun-14 21:05:00 as report begin time
Using 22-Jun-14 22:05:00 as report end time

3.3. Asignamos el nombre para el reporte ASH.

Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is ashrpt_1_0622_2205.html.  To use this name,
press  to continue, otherwise enter an alternative.
Enter value for report_name: reporte_ash.html
.
.
Report written to reporte_ash.html

3.4. Salimos de sqlplus.

SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options
bash-3.2$

4 Finalmente verificamos el archivo creado.

bash-3.2$ pwd
/u01/informes
bash-3.2$ ls
reporte_ash.html
bash-3.2$

C) Reporte ADDM (addmrpt.sql)
El utilitario de ADDM crea un informe con las conclusiones de rendimiento de base de datos. El script "addmrpt.sql" se encuentra en el directorio $ORACLE_HOME/RDBMS/admin. La salida del archivo se ubica en el directorio actual y es enformato de archivo de texto.
1. Ingresamos al directorio donde se generará el reporte ADDM.

bash-3.2$ cd /u01/informes/
bash-3.2$ pwd
/u01/informes
bash-3.2$ ls
bash-3.2$

2 Nos conectamos vía sqlplus con usuario de provilegios de DBA.

bash-3.2$ sqlplus pticona

SQL*Plus: Release 11.2.0.3.0 Production on Sun Jun 22 23:58:15 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Enter password:

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options

SQL>

3. Ejecutamos addmrpt.sql y nos aparecerá los datos actuales de la instancia.

SQL> @$ORACLE_HOME/rdbms/admin/addmrpt.sql

Current Instance
~~~~~~~~~~~~~~~~

   DB Id    DB Name      Inst Num Instance
----------- ------------ -------- ------------
  798387748 PRMY                1 prmy


Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   DB Id     Inst Num DB Name      Instance     Host
------------ -------- ------------ ------------ ------------
* 798387748         1 PRMY         prmy         primario

Using  798387748 for database Id
Using          1 for instance number


Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed.  Pressing  without
specifying a number lists all completed snapshots.



Listing the last 3 days of Completed Snapshots

                                                        Snap
Instance     DB Name        Snap Id    Snap Started    Level
------------ ------------ --------- ------------------ -----
prmy         PRMY                 4 22 Jun 2014 15:04      1
                                  5 22 Jun 2014 16:00      1
                                  6 22 Jun 2014 17:00      1
                                  7 22 Jun 2014 18:00      1
                                  8 22 Jun 2014 19:00      1
                                  9 22 Jun 2014 20:00      1
                                 10 22 Jun 2014 21:00      1
                                 11 22 Jun 2014 22:00      1
                                 12 22 Jun 2014 23:00      1
                                 13 23 Jun 2014 00:01      1

3.1. Elegimos el intervalo de snapshots para el reporte ADDM.

Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 10
Begin Snapshot Id specified: 10

Enter value for end_snap: 11
End   Snapshot Id specified: 11

3.2. Asignamos el nombre para el reporte.

Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is addmrpt_1_10_11.txt.  To use this name,
press  to continue, otherwise enter an alternative.

Enter value for report_name: reporte_addm.txt
.
.
.
The database's maintenance windows were active during 100% of the analysis
period.

End of Report
Report written to reporte_addm.txt
SQL>

3.3. Salimos de sqlplus.

SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options
bash-3.2$

4 Finalmente verificamos el archivo creado.

bash-3.2$ pwd
/u01/informes
bash-3.2$ ls
reporte_addm.txt
bash-3.2$

CLOUD CONTROL 12C

Comenzamos parando Cloud Control y todas las dependencias.

1 2 3 4 5 6 7 8 9 10 11 12 13

# Primero paramos Oracle Management Server (OMS) $OMS_HOME/bin/emctl stop oms -all   # Paramos el Agente $AGENT_HOME/bin/emctl stop agent   # Paramos la BD del Repositorio (MS12C) con SQL*Plus sqlplus / as sysdba << EOF SHUTDOWN IMMEDIATE EOF   # Paramos el Listener lsnrctl stop

Levantamos Cloud Control, pero hay que hacerlo en orden inverso a la parada.

1 2 3 4 5 6 7 8 9 10 11 12 13

# Levantamos el Listener lsnrctl start   # Paramos la BD del Repositorio (MS12C) con SQL*Plus sqlplus / as sysdba << EOF STARTUP EOF   # Levantamos Oracle Management Server (OMS) $OMS_HOME/bin/emctl start oms   # Por último levantamos el Agente (se recomienda esperar al menos 15 segundos antes de lanzar el comando) $AGENT_HOME/bin/emctl start agent