Reporte de Tablespace desde Cloud Control 13c

En esta ocasión les comparto una manera muy fácil de tener controlados los tablespaces de todas las bases de datos que tenemos que administrar en el día a día. El objetivo de esta guía es para poder enterarnos mediante un simple reporte las alertas abiertas relacionadas a tamaños de tablespaces, para poder accionar a tiempo antes de que alguno de ellos se quede sin espacio y generemos un corte de servicio.
En este ejemplo vamos a armar un reporte teniendo las siguientes consideraciones previas.
– Ya contamos con un Cloud Control 13c configurado.
– Las BBDD ya se encuetran monitoreandose por esta vía.
-Contamos con un grupo “Ej: Bases productivas” donde tenemos las bases de datos que queremos que nos informe el estado de sus tablespaces.

1)Abrimos nuestro Cloud Control y vamos al siguiente menu.
Enterprise -> Informes -> Informes de BI Publisher Enterprise

Outstanding Alerts (group) -> Vamos a usar ese reporte de modelo

Accedemos a “Editar Informe”
En la pestaña Group, podemos cambiar por el grupo que tengamos creados. En este ejemplo, yo cuento con un grupo “BD-Prod”, donde allí agrupé a todas las bases que dan servicios a los ambientes de Producción.

Accedemos al modelo de datos del reporte Modelo,

Vamos a crear un filtro en el modelo de datos de alertas, de modo tal que nos traiga únicamente las alertas asociadas a los tablespaces alertados (Warning y Criticals)

Agregamos el siguiente filtro
Metric_Alerts.METRIC_ID==’Tablespace Space Used (%)’

Modificamos el query para el Resumen, de manera tal que nos indique el resumen de las alertas de tablespaces.

Summary -> Editar Juego de Datos
SELECT 'Metric Alerts' ALERT_TYPE_ID,    NVL(SUM(decode(ALERT_STATE,'Critical',1,0)),0) CRITICAL_ID,
     NVL(SUM(decode(ALERT_STATE,'Warning',1,0)),0) WARNING_ID,'N/A' INFORMATIONAL_ID,
     COUNT(UNIQUE target_guid) TARGETS_AFFECTED_ID from MGMT$ALERT_CURRENT B where 
     target_guid IN( select  MEMBER_TARGET_GUID FROM  MGMT$TARGET_FLAT_MEMBERS where aggregate_target_name = (:param_group_name))
     AND B.violation_type in('Resource','Threshold Violation') AND B.ALERT_STATE in ('Critical','Warning') AND B.COLUMN_LABEL='Tablespace Space Used (%)'

Aceptamos el filtro, y guardamos el reporte, en la pestaña “Guardar como”
Para que quede ordenado, podemos guardarlo en la carpeta “Alerts”

En la pestaña de Datos, tenemos que cargar los datos de ejemplo, para luego incluirlos en el Informe. Para ello, aumentar el tamaño de filas a 50, y hacer click en “Ver”. Luego -> Guardar como Datos de Ejemplo

Pueden agregarle una descripción si quieren.

Hasta acá, ya contamos con el Data Model del reporte. Ahora vamos a Crear el informe a partir de uno ya existente. Para Ello:
En el Menú del BI Publisher -> Abrir.

Exportamos el informe como RTF, y lo guardamos en nuestra PC

Ahora, una vez descargado el RTF, Vamos a crear un Reporte Nuevo. Para ello
Nuevo -> Informe

Click en Finalizar -> Lo guardamos con un nombre acorde al Informe

Guardamos el informe, y lo visualizamos para ver los resultados.
Este es el ejemplo del reporte recientemente creado.

Asi se ve el reporte de tablespaces que generamos. Ahí mismo pueden programar el reporte para que les llegue al correo
“Acciones” -> “Programar”..
Es bastante intuitivo, el scheduler del BI. Pero cualquier cosa me preguntan

Saludos

OBIEE 12c – Tunning

Documento de referencia:
OBIEE 12c: Best Practices Guide for Infrastructure Tuning Oracle® Business Intelligence Enterprise Edition 12c (12.2.1) (Doc ID 2106183.1)

Uno de los errores mas comunes a la hora de instalar desde cero un producto de Oracle, ya sea Base de datos, EBS, OBIEE; etc, es dejar su configuración por default. En este post vamos a realizar un “Tunning” a la herramienta de explotación de datos de Oracle, o mejor conocida como “OBIEE”. Dejar esta configuración por defecto en un entorno productivo puede conllevar a problemas de disponibilidad cuando el número de usuarios comienza a crecer. Vamos a configurar parámetros, tanto de sistema operativo, como de OBIEE.
Nota importante: En este post omitimos la configuración de la base de datos, dado que no hay un parámetro en particular para mejorar la performance de OBIEE. A la base de datos, le llegaran queries cuyos puntos débiles serán los “Joins” y los “Group by”. Dependiendo del volumen de datos que se analizarán se necesitará más o menos Hardware para soportarlo.

Performance a nivel Sistema Operativo:
En este ejemplo, utilicé como SO un Oracle Linux 7

#Setear el tcp_fin_timeout para liberar mas rapidamente las sesiones que fueron cerradas, liberando los recursos para las siguientes.
/proc/sys/net/ipv4/tcp_fin_timeout -> Setear en 30

#Configuracion del limits.conf
#Modificar el archivo /etc/security/limits.conf, con los siguientes valores.
#Buenas prácticas en OBIEE
*  soft nofile 131072
*  hard nofile 131072
*  soft nproc 131072
*  hard nproc 131072

Performance a nivel Web Logic Server

1)Aumentar los “Connection Pools” de los datasources a 500.

La razón por la cual este valor viene por defecto en un valor pequeño, es debido a que Oracle protege los recursos de nuestra base de datos. Por ello, antes de cambiarlo hay que asegurarse que nuestra base de datos cumpla con los requisitos mínimos para correr OBIEE.
Una vez cambiado los valores, confirmar los cambios yendo a “Activate Changes”. Hacer esto para cada uno de los datasource que indica el weblogic

Configuracion de Stuck Threads
La configuracion mas importante dentro del WebLogic,
Configurar los “Stuck Thread Max Time”, Stuck Thread Timer Interval y Max Stuck Thread Time en 3600. Es el tiempo máximo (en segundos) que un thread se pone en estado “Stuck”, la principal causa de que un Thread se ponga en este estado es debido a reportes que demoran mas de lo seteado en estos parámetros. Hay que ir jugando con estos valores para dejarlo según las necesidades de cada ambiente. Para cambiarlo:
En la consola de weblogic: Environment -> Servers -> bi_server1 -> Tunning

Luego en la pestaña “Overload”, modificar el restante

Configuracion de memoria (JVM)
En este ejemplo, se llevan las memorias de java a 4GB
1) Aumentar la JVM encargada de levantar la instancia de OBIEE
Modificar el archivo /u01/app/Middleware/oracle_common/common/bin/commBaseEnv.sh

2) Aumentar las JVM del bi_server1 y NodeManager
Abrir el archivo /u01/app/Middleware/user_projects/domains/bi/bin/setStartupEnv.sh y editar a partir de la línea 296, las siguientes líneas

        # 64 bit JVM memory settings
        SERVER_MEM_ARGS_64="-Xms4096m -Xmx4096m"
        export SERVER_MEM_ARGS_64
        SERVER_MEM_ARGS_64HotSpot="-Xms4096m -Xmx4096m"
        export SERVER_MEM_ARGS_64HotSpot
        SERVER_MEM_ARGS_64JRockit="-Xms4096m -Xmx4096m"
        export SERVER_MEM_ARGS_64JRockit

En el mismo archivo, editar las lineas, a partir de la 192

       # 64 bit JVM memory settings
        SERVER_MEM_ARGS_64="-Xms4096m -Xmx4096m"
        export SERVER_MEM_ARGS_64
        SERVER_MEM_ARGS_64HotSpot="-Xms4096m -Xmx4096m"
        export SERVER_MEM_ARGS_64HotSpot
        SERVER_MEM_ARGS_64JRockit="-Xms4096m -Xmx4096m"
        export SERVER_MEM_ARGS_64JRockit

Configuracion en la capa OBIPS (Presentation Services Component)
Archivo a modificar: /u01/app/Middleware/user_projects/domains/bi/config/fmwconfig/biconfig/OBIPS/instanceconfig.xml

Agregar el siguientes lineas dentro de bloque <ServerInstance>

        <ThreadPoolDefaults>
          <ChartThreadPool>
             <MinThreads>100</MinThreads>
             <MaxThreads>400</MaxThreads>
             <MaxQueue>2048</MaxQueue>
          </ChartThreadPool>
        </ThreadPoolDefaults>

	 <Cache>
        <CatalogXml>
                <!-- Remove from the cache everything older than N minutes -->
                <MaxAgeMinutes>240</MaxAgeMinutes>
                <MaxLastAccessedSeconds>14400</MaxLastAccessedSeconds>
        </CatalogXml>
        <Query>
                <MaxEntries>5000</MaxEntries>
                <!-- AbsoluteMaxEntries is the enforced maximum number of entries. When this maximum is reached -->
                <!-- subsequent queries will fail until the maximum is no longer exceeded. -->
                <AbsoluteMaxEntries>20000</AbsoluteMaxEntries>
                <!-- CruiseEntries is amount of entries the OracleBI Presentation server tries to maintain in its cache. -->
                <CruiseEntries>3000</CruiseEntries>
                <!-- Forces the cache to attempt to remove an old entry when MaxEntries is exceeded. -->
                <ForceLRU>true</ForceLRU>
        </Query>
  </Cache>
		

Alinear el tiemout seteado en OBIPS con el analytics.
Para ello, ingresar al “Enterprise Manager” de OBIEE (http://yourserver.domain:9500/em), Navegar hasta el biinstance, y modificar el parámetro “Expiry time” a 60 minutos.

Es recomendable setear el parámetro “Session Expiry”, como bien dice el parámetro, setea un timeout cuando la sesión no se encuentra activa. En este caso en el ambiente de laboratorio se setea en 60 minutos.

Configuracion Capa BI Server
Archivo a modificar: $MW_HOME/user_projects/domains/bi/config/fmwconfig/biconfig/OBIS/NQSConfig.INI
Modificar los siguientes parámetros.

INIT_BLOCK_CACHE_ENTRIES = 5000;
SERVER_THREAD_RANGE = 80-1000;
DB_GATEWAY_THREAD_RANGE = 80-1000;
MAX_CACHE_ENTRY_SIZE = 40 MB;
MAX_CACHE_ENTRIES = 5000;
POPULATE_AGGREGATE_ROLLUP_HITS = YES;
WORK_DIRECTORY_PATHS = "/tmp/OBIEE";
SORT_BUFFER_INCREMENT_SIZE = 256 KB;
VIRTUAL_TABLE_PAGE_SIZE = 256 KB;

Se recomienda un reinicio general de OBIEE para que impacten todos los cambios.

Purga automática de la Recycle bin

En muchas organizaciones suele estar activa la recyclebin para poder aprovechar del feature “FLASHBACK TABLE”, el cual podemos recuperar una tabla accidentalmente eliminada con tal solo un comando (para el próximo posteo voy a publicar un caso de uso con este grandioso feature). A continuación voy a dejar el instructivo para poder, no solo activar la recyclebin, sino a mantenerla. Los motores Oracle no cuentan con un proceso automático de purga de la recyclebin, lo cual en caso de necesitarlo deberíamos programarlo por nuestra propia cuenta. Eso es lo que les voy a dejar a continuación.

  1. Primero nos vamos a asegurar que tengamos la recyclebin activa.
 sqlplus / as sysdba
SQL> set linesize 300
SQL> show parameter recyclebin
NAME                                 TYPE                             VALUE
------------------------------------ -------------------------------- -----------------------------
recyclebin                           string                           ON

En caso que el valor esté en “off”, debemos activarla. Para ello:

SQL> alter system set recyclebin=on scope=spfile;
System altered.

Ahora si, les comparto un procedure que encontré en un blog de un colega (
Rack Blogger ). La base del procedure es de el, pero lo he modificado dado que al implementarlo el mismo compilaba con errores.
IMPORTANTE: Antes de implementarlo en producción, les aconsejo probar su funcionamiento en los ambientes previos (Desarrollo, QA, Pre-Produccion)

CREATE OR REPLACE PROCEDURE purge_dba_recylebin (
   p_purge_before_date     IN DATE DEFAULT NULL,
   p_purge_keep_versions   IN NUMBER DEFAULT NULL,
   p_test_only             IN VARCHAR2 := 'Y')
IS
   CURSOR c_purge_before_date
   IS
      SELECT owner,object_name, type
        FROM dba_recyclebin
       WHERE droptime  p_purge_keep_versions;

   v_sql   VARCHAR2 (1024);

   PROCEDURE runsql (p_object_owner IN VARCHAR2, p_object_name in varchar2, p_object_type IN VARCHAR2)
   IS
   BEGIN
      v_sql := 'purge '||p_object_type||' '||p_object_owner||'."'|| p_object_name||'"';

      IF (p_test_only = 'N')
      THEN
         BEGIN
            EXECUTE IMMEDIATE v_sql;
         EXCEPTION
            WHEN OTHERS
            THEN
               DBMS_OUTPUT.put_line ('Error dropping ' || p_object_name);
               DBMS_OUTPUT.put_line (DBMS_UTILITY.format_error_backtrace);
         END;
      ELSE
         DBMS_OUTPUT.put_line (v_sql);
      END IF;
   END;
BEGIN
   IF p_purge_before_date IS NOT NULL AND p_purge_keep_versions IS NULL
   THEN
      FOR r IN c_purge_before_date
      LOOP
         runsql (r.owner,r.object_name,r.type);
      END LOOP;
   ELSE
      IF p_purge_before_date IS NULL AND p_purge_keep_versions IS NOT NULL
      THEN
         FOR r IN c_purge_before_version
         LOOP
            runsql (r.owner,r.object_name,r.type);
         END LOOP;
      END IF;
   END IF;   
   END purge_dba_recylebin;
/

Ahora generamos el scheduler job que ejecutará cada una hora, y ejecutará la purga de la recyclebin. En este ejemplo creo el job para que corra cada una hora, y voy a mantener 24 horas de recyclebin en la base de datos.

BEGIN
  SYS.DBMS_SCHEDULER.CREATE_JOB
    (
       job_name        => 'SYS.DAILY_PURGE_RECYCLEBIN'
      ,start_date      => SYSTIMESTAMP
      ,repeat_interval => 'freq=hourly; byminute=0; bysecond=0;'
      ,end_date        => NULL
      ,job_class       => 'DEFAULT_JOB_CLASS'
      ,job_type        => 'PLSQL_BLOCK'
      ,job_action      => 'BEGIN purge_dba_recylebin(sysdate-1,NULL,''N''); END;'
-- el sysdate-1 le indico al procedure que quiero mantener 24hs de retención.
      ,comments        => NULL
    );
  SYS.DBMS_SCHEDULER.SET_ATTRIBUTE
    ( name      => 'SYS.DAILY_PURGE_RECYCLEBIN'
     ,attribute => 'RESTARTABLE'
     ,value     => FALSE);
  SYS.DBMS_SCHEDULER.SET_ATTRIBUTE
    ( name      => 'SYS.DAILY_PURGE_RECYCLEBIN'
     ,attribute => 'LOGGING_LEVEL'
     ,value     => SYS.DBMS_SCHEDULER.LOGGING_OFF);
  SYS.DBMS_SCHEDULER.SET_ATTRIBUTE_NULL
    ( name      => 'SYS.DAILY_PURGE_RECYCLEBIN'
     ,attribute => 'MAX_FAILURES');
  SYS.DBMS_SCHEDULER.SET_ATTRIBUTE_NULL
    ( name      => 'SYS.DAILY_PURGE_RECYCLEBIN'
     ,attribute => 'MAX_RUNS');
  SYS.DBMS_SCHEDULER.SET_ATTRIBUTE
    ( name      => 'SYS.DAILY_PURGE_RECYCLEBIN'
     ,attribute => 'STOP_ON_WINDOW_CLOSE'
     ,value     => FALSE);
  SYS.DBMS_SCHEDULER.SET_ATTRIBUTE
    ( name      => 'SYS.DAILY_PURGE_RECYCLEBIN'
     ,attribute => 'JOB_PRIORITY'
     ,value     => 3);
  SYS.DBMS_SCHEDULER.SET_ATTRIBUTE_NULL
    ( name      => 'SYS.DAILY_PURGE_RECYCLEBIN'
     ,attribute => 'SCHEDULE_LIMIT');
  SYS.DBMS_SCHEDULER.SET_ATTRIBUTE
    ( name      => 'SYS.DAILY_PURGE_RECYCLEBIN'
     ,attribute => 'AUTO_DROP'
     ,value     => TRUE);

  SYS.DBMS_SCHEDULER.ENABLE(name => 'SYS.DAILY_PURGE_RECYCLEBIN');
END;
/

Para chequear el resultado de la corrida del scheduler, ejecutamos lo siguiente

set linesize 300
set pagesize 900
SELECT OWNER,
         JOB_NAME,
         LOG_DATE,
         STATUS,
         RUN_DURATION
    FROM dba_scheduler_job_run_details
   WHERE job_name = 'DAILY_PURGE_RECYCLEBIN'
ORDER BY log_date DESC;

Eso es todo. Ahora nos olvidamos de purgar manualmente la recyclebin

¡Hasta la próxima!

Schedule Backup desde OCC 13c

Buenas!!! En mi primer post voy a dejar el “Paso a Paso” de cómo realizar un schedule de backup de una determinada base de datos desde la conocida herramienta “Cloud Control 13c”. Es muy común administrar bases de datos que se encuentran en diversos servidores. Muchos administradores que tienen sus bases en SO Linux suelen dejar programados los backups con el “crontab”. Eso implica contar con un script de backup en cada servidor de base de datos, y a la larga, creanme se torna dificultoso el mantenimiento. He decidido centralizar esta tarea “engorrosa” pero necesaria en el Cloud Control, que permite crear schedule de backups en las BBDD que tenemos registradas allí. Comenzamos

Nota importante: Voy a configurar un schedule de backup “Online”. Recordemos que para realizar este tipo de backups es necesario tener nuestra base de datos en modo “archivelog”.


1)Accedemos con user/pass a nuestro Cloud Control (Voy a ingresar como SYSMAN en este ejemplo)

Hacemos clic en la “Lupa” para buscar nuestra BD que queremos programar el backup.
Availability -> Backup & Recovery -> Schedule Backup…
Nos pedirá credenciales para acceder a la BD, suelo utilizar SYS para no tener problemas de permisos. En caso de no poder contar con dicho usuario podemos realizarlo con un usuario que tenga role DBA.
Como mencionamos anteriormente, vamos a programar un FULL BACKUP ONLINE. Como verán, el OCC13 nos permite programar diferentes tipos de backup, incluyendo solo CDB (12c), solo PDB(12c), Tablespaces particulares, Datafiles particulares, Archivelogs, etc.
Como veremos, también nos da la posibilidad de programar backups incrementales, en nuestro caso solo queremos Full Backups.
Nota importante: Los backups incrementales son muy útiles a la hora de tomar backups de bases de datos extremadamente grandes, dado que partimos de un level 0, y luego se toma backup únicamente de los cambios. Tener en cuenta que a la hora de realizar el restore los tiempos de recupero son muchísimos mas altos que un restore de Full Backup.
Nota 2: Recordar que nuestra BD debe estar en modo archivelog para contar con Backups Online.
Nota 3: No olvidar hacer backups de nuestros archivelogs, y para evitar que se nos llene el espacio de los mismo, hacer el correspondiente “Delete input”.
Aquí podemos decidir si las piezas de backup irán al disco, o bien a una cinta. En este ejemplo vamos a configurar un backup a un FS /backup. De todas formas vamos a configurar ciertos parámetros de nuestro backup. Para ello vamos a “Override Default Settings”.
Paralelismo: En este caso voy a utilizar un paralelismo de 4. Tener mucho cuidado a la hora de configurar este parámetro, dado que puede causar sobrecarga en nuestros CPUs. causando una lentitud general del servidor donde reside nuestra base. Les dejo un criterio que suelo utilizar siempre y cuando los CPUs no sean una limitante.
– Bases que ocupan entre 0G y 50G -> Paralelismo 2.
– Bases que ocupan entre 50G y 200G -> Paralelismo 4
– Bases que ocupan entre 200G y 400G -> Paralelismo 6
– Bases que ocupan entre 400G y 800G -> Paralelismo 8
– Bases que ocupan más de 800G -> Paralelismo 10
Como les comentaba, es un criterio que utilizo. No necesariamente tienen que configurarlo de esta manera.

Importante: Al activar Compressed Backup Set, tengan en cuenta que requiere licencia adicional de compresión.

En backupset, vamos a configurar el nivel de compresión, en este ejemplo, utilizaré “MEDIUM
Nota: Vamos a configurar la politica de retención mas adelante. Hacemos clic en OK y nos llevará nuevamente al “Settings”. Luego en Next para ir al paso “Schedule”.
En este ejemplo, vamos a programar el backup para que corra todos los días, a las 00:00hs.
Luego nos vamos al próximo y último paso. el “Review”
Cuando hayamos revisado que los datos que hemos puesto sean los correctos, le daremos click a Submit y esta pantalla nos confirma que nuestro backup ha sido correctamente programado.
Si queremos ver cómo quedó programado, hacemos clic en “View Job”.
Evidencia de que nuestro backup quedó programado.
Si queremos reconfigurar nuestro backup, podemos hacerlo yendo a:
Availability > Backup & Recovery -> Backup Settings.
Configuramos por último nuestra politica de retenciones. En este ejemplo, voy a dejar solo 1 backup en disco.
Yendo a “Backup Reports” podemos visualizar el estado de nuestros backups.