Detectar trabajos suspendidos

Vamso a ver una entrada rápida y sencilla.

¿Como sabemos cuando y por que se nos ah quedado parado un impdp?

La respuesta es muy sencilla, y es chequeando la table DBA_RESUMABLE


SELECT NAME,STATUS, TIMEOUT, ERROR_NUMBER, ERROR_MSG FROM DBA_RESUMABLE;

Esto nos dará una salida del estilo :

NAME                                STATUS            TIMEOUT, ERROR_NUMBER, ERROR_MSG
SYSTEM.IMPORT_REGENERACION2	NORMAL	       7200	0
SYSTEM.IMPORT_REGENERACION2.1	SUSPENDED	7200	1652	ORA-01652:      no se ha podido ampliar el segmento temporal con 1024 en el tablespace USERS

Donde podemos ver claramente que estamos parados por un ORA-01652 por culpa de espacio en un tabelspace

Errores Private strand flush not complete en el alert.log

Vamos a echar un vistazo rápido a un error bastante común en los alert.log

Una alerta bastante común que vemos en los alertlog es

Thread 1 cannot allocate new log, sequence 6180
Private strand flush not complete

Esta línea nos indica que, no hemos completado la operación de guardar todo el REDO cuando hacemos el switch.
El término strand es la palabra que utiliza Oracle para referrse a los latches de los redo log, lo que tenemos en este caso es un caso de este tipo, y lo que nos está indicando es qeu en ved de bajar el redo en tiempo real, lo «bajará» con el commit.

Este tipo de mensajes no es alarmante a no ser que haya mas mensajes del tipo «cannot allocate new log» o «advanced to log sequence»

En cualquier caso, pueden indicarnos que hay problemas con la velocidad de IO del almacenamiento donde se encuentran o en caso de ser logs remotos con la red

Cambiar de Pfile a Spfile en Windows

Hoy vamos a ver una entrada que es muy básica en Unix pero que puede traer algún quebradero de cabeza en windows.

¿Que ocurre cuando queremos pasar de Pfile a Spfile en Windows?

La pregunta parece sencilla de resolver, y es que , simplemente tenemos que dejar un fichero llamado spfile_SID.ora en el directorio $ORACLE_HOME/database ( el equivalente a $ORACLE_HOME/dba de UNIX) pero, cuando hacemos esto en windows falla.

El problema se encuentra en el modo de arranque, a la hora de crear el servicio seguramente se creo con el parámetro «pfile=XXX» , con lo que el motor busca exactamente el fichero init_SID.ora y por eso no arranca con el nuevo spfile.

Para solucionarlo, abriremos el regedit e iremos a:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME
Allí hay una entrada para cada instancia llamada ORA__PFILE. Lo que vamos ha hacer es eliminar esa entrada, haciendo que el motor busque el fichero de arranque por defecto.

Ah!, recordad que debería de existir el fichero SPFILE, para crearlo desde la 11g la manera mas sencilla es:

 create spfile  from memory;

Si estáis en alguna versión anterior siempre podéis seguir la entrada http://clemente.pamplona.name/dba/recuperar-un-spfile-borrado/

Como siempre, mas información en Soporte.

  • (Doc ID 378021.1) Oradim and Spfile
  • (Doc ID 232587.1) FAQ About Usage of Spfile and Pfile on Windows

Instalacion básica para Oracle 11

Repasando la entrada
Creación de una plataforma de pruebas RAC con VirtualBox veo como partimos de la base de una instalación de linux ya hecha.

Hoy vamos a hacer una entrada rápida con los pasos y paquetes que hay que preparar para una instalación básica de Oracle en un Oracle Linux 6.

Partiremos de la base de que tenemos una instalación mínima.

Los pasos serán

Deshabilitar SELinux

Editaremos el fichero vi /etc/selinux/config
dejándolo como

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

Deshabilitar iptables y postfix

No necesitaremos estos servicios, por lo que podemos quitamos del arranque

root@plantilla rc3.d]# rm /etc/rc3.d/S08iptables 
rm: ¿borrar el enlace simbólico «/etc/rc3.d/S08iptables»? (s/n) s
[root@plantilla rc3.d]# rm /etc/rc3.d/S80postfix 
rm: ¿borrar el enlace simbólico «/etc/rc3.d/S80postfix»? (s/n) s

Actualizamos y metemos los paquetes básicos

Necesitaremos algunos paquetes para la BBDD, así pues, ejecutaremos

yum update 
yum install kernel-devel
yum  groupinstall "Development Tools"
yum install oracle-validated

Instalamos las X para los accesos remotos

Para poder lanzar las herramientas gráficas necesitaremos unos pocos paquetes,la manera mas sencilla de obtenerlos es con el paquete xeyes que es el testador definitivo de las Windows y aceptando las dependencias.

yum install xeyes xauth 

Instalamos Utilidades básicas

Hay una serie de utilidades que seguramente usaremos y que no estaban en la instalacion mínima, estas son

yum install unzip atop  yum-utils ntp parted  oracleasm-support kmod-oracleasm oracleasmlib oracleasm-`uname -r` 
yum install compat-libcap1 compat-libstdc++-33 sysstat libaio-devel ksh libaio bind-utils smartmontools cvuqdisk redhat-lsb-core

Con esto, tenemos un Oracle Linux instalado listo para servir de plantilla para la instalación de nuestra base de datos

ORA-08189: no se puede realizar flashback

Hoy vamos a ver otra entrada para dummies.
Un error tremendamente sencillo que puede darnos algún susto, pero que hará que todo se quede en eso, en un susto.

Supongamos que queremos volver una tabla de nuestra base de datos ha hace 2 horas , lo más inmediato es intentar hacer:

FLASHBACK TABLE OWNER.TABLA 
  TO TIMESTAMP (SYSTIMESTAMP - INTERVAL '120' minute);

Pero, nos encontramos con el error:

Error at line 1
ORA-08189: no se puede realizar flashback en la tabla porque el movimiento de filas no está activado

Lo primero que nos viene a la cabeza es pensar que no vamos a poder ser capaces de recupera la tabla, pero, realmente, cuando obtenemos este error (o en Ingles)
ORA-08189: cannot flashback the table because row movement is not enabled
no está todo perdido, simplemente nos está indicando que no tenemos la opcion de «row movement» para poder llevar a cabo esta actualizacion.

Para solventar este problema haremos


ALTER TABLE OWNER.TABLA ENABLE ROW MOVEMENT;

Con este sencillo comando ya podremos ejecutar nuestro flashback… TO TIMESTAMP sin recibir alertas de error