Hands-ON Oracle Recovery Manager - RMAN

Hola Amigos, Hace un tiempo construí este manual de RMAN avanzado de 11gR2. Acá existen ejemplos reales de situaciones que ocurren en un día normal de operación o frente a una consultoría técnica.

En esta presentación se incluyeron los siguientes tópicos para estudiar:

• INTRODUCCIÓN RECOVERY MANAGER 
• CONCEPTOS DE RESPALDO Y RECUPERACIÓN 
• ARQUITECTURA EL PROCESO LOG WRITTER 
• EL PROCESO ARCHIVER
• ESTRUCTURAS FÍSICAS DE BASES DE DATOS UTILIZADAS EN RECUPERACIÓN 
• TIPOS DE RESPALDOS TIPOS DE RECUPERACIÓN
• CONFIGURANDO EL AMBIENTE RMAN
• MULANDO UNA SUPER DLT A DISCO
• CONFIGURANDO TIPOS DE DISPOSITIVOS 
• CATÁLOGO DE RECUPERACIÓN 
• RECOVERY MANAGER EJERCICIOS DE RESPALDO, RECUPERACION, FLASHBACK, ASM METADATA

Hands-On Oracle Recovery Manager RMAN from Alberto Gallardo

Viva Linux!!!! Alberto Silva Gallardo

Deployment Manual Oracle Management Agent 12c

Este procedimiento busca realizar el Deployment del Oracle Management Agent 12c en cualquier plataforma, en donde no existan posibilidades de tener interfaz gráfica o no sea posible tener acceso directo al OMS.

Utilitario agentDeploy

Este script permite realizar la configuración en modo silencioso del Oracle
Management Agent 12c. El utilitario puede leer directamente un archivo de
respuestas llamado “Response File” o directamente configurar en línea
parámetros para realizar la instalación. Para plataformas Unix o Linux el script
es llamado agentDeploy.sh y para plataformas Windows se denomina
agentDeploy.bat

Parámetros en Línea

A continuación se muestran los parámetros en línea más importantes para
realizar la instalación mediante el método silencioso:

Configuración de archivo de Host

Se debe considerar agregar en el servidor de OMS todos los destinos que se
requieren monitorear. A su vez, en cada destino monitoreado, se debe agregar
en el archivo de host local, el nombre y la IP del servidor de OMS para que
pueda contactarse remotamente.

Procedimiento de Deployment Oracle Agent 12c

A continuación se revisa en detalle el método de instalación silenciosa, el cuál
puede ser aplicado en cualquier plataforma.

Conectarse al servidor de OMS y sincronizar la librería de Software

cd $OMS_HOME\bin
 

$OMS_HOME\oms\BIN>emcli login -username=sysman
 

Enter password : ingresar password de SYSMAN

Realizar la sincronización una vez conectado mediante el utilitario emcli

emcli sync

Verificación de plataformas disponibles

Para asegurar que la versión del agente se encuentra disponible y la librería
posee la versión adecuada para el sistema operativo en donde se realizara el
Deployment, es necesario ejecutar el comando emcli get_supported_platforms
de la siguiente manera:

E:\oracle\product\12.1.0\em12c\oms\BIN>emcli get_supported_platforms 

Getting list of platforms ...
Check the logs at E:\oracle\product\12.1.0\em12c\oms\BIN/agent.log
About to access self-update code path to retrieve the platforms list..
Getting Platforms list ...
-----------------------------------------------
Version = 12.1.0.1.0
Platform = HP-UX Itanium
-----------------------------------------------
Version = 12.1.0.1.0
Platform = Microsoft Windows x64 (64-bit)

Descomprimiendo la imagen del Software (Primer Método)

El software del agente se puede descomprimir de la siguiente manera:

emcli get_agentimage -destination=PATH\Destino -platform="HP-UX Itanium" -version=12.1.0.1.0

Segundo Método

En el caso que existan problemas con el primer método, se puede simplemente
descomprimir la imagen del software con el utilitario unzip u otro disponible. Es
importante saber donde el OMS descarga el software para realizar esta
operación manualmente para posteriormente copiar la imagen al nuevo destino
a monitorear. En la siguiente ruta, el OMS puede tener almacenada todas las
versiones disponibles para realizar el Deployment. En este caso la ruta es la
siguiente:

/u04/app/oracle/product/11.2.0/em12c/oms/sysman/agent
-rw-r--r-- 1 grid oinstall 284402265 Feb 11 2012 12.1.0.1.0_AgentCore_226.zip
-rw-r----- 1 grid oinstall 235607688 Jul 20 13:16 12.1.0.1.0_AgentCore_912.zip
-rw-r----- 1 grid oinstall 329520887 Jul 23 17:48 12.1.0.1.0_AgentCore_212.zip
-rwxr-xr-x 1 grid oinstall 231137201 Aug 29 15:29 p14018175_112000_Generic.zip

Ejecutando el Deployment del Agente

Como podemos observar, el script tiene varios de los parámetros mencionados
al principio de este documento. Para la plataforma Windows se debe
implementar con el Administrador Local de la máquina. Para el caso de Unix y
Linux, basta que la cuenta sea del grupo dba u oinstall según se haya definido
al momento de la creación de esta.

Para Windows: (todo esto en una sola línea)

agentDeploy.bat AGENT_BASE_DIR=D:\test\u01\app\oracle\product\11.2.0\agent12c
OMS_HOST=IP_OMS EM_UPLOAD_PORT=4909 AGENT_REGISTRATION_PASSWORD=password_sysman

-forceConfigure -debug -ignorePrereqs

Utilizando archivo de respuestas

OMS_HOST=
EM_UPLOAD_PORT=
AGENT_REGISTRATION_PASSWORD=password_sysman
AGENT_INSTANCE_HOME=<$ORACLE_BASE/product/agent12c> Directorio de instalación
AGENT_PORT=3872 <-- abir="" br="" para="" puerto="" utilizar.="">b_startAgent=true
ORACLE_HOSTNAME=

Para Unix y Linux

./agentDeploy.sh AGENT_BASE_DIR=<$ORACLE_BASE/product/agent12c> Directorio de instalación
-ignorePreReqs RESPONSE_FILE=

Y como siempre...

VIVA LINUX!!!
Alberto Silva Gallardo.

Recuperación de OCR en Oracle RAC

Se producen problemas con los servicios de CRS, ya que no se encuentran operativos en uno o más nodos del RAC. El síntoma principal es que el nodo afectado no es capaz de iniciar los servicios de Clusterware en forma automática.

[root@vmrac01 ~]# crs_stat -t

CRS-0184: Cannot communicate with the CRS daemon.

Este error indica que no es posible iniciar los servicios de Clusterware, ya que el servicio CRS no se encuentra disponible.

Como revisar las alertas del sistema para detectar el problema

Para determinar el problema que origina que los servicios de Clusterware se encuentren operativos, se debe ingresar al siguiente directorio para chequear los archivos de log correspondientes al CRS:

u01/app/oracle/product/10.2.0/cr_1/log/vmrac02/client

cls*.log

css*.log

Para determinar el error y los archivos de Log donde se determina el error, se debe ingresar al siguiente directorio de cualquier nodo del RAC y revisar el archivo alertrac2.log.

/u01/app/oracle/product/10.2.0/cr_1/log/nombre_nodo/alternombre_nodo.log

[client(23271)]CRS-1009:The OCR configuration is invalid. Details in /u01/app/oracle/product/10.2.0/cr_1/log/vmrac02/client/css18186.log. 2013-08-05 13:10:34.742 [client(23278)]CRS-1009:The OCR configuration is invalid. Details in /u01/app/oracle/product/10.2.0/cr_1/log/vmrac02/client/css18187.log. 2013-08-05 13:10:37.843 [client(23287)]CRS-1009:The OCR configuration is invalid. Details in /u01/app/oracle/product/10.2.0/cr_1/log/vmrac02/client/css18188.log. 2013-08-05 13:10:40.920 [client(23297)]CRS-1009:The OCR configuration is invalid. Details in /u01/app/oracle/product/10.2.0/cr_1/log/vmrac02/client/css18189.log.

El error se origina, ya que el OCR se encuentra con problemas de corrupción. El error se puede apreciar en el siguiente log:

u01/app/oracle/product/10.2.0/cr_1/log/nombre_nodo/client/

Oracle Database 10g CRS Release 10.2.0.4.0 Production Copyright 1996, 2008 Oracle. All rights reserved. 2013-08-05 13:10:40.920: [ OCRRAW][50530464]propriogid:1: INVALID FORMAT 2013-08-05 13:10:40.920: [ OCRRAW][50530464]proprioini: OCR configuration on disk 0 is not valid 2013-08-05 13:10:40.920: [ OCRRAW][50530464]proprinit: Could not open raw device 2013-08-05 13:10:40.921: [ default][50530464]a_init:7!: Backend init unsuccessful : [26] 2013-08-05 13:10:40.921: [ CSSCLNT][50530464]clsssinit: Unable to access OCR device in OCR init.PROC-26: Error while accessing the physical storage

Solucionando la corrupción del OCR

Para solucionar el problema de corrupción, se debe restaurar el OCR desde un backup. En este caso el backup se encuentra en el segundo nodo del RAC en el siguiente directorio:

/u01/app/oracle/product/10.2.0/cr_1/cdata/crs

-rw-r--r-- 1 root root 8663040 Jan 6 2012 26916645 -rw-r--r-- 1 root root 8663040 dec 20 05:28 week.ocr -rw-r--r-- 1 root root 7680000 Jan 1 09:35 week_.ocr -rw-r--r-- 1 root root 7680000 Jan 4 03:58 day.ocr -rw-r--r-- 1 root root 7680000 Jan 5 03:58 backup02.ocr -rw-r--r-- 1 root root 7680000 Jan 5 07:58 day_.ocr -rw-r--r-- 1 root root 7680000 Jan 5 07:58 backup01.ocr -rw-r--r-- 1 root root 7680000 Jan 5 11:58 backup00.ocr

Para restaurar elegimos el archivo llamado day.ocr. Este archivo posee la metadata que será cargada nuevamente al Clúster mediante el comando ocrconfig.

Restaurando el archivo OCR

Con el usuario root, ejecutar el siguiente comando:

ocrconfig –restore /u01/app/oracle/product/10.2.0/cr_1/cdata/crs/day.orc

      Chequeo de Servicios

Es importante cuando el OCR ha sido restaurado satisfactoriamente, revisar los servicios verificando mediante los comandos de Clusterware:

Reinicio de servicios CRS (usuario root)

crsctl start crs

chequeo de OCR (oracle/root)

[oracle@vmrac02 bin]$ ./ocrcheck Status of Oracle Cluster Registry is as follows : Version : 2 Total space (kbytes) : 3144280 Used space (kbytes) : 7072 Available space (kbytes) : 3137208 ID : 2109299085 Device/File Name : /dev/raw/raw1 Device/File integrity check succeeded Device/File Name : /dev/raw/raw3 Device/File needs to be synchronized with the other device Cluster registry integrity check succeeded

[oracle@vmrac02 bin]$ ./crs_stat -t -v Name Type R/RA F/FT Target State Host ---------------------------------------------------------------------- ora.rac.db application 0/0 0/1 ONLINE ONLINE vmrac02 ora....c1.inst application 0/5 0/0 ONLINE ONLINE vmrac01 ora....c2.inst application 0/5 0/0 ONLINE ONLINE vmrac02 ora....SM1.asm application 0/5 0/0 ONLINE ONLINE vmrac01 ora....C1.lsnr application 0/5 0/0 ONLINE ONLINE vmrac01 ora.rac1.gsd application 0/5 0/0 ONLINE ONLINE vmrac01 ora.rac1.ons application 0/3 0/0 ONLINE ONLINE vmrac01 ora.rac1.vip application 0/0 0/0 ONLINE ONLINE vmrac01 ora....SM2.asm application 0/5 0/0 ONLINE ONLINE vmrac02 ora....C2.lsnr application 0/5 0/0 ONLINE ONLINE vmrac02 ora.rac2.gsd application 0/5 0/0 ONLINE ONLINE vmrac02 ora.rac2.ons application 0/3 0/0 ONLINE ONLINE vmrac02 ora.rac2.vip application 0/0 0/0 ONLINE ONLINE vmrac02

Dimensionando el tamaño de nuevos índices mediante el Package DBMS_SPACE.CREATE_INDEX_COST

DBMS_SPACE.CREATE_INDEX_COST

Necesitamos dimensionar el espacio disponible para crear índices. Muchas veces, se detectan ciertas consultas SQL requieren de ellos para obtener un mejor desempeño. Para esto revisamos si el espacio del tablespace definido para índices posee los recursos necesarios.

Opcionalmente, podemos ejecutar estadísticas sobre la tabla para determinar de forma exacta cuantas filas tiene la tabla:
exec dbms_stats.gather_table_stats(user,'TABLA');

Conectarse con el usuario SYS y ejecutar el siguiente bloque de PL/SQL:

set serverout on

declare

   calc_used_bytes NUMBER;

   calc_alloc_bytes NUMBER;

begin

   DBMS_SPACE.CREATE_INDEX_COST (

      ddl => 'create index NOMBRE_INDICE on OWNER.TABLA '||'(campo1,campo2, etc)',

       used_bytes => calc_used_bytes,

      alloc_bytes => calc_alloc_bytes

   );

   DBMS_OUTPUT.PUT_LINE('Used bytes = '||calc_used_bytes/1024/1024);

   DBMS_OUTPUT.PUT_LINE('Allocated bytes = '||calc_alloc_bytes/1024/1024);

end;

/

Donde las variables de tipo number las definimos con el siguiente nombre:

calc_used_bytes :> Esta variable permite dar una estimación de la cantidad de espacio que se requiere para los datos del índice.

calc_alloc_bytes :> Esta variable proporciona una estimación de cuanto espacio será asignado dentro del Tablespace.

El resultado indica que la cantidad estimada de bytes asignados se encuentra en el cálculo aproximado de la cantidad de espacio consumida realmente.

Used bytes = 573,61937713623046875

Allocated bytes = 1152 -> cálculo en MB del espacio consumido en el tablespace.

En resumen, los resultados pueden ir variando dependiendo del número de registros, número de columnas, tipos de datos y la precisión de las estadísticas.

Como cambiar el UUID de un Disco Virtual en VirtualBox

Cuando necesitamos clonar una VM en VirtualBox, nos ha ocurrido que copiamos los discos virtuales directamente a un nuevo directorio y creamos una nueva máquina a partir de la configurada originalmente; Pero cuando asignamos los discos clonados manualmente, nos entrega el siguiente error

¿Qué es el UUID?

Para el Hipervisor existen dos UUID. Uno para referenciar a la Máquina Virtual y el otro para referenciar a los discos virtuales. En este caso nos referimos al UUID de cada disco, ya que la problemática se origina al copiar manualmente los discos y asignarlos a una nueva Máquina Virtual; pero estos UUID están siendo referenciados por la Máquina original y es ahí donde se presenta el problema.

Como podemos observar, dentro de la configuración de la Máquina Virtual, se hace referencia al UUIDs de los discos en el parámetro HardDisk_uuid:

Este cambio se debe realizar con el comando de sistemas llamado VBoxManage internalcommands sethduuid y se debe referenciar la ruta completa con el nombre del disco que se requiere modificar el UUID. En este caso, tengo dos discos llamados disk2_1.vmdk y disk2_2.vmdk:

Ahora ejecutamos el comando para cambiar el UUID de ambos discos:

Como podemos observar, al agregar los discos a la controladora, no se generan los problemas presentados anteriormente:

Y como siempre...

VIVA LINUX!!!

Alberto Silva Gallardo.

Instalando Solaris 11 en VirtualBox - EN CONSTRUCCION

Estoy trabajando en un proyecto de implementacion de Solaris VM sobre virtualbox. Para esto voy a presentar aspectos prácticos y básicos de la instalación para ir avanzando hasta llegar a la configuracion de Infraestructura de Grid, ASM y finalmente un servidor Standalone de Base de Datos.

Como borrar las Alertas de Oracle Enterprise Manager

Hace un tiempo estaba revisando un Grid Control que tenía alertas reportadas desde hace mucho (más de 3 años), la cual depuraré sin misericordia…Jajajajaja.
Estas alertas jamás podrían ser eliminadas ya que, si bien tienen un estado "limpio"; pero se encuentran dentro del umbral crítico definido para esta alerta; por lo tanto, nunca seran eliminadas por el agente. De esta manera se puede aplicar este WorkAround, el cual obviamente Oracle no publica nada al respecto y tampoco soporta como procedimiento oficial.

Esto funciona así:
El procedimiento bajo el esquema SYSMAN llamado em_severity.delete_current_severity posee 3 variables de entrada llamadas:

P_TARGET_GUID
P_METRIC_GUID
P_KEY_VALUE

Los valores son rescatadas por la consulta ejecutada a la tabla sysman.mgmt_targets, para luego armar un script dinámico que permita "fumigar" de una vez estas alertas que siempre quedan dando vuelta.
Además, para asegurar que la alerta que será eliminada corresponde al día y hora señalada, se recomienda cambiar la configuración del parámetro NLS_DATE_FORMAT para obtener un resultado más detallado:

alter session set NLS_DATE_FORMAT='DD-MM-YYYY HH24:MI:SS';

select t.target_name
, collection_timestamp
, message
, 'Ejecutar Comando bajo la cuenta SYSMAN :'||'exec em_severity.delete_current_severity(''' ||
t.target_guid || ''',''' ||
metric_guid || ''',''' ||
key_value || ''')' em_severity
from mgmt_targets t
inner join
mgmt_current_severity s
on
t.target_guid = s.target_guid
where
target_name like '&SERVIDOR_ALERTADO'


Resultado

JUDAS1
05-04-2009 17:35:23
Metrics "Global Cache Average CR Get Time" is at 2.29141
Ejecutar Comando bajo la cuenta SYSMAN:
exec em_severity.delete_current_severity('5E0A6DF17A248B926C8A33C034123EE9','97C89AFFEE006CBA603A30604D5A4A00',' ')

Luego verificar que las alertas sean eliminadas desde Grid Control -> bajar al final en el Link Alertas -> navegar al Tab Crítica!!!

Y como siempre...

VIVA LINUX!!!
Alberto Silva Gallardo.

Método para exportar particiones con el API Data Pump

Con el siguiente procedimiento PL/SQL es posible exportar una partición y utilizar todas las ventajas que nos ofrece siempre la programación.

La idea es exportar una partición que tiene un tamaño de 1,5GB desde una tabla. Este procedimiento es muy útil y es muy efectivo. En algún momento trabajare en el método para Importar particiones, ahora si hay algún "amigo" que pueda aportar con el Import siempre será bienvenido por compartir lo que sabe globalmente.


Procedimiento para export particiones

DECLARE
l_dp_handle NUMBER;
BEGIN
l_dp_handle := DBMS_DATAPUMP.open(
operation => 'EXPORT',
job_mode => 'TABLE',
remote_link => NULL,
job_name => 'JOB_EXPORTA_PARTICION',
version => 'LATEST');

DBMS_DATAPUMP.add_file(
handle => l_dp_handle,
filename => 'test_part1.dmp',
directory => 'EXP');

DBMS_DATAPUMP.add_file(
handle => l_dp_handle,
filename => 'test_part1.log',
directory => 'EXP',
filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_LOG_FILE);

Los siguientes parámetros son los encargados de filtrar la metadata que necesitamos exportar:

DBMS_DATAPUMP.metadata_filter(
handle => l_dp_handle,
name => 'SCHEMA_LIST',
value => '''PEPITO''');

DBMS_DATAPUMP.metadata_filter(
handle => l_dp_handle,
name => 'NAME_LIST',
value => '''TABLA_TRANSACCIONES''');

Las comillas simples alrededor del nombre de la partición (que se duplica es requerido por PL / SQL)

DBMS_DATAPUMP.data_filter(
handle => l_dp_handle,
name => 'PARTITION_LIST',
value => '''PARTICION_TABLA_TRANSACCIONES''',
table_name => ' TABLA_TRANSACCIONES ',
schema_name => 'PEPITO');

DBMS_DATAPUMP.start_job(l_dp_handle);

DBMS_DATAPUMP.detach(l_dp_handle);
END;
/

LOGS DataPump

Starting "SYS"."TABLA_TRANSACCIONES":
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 1.5 GB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type TABLE_EXPORT/TABLE/AUDIT_OBJ
Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
. . exported "PEPITO"."TBL_TRX_TRANSACCIONES":"PARTICION_TABLA_TRANSACCIONES" 1.371 GB 4289848 rows
Master table "SYS"."TABLA_TRANSACCIONES" successfully loaded/unloaded
******************************************************************************
Dump file set for SYS.TABLA_TRANSACCIONES is:
/archive/exp/test_part1.dmp
Job "SYS"."TABLA_TRANSACCIONES" successfully completed at 10:33:01

En el Sistema Operativo

test_part1.log
test_part1.dmp



!!!!!Para Monitorear el progreso del proceso Export!!!!!

set lines 120
col opname for a25 trunc
col username for a15 trunc
col target for a20
col sid for 999999
col serial# for 999999
col %DONE for a8
select b.username,a.sid,b.opname,b.target,round(b.SOFAR*100 / b.TOTALWORK,0) || ‘%’ as “%DONE”,
b.TIME_REMAINING,to_char(b.start_time,’YYYY/MM/DD HH24:MI:SS’) START_TIME
from V$SESSION_LONGOPS b,V$SESSION a where a.sid=b.sid and TIME_REMAINING 0 order by b.SOFAR/b.TOTALWORK;


VIVA LINUX!!!!
Alberto Silva Gallardo

Como mover un indice de tipo LOB a un tablespace diferente

Muchas veces se necesita realizar la tarea de mover índices a otros tablespaces debido a la ganancia en el balanceo de carga (I/O) y la ganancia que esto produce cuando no tenemos una base de datos por ejemplo configurada con ASM o en versiones antiguas de base de datos como Oracle8i y Oracle9i.

La sintaxis para mover un índice de un tablespace a otro se realiza de la siguiente manera:

alter index OWNER.INDEX_NAME rebuild tablespace TABLESPACE_DE_DESTINO;

Para calcular cuánto espacio se necesita disponible para mover este segmento de tipo índice, se puede utilizar la siguiente consulta:

select sum(bytes)/1024/1024 "Tamaño_en_MB"
from dba_extents
where segment_name ='INDEX_NAME';

Para los índices de tipo LOB que están asociados a una columna de la tabla, la cual fue creada con este tipo de segmento es necesario utilizar la siguiente consulta para determinar que índice debemos mover:

select 'alter table '||owner||'.'||table_name||' move '||chr(10)|| 'LOB ('||column_name||') store as '||'(tablespace TABLESPACE_DE_DESTINO);'
from dba_lobs
where owner ='ESQUEMA_A_MOVER';

Output:

alter table OWNER.TABLE_NAME move lob (COLUMNA_DE_TIPO_LOB) store as (tablespace TABLESPACE_DE_DESTINO);

Si no es utilizado este método para mover el índice de tipo LOB al nuevo tablespace, Oracle nos entrega el siguiente error:

ORA-02327: cannot create index on expression with datatype LOB

VIVA LINUX!!!!
Alberto Silva Gallardo.