Archivo de la categoría: dummie

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

Posted on por

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

Funcionamiento del Redo en el RAC

Posted on por

Hoy vamos con otra de las entradas para dummies, viendo un poco el funcionamiento del redo en el RAC.
Cada instancia dentro del RAC debe de tener su propio espacio de redo (que se corresponderá con un número único de thread para toda la instancia) y undo.

Pero que ocurre si muere un nodo?
¿Que pasa con los datos que están en esos redos?

En un entorno de RAC, todas las instancias de la base de datos tienen acceso a todos los redo logs de todos los nodos, de esta manera, si uno de los nodos muere, uno de los nodos vivos accederá a el redo de la instancia caída y aplicará de manera automática los cambios de la misma manera que se haría un instance recovery a la hora de arrancar la base de datos. Con lo que los datos en disco siempre estarán consistentes.

¿Que ocurre si caen todos a la vez?
Si todas las instancias cayeran el instance recovery sería llevado a cabo por la primera de las instancias que se levantara, esta sería la encargad de hacer el instance recovery de todos los redos de todas las instancias del rac.

Como veis, a pesar de la complejidad del RAC, el funcionamiento no deja de ser muy sencillo, al menos, visto desde arriba 😉

Parámetro compatible en las bases de datos

Posted on por

Hoy vamos a ver uno de los parámetros mas sencillos que hay pero que puede provocarnos algún que otro quebradero de cabeza. El parámetro «compatible»

Uno de los parámetros del init.ora de nuestras bases de datos es el de la compatibilidad.
Este parámetro afecta al funcionamiento interno de la base de datos afectando no solamente al modo de trabajo del optimizador sino también pudiendo afectar a la manera en la que Oracle maneja físicamente algunas estructuras de datos.

¿Cual es la principal consecuencia de esto?
Que NO es posible la vuelta atrás.
Desde Oracle 9i , la versión de base de datos está compuesta por 5 dígitos cuyo significado es:
Opciones del número

En nuestro afán de tener la base de datos al último nivel de funcionalidad podemos tender a subir siempre el nivel de compatibilidad al máximo.
Esta costumbre no solo la desaconsejamos aquí, sino que es una de los advices que dan desde Oracle «Use only the first 3 digits for the compatible parameter unless there would be some very specific instructions to do otherwise.».

La razón es que, como comentábamos al principio, el parámetro compatible no es algo que pueda deshacerse ya que afecta a la estructura física de la base de datos con lo que, en caso de tener que hacer marcha atrás hacia una versión compatible inferior deberá de hacerse un downgrade completo de la base de datos.

Para mas información, como siempre en soporte de Oracle:

  • About Oracle Database Release Numbers
  • Note 733987.1 How To Change The COMPATIBLE Parameter And What Is The Significance? (Doc ID 733987.1)
  • Note 1563364.1 What is the Relationship between the COMPATIBLE Initialization Parameter and the Optimizer (Doc ID 1563364.1)
  • Note 1458741.1 COMPATIBLE Parameter – Explanation, Usage and Advise (Doc ID 1458741.1)

Rotar el listener sin pararlo

Posted on por

Hoy vamos a ver una entrada de dummy pero de mucha utilidad.

Habitualmente, el log del listener crece de manera descontrolada y solemos tener problemas a la hora de borrarlo. No podemos detener el listener,por que cortaríamos el servicio, y tampoco podemos borrar el fichero del log por que está en uso.
¿Que hacemos entonces?

La solución es bien sencilla, simplemente dejamos de logar, vaciamos y volveos a logar.
Lo primero que hemos de hacer es conectarnos desde linea de comandos al listener, lo que vamos ha hacer es:

  • Comprobar si estamos logando
  • Mirar cual es el log
  • Mirar cual es el directorio de trazas

La salida de los comandos será:

oracle@server : lsnrctl
LSNRCTL> show log_status
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC_FOR_XE)))
LISTENER parameter "log_status" set to ON
The command completed successfully
LSNRCTL> show log_file
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC_FOR_XE)))
LISTENER parameter "log_file" set to /u01/app/oracle/diag/tnslsnr/server/listener/alert/log.xml
The command completed successfully
LSNRCTL> show trc_directory
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC_FOR_XE)))
LISTENER parameter "trc_directory" set to /u01/app/oracle/diag/tnslsnr/server/listener/trace
The command completed successfully
LSNRCTL> set log_status off

En otra ventana, iremos al directorio de tazas y borraremos o moveremos las trazas que nos molestan
Una vez eliminados, solamente hemos de volver a activar el log

LSNRCTL> set log_status on;
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC_FOR_XE)))
LISTENER parameter "log_status" set to ON
The command completed successfully
LSNRCTL> show log_status
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC_FOR_XE)))
LISTENER parameter "log_status" set to ON
The command completed successfully
LSNRCTL>

Escribir la salida de un sql en un fichero con UTL_FILE

Posted on por

Vamos con otra entrada básica para dummies.

Supongamos que queremos hacer implantar algún tipo de sonda que nos haga una pregunta a la base de datos y nos deje el resultado en un directorio.
Vamos a crear un pequeño procedimiento que, a modo de ejemplo nos saque algunos parámetros del v$session y nos lo deje en un directorio previamente definido llamado SONDA

CREATE OR REPLACE PROCEDURE proc_a_file AS
     fichero utl_file.file_type;
     nombre_fichero  VARCHAR2(255);
     linea_resul  VARCHAR2(255);
        BEGIN
  -- Definimos el nombre del log de salida
     select  'sonda_'||
              to_char(TO_CHAR(sysdate, 'YYYYMMDDHHmiss'))||
             '.log'
              into nombre_fichero  from dual  ;
  -- Abrimos fichero      
       fichero := utl_file.fopen('SONDA', nombre_fichero, 'A');
  -- Añadimos encabezado   
           UTL_FILE.PUT_LINE ( fichero ,'SID, SERIAL,TERMINAL,OSUSER');
  -- Lanzamos consulta        
                     FOR ciclo IN (
                         SELECT
                              select sid SID,
                              serial#  SERIAL,
                              terminal TEMINAL,
                              osuser  USER  
                         from v$session
                               )
                  LOOP  --Bucle de scritura de datos 
                 UTL_FILE.PUT_LINE ( fichero ,ciclo.SID||
                                              chr(44)|| 
                                             ciclo.SERIAL||
                                              chr(44)|| 
                                            ciclo.TERMINAL||
                                            chr(44)||
                                            ciclo.USER);
                 END LOOP;         
-- Limpiamos y cerramos
          utl_file.fflush(fichero);
        utl_file.fclose(fichero);
-- Excepciones de error en el alert.log
    EXCEPTION
    WHEN UTL_FILE.WRITE_ERROR THEN
    dbms_system.ksdwrt(2, 'ORA-XXXX  Error en procedure proc_a_file escrbiendo en fichero de log.');
    WHEN others THEN
       dbms_system.ksdwrt(2, 'ORA-XXXX  Error genérico en procedure   proc_a_file. '||SQLERRM);
      END proc_a_file; -- En del procedure

Ahora ya podemos lanzar nuestro procedimiento, bien desde el código de aplicación, cron, task manager, trigger o desde el lugar que deseemos