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

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.

expdp de una particion

Hoy vamos a ver otra entrada para dummies, esta vez una entrada rápida y sencilla sobre el exdp

¿Como podemos hacer para exportar los datos de una partición de una de las tablas de la base de datos?

La respuesta es muy sencilla, ya que, la opción TABLE nos permite mediante el uso de : indicar que lo que queremos extraer de esa tabla es una partición determinada.
Así pues para sacar una o varias particiones de una tabla, el comando sería :

expdp dba_user/password dumpfile=expdppart.dmp 
tables=(
schema_name.tablename:partition_name1,\
schema_name.tablename:partition_name2,\
schema_name.tablename:partition_name3,\
schema_name2.tablename:partition_name \
)

IMPORTANTE
Recordad que, a pesar de que hacer el export es tan sencillo, como vimos en una entrada anterior No se puede importar una partición por separado

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

Para un job de impdp de manera correcta

Hoy vamos a ver otra de esas entradas útiles del día a día.

En la entrada eliminar datapumps fallidos vimos como borrar los trabajos de impdp/expdp que estaban en entado fallido. Pero ¿que ocurre si queremos detener un trabajo en ejecución ?

Lo primero que haremos es volver a usar la consulta para ver el estado de los trabajos.

SET lines 200
SELECT owner_name, job_name, operation, job_mode,
state, attached_sessions
FROM dba_datapump_jobs
ORDER BY 1,2;

Y vemos que tenemos un JOB en modo de ejecucion

OWNER_NAME JOB_NAME    OPERATION JOB_MODE  STATE  ATTACHED
———- ——————- ——— ——— ———– ——–
SCOTT      EXPORT_TABLA_1 EXPORT  TABLE   EXECUTING  0
SYSTEM     EXPORT_DIARIA  EXPORT FULL     NOT RUNNING 0

Si lo que queremos es detener ese trabajo EXPORT_TABLA_1 de manera correcta, ejecutaremos:

SET serveroutput on
SET lines 100
DECLARE
   h1 NUMBER;
BEGIN
  -- Format: DBMS_DATAPUMP.ATTACH('[job_name]','[owner_name]');
   h1 := DBMS_DATAPUMP.ATTACH('SEXPORT_TABLA_1','SCOTT');
   DBMS_DATAPUMP.STOP_JOB (h1,1,0);
END;
/

Ejecutando la consulta que muestra los jobs de exports vemos que tenemos trabajos NOT RUNNING residuales, siempre podemos limpiar la tabla con el resultado de :

SELECT 'DROP TABLE '|| owner_name||'.'|| job_name ||';'
FROM dba_datapump_jobs
where STATE='NOT RUNNING';