jueves, 5 de febrero de 2009

Bye bye raw device, ¡bienvenido ASM!

Durante décadas se han venido usando raw devices en un intento de obtener el mejor desempeño posible para las bases de datos Oracle. La alternativa eran los file systems que si bien eran fáciles de administrar, tenían un desempeño que dejaba mucho que desear. Con el transcurrir de los años los fabricantes han venido mejorando los file systems, agregándoles direct I/O y concurrent I/O por ejemplo, al punto que los han hecho casi tan eficientes como los raw devices. Por su parte Oracle dio la sorpresa cuando anunció la aparición de ASM, ofreciendo el alto desempeño de los raw devices con la facilidad de administración de los file systems, amén de muchas otras adiciones que lo hacen único y deseable.

El 2008 recibimos la noticia, mediante el hoy desaparecido Note 578455.1, que a partir de Oracle 12g los raw devices ya no serán soportados y más recientemente, con el Note 754305.1, se nos indica que con Oracle 11gR2 ya no se ofrecerán los raw devices desde DBCA/OUI, por lo que tendremos que recurrir a la línea de comandos si queremos crear una base de datos que los emplee. Debemos entonces ir pensando en abandonar los raw devices pero, ¿qué usar en su reemplazo? En mi opinión la mejor alternativa es ASM y por ello empiezo hoy esta serie de Posts; en este primero les mostraré la instalación del software requerido, las configuraciones necesarias y la creación de una instancia ASM, en un siguiente Post les mostraré cómo trasladar manualmente la base de datos hacia ASM y en un último Post les mostraré cómo hacer lo mismo con Database Console así como el procedimiento a seguir para hacer upgrade a ASM.

Estaré usando una máquina virtual en VMWare, que ejecuta RHEL 5.2 de 32 bits y cuenta con 6 discos virtuales de 1GB cada uno, los cuales serán gestionados por ASM. Si bien voy a emplear Oracle 11.1.0.7, los pasos han sido debidamente probados con Oracle 10.2.0.1 y 10.2.0.4 por lo que no debe haber problemas si siguen estos pasos con versiones 10.2.0.1 o superiores. Veamos entonces la secuencia de pasos a seguir para contar con una instancia ASM operativa.

1. Particionando los discos.

Se requiere que los discos estén debidamente particionados para que puedan ser usados, para ello haremos uso del utilitario fdisk. Primero veamos los nombres de los dispositivos:

root@urania ~]# ls /dev/sd*
/dev/sda  /dev/sda1  /dev/sda2  /dev/sdb  /dev/sdc  /dev/sdd  /dev/sde  /dev/sdf  /dev/sdg

A partir de /dev/sdb hasta /dev/sdg, son los discos que asignaremos a ASM, creemos entonces las particiones.

[root@urania ~]# fdisk /dev/sdb

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-130, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-130, default 130):
Using default value 130

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Este mismo procedimiento se aplica a los restantes 5 discos para finalmente obtener 6 particiones:

[root@urania ~]# ls /dev/sd*
/dev/sda  /dev/sda2  /dev/sdb1  /dev/sdc1  /dev/sdd1 /dev/sde1  /dev/sdf1  /dev/sdg1
/dev/sda1 /dev/sdb   /dev/sdc   /dev/sdd   /dev/sde  /dev/sdf   /dev/sdg

2. Instalación y configuración del software ASMLib.

Para ello debemos empezar por identificar la versión del kernel en uso.

[root@urania ~]# uname -r
2.6.18-92.el5

Con este dato procedemos a descargar los rpm respectivos y los instalamos.

[root@urania ~]# ls
oracleasm-2.6.18-92.el5-2.0.5-1.el5.i686.rpm
oracleasm-support-2.1.2-1.el5.i386.rpm
oracleasmlib-2.0.3-1.el5.i386.rpm

[root@urania ~]# rpm -Uvh oracleasm-support-2.1.2-1.el5.i386.rpm \
> oracleasmlib-2.0.3-1.el5.i386.rpm \
> oracleasm-2.6.18-92.el5-2.0.5-1.el5.i686.rpm
Preparing...                ########################################### [100%]
   1:oracleasm-support      ########################################### [ 33%]
   2:oracleasm-2.6.18-92.el5########################################### [ 67%]
   3:oracleasmlib           ########################################### [100%]

Con el software ya instalado es hora de configurarlo.

[root@urania ~]# /etc/init.d/oracleasm configure
Configuring the Oracle ASM library driver.

This will configure the on-boot properties of the Oracle ASM library
driver.  The following questions will determine whether the driver is
loaded on boot and what permissions it will have.  The current values
will be shown in brackets ('[]').  Hitting  without typing an
answer will keep that current value.  Ctrl-C will abort.

Default user to own the driver interface [oracle]:
Default group to own the driver interface [dba]:
Start Oracle ASM library driver on boot (y/n) [n]: y
Scan for Oracle ASM disks on boot (y/n) [y]:
Writing Oracle ASM library driver configuration: done
Initializing the Oracle ASMLib driver:                     [  OK  ]
Scanning the system for Oracle ASMLib disks:               [  OK  ]

Ahora hay que etiquetar las particiones para que sean reconocidas como dispositivos habilitados para ASM.

[root@urania ~]# /etc/init.d/oracleasm createdisk DISK1 /dev/sdb1
Marking disk "DISK1" as an ASM disk:                      [  OK  ]

Esto se repite para las 5 particiones restantes para finalmente obtener:

root@urania ~]# /etc/init.d/oracleasm listdisks
DISK1
DISK2
DISK3
DISK4
DISK5
DISK6

3. Creación de la instancia ASM

Esta tarea se realiza con ayuda del utilitario DBCA.


Se nos solicita ejecutar un script para configurar e iniciar el servicio CSS.

[root@urania ~]# sh /u01/app/oracle/product/11.1.0/db_2/bin/localconfig add
/etc/oracle does not exist. Creating it now.
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
Configuration for local CSS has been initialized

Adding to inittab
Startup will be queued to init within 90 seconds.
Checking the status of new Oracle init process...
Expecting the CRS daemons to be up within 600 seconds.
CSS is active on these nodes.
        urania
CSS is active on all nodes.
Oracle CSS service is installed and running under init(1M)

Retornamos a DBCA y ahora ingresamos el password para el usuario SYS (de ASM no de la base de datos)


Con este dato DBCA procede a crear e iniciar la instancia ASM


Ahora podemos crear los Disk Groups; en esta ocasión serán 2 los que crearemos.


Al primero lo llamaremos DAT, le asignaremos 2 discos y servirá para contener la base de datos. Escogemos external redundancy para aprovechar todo el espacio, pero estaremos sin mirror por lo que es algo que no deberías usar en Producción, salvo el mirror lo estés manejando a nivel del arreglo de discos.


Al segundo lo llamaremos FRA, le asignaremos los 4 discos restantes y servirá para contener el Flash Recovery Area, nuevamente escogemos external redundancy.



Para culminar presionamos el botón [Finish] y ¡listo!, hemos terminado con esta primera parte, ya tenemos una instancia ASM plenamente operativa y lista para albergar nuestra base de datos, pero como les adelantara, eso lo veremos en un siguiente Post.

Post Relacionados:

Siga leyendo >>

¿Te pareció interesante este artículo?, ¿te quedaron algunas dudas?, ¿quieres sugerirme un tema a tratar?, pues déjame tus comentarios o envíame un email y para que NO te pierdas ningún Post, suscríbete por email ahora mismo!

lunes, 2 de febrero de 2009

De cómo un clon nos puede ayudar con un patch

Si vamos a aplicar un patch o un patch set, una de las tareas previas es detener todos los procesos que estén ejecutándose en el Oracle home directory involucrado. Esto implica que debemos dejar de prestar servicio para iniciar el patching, proceso que si bien es relativamente fácil y sencillo, está sujeto a eventuales fallas que, de ocurrir, pueden llevar a una situación de crisis en la cual el DBA debe identificar el problema y tratar de resolverlo, u optar por dar marcha atrás.

Para evitar pasar por una situación como ésta, es una buena práctica proceder al patching sobre un Oracle home directory nuevo, uno que sea un "Clon" del que está en producción, y así no tener que suspender el servicio sino hasta que estemos seguros que la primera parte del patching se ha logrado de forma satisfactoria. A continuación veremos cómo en sólo 3 pasos, podemos tener en pocos minutos un Clon completamente soportado y listo para ser objeto del patching.

Clonación al estilo Oracle
Antes de iniciar la clonación, tomemos en cuenta las siguientes suposiciones iniciales:
  • Oracle home directory original: /u01/app/oracle/product/10.2.0/db_1
  • Oracle home directory clonado: /u01/app/oracle/product/10.2.0/db_2

1. Copiar el software desde el Oracle home directory original hacia el clonado.
Esto se debe hacer como el usuario root para que los permisos no se pierdan durante el proceso.
[root@urania ~]# cp -Rp /u01/app/oracle/product/10.2.0/db_1 /u01/app/oracle/product/10.2.0/db_2

Si la clonación se realizará en otro servidor, puedes usar tar para generar un archivo con los contenidos del Oracle home directory original:
[root@urania ~]# cd /u01/app/oracle/product/10.2.0/db_1
[root@urania db_1]# tar -cvf /stage/10gR2.tar .

Luego transfieres el archivo generado (con ftp por ejemplo) y una vez esté disponible en el nuevo servidor lo reconstituyes:
[root@caliope ~]# cd /u01/app/oracle/product/10.2.0/db_1
[root@caliope db_1]# tar -xvf /stage/10gR2.tar

2. Clonar la instalación con Oracle Universal Installer (OUI).
Esta parte se hace con el usuario oracle. Existen 2 formas de hacerlo, ambas producen el mismo resultado:

a. Usando clone.pl
[oracle@urania ~]$ cd /u01/app/oracle/product/10.2.0/db_2/clone/bin
[oracle@urania bin]$ perl clone.pl ORACLE_HOME="/u01/app/oracle/product/10.2.0/db_2" ORACLE_HOME_NAME="OraDb10g_home2"

Properties file /config/cs.properties was not found. Failed loading correponding properties../runInstaller -silent -clone -waitForCompletion "ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_2" "ORACLE_HOME_NAME=OraDb10g_home2"
Starting Oracle Universal Installer...

No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2009-01-31_02-14-44PM. Please wait ...Oracle Universal Installer, Version 10.2.0.1.0 Production
Copyright (C) 1999, 2005, Oracle. All rights reserved.

You can find a log of this install session at:
 /u01/app/oracle/oraInventory/logs/cloneActions2009-01-31_02-14-44PM.log
............................................................... 100% Done.

Installation in progress (Sat Jan 31 14:15:07 PET 2009)
.........................................................................
Install successful

Linking in progress (Sat Jan 31 14:15:20 PET 2009)
.                                                                74% Done.
Link successful

Setup in progress (Sat Jan 31 14:17:14 PET 2009)
....................                                            100% Done.
Setup successful

End of install phases.(Sat Jan 31 14:17:21 PET 2009)
WARNING:The following configuration scripts
/u01/app/oracle/product/10.2.0/db_2/root.sh
need to be executed as root for configuring the system.

The cloning of OraDb10g_home2 was successful.
Please check '/u01/app/oracle/oraInventory/logs/cloneActions2009-01-31_02-14-44PM.log' for more details.

b. Usando runInstaller
[oracle@urania ~]$ cd /u01/app/oracle/product/10.2.0/db_2/oui/bin
[oracle@urania bin]$ ./runInstaller -clone -silent -ignorePreReq ORACLE_HOME="/u01/app/oracle/product/10.2.0/db_2" ORACLE_HOME_NAME="OraDb10g_home2"

Starting Oracle Universal Installer...

No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2009-01-31_04-10-24PM. Please wait ...Oracle Universal Installer, Version 10.2.0.1.0 Production
Copyright (C) 1999, 2005, Oracle. All rights reserved.

You can find a log of this install session at:
 /u01/app/oracle/oraInventory/logs/cloneActions2009-01-31_04-10-24PM.log
............................................................... 100% Done.

Installation in progress (Sat Jan 31 16:10:49 PET 2009)
.........................................................................
Install successful

Linking in progress (Sat Jan 31 16:11:03 PET 2009)
.                                                                74% Done.
Link successful

Setup in progress (Sat Jan 31 16:13:03 PET 2009)
....................                                            100% Done.
Setup successful

End of install phases.(Sat Jan 31 16:13:08 PET 2009)
WARNING:The following configuration scripts
/u01/app/oracle/product/10.2.0/db_2/root.sh
need to be executed as root for configuring the system.

The cloning of OraDb10g_home2 was successful.
Please check '/u01/app/oracle/oraInventory/logs/cloneActions2009-01-31_04-10-24PM.log' for more details.

Si estamos clonando un Oracle home directory en 11g debemos tener en cuenta que es requerido indicar también ORACLE_BASE:

[oracle@urania ~]$ cd /u01/app/oracle/product/10.2.0/db_2/clone/bin
[oracle@urania bin]$ perl clone.pl ORACLE_BASE="/u01/app/oracle" ORACLE_HOME="/u01/app/oracle/product/10.2.0/db_2" ORACLE_HOME_NAME="OraDb10g_home2"

3. Ejecutar los scripts de configuración requeridos en el paso anterior.

Si la clonación se ha realizado sobre un servidor que ya tenía Oracle installado el mensaje que se obtiene al concluir el paso previo es:
WARNING:The following configuration scripts
/u01/app/oracle/product/10.2.0/db_2/root.sh
need to be executed as root for configuring the system.

En caso se hubiese tratado de un servidor en el cual se está instalando Oracle por primera vez, se obtiene:
WARNING:A new inventory has been created in this session. However, it has not yet been registered as the central inventory of this system.
To register the new inventory please run the script '/u01/app/oracle/oraInventory/orainstRoot.sh' with root privileges.
If you do not register the inventory, you may not be able to update or patch the products you installed.

The following configuration scripts
/u01/app/oracle/product/10.2.0/db_2/root.sh
need to be executed as root for configuring the system.

Cualquiera fuese el caso, hay que ejecutar los respectivos scripts bajo el usuario root, asumiendo que se trata del último caso:

[root@caliope ~]# sh /u01/app/oracle/oraInventory/orainstRoot.sh

Changing permissions of /u01/app/oracle/oraInventory to 770.
Changing groupname of /u01/app/oracle/oraInventory to oinstall.
The execution of the script is complete

[root@caliope ~]# sh /u01/app/oracle/product/10.2.0/db_2/root.sh

Running Oracle10 root.sh script...

The following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /u01/app/oracle/product/10.2.0/db_2

Enter the full pathname of the local bin directory: [/usr/local/bin]:
   Copying dbhome to /usr/local/bin ...
   Copying oraenv to /usr/local/bin ...
   Copying coraenv to /usr/local/bin ...

Creating /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.

¡Felicitaciones!, si llegaste a éste punto entonces ya tienes un Oracle home directory debidamente clonado sobre el cual puedes aplicar el patch o patch set que necesitas, sin tener que suspender el servicio (por el momento). En cuanto termines el patching sobre este Oracle home directory ya puedes suspender el servicio (de ser necesario) y seguir con los pasos restantes que se señalen en el archivo Installation Notes que acompaña al patch/patch set.

Conclusiones
Es altamente recomendable realizar el patching sobre un Clon del Oracle home directory original. Esto permite retrasar la suspensión del servicio hasta el momento en que tengamos el patch debidamente aplicado sobre el software, así nos evitaremos desagradables situaciones de tensión en caso algo salga mal.

Post Relacionados:

Siga leyendo >>

¿Te pareció interesante este artículo?, ¿te quedaron algunas dudas?, ¿quieres sugerirme un tema a tratar?, pues déjame tus comentarios o envíame un email y para que NO te pierdas ningún Post, suscríbete por email ahora mismo!