Instalando Oracle VM

Hoy vamos a ver como se instala la plataforma de virtualizacion Oracle Vm. Al igual que otras veces, lo vamos ha hacer en una maqueta de pruebas formada por 3 servidores x86 en un entorno de Virtualbox.

Lo primero que tenemos que hacer es descargar las isos que necesitamos, para ello, iremos a downloads de oracle nos bajaremos las ISOS del vmserver y el vmmanager

ISOS disponibles

A continuación, deberemos de crear una máquina virtual, en mi caso la creación ha sido:

  • Arquitectura X86
  • Others
  • 4 Gb de RAM
  • 2 Cores
  • 100Mb de disco

Asignáremos la ISO del manager a nuestro servidor, y procederemos con la instlación tal y como se ve en las pantallas siguientes

Bienvenida

chequeo

Captura de pantalla 2014-05-28 a la(s) 21.01.23

a href=»http://clemente.pamplona.name/dba/wp-content/uploads/2014/05/Captura-de-pantalla-2014-05-28-a-las-21.13.17.png»>Discos

EULA

Captura de pantalla 2014-05-28 a la(s) 21.02.09

Boot loader

red

red

reloj

Captura de pantalla 2014-05-28 a la(s) 21.25.29

Captura de pantalla 2014-05-28 a la(s) 21.26.16

Captura de pantalla 2014-05-28 a la(s) 21.31.41

Captura de pantalla 2014-05-28 a la(s) 21.57.59

Con esto tenemos instalado el Hypervisor, pero para poder tener la plataforma completa deberemos de instalar el VM manager desde la cual controlarlo.

El equivalente a CONSISTENT=Y con expdp

Hoy vamos a ver otra de esas entradas sumamente sencillas que nos ahorrarán un montón de tiempo.

Si intentamos hacer un exdp de una base de datos grande que hace un uso muy intensivo de secuencias, podemos encontrarnos problemas a la hora de la importación con las claves ajenas, esto es debido a que el export que hemos llevado a cabo no es consistente.

En la versión antigua del export (exp) teníamos una opción llamda CONSISTENT=Y que nos permitía congelar la base de datos en el momento del export de manera que, la exportacion de nuestra base de datos era totalmente consistente. Sin embargo, la nueva funcionalidad expdp no lo tiene ¿hemos dado un paso atrás?

Afortunadamente, la respuesta es no, lo único que pasa, es que (como siempre) Oracle nos ha puesto algo mas dificil acertar con el nombre.

Lo que haremos con el expdp será el hacer un expdp con la opción FLASHBACK_TIME ó FLASHBACK_SCN

La nueva sintaxsis será :

  • Para hacer un export en el momento 15-05-2014 a las 21:00
    expdp user/pass ... FLASHBACK_TIME="TO_TIMESTAMP('15-05-2014 21:00:00', 'DD-MM-YYYY HH24:MI:SS')" ...
    
  • Para hacer un export en el momento que lo lanzas
    expdp user/pass ... FLASHBACK_TIME=systimestamp  ...
    
  • O bien, para lanzar un export en un determinado SCN
    expdp user/pass ... FLASHBACK_SCN=7782903
    

Hay que tener en cuenta dos cosas cuando lanzamos un expdp con FLASHBACK

  • Las dos opciones TIME y SCN son excluyentes: No se pueden poner las dos claúsulas en el mismo script de export
  • Es necesario contar con un UNDO suficiente para albergar los datos durante todo el export: Lo que estamos haciendo con esto, es mantener la base de datos congelada en ese punto, si el export dura 7 horas, deberemos de contar con un UNDO capaz de mantener todos los datos que se llevan a cabo durante estas 7 horas, de lo contrario ,el export fallará con el error típico de UNDO insuficiente

Como siempre, la información completa en la Documentación de oracle

Mantenimiento de las tablas de auditoría SYS.AUD$

Hoy vamos a ver algo tan básico como es el mantenimiento de las tablas de auditoria. Los registros de auditoria de la base de datos es una de esas cosas que tienden a crecer indiscriminadamente llenándonos los tablespaces del sistema sin que nos demos cuenta. Hoy vamos a ver como limitar estos registros a los de los últimos 100 días (algo mas de 3 meses).

En las versiones anteriores (9i,10g ) el mantenimiento de las tablas de auditoria era un poco «por tu cuenta y riesgo», había documentación de como hacerlo pero decía que no era soportada ( por ejemplo la nota Note: 1019377.6 Script to move SYS.AUD$ table out of SYSTEM tablespace ).
Afortunadamente en la versión 11g Oracle ha creado el paquete DBMS_AUDIT_MGMT facilitándonos la labor.

Lo primero que tenemos que ver es donde se encuentran las tabas de auditoria, para ello usaremos la consulta

SELECT table_name, tablespace_name
FROM dba_tables
WHERE table_name IN ('AUD$', 'FGA_LOG$')
ORDER BY table_name;

TABLE_NAME                     TABLESPACE_NAME
------------------------------ ------------------------------
AUD$                           SYSTEM
FGA_LOG$                       SYSTEM

O con la llamada al paquete

column parameter_name format a30
column parameter_value format a20
SELECT * FROM dba_audit_mgmt_config_params;

PARAMETER_NAME            PARAMETER_VALUE      AUDIT_TRAIL
------------------------ ------------------ ----------------------
DB AUDIT TABLESPACE            TS_AUD         STANDARD AUDIT TRAIL
DB AUDIT TABLESPACE            TS_AUD         FGA AUDIT TRAIL
AUDIT FILE MAX SIZE            10000          OS AUDIT TRAIL
AUDIT FILE MAX SIZE            10000          XML AUDIT TRAIL
AUDIT FILE MAX AGE             5              OS AUDIT TRAIL
AUDIT FILE MAX AGE             5              XML AUDIT TRAIL
DB AUDIT CLEAN BATCH SIZE      10000          STANDARD AUDIT TRAIL
DB AUDIT CLEAN BATCH SIZE      10000          FGA AUDIT TRAIL
OS FILE CLEAN BATCH SIZE       1000           OS AUDIT TRAIL
OS FILE CLEAN BATCH SIZE       1000           XML AUDIT TRAIL

10 filas seleccionadas.

Por defecto, estas tablas estarán en el tablespace SYSTEM, es muy importante el mover estas tablas fuera de este tablespace si vamos a trabajar sobre ellas,ya uqe, sino Oracle usará el tablespace SYSAUX,algo que no queremos que pase bajo ningún concepto.
Lo primero que vamos a hacer es crear un tablespace para la auditoria, así que, vamos a ver el tamaño que necesitamos y a crear un tablespace con suficiente tamaño:

SQL> select sum(bytes)/1024/1024 Mb 
        from dba_segments 
          where segment_name in ('AUD$', 'FGA_LOG$');
-------
200,0625
SQL> create tablespace TS_AUD
   datafile '\oracle\oradata\instancia\ts_audit01.dbf' size 250M;

Una vez tengamos el tablespace creado, podemos usar la llamada DBMS_AUDIT_MGMT.set_audit_trail_location para mover las tablas actuales al nuevo tablespace

BEGIN
 DBMS_AUDIT_MGMT.set_audit_trail_location(
 audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
 audit_trail_location_value => 'TS_AUD');
END;
 
BEGIN
 DBMS_AUDIT_MGMT.set_audit_trail_location(
 audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD,
 audit_trail_location_value => 'TS_AUD');
END;

Con estos pasos, ya tenemos las tablas de auditoria en un tablespace especifico llamado TS_AUD, es en este momento cuando podemos comenzar con las tareas de mantenimiento de los registros de auditoría.

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;

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;

Como siempre, podemos encontrar mas información en soporte Oracle en las notas :
Documentación del paquete DBMS_AUDIT_MGMT
Note 72460.1 Moving AUD$ to Another Tablespace and Adding Triggers to AUD$
Note: 1019377.6 Script to move SYS.AUD$ table out of SYSTEM tablespace
Note: 166301.1 How to Reorganize SYS.AUD$ Table
Note: 731908.1 New Feature DBMS_AUDIT_MGMT To Manage And Purge Audit Information
Note: 73408.1 How to Truncate, Delete, or Purge Rows from the Audit Trail Table SYS.AUD$

Oracle cluster registry OCR (componentes del grid)

Oracle cluster registry ( OCR)

El Oracle cluster registry (OCR) mantiene los metadata y los wallets para todos los recursos que maneja el clusterware , al contrario de lo que ocurría en las versiones previas, solamente se requiere para administrar los recursos que están bajo la CRSD stack and its agents.
En la versión 11gR2 el l OCR incluye el Oracle Local Registry (OLR)

En esta versión el OCR no es necesario para unirse al cluster,ya que la información necesaria para unirse al cluster está en el OLR and GPnP, la información que maneja el OCR si que incluye aquella que requiere el agente para crear ,comprobar el estado,parar o arrancar un recurso así como la de las dependencias de un recurso ante un cambio de estado (Por ejemplo qué hacer con un listener si la IP sobre la que está desaparece)

Como mínimo debe de existir un OCR, sin embargo es posible tener hasta 5 copias, el OCR puede estar (desde 11gR2) en los discos ASM, pero a diferencia del voting disk puedes tener un OCR en los mismos discos que datos o copias.
La localización de los OCR (en un sistema linux) se encuentra en /etc/oracle/ocr.loc

[grid@rac1 oracle]$ cat /etc/oracle/ocr.loc
ocrconfig_loc=+OCRQUORUM
local_only=FALSE

La variable local_only puede tener dos valores:

  • FALSE: Estamos en un RAC
  • TRUE: estamos en una single instance

Mediante el comando ocrconfig se pueden llevar acciones de añadir , eliminar y reemplazar ubicaciones del OCR, sin embargo , si hay solamente una localización e OCR no se puede hacer un replace, hay que añadir uno nuevo y eliminar el viejo.
La información del OCR se guarda cada 4 horas en el $GI_HOME/cdata de uno de los nodos, desde la versión 11gR2 se reparten por todos los nodos (donde está instalado). Habitualmente se guarda los últimos 3 backups horarios ( 12 horas), 1 backup con un día de antigüedad y otro con una semana de antigüedad.
Cuando el OCR se almacena en ASM hace que la instancia de ASM y los diskgroups en los que está ubicado el OCR se monten antes de que el CRSD sea arrancado. Igualmente, si hay que detener el ASM hay que parar toda la pila del CRSD mediante el comando crscrtl stop crs ya que, sino la parada del ASM dará el error

 “ORA-15097: cannot SHUTDOWN ASM instance with connected client.”

por supuesto ni se te ocurra para el asm de manera forzada.

Los comandos para interactuar con el OCR son:

[grid@rac1 oracle]$ ocrcheck
Status of Oracle Cluster Registry is as follows :
	 Version                  :          3
	 Total space (kbytes)     :     262120
	 Used space (kbytes)      :       2644
	 Available space (kbytes) :     259476
	 ID                       :  165462643
	 Device/File Name         : +OCRQUORUM
                                    Device/File integrity check succeeded

                                    Device/File not configured

                                    Device/File not configured

                                    Device/File not configured

                                    Device/File not configured

	 Cluster registry integrity check succeeded

	 Logical corruption check bypassed due to non-privileged user


Añadir un disco

[grid@rac1 oracle]$ ocrconfig -add +DATA

reemplazarlo

[grid@rac1 oracle]$ ocrconfig -replace +DATA  -replacement +DATA2

O eliminarlo

[grid@rac1 oracle]$ ocrconfig -delete +DATA2

La documentación del ocrconfig podemos encontrarla en http://docs.oracle.com/cd/E11882_01/rac.112/e16794/ocrsyntax.htm#CWADD92022

Voting disk (componentes del grid)

Vamos a dedicar una serie de entradas a explicar los distintos componentes del Grid infraestructurae de Oracle a partir de la version 11gR2

El voting disk es usado por el demonio de sincronización de servicios (ocssd Oracle cluster sincronization services daemon) para comprobar el estado de los nodos del disco.
Cada uno de los nodos envía en intervalos predeterminados un herbeat por la red para indicar a el resto que está vivo. Si el resto determina que uno de los nodos está muerto entonces le hace un “fence” para evitar corrupción de datos o un split brain.
Cada nodo debe de enviar un hearbeat por red por segundo y escribir un herbeart por voting disk por segundo. Si un nodo no hiciera ambas cosas, el resto de nodos comenzarían un proceso de reconfiguración que, sirve para comprobar qué nodos están vivos que básicamente es que cada nodo indica cuales encuentra como vivos y cuáles no .
A los nodos que no contestan se les envía un “poison packet via network and disk” y se les saca del cluster.

En las versiones anteriores el voting file debía de ser un sistema compartido de red (NFS,OCFS.. ), pero en la versión 11gR2 ya puede ser un disco de ASM (Es aconsejable ir pasándolos a ASM ya que podrían ser de-soportados los otros tipos de voting)

Si usas OCFS para el voting file, se aconseja el uso de 3 o 5 copias del voting file, aunque el máximo es de 15. En caso de uso del ASM no puedes determinarlo ya que es transparente y dependen del tipo de redundancia del ASM (external,normal,hit). En el caso de tener redundancia interna de ASM (normal/high),oracle chequea que tengas el número de discos mencionados anteriormente, conlo que deberás de tener un mínimo de 3 failure groups en redundancia normal y 5 en high. Si no los tuvieras, recibirás un error indicándote lo :

ORA-15273: Could not create the required number of voting files
ORA-15274 ...

En la versión 11gR2, el voting file, registro local y el perfil de Grid Plug and Play (GPnP) tienen toda la información necesaria del cluster por lo que no dependen del OCR, sin embargo el OCR es necesario para administrar los recursos del cluster

El voting disk se ubica en un disco de ASM individual, esto hace que el Cluster Synchronization Services daemon (CSSD) acceda directamente al contenido de los voting disk, lo que le permite arrancarse antes que los propios discos de ASM

En la versión 11gR2 de Oracle el backup del voting disk se lleva a cabo automáticamente con el backup el OCR.

El comando con el que administraremos el voting disk es el crscrtl, la sintaxsis de las acciones mas comunes es:


[grid@rac1 oracle]$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   731fe6f479734f1fbf75ed0d30b3e76b (/dev/asmdisk_sdb1) [OCRQUORUM]
Located 1 voting disk(s).

También prodríamos añadir un votedisk

[grid@rac1 oracle]$ crsctl add css votedisk /shared/vfile1 

Reemplazar un votedisk

[grid@rac1 oracle]$ crsctl replace votedisk /shared/vfile1
  /shared2/vfile2 

O eliminar un votedisk

[grid@rac1 oracle]$ crsctl delete votedisk  /shared2/vfile2 

Como siempre, mas información en la documentación de Oracle en:
http://docs.oracle.com/cd/E11882_01/rac.112/e16794/crsref.htm#CWADD91143