Cambiar el partner agent en un OEM13

Hoy vamos a ver de manera sencilla como cambiar un partner agent en un OEM13.
Lo primero que debemos de tener en cuenta es ..

¿que es un partner agent?

Un partner agent es un agente al que se le asigna a propiedad de comprobar el estado de otro host, mediante esto lo que conseguimos es hacer mas rapido la deteccion del estado de un host.

Como sabemos cual es nuestro partner agent?

En el caso de tener definido un parner agent lo veremos en la ventana del OEM, pero , podemos comprobarlo tambien mediante la consulta SQL


set linesize 200
col 'Target Agent' format a50;
col 'Partner Agent' format a50;
select target_agent.target_name "Target Agent",
           partner_agent.target_name "Partner Agent"
      from
           sysman.EM_AGENT_BUDDY_MAP eabm,
                 sysman.mgmt_targets target_agent,
                 sysman.mgmt_targets partner_agent
      where
          eabm.buddy_target_guid = partner_agent.target_guid and
          eabm.agent_target_guid = target_agent.target_guid and
         target_agent.target_name like  'server.pamplona.name:3875';
	
	
		 Target Agent                                       Partner Agent
-------------------------------------------------- --------------------------------------------------
server.pamplona.name:3875                        oldpartnerpamplona.name:3875

COmo cambiamos nuestro partner agent

Supongamos que quremos cambiarlo de oldpartner a newpartner
Lo primero que tendremos que hacer es eliminar el antiguo

./emcli manage_agent_partnership -remove_agent_partnership -monitored_agent=server.pamplona.name:3875 -partner_agent=oldpartnerpamplona.name:3875
Manage Agent Partnership operation completed successfully

Tras esto, ejecutamos el comando para añadir el nuevo

./emcli manage_agent_partnership -add_agent_partnership -monitored_agent=server.pamplona.name:3875 -partner_agent=newpartner.pamplona.name:3875
Manage Agent Partnership operation completed successfully

Con esto tendremos cambiado el agente

Mas informacion el la nota EM 12c, 13c: FAQs on Partner Agent / Buddy Agent / Real Time Monitoring (Doc ID 1952190.1)

Errores psdgbt: bind csid (X) does not match session csid (YY)

Hoy vamos a ver una entrada rapida y sencilla que nos ayudara a evitar una cascada de errores en el alert.log

Es posible que, la reiniciar alguna e nuestras bases de datos que se encuentran bajo la monitorizacion de un Enterprise manager veamos que el alert.log de nuestra base de datos comienza a mostrar continuamente errores del tipo

Errors in file /u01/app/oracle/diag/rdbms/TEST_stby/TEST/trace/TEST_ora_743.trc:
Mon March 11 12:24:47 2019
Errors in file /u01/app/oracle/diag/rdbms/TEST_stby/TEST/trace/TEST_ora_743.trc:
Mon March 11 12:25:06 2019
Errors in file /u01/app/oracle/diag/rdbms/TEST_stby/TEST/trace/TEST_ora_743.trc:

Si comprobamos la traza podemos ver como se trata de errores del tipo

psdgbt: bind csid (1) does not match session csid (46)
psdgbt: session charset is XXX

Donde el charset variara en funcion de nuestra base de datos, veamos una de estas trazas

ORACLE_HOME = /u01/app/oracle/product/12.1.0/db
System name: Linux
Node name: test.pamplona.name
Release: 3.8.13-118.19.12.el6uek.x86_64
Version: #2 SMP Tue Oct 31 12:31:15 PDT 2017
Machine: x86_64
Instance name: TEST
Redo thread mounted by this instance: 1
Oracle process number: 32
Unix process pid: 743, image: oracle@test.pamplona.name

*** 2019-03-11 21:20:06.886
*** SESSION ID:(2.57596) 2019-03-11 21:20:06.886
*** CLIENT ID:() 2019-03-11 21:20:06.886
*** SERVICE NAME:() 2019-03-11 21:20:06.886
*** MODULE NAME:(emagent_SQL_oracle_database) 2019-03-11 21:20:06.886
*** CLIENT DRIVER:(jdbcthin) 2019-03-11 21:20:06.886
*** ACTION NAME:(ME$icc_dbs_age_last_backup) 2019-03-11 21:20:06.886

psdgbt: bind csid (1) does not match session csid (46)
psdgbt: session charset is WE8ISO8859P15

*** 2019-03-11 21:20:06.886
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=1, mask=0x0)
—– Error Stack Dump —–
—– Current SQL Statement for this session (sql_id=a0qc12302fzfk) —–
begin dbms_application_info.set_module(:1 , :2 ); end;

La solucion para este problema es muy muy sencila, simplemente, reinicia el agente del enterprise manager del servidor donde se encuentra ubicada la base de datos.

Como siempre, mas informacion en soporte de Oracle
Doc ID 956222.1

Comprobando del OEM 13: alertas Data Failure Detected

Hoy vamos a ver otra entrada sobre las comprobaciones del OEM .

Una de los incidentes que hay que limpiar a mano en el enterprise manager es el de la comprobacion de la integridad dela base de datos.
El check de la metrica Data Failure Detected se basa en las comprobaciones de los Health monitor de Oracle.

Como saber a que problema se refiere

Mediante la libreria DBMS_HM podemos acceder a los checks llevados a cabo por Oracle.
Si ejecutamos la consulta

SET LONG 100000;
SET LONGCHUNKSIZE 1000
SET PAGESIZE 1000
SET LINESIZE 512
column name format a20;
column STATUS format a10;
column START_TIME format a20;
column END_TIME format a20;
column name format a20;
column STATUS format a10;
column START_TIME format a30;
column END_TIME format a30;
column CHECK_NAME format a40;

 select run_id,name,check_name,start_time,end_time,status 
   from v$hm_run order by START_TIME asc;

Obtendremos el listado de los checks ejecutados

    RUN_ID NAME                 CHECK_NAME                   START_TIME
---------- ---------------- -------------------- ------------------------------
   1 HM_RUN_1       DB Structure Integrity Check   25-JUL-18 05.18.01.337628 PM
  21 HM_RUN_21      DB Structure Integrity Check   25-JUL-18 05.19.35.157614 PM
  41 HM_RUN_41      DB Structure Integrity Check   25-JUL-18 05.20.51.496617 PM
  61 HM_RUN_61      DB Structure Integrity Check   25-JUL-18 05.52.24.630598 PM
9621 HM_RUN_9621    DB Structure Integrity Check   15-SEP-18 05.51.52.339032 PM
9641 HM_RUN_9641    DB Structure Integrity Check   15-SEP-18 05.53.25.135027 PM
 6 rows selected.

En el caso del ejemplo, preguntaremos por la ultima ejecucion, que es la HM_RUN_9641

DBMS_HM.GET_RUN_REPORT('HM_RUN_9641')
-----------------------------------------------------------------------------------------
Basic Run Information
 Run Name                     : HM_RUN_9641
 Run Id                       : 9641
 Check Name                   : DB Structure Integrity Check
 Mode                         : REACTIVE
 Status                       : COMPLETED
 Start Time                   : 2018-09-15 17:53:25.135027 +02:00
 End Time                     : 2018-09-15 17:53:28.473273 +02:00
 Error Encountered            : 0
 Source Incident Id           : 0
 Number of Incidents Created  : 0

Input Paramters for the Run
Run Findings And Recommendations
 Finding
 Finding Name  : Inaccessible CF
 Finding ID    : 9642
 Type          : FAILURE
 Status        : CLOSED
 Priority      : CRITICAL
 Message       : Control file
               +DATA/test/controlfile/current.599.982430265
               cannot be accessed because of an ASM Failure
 Message       : Database cannot be mounted

Aqui podemos ver como el error es referente a un controlfile inaccesbile , lo que parece ser un error antiguo.

¿Como asegurarnos de que todo esta correcto?

La respuesta mas obia es, lanzar nosotros mismos este check de manera manual para ver el resultado.
Para ello usaremos el procedure DBMS_HM.RUN_CHECK

SQL> SELECT DBMS_HM.GET_RUN_REPORT('Clear_OEM') FROM DUAL;

DBMS_HM.GET_RUN_REPORT('CLEAR_OEM')
-----------------------------------------------------------------------------------
Basic Run Information
 Run Name                     : Clear_OEM
 Run Id                       : 10581
 Check Name                   : DB Structure Integrity Check
 Mode                         : MANUAL
 Status                       : COMPLETED
 Start Time                   : 2018-09-18 20:58:12.283769 +02:00
 End Time                     : 2018-09-18 20:58:12.476010 +02:00
 Error Encountered            : 0
 Source Incident Id           : 0
 Number of Incidents Created  : 0

Input Paramters for the Run
Run Findings And Recommendations

Donde podemos ver como ya no tenemos errores

Como siempre, mas informacion en:

Asignar un EM Express para un PDB específico

Vamos a seguir viendo pequeñas entradas sencillas sobre aspectos básicos de las PDB y las 12c . En este caso veremos como habilitar el EMexprss para un PDB específico.

En la entrada Donde está la consola en la 12c? vimos que en la version 12c había desaparecido el EM console tal y como lo conocíamos, habiendo sido substituido por una version mucho mas ligera integrada en la propia base de datos y que funciona mediante XMLdb.

Hasta el momento, teníamos acceso a este EMXpress , hemos visto como Dar permisos solo lectura a un usuario del EM express, pero estábamos dando acceso a todo el CDB , algo que seguramente no queramos hacer.

Como habilitamos el acceso a un único PDB

La respuesta es tremendamente sencilla, solamente hay que logarse a este pDB y asignarle un puerto libre a el EM express.
Veamos la secuencia de comandos:



SQL> SHOW CON_NAME
CON_NAME 
------------------------------
CDB$ROOT

SQL> ALTER SESSION SET container = test1;

Session alterado.


SQL> select dbms_xdb_config.gethttpsport () from dual;

DBMS_XDB_CONFIG.GETHTTPSPORT()
------------------------------
                             0

SQL> exec dbms_xdb_config.Sethttpsport (5501);
Procedimiento PL/SQL terminado correctamente.
SQL> 

Si ejecutamos el comando DBMS_XDB_CONFIG.GETHTTPSPORT dentro de un PDB veremos que no aparece ningún puerto configurado, esto es por que por defecto el EM solamente está configurado en el CBD principal. Como vemos en los comandos, simplemente asignando un puerto con dbms_xdb_config.Sethttpsport obtenemos en el puerto elegido la consola del EM Express dedicada unidamente a este PDB

A pesar de que nos hemos logrado con SYS, que es un usuario global del CDB, en el puerto 5501 solamente podemos acceder al PDB TEST1

Donde está el Oracle Enterprise Manager en la 12c?

Una de las nuevas funcionalidad es de la 12c es que «la consola web» de Oracle pasa de ser un servicio java externo a ser un elemento en debido dentro de la base de datos.El nombre oficial de la consola es «Oracle Enterprise Manager Database Express» (OEM Database Express)
Esta consola es gestionada mediante el paquete DBMS_XDB_CONFIG.

EL EM express está iespecíficamente dseñado para ser un interfaz ligero que no tenga afectación sobre le rendimiento de la base de datos , no tiene ningún proceso de background o tareas asociado a la consola.
Al ser un componente dentro de la base de datos, necesita de que la propia base de datos esté levantada ,y no puede llevar acciones fuera de la base de datos.

Vamos a ver cuales son los comandos básicos para su uso

Lo primero que tenemos que hacer es asegurarnos que hay un displacer asociado


NAME            TYPE	 VALUE
-------------- ----------- ------------------------------
dispatcher       string	 (PROTOCOL=TCP) (SERVICE=testXDB)

Comprobar el puerto

SQL> select dbms_xdb_config.gethttpsport () from dual;
DBMS_XDB_CONFIG.GETHTTPSPORT()
------------------------------
			  5500

Cambiar el puerto

SQL> exec dbms_xdb_config.sethttpsport (5501);

Los procedimientos de DBMS_XDB_CONFIG necesitan permisos SYSDBA para poder ejecutarse

El EM Express usa Shockwave Flash ( SWF) por lo que su funcionamiento necesita de un navegador que tenga el pugin de flash instalado

Mas información óen :