martes, 4 de diciembre de 2012

El caso curioso del datafile que "pertenecía" a dos Bases de Datos


En primer lugar quiero empezar diciendo que tengo una idea de cómo sucedió esto, pero no he sido capaz de recrear esta situación, ya que esto me fue heredado, de igual manera tuve la suerte de que el tablespace que tenía el problema era un tablespace DUMMY por lo que no causó un problema.

Ahora si a la descripción del problema, lo que pasa es que tengo una Base de Datos fuente con una ubicación de los datafiles en + DATA1/SOURCE, pero en algún momento alguien añadió una segunda ubicación para la realizar algunas pruebas en un tablespace TEST1 en +DATA2/TEST, esta base de datos fuente se duplicó a través de RMAN hacia 2 bases de datos, llameseles  a ellas DUP1 y DUP2. En el comando duplicate de RMAN , se uso el parámetro DB_FILE_NAME_CONVERT para cambiar la ubicación de los datafiles de la base de datos de origen hacia DUP1 o DUP2, pero en este parámetro solo se puso para la ubicacion de +DATA1/SOURCE y no para +DATA2/TEST .

Lo que se puso en el comando RMAN fue lo siguiente:

DB_FILE_NAME_CONVERT '+DATA1/SOURCE','DATA1/DUP1'

Como debería de haber sido:

DB_FILE_NAME_CONVERT '+DATA1/SOURCE','+DATA1/DUP1','+DATA2/TEST','+DATA1/DUP1'

Y porque el diskgroup y directorio de + DATA2/TEST existen donde DUP1 y DUP2 residiría, no causo ningún problema cuando se corrió el comando DUPLICATE, y esto es algo que todavía es  desconocido para mí, el duplicado termino con éxito para ambas bases de datos y no surgió ningún problema al abrirlas con resetlogs, como lo hace el comando.

Como probablemente ya saben, cuando se emite el comando DUPLICATE, la DBID es implicitamente cambiada, y lo que hace esto es que actualiza el controlfile con el dbid nuevo y también las cabeceras de los datafiles, de esa manera es como sabrá que estos XX datafiles pertenecen a la base de datos NN.

Una vez que ambas bases de datos estaban arriba y corriendo, corri un respaldo de las bases de datos, DUP1 termino exitosamente, el respaldo de DUP2 falló con el siguiente error :

RMAN-06169: could not read file header for datafile 148 error reason 9
RMAN-06056: could not access datafile 148

Una de las primeras cosas que hice fue correr un VALIDATE DATABASE, y me mostraba el mismo error:

RMAN> VALIDATE DATABASE;
Starting validate at 29-NOV-12 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=145 instance=DUP21 device type=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: SID=164 instance=DUP21 device type=DISK RMAN-06169: could not read file header for datafile 148 error reason 9 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of validate command at 11/29/2012 01:40:41 RMAN-06056: could not access datafile 148

Lo siguiente que hice fue ver a donde pertenecía el datafile 148 y de igual manera el DBID de  DUP2, ya que el error de la cabecera me llevó a buscar por ahi

DUP21 >select DBID,open_mode from v$database;
 
      DBID OPEN_MODE
---------- ------------------------------------------------------------
2211912429 READ WRITE
 
DUP21 >select file_name from dba_data_files where TABLESPACE_NAME='TEST1';
 
FILE_NAME
--------------------------------------------------------------------------------
+DATA2/test/test01.dbf
 
 
DUP21 >select STATUS from dba_tablespaces where TABLESPACE_NAME='TEST1';
 
STATUS
---------------------------
ONLINE

Debido al error 06169 RMAN  me decía que no podía leer la cabecera del datafile, hice un volcado de la esta.

DUP21 >oradebug setmypid

Statement processed.

DUP21 >oradebug unlimit

Statement processed.

DUP21 >oradebug dump file_hdrs 3

Statement processed.

DUP21 >oradebug tracefile_name

Y en efecto vi que el DBID de test01.dbf pertenecía a DUP1, que había sido la primera de las dos bases de datos duplicadas

V10 STYLE FILE HEADER:
        Compatibility Vsn = 186646528=0xb200000
        Db ID=4005607769=0xeec0b959, Db Name='DUP1'

Así que, para nada mas estar seguro , fui a DUP1 a verificar, y sí, era el mismo que el DBID del volcado de la cabecera , y de igual manera el tablespace TEST1 estaba en línea, así como en DUP2

DUP11 >select DBID,open_mode from v$database;
 
      DBID OPEN_MODE
---------- ------------------------------------------------------------
4005607769 READ WRITE

DUP11 >select STATUS from dba_tablespaces where TABLESPACE_NAME='TEST1';
 
STATUS
---------------------------
ONLINE
 
DUP11 >select file_name from dba_data_files where TABLESPACE_NAME='TEST1';
 
FILE_NAME
--------------------------------------------------------------------------------
+DATA2/test/test01.dbf

DUP11 >select STATUS from dba_tablespaces where TABLESPACE_NAME='TEST1';
 
STATUS
---------------------------
ONLINE

Porque ese tablespace en particular era de ninguna utilidad para la aplicación, simplemente lo tire.


DUP21 >ALTER TABLESPACE TEST1 OFFLINE IMMEDIATE;

Tablespace altered.

DUP21 >DROP TABLESPACE TEST1;

Tablespace dropped.

Lo que te puedes llevar de esta entrada

Tengo que decir que esto es con un OH en 11.2.0.3 con un GI  en 11.2.0.3 en RHEL 5 x86_64, lo que te diria es que cada vez que haces un duplicado y utilizas el DB_FILE_NAME_CONVERT, asegúrate de que todos los lugares están cubiertos. Pero lo realmente me intriga es la forma en que DUP2 fue capaz de abrirse con resetlogs sin que esto fuera un problema, voy a tratar de recrear esto y actualizar este post, siempre y cuando lo logre hacer.

martes, 13 de noviembre de 2012

RAC : Opcion para verificar la "salud" de la Base de Datos en version 11.2.0.3

El otro día estaba haciendo una instalación de los binarios del Clusterware 11.2.0.3 y me tope que ahora con la herramienta cluvfy en 11.2.0.3 viene con una opción de verificar la "salud" de la Base de Datos.Para que esta opcion funcione tienes que instalar el usuario cvusys asi como el rol cvusapp , existe un script para poder hacer esto y se encuentra en el directorio CLUVFY_HOME/cv/admin.

Como el usuario oracle corre el script $CLUVFY_HOME/cv/admin/cvusys.sql para crear el usuario, el rol y los grants necesarios para que funcione. Este usuario tendra el tablespace por defacto que tiene la Base de Datos, si no quieres que tenga ese tablespace modifica este script para que lo cree en el tablespace que deseas..

oracle@servidor1.localdomain [TESTDB1] /home/oracle
oracle $ id
uid=54321(oracle) gid=54321(oinstall) groups=54321(oinstall),501(vboxsf),54322(dba)

TESTDB1> @cvusys.sql

User dropped.


Role dropped.

Enter password for user cvusys 
'Creating user cvusys...'

User created.


Grant succeeded.


Role created.


Grant succeeded.

.
.
.

Una vez que hayas inicializado el ambiente para el usuario de la Base de Datos cvusys verifica que como el usuario de OS grid tengas la variable de ambiente $ORACLE_HOME con el GRID_HOME correcto.

grid@servidor1.localdomain /home/grid
oracle $ id
uid=54324(grid) gid=54321(oinstall) groups=54321(oinstall),501(vboxsf),54322(dba),54323(asmadmin),54325(asmoper)

grid@servidor1.localdomain /home/grid
oracle $ echo $ORACLE_HOME
/mount/oracle/11.2.0.3/grid

Una de las cosas que note fue que si no tienes el GRID_HOME correcto o le pasas el nombre de tu Base Datos en mayúsculas cuando el nombre de la Base de Datos es en minúsculas, te puede arrojar el error PRVG-11005, esto aunque cuando veas el log en $CLUVFY_HOME/cv/log el comando srvctl config database se esta ejecutando correctamente.

grid@servidor1.localdomain /home/grid
oracle $ cluvfy comp healthcheck -collect database -db TESTDB -deviations -save -savedir /home/grid/audit

ERROR:
PRVG-11005 : Database  "TESTDB" is not defined in this cluster


grid@servidor1.localdomain /home/grid/cv/log
root $ more cvutrace.log.0
.
.
.
[17455@servidor1.localdomain] [Worker 0] [ 2012-11-04 22:41:33.595 EST ] [VerificationCommand.execute:232]  Formatted exectask output is:
 <CV_CMD>/mount/oracle/11.2.0.3v1/rdbms/bin/srvctl config database -d TESTDB -a </CV_CMD><CV_VAL>Database unique name: TESTDB
Database name: TESTDB
Oracle home: /mount/oracle/11.2.0.3v1/rdbms
Oracle user: oracle
Spfile: +DATA/TESTDB/PARAMETERFILE/spfileTESTDB.ora
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: TESTDB
Database instances: TESTDB1,TESTDB2
Disk Groups: DATA
Mount point paths:
Services:
Type: RAC
Database is enabled
Database is administrator managed
</CV_VAL><CV_VRES>0</CV_VRES>Exectask: runexe was successful</CV_LOG><CV_ERES>0</CV_ERES>
.
.
.

Cuando usas esta utilería , puedes correrla contra todas las Base de Datos en el cluster si no usas la opción de , lo único que si te digo es que tienes que crear el usuario cvusys en cada una de las Base de Datos del cluster. De la misma manera puedes verificar cuales son las mejores practicas recomendadas por Oracle y como tu Base de datos se desvian de estas con las opciones [-bestpractice|-mandatory] [-deviations].

En este caso , corri la utileria con el nombre de la Base de datos en minúsculas con la opción de mejores practicas (-bestpractice) y termino correctamente.

grid@servidor1.localdomain /home/grid/cv/log
root $ cluvfy comp healthcheck -collect database -db testdb -bestpractice -deviations -save -savedir /home/grid/audit/

Verifying Database "testdb"

Please specify password for user "cvusys" :

Verifying Database Best Practice for "testdb"

Verifying JVM configuration for database ...not met
Verifying Java Role Count ...not met
Verifying Duplicate SYS or SYSTEM Schema Objects ...not met
Verifying Users Granted CONNECT Role ...not met
Verifying DB Log Mode ...not met



******************************************************************************************
        Summary of environment
******************************************************************************************

Date (mm/dd/yyyy)    :  11/05/2012
Time (hh:mm:ss)      :  22:37:28
Cluster name         :  cluster-test
Clusterware version  :  11.2.0.3.0
Grid home            :  /mount/oracle/11.2.0.3/grid
Grid User            :  grid
Operating system     :  Linux2.6.18-238.el5
Database1            :  Database name     -  testdb
                        Database version  -  11.2.0.3
                        Database home     -
                        /mount/oracle/11.2.0.3v1/rdbms

******************************************************************************************
Database recommendation checks for "testdb"
******************************************************************************************
.
.
.

Ahora lo que tienes que hacer es ir al directorio donde guardaste el reporte y ver las desviaciones de las mejores practicas recomendadas por Oracle. Aquí es donde yo te diria que verifiques y tengas cuidado con las recomendaciones que te arroja, ya que una de las recomendaciones era que estaba corriendo en modo ARCHIVE_LOG vs la recomendación NOARCHIVELOG, espero que puedas ver en donde no estoy de acuerdo con este reporte, pero si no estas verificando la salud de tus Base de Datos después de una instalación nueva, esta es una gran manera de empezar y te ayudara en un futuro a ver que es lo que puedo hacer para mejorar mi ambiente.

__________________________________________________________________________________________

Verification Check        :  Duplicate SYS or SYSTEM Schema Objects                       
Verification Description  :  Checks for duplicate SYS or SYSTEM schema objects            
Verification Result       :  NOT MET                                                      
Verification Summary      :  Check for Duplicate SYS or SYSTEM Schema Objects failed      
Additional Details        :  If any duplicate objects were found in the SYS and SYSTEM    
                             schemas, refer to articles in the references section. Read   
                             the exceptions carefully before taking action.               
References (URLs/Notes)   :  https://support.oracle.com/CSP/main/article?cmd=show&type=N  
                             OT&id=1030426.6                                              

Node                Status    Expected Value                Actual Value                  
------------------------------------------------------------------------------------------

testdb              FAILED    sys_duplicate_obj = 0         sys_duplicate_obj = 4         

__________________________________________________________________________________________

Verification Check        :  INVALID objects in the application related schemas           
Verification Description  :  Checks for the presence of INVALID objects in the            
                             application related schemas (non SYS and SYSTEM)             
Verification Result       :  NOT MET                                                      
Verification Summary      :  Check for INVALID objects in the application related         
                             schemas failed                                               
Additional Details        :  Investigate invalid objects in the application related       
                             schemas (non SYS and SYSTEM).                                

Node                Status    Expected Value                Actual Value                  
------------------------------------------------------------------------------------------

testdb              FAILED    app_invalid_obj = 0           app_invalid_obj = 5           

lunes, 5 de noviembre de 2012

RAC : Secuencia de Arranque del Clusterware de Oracle 11gR2

Para cualquiera que haya trabajado con la versión 11gR2 del Clusterware de Oracle se ha topado con el diagrama de arranque de esta tecnología, y la verdad desde mi punto de vista es realmente difícil de ver y entender, y no es "KISS" , Keep It Simple Stupid por sus siglas en ingles.

Luego hay un segundo diagrama, que ese esta mucho mejor, pero de igual manera, la calidad de este segundo diagrama es de muy mala calidad , y para mi muy mala vista ,no me ayuda en nada.

Si quiero mencionar que no estoy poniendo nada nuevo en este post que no puedas encontrar en el documento de MOS 1053147.1, simplemente lo estoy poniendo en un formato que sea mas legible y fácil de entender.

Dale click a la imagen para verla en su tamaño real:


Las descripciones de abajo son una traducción del mismo documento de MOS

Unix INIT manda a llamar a init.ohasd (con respwan) , que a su vez manda a llamar los procesos OHASD (Oracle High Availability Services Deamon, por sus siglas en ingles) . Este demonio genera 4 procesos:

Nivel 1 .- OHASD genera :

    cssdagent          - Agente responsable de generar  CSSD.
    orarootagent     - Agente responsable de administrar todos los recursos ohasd del usuario root.
    oraagent           - Agente responsable de administrar todos los recursos ohasd del usuario oracle o grid 
                              (Dependiendo bajo que usuario hayas instalado los binarios del clusterware).
    cssdmonitor      - Monitorea el CSSD y la "salud" del nodo (así como el agente cssdagent).

Nivel 2 .- El agente orarootagent de OHASD genera:

    CSDD (ora.cssd)        - Servicios de Sincronizacion del Cluster (Cluster Synchronization Services)
    CRSD(ora.crsd)         - Demonio primario responsable de administrar los recursos del cluster.
    CTSSD(ora.ctssd)      - Demonio de Sincronizacion de Servicios del Tiempo del Cluster
    Diskmon(ora.diskmon)
    ACFS (ASM Cluster File System) Drivers

Nivel 3 .-  CRSD genera

    orarootagent     - Agente responsable de administrar todos los recursos crsd del usuario root.
    oraagent           - Agente responsable de managing todos los recursos crsd del usuario oracle o grid.


Nivel 4 .- CRSD orarootagent genera:

    Network resource      - Para monitorear la Red Publica
    SCAN VIP(s)           - Single Client Access Name Virtual IPs
    Node VIPs               - IP Virtual del Nodo,Uno por Nodo
    ACFS Registery       - Para montar el Sistema de Archivos Cluster ASM (ASM Cluster File System
    GNS VIP (opcional) - VIP para GNS

  Nivel 4 .- CRSD oraagent spawns:

    ASM Resource   - Recurso de Instancia(s) de ASM
    Diskgroup           - Usado para administrar/monitorear grupos de discos de ASM .
    DB Resource      - Usado para administrar/monitorear las BD's y las instancias
    SCAN Listener   - Listener para SCAN, escuchando la IP Virtual del  SCAN
    Listener               - Listener del Nodo, escuchando la VIP del Nodo.
    Services              - Usado para administrar y monitorear servicios
    ONS                   - Servicio de Notificación de Oracle (Oracle Notification Service)
    eONS                 - Servicio de Notificación de Oracle Mejorado (Enhanced Oracle Notification Service)
    GSD                   - Para compatibilidad hacia atrás con 9i
    GNS (opcional)   - Servicio de Nombres de Gird (Grid Naming Service) - Realiza resolución de nombres

jueves, 25 de octubre de 2012

RMAN : Crear un respaldo consistente y un RESTORE POINT todo a la vez

Una característica que tiene RMAN en 11g es que tienes la posibilidad de crear un punto de restauración en el mismo respaldo, este método es muy útil, sobre todo cuando vas a hacer una actualización importante en tu Base de Datos y tienes que crear un respaldo antes, este es el mejor método desde mi punto de vista.

Lo primero , es que verifico que no hay un punto de restauración para mi base de datos

TESTDB> set linesize 121
TESTDB> col name format a15
TESTDB> col time format a32

TESTDB> SELECT name, scn, time, database_incarnation#, guarantee_flashback_database, storage_size
  2  FROM gv$restore_point;

no rows selected

Ahora lo que hago es que corro un respaldo con la opción de KEEP UNTIL y RESTORE POINT

RMAN> RUN
2>  {
3> BACKUP AS COMPRESSED BACKUPSET
4>  INCREMENTAL LEVEL = 0
5>  DATABASE
6>   FORMAT '/mount/copy01/TESTDB/oracle/TESTDB/incr/%d_HOT_%M%D%Y_%p_%s' 
7>   TAG TESTDB
8>   KEEP UNTIL TIME 'SYSDATE + 5'
9>   RESTORE POINT BEFORE_UPGRADE;
10> }
Starting backup at Oct 25 2012 08:41:49
current log archived

using channel ORA_DISK_1
backup will be obsolete on date Oct 30 2012 08:41:50
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting compressed incremental level 0 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/mount/u01/oracle/TESTDB/data/system01.dbf
input datafile file number=00003 name=/mount/u01/oracle/TESTDB/data/undotbs1_01.dbf
input datafile file number=00004 name=/mount/u01/oracle/TESTDB/data/users01.dbf
input datafile file number=00002 name=/mount/u01/oracle/TESTDB/data/sysaux01.dbf
channel ORA_DISK_1: starting piece 1 at Oct 25 2012 08:41:50
channel ORA_DISK_1: finished piece 1 at Oct 25 2012 08:41:57
piece handle=/mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_10252012_1_24 tag=TESTDB comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07

using channel ORA_DISK_1
backup will be obsolete on date Oct 30 2012 08:41:57
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at Oct 25 2012 08:41:57
channel ORA_DISK_1: finished piece 1 at Oct 25 2012 08:41:58
piece handle=/mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_10252012_1_25 tag=TESTDB comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01


current log archived
using channel ORA_DISK_1
backup will be obsolete on date Oct 30 2012 08:41:58
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting compressed archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=19 RECID=19 STAMP=797589718
channel ORA_DISK_1: starting piece 1 at Oct 25 2012 08:41:58
channel ORA_DISK_1: finished piece 1 at Oct 25 2012 08:41:59
piece handle=/mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_10252012_1_26 tag=TESTDB comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

using channel ORA_DISK_1
backup will be obsolete on date Oct 30 2012 08:41:59
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at Oct 25 2012 08:42:00
channel ORA_DISK_1: finished piece 1 at Oct 25 2012 08:42:01
piece handle=/mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_10252012_1_27 tag=TESTDB comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at Oct 25 2012 08:42:01

Para verificar que se creo el punto de restauración corro los siguientes comandos en RMAN

RMAN> list restore point all;

SCN              RSP Time             Type       Time                 Name
---------------- -------------------- ---------- -------------------- ----
234073                                           Oct 25 2012 08:41:58 BEFORE_UPGRADE

y en Sqlplus

SQL> SELECT name, scn, time, database_incarnation#, guarantee_flashback_database, storage_size
  2  FROM gv$restore_point;

NAME         SCN TIME        DATABASE_INCARNATION# GUA STORAGE_SIZE
--------------- ---------- -------------------------------- --------------------- --- ------------
BEFORE_UPGRADE     234073 25-OCT-12 08.41.58.000000000 AM   1 NO   0

Si te fijas, el SCN es el mismo , 234073,  que es lo que andamos buscando. En dado caso de que tengas que hacer un rollback, a este SCN seria al que regresarias.

Este respaldo de igual manera lo podemos utilizar para clonar una base de datos hasta el punto de restauración que creaste con la opción TO RESTORE POINT, no puse toda la salida, pero si te fijas abajo, esta recuperando hasta el punto de restauración que creamos en la Base de Datos TESTDB

oracle@servidor1.oracleenespanol.blogspot.com [TESTDB] /mount/dba01/oracle/TESTCOPY/scripts
oracle $ rman target / auxiliary sys@TESTCOPY


RMAN> RUN
2> {  
3>   ALLOCATE AUXILIARY CHANNEL newdb DEVICE TYPE disk; 
4>   DUPLICATE TARGET DATABASE TO testcopy
5>     TO RESTORE POINT BEFORE_UPGRADE
6>      DB_FILE_NAME_CONVERT ('/mount/u01/oracle/TESTDB/','/mount/u01/oracle/TESTCOPY/','/mount/u02/oracle/TESTDB/','/mount/u02/oracle/TESTCOPY/')
7> LOGFILE
8>       GROUP 1 ('/mount/u01/oracle/TESTCOPY/log/redo01_1.f',
9>                '/mount/u02/oracle/TESTCOPY/log/redo01_2.f') SIZE 4M,
10>       GROUP 2 ('/mount/u01/oracle/TESTCOPY/log/redo02_1.f',
11>                '/mount/u02/oracle/TESTCOPY/log/redo02_2.f') SIZE 4M,
12>       GROUP 3 ('/mount/u01/oracle/TESTCOPY/log/redo03_1.f',
13>                '/mount/u02/oracle/TESTCOPY/log/redo03_2.f') SIZE 4M REUSE;
14> }
using target database control file instead of recovery catalog
allocated channel: newdb
channel newdb: SID=19 device type=DISK

Starting Duplicate Db at Oct 25 2012 08:50:53

contents of Memory Script:
{
   set to restore point  'BEFORE_UPGRADE';
   sql clone "alter system set  db_name = 
 ''TESTDB'' comment=
 ''Modified by RMAN duplicate'' scope=spfile";
   sql clone "alter system set  db_unique_name = 
 ''TESTCOPY'' comment=
 ''Modified by RMAN duplicate'' scope=spfile";
   shutdown clone immediate;
   startup clone force nomount
   restore clone primary controlfile;
   alter clone database mount;
}
.
.
.
contents of Memory Script:
{
   Alter clone database open resetlogs;
}
executing Memory Script

database opened
Finished Duplicate Db at Oct 25 2012 08:51:57
released channel: newdb


Espero que este método te sirva en tus próximas actualizaciones.




lunes, 15 de octubre de 2012

Oracle Open World 2012 : La Experiencia

Este año tuve la oportunidad de asistir al Oracle Open World, y desde mi punto de vista es algo que todo mundo que esta relacionado en el ambiente de las tecnologias de Oracle tiene que hacer por lo menos una vez en su vida, ya que no es nada mas lo que aprendes en el evento, sino como lo dice el titulo , es toda una experiencia y en todos los sentidos.

Vas a tener la oportunidad de escuchar el rumbo que tiene la empresa y sus productos , que si estas leyendo este blog es, por que estas interesado en esta tecnologia o ya llevas varios años manejandola. Esta vez toco el anuncio de la nueva version de la Base de Datos, 12c , que como puedes imaginar la "c" es por "Cloud" (Nube en ingles).

Y viene un cambio bastante significante en lo que es el concepto que tenemos en la relacion de Base de Datos e Instancia. Ya que hasta la version 11.2.0.3, toda Base de Datos podia tener una o mas Instancias, pero una Instancia solo podia tener una Base de Datos.

Esto va a cambiar en 12c , ya que ahora va a existir un nuevo tipo de Base de Datos, llamada Base de Datos Contenedor , esta Base de Datos va a tener una instancia ( procesos y memoria) y a esta Base de Datos/Instancia le vas a "conectar" tus otras Bases de Datos, estas se llaman Bases de Datos con capacidad de Conectarse (Pluggable Databases o PDB).  

Regresando al tema del OOW, vas a tener la oportunidad de conocer, platicar y hasta hecharte un cafe o cerveza si es tu gusto con las personas mas respetadas del ambito y escuchar que tienen que decir al respecto del rumbo que esta tomando Oracle.

Ya que estas ahi vas a poder conocer una ciudad que esta llena de opciones y aventuras para todos los gustos. Asi que el proximo año toma la iniciativa y nos vemos en el OOW 2013.

Aqui otras entradas de las experiencias del Oracle Open World 2012 , estas entradas estan en ingles

Oracle OpenWorld 2012: A photographic experience

Favourite Oracle 12c database features of OpenWorld Bloggers

The Fun of Oracle OpenWorld

Oracle OpenWorld - Swim in the Bay 2012


martes, 25 de septiembre de 2012

La importancia de un DRP y unos cuantos datos al respecto

Este fin de semana pasado estuve involucrado en un plan de desastres y recuperación, DRP (Disaster Recovery Plan) por sus siglas en ingles, básicamente lo que se hace en un DRP es planear lo peor, como por ejemplo que pasaría si tu site principal se cae, y que acciones tomar en caso de que suceda.

Y aunque se puede decir que en un DRP tienes un control de lo que esta sucediendo, si te ayuda a ver que pasos te están fallando en tus procedimientos estándares de operación, y poder actualizarlos, ya que a la mejor pensabas que tu manera de tomar un respaldo era correcta, pero al ejecutar el DRP te das cuenta de que no puedes recuperar tu base de datos, estas pruebas te sirven para encontrar esos hoyos en tu plan.

Buscando un poco mas de datos acerca de la cantidad de empresas que llevan a cabo un DRP, me tope con una encuesta ejercida por el IOUG (Independent Oracle Users Group) efectuada este 2012 a mas de 350 profesionistas en donde el 51% fueron administradores de base datos, en donde resalta para mi lo siguiente :

  • El 18% de los encuestados nunca han llevado a cabo un DRP
  • El 37 % de los encuestados solamente hace un DRP parcial de sus datos.
  • El 43 % de los encuestados mencionan que el financiamiento es una de las mas fuertes restricciones para llevar a cabo un DRP.
  • El 12% de los encuestados no sabe cuanto tiempo se puede llevar en restaurar los datos en caso de un "apagón" de operaciones.

Es un poco preocupante ver números arriba del 10% en estas categorías, ya que desde mi punto de vista, como DBA, lo mas importante es tener los datos disponibles, si tus datos no están disponibles, realmente estas en una situación no deseable por ningún DBA.

A final de cuentas, si tu cliente se tarda en recibir los datos que necesita cuando lanza un Query , puede de alguna manera en vivir con ese tiempo en que se esta tardando en recibir los datos, no va a estar contento, pero va a obtener los datos que anda buscando, pero que pasa si necesita los datos y nunca los va a poder obtener?

A lo que quiero llegar es que si al día de hoy no tienes entre tus estándares un DRP en operacion, ve planeando uno, este te va servir para detectar , corregir y hasta probablemente prevenir un "apagón" de tus operaciones y/o perdida de datos. De igual manera, un DRP te va ayudar a establecer un SLA de tus tiempos en caso de un desastre,

Así que ve planeando un DRP y encuentra las debilidades en tu arquitectura para en lugar de salir como perdedor en un desastre seas el héroe y de pasada mantengas tu trabajo :) .

miércoles, 5 de septiembre de 2012

RAC : Como crear un recurso de aplicacion de usuario en CRS

Cuando manejas RAC, existe un herramienta llamada crsctl, esta herramienta es una interfase para manejar los recursos pertenecientes al clusterware. Pero al igual esta herramienta te puede ayudar para que tus aplicaciones estén disponibles cuando tu cluster esta disponible y viceversa.

Esto nos sirve a nosotros no nada mas para aplicaciones de usuario , si no también para herramientas que nos sirven para monitorear nuestros nodos, en este caso OSWbb (OS Watcher Black Box 461053.1) y aunque existe un documento para arrancar OSWbb como un servicio del sistema operativo,580513.1, aquí lo vamos a poner con crsctl

Como siempre, esto lo debes de ensayar en un ambiente de pruebas antes de moverlo a un ambiente de producciony de igual manera verificar los scripts que te estoy mencionando.

Lo primero que tienes que hacer es bajar OSWbb e instalarlo en la misma dirección en todos los nodos que le pertenece a tu granja de servidores RAC, yo lo puse en la siguiente dirección:

/mount/dba01/oracle/oswbb_51

De ahí tienes que crear un script que llame a los cuatro comandos necesarios para que funcione con crsctl (START,STOP,CHECK y CLEAN) y que de la misma manera sea visible para todos los nodos en la misma locación , en este caso el script que voy a utilizar  lleva el nombre de rac_verificar_oswbb.sh , y lo puede encontrar dándole click al nombre anterior.

Lo único que cambiar en el script que te acabo de mencionar es cambiar la variable OSWPATH a donde tu descomprimiste la ultima versión de OSWbb.

OSWPATH=/mount/dba01/oracle/oswbb_51

Asegurate que el usuario con el que vas a crear el recurso, ya sea root o grid ,tenga permisos de escritura y ejecución sobre rac_verificar_oswbb.sh  y OSWPATH

Una vez que hiciste lo anterior , con el usuario root o el usuario grid, dependiendo con que usuario vayas a crear el recurso, en mi caso use el usuario root, tienes que verificar que los siguiente cuatro comandos corran sin ningún error, si alguno no sirve o corre con error, no va a funcionar lo que estamos haciendo.

Una vez que hayas resuelto y/o verificado que no tienes ningún problema, hay que crear el recurso, asegurate que el recurso no tenga el prefijo ora.,ya que este es para los recursos manejados por Oracle, en este caso utilice un prefijo llamado usr.

root@servidor1.oracleenespanol.blogspot.com  /home/oracle
root $ crsctl add resource usr.oswbb -type ora.local_resource.type -attr "AUTO_START=always,RESTART_ATTEMPTS=2, START_TIMEOUT=100,STOP_TIMEOUT=100,CHECK_INTERVAL=60,ACTION_SCRIPT=/mount/dba01/oracle/admin/rac_verificar_oswbb.sh"

Ya creado el recurso, ya nada mas tienes que iniciarlo y verificar que esta corriendo

root@servidor1.oracleenespanol.blogspot.com  /home/oracle
root $ crsctl start resource usr.oswbb
CRS-2672: Attempting to start 'usr.oswbb' on 'servidor1'
CRS-2672: Attempting to start 'usr.oswbb' on 'servidor2'
CRS-2676: Start of 'usr.oswbb' on 'servidor1' succeeded
CRS-2676: Start of 'usr.oswbb' on 'servidor2' succeeded

root@servidor1.oracleenespanol.blogspot.com  /home/oracle
root $ crsctl status resource usr.oswbb
NAME=usr.oswbb
TYPE=ora.local_resource.type
TARGET=ONLINE                , ONLINE
STATE=ONLINE on servidor1, ONLINE on servidor2

Conclusión

Este método no nada mas sirve para OSWbb , si no para cualquier aplicación que este ligado a tu cluster, y ahora si la imaginación y lo complejo que quieres que sea es tuyo.


lunes, 3 de septiembre de 2012

RMAN : Como Verificar que tengo un respaldo consistente

El otro día me hicieron una pregunta de que como podía verificar que el respaldo que había tomado . Para esto RMAN tiene unos comandos que nos ayudan a verificar que respaldos tenemos y la integridad de ellos

Todos lo comandos que utilice no van a restaurar los respaldos, solamente lee y los valida, lo que si te debo de decir es que tengas cuidado con los comandos que vas a lanzar, ya que en varios , si la palabra VALIDATE no se encuentra presente, en lugar de validar el respaldo, empieza a restaurar el respaldo.

Aquí esta un resumen de los comandos que vamos a usar y estos son validos para un canal SBT o DISK

  • RESTORE DATABASE PREVIEW ;
  • RESTORE DATABASE VALIDATE;
  • RESTORE ARCHIVELOG FROM sequence xx UNTIL SEQUENCE yy THREAD nn VALIDATE;
  • RESTORE CONTROLFILE VALIDATE;
  • RESTORE SPFILE VALIDATE;
Lo primero que tenemos que hacer es definir el tiempo al que queremos restaurar nuestro respaldo. Una vez definido este tiempo, el primer comando que vamos a usar es RESTORE... PREVIEW, este comando identifica el respaldo necesario para llevar a cabo la operación de restaurar así como los Archived Redo logs necesarios.


RMAN> RUN
2> {
3> set until time "to_date('03-SEP-201222:20:00','dd-mm-yyyyhh24:mi:ss')";
4> allocate channel ch1 device type disk ;
5> RESTORE DATABASE PREVIEW ;
6> }   

executing command: SET until clause

allocated channel: ch1
channel ch1: SID=158 instance=TESTDB1 device type=DISK

Starting restore at 03-SEP-2012 22:54:18


List of Backup Sets
===================


BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ --------------------
6       Full    75.34M     DISK        00:00:19     03-SEP-2012 22:01:04
        BP Key: 6   Status: AVAILABLE  Compressed: YES  Tag: TESTDB_HOT_0904_2100
        Piece Name: /mount/copy01/TESTDB/oracle/TESTDB/full/TESTDB_HOT_09032012_1_6_793058445
  List of Datafiles in backup set 6
  File LV Type Ckp SCN    Ckp Time             Name
  ---- -- ---- ---------- -------------------- ----
  1       Full 224235     03-SEP-2012 22:00:46 +DATA/TESTDB/datafile/system01.dbf
  2       Full 224235     03-SEP-2012 22:00:46 +DATA/TESTDB/datafile/sysaux01.dbf
  3       Full 224235     03-SEP-2012 22:00:46 +DATA/TESTDB/datafile/undotbs1_01.dbf
  4       Full 224235     03-SEP-2012 22:00:46 +DATA/TESTDB/datafile/undotbs2_01.dbf
  5       Full 224235     03-SEP-2012 22:00:46 +DATA/TESTDB/datafile/users_01.dbf


List of Backup Sets
===================


BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ --------------------
9       482.00K    DISK        00:00:00     03-SEP-2012 22:01:39
        BP Key: 9   Status: AVAILABLE  Compressed: YES  Tag: TESTDB_ARCH_0904_2100
        Piece Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_09032012_1_9_793058499

  List of Archived Logs in backup set 9
  Thrd Seq     Low SCN    Low Time             Next SCN   Next Time
  ---- ------- ---------- -------------------- ---------- ---------
  1    8       222449     03-SEP-2012 21:57:53 224442     03-SEP-2012 22:01:33
  2    4       222452     03-SEP-2012 21:59:38 224448     03-SEP-2012 22:03:17
  1    9       224442     03-SEP-2012 22:01:33 224456     03-SEP-2012 22:01:36
  2    5       224448     03-SEP-2012 22:03:17 224459     03-SEP-2012 22:03:21

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ --------------------
12      389.50K    DISK        00:00:01     03-SEP-2012 22:21:50
        BP Key: 12   Status: AVAILABLE  Compressed: YES  Tag: TESTDB_ARCH_0904_22_20
        Piece Name: /mount/copy01/TESTDB/oracle/TESTDB/full/0bnka8bt_1_1

  List of Archived Logs in backup set 12
  Thrd Seq     Low SCN    Low Time             Next SCN   Next Time
  ---- ------- ---------- -------------------- ---------- ---------
  1    10      224456     03-SEP-2012 22:01:36 225574     03-SEP-2012 22:21:01

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ --------------------
11      25.00K     DISK        00:00:00     03-SEP-2012 22:21:50
        BP Key: 11   Status: AVAILABLE  Compressed: YES  Tag: TESTDB_ARCH_0904_22_20
        Piece Name: /mount/copy01/TESTDB/oracle/TESTDB/full/0cnka8bu_1_1

  List of Archived Logs in backup set 11
  Thrd Seq     Low SCN    Low Time             Next SCN   Next Time
  ---- ------- ---------- -------------------- ---------- ---------
  2    6       224459     03-SEP-2012 22:03:21 225577     03-SEP-2012 22:22:45
Media recovery start SCN is 224235
Recovery must be done beyond SCN 224235 to clear datafile fuzziness
Finished restore at 03-SEP-2012 22:55:15
released channel: ch1

El siguiente paso, que es RESTORE DATABASE VALIDATE, va a leer las piezas del respaldo y si llega a encontrar algún error , va a reportar este error


RMAN> RUN
2> {
3> set until time "to_date('03-SEP-201222:20:00','dd-mm-yyyyhh24:mi:ss')";
4> allocate channel ch1 device type disk ;
5> restore database validate;
6> }

executing command: SET until clause

allocated channel: ch1
channel ch1: SID=158 instance=TESTDB1 device type=DISK

Starting restore at 03-SEP-2012 22:51:44

channel ch1: starting validation of datafile backup set
channel ch1: reading from backup piece /mount/copy01/TESTDB/oracle/TESTDB/full/TESTDB_HOT_09032012_1_6_793058445
channel ch1: piece handle=/mount/copy01/TESTDB/oracle/TESTDB/full/TESTDB_HOT_09032012_1_6_793058445 tag=TESTDB_HOT_0904_2100
channel ch1: restored backup piece 1
channel ch1: validation complete, elapsed time: 00:00:25
Finished restore at 03-SEP-2012 22:52:38
released channel: ch1

Pero si te fijaste, esto solamente leyó el backupset del respaldo completo, así que hace falta ver si los backupsets de los archivelogs estan integros para hacer en dado caso de ser necesario restaurar tu base de datos, para esto, lo que te recomiendo yo es que del resultado del primer comando, de allí sacar los valores de la secuencias de archive logs que requieres y de una vez que tienes estos valores ,correr el comando RESTORE ARCHIVELOG. . . VALIDATE

RMAN> RUN
2> {
3> allocate channel ch1 type disk;
4> restore archivelog from sequence 8 until sequence 10 thread 1 validate;
5> restore archivelog from sequence 4 until sequence 6 thread 2 validate;
6> }

allocated channel: ch1
channel ch1: SID=158 instance=TESTDB1 device type=DISK

Starting restore at 03-SEP-2012 23:15:11

channel ch1: starting validation of archived log backup set
channel ch1: reading from backup piece /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_09032012_1_9_793058499
channel ch1: piece handle=/mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_09032012_1_9_793058499 tag=TESTDB_ARCH_0904_2100
channel ch1: restored backup piece 1
channel ch1: validation complete, elapsed time: 00:00:01
channel ch1: starting validation of archived log backup set
channel ch1: reading from backup piece /mount/copy01/TESTDB/oracle/TESTDB/full/0bnka8bt_1_1
channel ch1: piece handle=/mount/copy01/TESTDB/oracle/TESTDB/full/0bnka8bt_1_1 tag=TESTDB_ARCH_0904_22_20
channel ch1: restored backup piece 1
channel ch1: validation complete, elapsed time: 00:00:01
Finished restore at 03-SEP-2012 23:15:15

Starting restore at 03-SEP-2012 23:15:17

channel ch1: starting validation of archived log backup set
channel ch1: reading from backup piece /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_09032012_1_9_793058499
channel ch1: piece handle=/mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_09032012_1_9_793058499 tag=TESTDB_ARCH_0904_2100
channel ch1: restored backup piece 1
channel ch1: validation complete, elapsed time: 00:00:01
channel ch1: starting validation of archived log backup set
channel ch1: reading from backup piece /mount/copy01/TESTDB/oracle/TESTDB/full/0cnka8bu_1_1
channel ch1: piece handle=/mount/copy01/TESTDB/oracle/TESTDB/full/0cnka8bu_1_1 tag=TESTDB_ARCH_0904_22_20
channel ch1: restored backup piece 1
channel ch1: validation complete, elapsed time: 00:00:01
Finished restore at 03-SEP-2012 23:15:21
released channel: ch1

Ya por ultimo vamos a validar que podemos restaurar el controlfile y nuestro archivo de parámetros binario


RMAN> RUN
2> {
3> allocate channel ch1 type disk;
4> set until time "to_date('03-SEP-201222:20:00','dd-mm-yyyyhh24:mi:ss')";
5> restore controlfile validate;
6> restore spfile validate;
7> }

allocated channel: ch1
channel ch1: SID=158 instance=TESTDB1 device type=DISK

executing command: SET until clause

Starting restore at 03-SEP-2012 23:23:14

channel ch1: starting validation of datafile backup set
channel ch1: reading from backup piece /mount/copy01/TESTDB/oracle/TESTDB/control/c-3899479525-20120903-03
channel ch1: piece handle=/mount/copy01/TESTDB/oracle/TESTDB/control/c-3899479525-20120903-03 tag=TAG20120903T220143
channel ch1: restored backup piece 1
channel ch1: validation complete, elapsed time: 00:00:01
Finished restore at 03-SEP-2012 23:23:15

Starting restore at 03-SEP-2012 23:23:16

channel ch1: starting validation of datafile backup set
channel ch1: reading from backup piece /mount/copy01/TESTDB/oracle/TESTDB/control/c-3899479525-20120903-04
channel ch1: piece handle=/mount/copy01/TESTDB/oracle/TESTDB/control/c-3899479525-20120903-04 tag=TAG20120903T222152
channel ch1: restored backup piece 1
channel ch1: validation complete, elapsed time: 00:00:01
Finished restore at 03-SEP-2012 23:23:18
released channel: ch1

Conclusión

Estos comandos aunque sencillos, son muy útiles para validar tus respaldos, mi recomendación es que los corras una vez a la semana, ya que no te quieres enfrentar a una situación en donde tengas que restaurar tus respaldo y saber que tenias algún error y no poder hacerlo