Nuevas funcionalidades por defecto de Opatch 12c

Hoy vamos a ver una pequeña entrada sobre algo que me ha sorprendido.

Entre los cambios que han llevado a cabo en el parchado de la 12c además de tener el parchado en dos fases (Opatch + datapatch), me he encontrado con que, las ultimas versiones de Opatch llevan a cabo muchas mas comprobaciones en la fase de pre-requisitos.
Como curiosidad, alguna de ellas son:

  • CheckActiveFilesAndExecutables Comprueba si alguno de los componentes a parchar esta corriendo, esto incluye el listener.
  • CheckActiveServicesEspecifico de equipos windows, comprueba los servicios activos.
  • CheckSystemSpace Comprueba que haya bastante espacio para la aplicacion
  • CheckUserAdminPrivilege comprueba que no sea lanzado como root

Hay muchísimos mas , y puedes verlos con

opatch prereq -help

Pero, no deja de ser curioso la cantidad de comprobaciones que lleva a cabo en estos momentos el optach

Errores ORA-16179 al intentar cambiar el LOG_ARCHIVE_DEST_1

Hoy vamos a ver una entrada tan absurda que roza casi lo idiota.

Supongamos que queramos modificar o añadir el destino de nuestros archivers,e intentándolo tenemos el error ORA-16179

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1 = 'LOCATION = D:\oracle\FRA\QA';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1 = 'LOCATION = D:\oracle\FRA\QA''
ERROR en lφnea 1:
ORA-32017: fallo al actualizar SPFILE
ORA-16179: cambios incrementales en "log_archive_dest_1" no permitidos con SPFILE

La primera accion a temar en cuenta, es buscar blancos en el entrecomillado

Una vez eliminados los blancos, funcionará correctamente 🙂

Pueden haber otros problemas que den este ORA-, todos ellos mas serios que el de esta entrada, su solucion la podéis busar en:

  • Soporte en la Nota OERR: ORA-16179 «incremental changes to %s not allowed with SPFILE» Reference Note (Doc ID 194494.1)
  • Blog de Juan Andres Mercado

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

Usuario administrador de Weblogic en OEM12C

Vamos con una entrada rápida de esas que nos evitarán quebraderos de cabeza.

¿Sabemos cual es el usuario de administración de nuestro weblogic?

Cuando vamos a parchear nuestro Cloud control nos encontramos con lo siguiente

oracle@emc 18295180]$ opatchauto apply -analyze -property_file bundle.xml
OPatch Automation Tool  
 Copyright (c) 2013, Oracle Corporation.  All rights reserved.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          OPatchauto version : 11.1.0.10.0                                                                                                                                                                                                             OUI version        : 11.1.0.11.0                                                                                                                                                                                                             Running from       : /u01/app/oracle/middleware/oms
Log file location  : /u01/app/oracle/middleware/oms/cfgtoollogs/opatch/opatch2015-05-26_09-09-22AM_1.log
opatchauto log file: /u01/app/oracle/middleware/oms/cfgtoollogs/opatchauto/18295180/opatch_oms_2015-05-26_09-09-27AM_analyze.log
OPatch will do the following:
[Get weblogic Admin Server information]                        : Interview to get weblogic Admin Server of the GC Domain
[Generate configuration context of the GC Domain]              : Get the configuration context for the GC Domain
[Run patch(es) deployment prerequisite checks]                 : Check the status of admin server of the GC Domain
                                                               :  Check the status of OMS repository 
[Run patch(es) binary prerequisite checks]                     :Check if all the patches can be applied to or rolled back from their corresponding Oracle Home
[Generate execution steps to apply and deploy the patch(es)]   : Generate execution steps to modify bits and deploy artifacts of the patch

Please enter the WebLogic Admin Server URL for primary OMS(t3s://emc.pamplona.name :7103):>
Please enter the WebLogic Admin Server username for primary OMS:> 
Please enter the WebLogic Admin Server password for primary OMS:> 

¿Cual es ese usuario que nos piden?
Si vamos a la URL que nos indica el fichero setupinfo.txt que nos dejó la instalacion en $ORACLE_HOME/install vemos que:

 Admin Server URL: https://emc.pamplona.name:7103/console

Y acediendo a esa URL nos encontramos con
ScreenHunter_112 May. 26 09.44

Pero si revisamos los pasos de la instalacion del OEM12c veremos como en ninguna de las ventanas indicamos cual era el usuario de administrador del servidor de aplicaciones que va a correr el OEM12c. Solo indicamos el password.

La respuesta es sencilla :

usuario : weblogic
Contraseña: La de la instalación

Vuelta tras de una base de datos a una fecha con rman

Revisando las entradas de RMAN veo que nos falta una entrada para el caso mas común y mas sencillo de todos, volver la base de datos a una determinada fecha.
La manera mas cómoda de hacer esto desde la versión 11g es hacerlo con un flashback database pero, por si no pudiese hacerse, vamos a explicar la recuperación mas sencilla que hay.

Supuesto

Nos encontramos en el caso en el que no hemos perdido nada en la base de datos pero debemos de hacer una marcha atrás en el tiempo de la base de datos a un momento anterior a 7 días(o la etencion del backup del controlfile).
En este caso disponemos en el servidor de todos los elementos de la base de datos ( passwd,spfile,controlfile….) pero los datos no no son válidos.

Pasos previos

En este caso y para garantizar que si fallamos en el proceso podemos repetirlo guardaremos el controlfile.
Este paso es de suma importancia ya que, al no tener base de datos de catálogo de RMAN si perdiésemos el controlfile perderíamos toda la información del RMAN
Para ello haremos dos acciones:

Copia del controlfile a texto

alter database backup controlfile to  trace as ‘….\CONTROLFILE.TXT’;

Copia física del controlfile

Como decíamos anteriormente, el controlfile el único elemento de la base de datos en el que mantenemos la información de donde esta el catálogo de rman, así que, pararemos la base de datos y copiaremos los 3 controlfiles desde su ubicación en los discos a un directorio dedicado creado para esta copia
El contenido de los 3 controlfiles es exactamente el mismo, con lo que, al copiar los 3 estamos haciendo 3 backups

Recuperacion

Una vez hemos guardado nuestros controlfiles para tener las espaldas cubiertas, procederemos a recuperar la base de datos a el momento en que queremos.
Para ello, crearemos un script de rman llamado recuperacion.cmd con el contenido :

startup mount;
RUN {
SET until time="TO_DATE('23/02/15 21:00:00','DD/MM/YY hh24:mi:ss')";
allocate channel DEV0 type SBT_TAPE PARMS 'ENV=(XXXXXXXXXXXXXXX)';
restore database;
recover database;
 }

Donde ENV=(XXXXXXXXXXXXXXXXXX) dependerá de la integración de backup que se use.
Y lo ejecutaremos con el comando

ORACLE_SID=XXX
rman cmdfile restauracion.cmd log=estado_restauracion.log

Apertura

Al estar haciendo una recuperación de la base de datos incompleta deberemos de abrir la base de datos en modo resetlogs, para ello, desde la línea de comandos

 ORACLE_SID=XXX
Sqlplus “/as sysdba”
ALTER DATABASE OPEN RESETLOGS;

Y con esto tendremos la base de datos recuperada a la fecha que buscábamos.
Como veis, al no tener que conocer DBIDs, ni recuperar controlfiles u spfiles, el