Ruta del Alert de la Base de Datos de Oracle



Ruta del Alert de la Base de Datos de Oracle

Saber ubicación donde sale el log de Base de Datos Oracle:
1 opción SQL> show parameter background 
2 opción SQL> show parameter dump
3 opción adrci 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
background_core_dump                 string      partial
background_dump_dest                 string      /oracle/app/oracle/diag/rdbms/PROD/PROD/trace

SQL> !ls -ltr /oracle/app/oracle/diag/rdbms/PROD/PROD/trace/al*
-rw-r----- 1 oracle oinstall 78512424 2011-10-03 02:00 /oracle/app/oracle/diag/rdbms/PROD/PROD/trace/alert_PROD.log

Obtener procesos en ejecución en Base de Datos Oracle


Obtener procesos en ejecución en Base de Datos Oracle

Útil para cuando no tenemos una herramienta de monitoreo como Lab... y queremos saber que usuarios estan activos en la Base de Datos:


SELECT sess.process, sess.status, sess.username, sess.schemaname, sql.sql_text
FROM v$session sess, v$sql sql
WHERE sql.sql_id(+) = sess.sql_id
AND sess.type = 'USER'
AND sess.status = 'ACTIVE'; 

Conectar Servidores UNIX/Linux sin clave para Backup

Generando tu clave pública SSH

Tal y como se ha comentado, muchos servidores en Producción utilizan la autenticación a través de claves públicas SSH. El proceso para hacerlo es similar en casi cualquier sistema operativo. Ante todo, asegurarte que no tengas ya una clave. Por defecto, las claves de cualquier usuario SSH se guardan en la carpeta ~/.ssh de dicho usuario. Puedes verificar si tienes ya unas claves, simplemente revisando sobre dicha carpeta y viendo su contenido:

$ cd ~/.ssh
$ ls -larth
authorized_keys  id_dsa  id_dsa.pub  known_hosts



NOTA: Si no se han generado no aparece nada.

Para generar llaves

$ ssh-keygen 


00 $ ssh-keygen 01 Generating public/private dsa key pair. 02 Enter file in which to save the key (/home/oracle/.ssh/id_dsa): 03 Enter passphrase (empty for no passphrase): 04 Enter same passphrase again: 05 Your identification has been saved in /home/oracle/.ssh/id_dsa. 06 Your public key has been saved in /home/oracle/.ssh/id_dsa.pub. 07 The key fingerprint is: 08 e7:0e:1e:d6:aa:90:6e:9b:ac:ad:7f:6f:1d:23:05:82 oracle@sv07



Explicación:


Lo que sucede, en la línea '02', el programa propone el directorio donde guardará el par de llaves que se crearán la llave pública y privada, y este por defecto es el directorio oculto '.ssh', en el HOME del usuario. Es posible indicar otro directorio si se desea.
En las líneas '03' y '04' se pide un 'passphrase' que es como una contraseña. En este primer ejemplo usaremos el certificado generado para tareas automatizadas, como por ejemplos respaldos, así que no es necesario indicarlas y las dejamos en blanco.
Las líneas '05' y '06' nos indican que se generó correctamente la llave privada 'id_dsa' y la llave pública 'id_dsa.pub'.
Y por último la línea '08' es el fingerprint de nuestro archivo público.


Si deseas ver su huella digital original y comprobar que no se ha alterado en ningún caracter, entonces usamos de nuevo el comando ssh-keygen con las opciones l y fque muestra el fingerprint a partir del archivo indicado.

$ ssh-keygen -l -f id_dsa.pub
1024 e7:0e:1e:d6:aa:90:6e:9b:ac:ad:7f:6f:1d:23:05:82 id_dsa.pub

Copiarla al servidor que necesitamos autenticarnos

$ ssh-copy-id oracle@remote_ip

Como bien nos aparece en la terminal, probemos si de veras todo funcionó 100% OK. Para probar, ponemos:


$ ssh oracle@10.10.0.5












Guía Básica de RMAN

Guía Básica de RMAN (actualizada)

Conexión a RMAN

La forma más simple de conectarse a RMAN es la siguiente (con el usuario oracle):
$ rman target /

Recovery Manager: Release 10.2.0.1.0 - Production on Wed Mar 8 13:16:22 2006

Copyright (c) 1982, 2005, Oracle. All rights reserved.

connected to target database: LCBDPROD (DBID=2582320114)

RMAN>
Si queremos que nuestras actividades se registren en un archivo log:
$ rman target / log /ruta/archivo.log [append]

Parámetros de configuración de RMAN

RMAN viene configurado con una serie de parámetros predefinidos, mismos que podemos ver con el comando show:
RMAN> show all ;
using target database control file instead of recovery catalog
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/10.2.0/dbs_1/dbs/snapcf_LCBDPROD1.f'; 
 # default

Respaldos incrementales

Un respaldo incremental consta de dos niveles: 0 (respaldo completo de la base de datos y que sirve de base a los respaldos incrementales) y 1 (respaldos incrementales en los que solamente se respaldan los bloques que han cambiado desde el último respaldo). Adicionalmente, es posible “actualizar” el respaldo de nivel 0 con los cambios del respaldo de nivel 1. Un respaldo de este tipo se haría de la siguiente forma:
Paso 1. Respaldo completo (nivel 0):
RMAN> backup incremental level 0 tag ‘INC_L0’ database ;
Paso 2: Primer respaldo incremental (nivel 1):
RMAN> backup incremental level 1 for recover of copy tag ‘INC_L0’ database ;
Paso 3: Aplicar el respaldo incremental al respaldo de nivel 0, es decir, aplicar los cambios en los bloques al respaldo base.
RMAN> recover copy of database with tag ‘INC_L0’ ;
Para que el desempeño del respaldo incremental sea óptimo, es necesario habilitar la opción llamada block change tracking, que es un archivo que lleva el registro de los bloques que van cambiado desde el último respaldo. Si no está habilitado, RMAN tiene que leer todos los bloques de la base de datos para determinar cual respaldar, haciendo el respaldo tan caro como un full backup. Para habilitar block change tracking:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING ;
El archivo de tracking se genera automáticamente en el área de flashback.

Respaldo de los respaldos

Si los respaldos se están haciendo en flashback recovery area, es conveniente respaldar también esta área que se encuentra en disco.
RMAN> backup recovery area ;
Esto respalda todos los archivos de recuperación en flashback recovery area: full backups, copies, incrementals, respaldos de controlfiles, y archivelogs. No se respaldan block change tracking files, controfiles actuales ni redo logs. El único destino válido para estos respaldos es cinta.

Políticas de retención

Las políticas de retención nos ayudan a determinar qué respaldos todavía son necesarios y cuáles ya no debido a que han quedado obsoletos por un respaldo más reciente. Hay dos tipos de políticas de retención y son mutuamente excluyentes: redundancy y recovery window.
  • Redundancy: determina cuantas copias de un archivo se necesitan antes de considerar una copia obsoleta. Si la redundancia es 1, cada que se respalde un archivo (copia), todas las copias anteriores son obsoletas. REDUNDANCY=1 es la política de retención por default.
  • Recovery Window: determina el tiempo que debe ser retenido un archivo antes de ser obsoleto.
Para cambiar la política de retención:
RMAN> configure retention policy to redundancy X ;
ó
RMAN> configure retention policy to recovery window of X days ;
Con nuestra política definida, podemos revisar los respaldos que ya son obsoletos:
RMAN> report obsolete ;
Y borrarlos si determinamos que ya no son necesarios:
RMAN> delete obsolete ; <-- borrar="" nos="" pregunta="" queremos="" realmente="" rman="" si=""> delete force noprompt obsolete ; <-- borra="" confirmaci="" n.="" pre="" sin="">
Oracle automáticamente borrará respaldos obsoletos si flashback recovery area comienza a tener problemas de espacio.

Configuración de cintas

RMAN no puede escribir directamente a cintas, por lo que es necesario configurar una librería que generalmente es proporcionada por el fabricante de la unidad de respaldo a cinta. En versiones anteriores de RMAN dicha librería se configuraba en $ORACLE_HOME/lib, sin embargo, en 10g Oracle recomienda que se especifique la librería directamente:
RMAN> configure channel device type sbt
2> parms= ‘SBT_LIBRARY=/path/librería’ ;

Reporte de operaciones

Podemos usar los comandos LIST y REPORT para generar reportes de actividades realizadas con RMAN:
list backup summary;
list backup by datafile;
list backup of database;
list backup of archivelog all;
list backup of controlfile;
report obsolete ;
report need backup ;

Scripts

Archivos de comandos: Un archivo de comandos es un archivo de texto conteniendo comandos RMAN, y que puede ser llamado de la siguiente forma:
RMAN> @/ruta/script.txt 
ó 
$ rman target / @/ruta/script.txt
Comando RUN: El comando RUN agrupa comandos de RMAN para ser ejecutados como uno solo. Si uno de los comandos falla, el resto ya no es ejecutado.
RUN {
 BACKUP ARCHIVELOG ALL DELETE ALL INPUT;
 BACKUP INCREMENTAL LEVEL 0 TAG mon_bkup DATABASE;
}

Casos de recuperación

Se puede ejecutar el comando RESTORE … VALIDATE para confirmar que una operación puede ser ejecutada correctamente. RMAN automáticamente decide qué archivos son necesarios para la recuperación y verifica que sean utilizables.
RMAN> restore database validate ;
Caso 1. Recuperación completa de la base de datos cuando se tiene el archivo de control y la base de datos está montada:
RMAN> restore database ;
RMAN> recover database ;
Caso 2. Se tiene la situación del caso 1 pero se desea recuperar a un punto pasado en el tiempo:
RMAN> run {set until time = ’04-MAR-06 12:00:00’;
2> restore database ;
3> recover database ;
4> }
Caso 3. Recuperación de un datafile
Identificar el número de datafile:
SQL> select file#, name from v$datafile ;

Poner offline el datafile, ya sea desde SQL*Plus o desde RMAN:
RMAN> sql ‘alter database datafile 8 offline’ ;

Recuperar el datafile:
RMAN> run {restore datafile 8 ;
2> recover datafile 8 ;
3> sql ‘alter database datafile 8 online’ ;
4> }
Caso 4. Recuperación de un tablespace.
RMAN> run {sql ‘alter tablespace users offline’ ;
2> restore tablespace users ;
3> recover tablespace users ;
4> sql ‘alter tablespace users online’ ;
5> }
El comando run es para correr las instrucciones en modo script, pero también pueden ser ejecutadas una por una:
RMAN> sql ‘alter tablespace users offline’ ;
RMAN> restore tablespace users ;
RMAN> recover tablespace users ;
RMAN> sql ‘alter tablespace users online’ ;
Caso 5. Recuperación de bloques corruptos RMAN es la herramienta ideal para recuperación de bloques corruptos (ORA-1578). El error nos dice cuál es el bloque corrupto:
ORA-1578: ORACLE data block corrupted (file # 7, block # 1234)
Mismos que también podemos consultar en la vista v$database_block_corruption. Para recuperar todos los bloques corruptos:
RMAN> blockrecover corruption list ;
O podemos recuperar bloques individuales:
RMAN> blockrecover datafile 7 block 1234[, datafile 10 block 3265, ...] ;

Nuevas Características RMAN 11g r2

Duplicación de Base de Datos

La duplicación de base de datos es muy útil en las siguientes situaciones:
  • Probar procedimientos de respaldos y restauraciones
  • Probar procedimientos de actualización de versiones de base de datos
  • Probar los efectos de las aplicaciones sobre el rendimiento de base de datos
  • Creación de una base de datos standby
  • Generación de reportes
RMAN soporta dos tipos de duplicación: Active database duplication y backup-based duplication:
rman

EJEMPLOS DE CONEXIÓN CON RMAN PARA LA DUPLICACIÓN DE BASE DE DATOS:

RMAN> CONNECT TARGET SYS/sysdba@prod;    # source database
connected to target database: PROD (DBID=39525561)

RMAN> CONNECT AUXILIARY SYS/sysdba@dupdb; # duplicate database instance
connected to auxiliary database: DUPDB (not mounted)

RMAN> CONNECT CATALOG rman/rman@catdb;    # recovery catalog database
connected to recovery catalog database
Duplicación de base de datos a un servidor con la misma estructura (Active):
DUPLICATE TARGET DATABASE TO dupdb
   FROM ACTIVE DATABASE
   PASSWORD FILE
   SPFILE
   NOFILENAMECHECK;
Duplicación de base de datos basada en respaldo con Catalogo de recuperación:
Ejemplo: Duplicación en un punto de tiempo
DUPLICATE DATABASE prod DBID 8675309 TO dupdb
   UNTIL TIME "TO_DATE('11/01/2007', 'MM/DD/YYYY')" 
   SPFILE
   NOFILENAMECHECK;
Ejemplo: Duplicación en un punto de restauración:
DUPLICATE DATABASE prod DBID 8675309 TO dupdb
   TO RESTORE POINT TESTDB103107
   SPFILE
   NOFILENAMECHECK;
Duplicación de base de datos basada en respaldo sin conexión a objetivo ni catálogo de recuperación:
DUPLICATE DATABASE TO dupdb
   UNTIL TIME "TO_DATE('11/01/2007 14:00:00', 'MM/DD/YYYY HH24:MI:SS')"
   SPFILE
   BACKUP LOCATION '/prod_backups'
   NOFILENAMECHECK;
Duplicación de base de datos cuando se tiene diferente estructura de directorios
RUN
{
 SET NEWNAME FOR DATAFILE 1 TO '/oradata1/system01.dbf';
 SET NEWNAME FOR DATAFILE 2 TO '/oradata2/sysaux01.dbf';
 SET NEWNAME FOR DATAFILE 3 TO '/oradata3/undotbs01.dbf';
 SET NEWNAME FOR DATAFILE 4 TO '/oradata4/users01.dbf';
 SET NEWNAME FOR DATAFILE 5 TO '/oradata5/users02.dbf';
 SET NEWNAME FOR TEMPFILE 1 TO '/oradatat/temp01.dbf';
 DUPLICATE TARGET DATABASE TO dupdb
   SKIP TABLESPACE tools
   LOGFILE
     GROUP 1 ('/duplogs/redo01a.log',
              '/duplogs/redo01b.log') SIZE 4M REUSE,
     GROUP 2 ('/duplogs/redo02a.log',
              '/duplogs/redo02b.log') SIZE 4M REUSE
}

Flashback Database

Característica relacionada a la protección de los datos que nos permite regresar los datos en el tiempo para la corrección causados por corrupción lógica de la información o errores de usuario dentro de un periodo de tiempo asignado.
Flashback Database es accesible a través de RMAN o SQL con el comando FLASHBACK DATABASE
FLASHBACK DATABASE TO RESTORE POINT 'before_upgrade';

FLASHBACK DATABASE TO SCN 202381;

Nuevas Características RMAN 12c

RMAN en Nueva Arquitectura Multitenant (CDB,PDB)
Respaldar toda la base de datos contenedor es similar a respaldar una base de datos en la arquitectura anterior (non-CDB), Cuando se respalda toda CDB, RMAN respalda el contenedor root, todos los PDB y los archived redo logs. Durante la restauración es posible recuperar todo el CDB o en específico algún PDB.
Para respaldar todo el CDB es necesario conectarse al contenedor root con un common user con privilegios de SYSBACKUP o SYSDBA y ejecutar:
BACKUP DATABASE;
BACKUP DATABASE PLUS ARCHIVELOG;
Para respaldar en específico los PDB’s es necesario conectarse al contenedor root con un common user con privilegios de SYSBACKUP o SYSDBA y ejecutar el nuevo comando BACKUP PLUGGABLE DATABASE:
BACKUP PLUGGABLE DATABASE sales, hr;
Restaurar tablas o particiones desde respaldos con RMAN
RMAN 12c puede recuperar una o más tablas o particiones a un punto específico de tiempo sin afectar los demás objetos de base de datos. Ejemplo:
RECOVER TABLE HR.PDB_EMP OF PLUGGABLE DATABASE HR_PDB
UNTIL TIME 'SYSDATE-4'
AUXILIARY DESTINATION '/tmp/backups'
REMAP TABLE 'HR'.'PDB_EMP':'EMP_RECVR';
Donde se recuperara la tabla HR.PDB_EMP del PDB HR_PDB
Es posible especificar el punto en el tiempo con las clausulas:
UNITL TIME 
UNTIL SCN 
o 
UNTIL SEQUENCE
RMAN recupera los objetos en una instancia auxiliar y se especifica la ubicación de los archivos con la cláusula:
AUXILIARY DESTINATION
Es posible renombrar los objetos recuperados o especificar su almacenamiento en otro tablespace con las siguientes clausulas:
REMAP TABLE 
REMAP TABLESPACE