Script para generar exports desde windows logando en el Event Log

Una entrada rápida para dummies sobre el export en windows.
Habitualmente la monitorizacion de los exports en plataformas windows es mas compleja que en los linux, esto es debido a que en muchos casos los equipos de gestion de los servidores windows se ciñen a la monitorizacion del visor de eventos no queriendo/pudiendo hacerlo de un fichero de texto plano como es el fichero de log del export.

¿Como solucionamos esto?

Aquí hay un pequeño script que es capaz de llevar a cabo un export y logar en el visor de sucesos el comienzo y le estado final

ECHO OFF
setlocal ENABLEDELAYEDEXPANSION
:: Directorio desde el cual vamos a ejecutar nuestro .bat 
SET SCRIPTDIR=O:\TAREAS\BACKUP
SET ORACLE_SID=%1
SET PARALLELISM=%2
SET MYFILE=DPEXP_%ORACLE_SID%_%%U.dmp
SET MYLOG=DPEXP_%ORACLE_SID%.log
:: RUTA tiene el valor del oracle directory EXPORTS 
SET RUTA=\\SERVIDOR\DIRECTORIO
SET export_log=%RUTA%\DPEXP_%ORACLE_SID%.log

if "%1"=="" goto uso
if "%2"=="" goto SET PARALLELISM=1


EVENTCREATE /T INFORMATION /SO  EXPORT.%ORACLE_SID% /ID 36 /L APPLICATION /D "Comienza el export  de %ORACLE_SID% con paralelismo %PARALLELISM% y log %export_log%"
cd /d %SCRIPTDIR%
del %export_log%
:: Eliminamos los ficheros anteriores por seguridad (a pesar de tener el reuse)

expdp USER/PASS DIRECTORY=EXPORTS  DUMPFILE=%MYFILE% PARALLEL=%PARALLELISM%  LOGFILE=DPEXP_%ORACLE_SID%.log reuse_dumpfiles=Y FULL=Y  METRICS=Y  
SET CORRECTO=%ERRORLEVEL%

IF %CORRECTO% GTR 0  goto error 
IF "%CORRECTO%"=="0"  goto OK

:uso 
echo "USO exportar.bat  SID PARALELISMO "
SET CORRECTO=2
goto end

:error
echo "Error en la realización del export"
EVENTCREATE /T ERROR /SO EXPORT.%ORACLE_SID% /ID 1000 /L APPLICATION /D "ERROR en el export de %ORACLE_SID%"
goto end

:OK 
echo "Backup OK "
EVENTCREATE /T INFORMATION /SO EXPORT.%ORACLE_SID% /ID 1000 /L APPLICATION /D "Export de  %ORACLE_SID% finalizado OK "
goto end

:end
exit %CORRECTO%

Hay que tener en cuenta que:

  • La cuenta desde la que se lance el .bat debe de tener permisos tanto para ejecutar los binarios de oracle como para lanzar el comando EVENTCREATE
  • El ID que hemos elegido (100 y 36) es arbitrario, es deicr , hemos puesto dos IDs al azar para las pruebas.
  • Hemos de conocer a proiri el path del ORACKE DIRECTORY donde va a ir el export para ponerlo en la variable RUTA

    Si somos capaces de cumplir estas 3 premisas podremos tener en el visor de eventos de windows el comienzo y el resultado de nuestro exdp en windows.

Errores ORA-29279 usando UTL_SMTP

Con la implementacion del Fine Grained Acess en la gestión de conexiones de la base de datos,el DBA acaba siendo en muchos casos el punto de entrada de la resolucion de errores que nada tienen que ver con el motor de la base de datos.
Uno de estos errores muy comunes son los ORA-29279 usando UTL_SMTP

Afortunadamente, Oracle es muy claro al respecto.
Los errores ORA-29279 no son un error del motor, sino que nos transmite os escalan el error que dando el servidor de correo


Contact your SMTP administrator for additional assistance as this solution may require your e-mail administrator to make the necessary changes.

Así que, claro y en botella.
Mas info en :

  • ORA-29279 SMTP: 554 Using Utl_smtp To Send Email (Doc ID 1471828.1)
  • Document 604763.1 – Check SMTP Server Availability for ORA-29278 or ORA-29279 errors using UTL_SMTP to Send Email
  • ORA-2427 con el paquete SMTP

Manejo de ASM , Multipath y ASMLIB

Hoy vamos a ver la manera de crear discos con ASM en equipos linux con el multipath y ASMLIB.
La primera pregunta es ¿por que ASMLIB?

Al igual que en las versiones anteriores de Redhat o Oracle Linux donde mi opinión era usar el rawdevices de la manera clásica accediendo al dispositivo en crudo, con la llegada del systemd no me la jugaría en las secuencias de arranque y usaría siempre las librerías que nos proporcionan de manera soportada para ayudarnos con esto, y esa librería es el asmlinb

Multpath en Linux

Lo primero que tenemos que ver es como funciona el multipath en linux.
El «device Mapper Multipath» es una herramienta nativa de Linux para el manejo de múltiples caminos en los accesos a disco.
Resumiendo mucho, el multipath nos va a crear 3 devices:

  • /dev/dmX Dispositivo real
  • /dev/multipath/multipahX Alias del dispositivo para la facilitar la localizacion (formato humano)
  • /dev/mapper/multipathX Dispositivo de acceso al que deberemos apuntar nuestro ASM

Gran parte de los problemas que se tienen con el multipath es el uso de estos tres devices, ya que, es muy común el crear el disco en el dispositivo que no es correcto.

Primer paso, preparar el disco

El primer paso como siempre será la detección del disco. Este paso probablemente lo lleve a cabo el administrador del sistema operativo. Vamos a suponer que el dispositivo sobre el que queremos actuar es el /dev/mapper/mpath10

Lo primero que tendremos que hacer es crear una partición ( Oracle recomienda crear en raw sobre una particion)
para ello

fdisk /dev/mapper/mpath10
Command (m for help): n   
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1017, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-31455238, default 31455238):
Using default value 31455238
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.

Si os habeis fijado, hemos utilizado el dispositivo bajo /dev/mapper y no ninguno de los otros dos.
Con esto hemos creado la partición, pero no se ha grabado en la tabla de particiones del disco ya que hemos actuado sobre el multipath no sobre los discos físicos, para lo que tendremos que llamar el kpartx, y actualizar el kernel con partprobe.
Aquí es donde tenemos que tener mucho cuidado, ya que debemos de usar de nuevo el /dev/mapper

kpartx -a /dev/mapper/mpath10
partprobe

Estas acciones nos habrán creado un nuevo device en el /dev/mapper que se corresponderá con la primera partición de nuestro dispositivo multipath, es decir el /dev/mapper/mpath10p1

Segundo paso, mostrarlo al ASM

Una vez tenemos la partición creada, ya tendremos nuestro disco para añadir a ASM, esta partición se llamará DISKp1, por lo que para nuestro mpath10 será la mpath10p1
Así pues, llamamos al ASMLIB con

/etc/init.d/oracleasm createdisk DATAXX /dev/mapper/mpath10p1

ASMLIB nos habrá creado el dispositivo DATAXX en /dev/oracleasm/disks que será la ruta que usaremos en nuestra variable ASM_DISKSTRING del ASM y que ya tratará de manera indistinta el disco independientemente del camino por el que llegue.

Como siempre , mas información en

  • How To Setup ASM & ASMLIB On Native Linux Multipath Mapper disks? (Doc ID 602952.1)
  • How to Partition DM-Multipath Pseudo Devices (Doc ID 470913.1)

Localizar un disco entre ASM y el almacenamento con asmlib

Hoy vamos a ver una entrada muy sencilla en la que veremos la manera de correlar entre un disco de ASM y su dispositivo físico (usando multipah) .
Disponemos de un sistema Linux con multipath y asm donde los discos de ASM tienen una redundancia external, queremos saber que dispositivo físico en la cabina de almacenamiento es nuestro disco DATA01
La manera mas sencilla de hacerlo es obteniendo el World Wide Identifier (WWID) de ese disco, y esto lo haremos mediante el comando multipath de linux con los datos que obtenemos de la utilidad oracleasm .

Veamos cualess son los pasos.
Primero debemos de averiguar cual es el dispositivo de linux que se corresponde con nuestro disco DATA01

root@BBDD1 ~]# /etc/init.d/oracleasm querydisk -v -d -p  DATA01
Disk "DATA01" is a valid ASM disk on device [8,49]
/dev/sdd1: LABEL="DATA01" TYPE="oracleasm"
/dev/sdy1: LABEL="DATA01" TYPE="oracleasm"
/dev/mapper/mpath10p1: LABEL="DATA01" TYPE="oracleasm"

Con esto ya sabemos el /dev/mapper que le corresponde, y el numero de bloques.
Si ahora quisiésemos saber que dispositivo de cabina usaríamos el comando multipath -ll

[root@BBDD ~]# multipath -ll
.
.
mpath11 (3600a0b800050c7420000222a56728a6d) dm-3 IBM,1814      FAStT
size=30G features='1 queue_if_no_path' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=6 status=active
| |- 1:0:0:104 sde  8:64   active ready running
| `- 2:0:1:104 sdz  65:144 active ready running
`-+- policy='round-robin 0' prio=1 status=enabled
  |- 1:0:1:104 sdl  8:176  active ghost running
  `- 2:0:0:104 sds  65:32  active ghost running
mpath10 (3600a0b800050c7420000222856728a54) dm-2 IBM,1814      FAStT
size=30G features='1 queue_if_no_path' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=6 status=active
| |- 1:0:0:103 sdd  8:48   active ready running
| `- 2:0:1:103 sdy  65:128 active ready running
`-+- policy='round-robin 0' prio=1 status=enabled
  |- 1:0:1:103 sdk  8:160  active ghost running
  `- 2:0:0:103 sdr  65:16  active ghost running
.
.

En la salida de este comando veremos que coincide que el mpath10 contiene los discos sdd e sdy, por lo que, el World Wide Identifier (WWID) que buscamos sera el 3600a0b800050c7420000222856728a54

Métodos de parcheados del RAC

Hoy vamos a ver unas nociones rápidas sobre el parchado en un RAC
Parchear el RAC es diferente al parcheado de un sibgle node, si Opatch detecta un cluster preguntará al OUI el nombre del nodo local y el listado de nodos.
Además de esto, antes de instalar un parche hay que parar todoas las aplicaciones que corren en ese directorio de software deben de pararse.

Exsisten 3 métodos de parcheado de un RAC

  • All Node Patching
  • Rolling Patching
  • Minimum Dowtime

Para llevar a cabo el parchado seguiremos los siguientes pasos:
1. Parar el grid y todo lo que dependa de el en el nodo ( incluido ASM de single instances)
2. Desbloquear el GRID_HOME, como root ejecutaremos
cd $GRID_HOME/crs/install
perl rootcrs.pl -unlock -crshome /u01/app/11.2.0/grid

Al ejecutar el rootcrs.pl con el flag -unlock desbloqueamos el GRID_HOME con lo que ya puede modificarse
3.Con el usuario del grid p parcheamos con el método que elijamos ( ver 3 métodos)
4. Como root de nuevo,volvemos a bloquear los binarios del grid con
cd $GRID_HOME/crs/install
perl rootcrs.pl -patch

Al ejecutar el rootcrs.pl con el flag -patch bloqueamos el GRID_HOME y se rearranca el Oracle Clusterware stack

Métodos de parcheado

Vamos a describir cada uno de los tres métodos de parchado y las diferencias entre ellos

All Node Patching

Este método consiste en parar todos los recursos de todos los nodos y se instalan a la vez. una vez están todos parcheados arrancamos de nuevo.
Esté método es el que se usa típicamente para los parches críticos y es el que tiene el máximum downtime.
Opatch usa este método cuando el parche no puede aplicarse en “ rolling fashion” y cuando no se especifica la opcion minimize_downtime
Los pasos serían:

$ CRS_home/crs/bin/crsctl stop cluster -all
$ Grid_home/bin/crsctl status resource -t
$ cd Oracle_home/OPatch/4519934/4519934
opatch apply
# Grid_home/bin/crsctl start cluster -all (como root)
$ Grid_home/bin/crsctl status resource -t

Tras esto ejecutamos los post-scripts que nos diga el readme.

Rolling Patching

El método de Rolling patching es el método mas eficiente para la aplicación de parches en un RAC o un GRID. En este método se para un grupo de nodos , se aplican los parches a ese grupo, se levanta.. se va haciendo así hasta que todos los nodos del cluster están parcheados.
De esta forma el downtime es cero ya que siempre dejas un nodo disponible de cada instancia.
No todos los parches pueden ser aplicados mediante este método. Si no puede aplicarse es cuando tendrás que aplicar el “minimun downtime” o “all node”
Los pasos son:

opatch query -is_rolling_patch
$ Grid_home/crs/bin/crsctl stop cluster -n RAC1 (paramostodo)
opatch apply [-local_node rac1] -remote_nodes rac2, rac3 Arrancamos los nodos que hemos parcheado
Comprobamos el estado con crsctl stat res –t
Repetimos lospasos 2-5 en los que quedan
Ejecutamos los comandos post-pacth

Minimun Downtime

Este método es el casi igual que el de rolling patching, pero lo llevamos a cabo cuando losparches no sean “rolling patch”La diferencia principal es que los nodos que se van parando y arrancando son los que tienen un mismo servicio.Se pierde servicio enlos nodos parcheados, pero si hay mas de un servicio el resto sigue funcionando. Es una mezcla entre el mejor (rolling) y el peor(all nodes)
En este método se para un grupo de nodos , se aplican los parches a ese grupo, se levanta.. se va haciendo así hasta que todos los nodos del cluster están parcheados.
Los pasos son:

Elegimos un grupo de onodos aparchear.
$ Grid_home/crs/bin/crsctl stop cluster -n RAC1 (paramos todo)
opatch apply -minimize_downtime
Arrancamos los nodos que hemos parcheado
Comprobamos el estado con crsctl stat res –t
Repetimos lospasos 2-5 en los que quedan
Ejecutamos los comandos post-pacth

A groso modo esta es la diferencia entre los 3 métodos de parchado de un RAC, evidentemente, como siempre, conviene leerse el README tanto para ver las especificaciones del parche, como la vuelta atrás.
Antes de ejecutar los comandos que ponemos aquí, es siempre recomendable el hacer las propias comprobaciones previas con el Opatch tal y como indicábamos en la entrada para ver si la instalación cumple con los requisitos del parche.