Blog de Erika Mudespacher

Database Vault

2010-08-18T10:54:00.001-07:00

Ahora me ha tocado aprender database vault para un proyecto en el que iba a ser consultora, y por vueltas del destino me tocó ser el dba que instaló el producto en varias bases de datos del mismo proyecto.
Les paso la guía que generé después de algo de investigación, espero que les guste y les sirva.
Agradezco a mi compañero Nacho Vega por ayudarme a mejorar y completar mi documentación.

saludos!

1. Ingresar al servidor y fijar ambiente a la base de datos a instalar.

2. Realizar respaldo de la base de datos en frío.

3. Realizar respaldo del Home de Oracle de la base de datos a instalar.

4. Configurar el oraInventory:

Dependiendo el sistema operativo :
AIX /etc
Solaris /var/opt/oracle
a. Renombrar el archivo oraInst.loc, y renombrar el archivo oraInst de la base de datos a actualizar a oraInst.loc, o en su defecto, modificar la ruta de oraInst.loc para que apunte al inventory del Home de Oracle a instalar.
b. Esto es para que la instalación quede registrada en el inventory propio de la base de datos.

5. crear password file para la base de datos

6. Realizar los pasos de instalación de emca (opcional, se usará la consola de DBVault 11g):
a. Ejecutar el script de creación del usuario dbsnmp:
?/rdbms/admin/catsnmp.sql
b. Ejecutar emca con la siguiente sintaxis:
emca –config dbcontrol db –repos create

preguntara varios datos

Database SID:
Listener port number:
Password for SYS user:
Password for DBSNMP user:
Password for SYSMAN user:
Email address for notifications (optional):
Outgoing Mail (SMTP) server for notifications (optional):

c. En caso de ser necesario recrear o eliminar el repositorio, seguir los pasos indicados en la nota de metalink 278100.1
7. Respaldar los siguientes archivos:

Dependiendo el sistema operativo
AIX /etc
Solaris /var/opt/Oracle

a. oratab

Respaldar los archivos de red

b. /var/opt/oracle/listener.ora
c. /var/opt/oracle/tnsnames.ora

8. Revisar que el archivo de script bndlchk, ubicado en $ORACLE_HOME/bin, tenga configurado correctamente el ORACLE_HOME, para evitar errores al momento de instalar DBVault.

9. Crear un servicio de red (listener) con nombre LISTENER y en el puerto 1521.

10. Asegurarse que la variable TNS_ADMIN y ORACLE_BASE no tenga valor asignado.

unset TNS_ADMIN
unset ORACLE_BASE

11. bajar los servicios excepto el listener del puerto 1521

12. Ejecutar runinstaller como se muestra a continuación:

13. runInstaller ORACLE_HOSTNAME= xxx (donde xxx es el nombre del equipo)

14. El log de instalación puede ser monitoreado en $ORACLE_HOME/oraInventory/logs

15. Introducir los datos correspondientes al ambiente:

a. ORACLE_HOME donde será instalado.
b. Base de datos donde será instalado.
c. Usuario y contraseña del dueño de DBVault (dvowner).
d. Usuario y contraseña del administrador de cuentas (dacctmgr).
e. Seleccionar “User Verified” al error que indica que la variable ORACLE_BASE no está correctamente configurada.
Nota que para este post, estoy tomando como usuario "dvowner" y "dvacctmgr" como dueños de Database Vault y Administrador de cuentas respectivamente.

16. dar el password de sys y verificar que el ORACLE_HOME y la base de datos que selecciona el Universal Installer sean correctos

17. mandara un mensaje de que dará de baja los servicios

18. Ya verificado los procesos de instalación se debe de dar ok

19. Se verifica que debe de estar en la home correcto

20. Por un defecto en el software, dvca falla durante el proceso de instalación, por lo mismo es necesario ejecutarlo manualmente.

21. Verificar que la base de datos este levantada con spfile

show parameter spfile

22. Ejecutar dvca con los siguientes parámetros:

dvca -action option -oh $ORACLE_HOME -s_path /tmp -logfile $ORACLE_HOME/cfgtoollogs/dvca_install.log -owner_account dvowner -owner_passwd pass1234# -acctmgr_account dvacctmgr -acctmgr_passwd pass1234# -jdbc_str jdbc:oracle:oci:@$ORACLE_SID -sys_passwd xxx -languages {en} –nodecrypt

Donde:
Pass1234# es la contraseña que hayamos asignado a los usuarios dvowner y dvacctmgr
Xxx es la contraseña de nuestro usuario sys
$ORACLE_SID es el nombre de nuestra base de datos, la cual debe de estar previamente configurada en la variable de ambiente ORACLE_SID
$ORACLE_HOME también debe de estar previamente configurado al path del software de oracle

23. Realizar verificación de la instalación de Database Vault:

a. Primero, al ejecutar SQL*Plus, vemos que marca como opción Database Vault y antes no lo marcaba:

SQL*Plus: Release 10.2.0.5.0 - Production on Wed Aug 18 13:20:16 2010

Copyright (c) 1982, 2010, Oracle. All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options

b. Verificar que todos los objetos de DVSYS y DVF estén válidos

select owner,status,count(1)
from dba_objects
group by owner,status
order by 1;

c. Verificar que es posible ejecutar lo siguiente:
Select dvf.f$session_user from dual;

F$SESSION_USER
--------------------------------------------------
SYS

d. Verificar que el usuario sys no puede ver la siguiente table:
Select * from dvsys.audit_trail$;

Select * from dvsys.audit_trail$
*
ERROR at line 1:
ORA-01031: insufficient privileges

e. Eliminar los datos de OLAP que pueden ocasionar problemas al momento de realizar exports con Data Pump:
Delete from SYS.EXPPKGACT$ where package=’DBMS_AW_EXP’;

e. Bajar la Base de datos.

24. Cambiar contraseñas de DVSYS y DVF, y desbloquear cuentas. Para esto, es necesario primero deshabilitar DBVault y realizar los cambios.

25. Para deshabilitar Database Vault:

a. cd $ORACLE_HOME/rdbms/lib
b. make –f ins_rdbms.mk dv_off
c. cd $ORACLE_HOME/bin
d. relink all

26. Aplicar los parches de database vault:

a. 6401347 solo aplica para versión 10.2.0.4

27. Levantar la base de datos

28. Ejecutar una compilación de objetos inválidos:

@?/rdbms/admin/utlrp.sql

29. Revisar nuevamente que todos los objetos de DVSYS y DVF estén válidos.

select owner,status,count(1)
from dba_objects
group by owner,status
order by 1;

30. Cambiar passwords y desbloqueo de los usuarios dvsys y dvf (Esto aunque no está en el manual de oracle, yo lo recomiendo para no tener que deshabilitar database vault en el momento en que se quieran desbloquear las cuentas, hay que considerar que para deshabilitar database vault hay que bajar la base de datos)

alter user dvsys identified by cambiame;
alter user dvf identified by cambiame;
alter user dvsys account unlock;
alter user dvf account unlock;

31. Bajar la base de datos y habilitar nuevamente Database Vault.

32. Para habilitar Database Vault:

a. cd $ORACLE_HOME/rdbms/lib
b. make –f ins_rdbms.mk dv_on
c. cd $ORACLE_HOME/bin
d. relink all

BBED en Windows

2009-03-28T23:05:00.000-07:00

BBED es un Editor binario de bloques, con el cual podemos examinar los bloques de Oracle en los datafiles.

Es una utilería poco publicitada ya que está reservada para uso interno de Oracle, y con un mal uso de la misma podemos corromper la base de datos.

Este post no está orientado a escribir sobre cómo utilizar bbed, para eso existe un buen documento en Internet hecho por Graham Thornton “Dissassembling the data block”.

Para poder usar bbed en linux se tiene que ligar la utilería, la cual todavía se puede obtener en distribuciones recientes de Oracle..
Sin embargo en Windows venía como un ejecutable (bbed.exe) que se encontraba en ORACLE_HOME\bin, hasta la versión 8 de Oracle, desde la versión 9 ya no viene el ejecutable.

Si tienen a la mano una instalación de Oracle versión 8, pueden buscar las librerías que listo a continuación y copiarlas al directorio ORACLE_HOME\bin de su Oracle 10g o 9i, y así podremos usar bbed versión 8 en las versiones 9 y 10 de Oracle.

Estos son los archivos necesarios:

Bbed.exe
Oran8.dll
Oranl8.dll
Oranldap8.dll
Orannzsbb8.dll
Oracore8.dll
Oranls8.dll
Orageneric8.dll
Oracommon8.dll
Oraclient8.dll
Oravsn8.dll
Orawtc8.dll
Oranro8.dll
Orapls8.dll
Oraslax8.dll
Orasql8.dll
Oraldapclnt8.dll
Oratrace8.dll
Orancrypt8.dll
Oranhost8.dll
Oranoname8.dll
Orancds8.dll
Orantns8.dll
Orannds8.dll

Y así finalmente puedo utilizar bbed en windows!

C:>bbed
Password:

BBED: Release 2.0.0.0.0 - Limited Production on Sat Mar 28 23:52:45 2009

(c) Copyright 2000 Oracle Corporation. All rights reserved.
************* !!! For Oracle Internal Use only !!! ***************

BBED>

Recordemos que BBED debe de usarse únicamente en bases de datos de pruebas y solo es soportado por Oracle si lo realiza alguien de su mismo staff.

PD: Si alguien necesita los binarios y librerías, me pueden mandar un correo y se las comparto.

UTL_SMTP

2009-03-18T21:54:00.000-07:00

Un usuario de la base de datos con dos privilegios: create session y create procedure puede mandar correos desde la base de datos, establecer conexiones de red con servicios TCP/IP, enviar y recibir datos a través del protocolo HTTP y escribir y leer datos de ciertos archivos de sistema operativo.

Todo esto lo pueden hacer con los paquetes UTL_TCP, UTL_SMTP, UTL_HTTP y UTL_FILE, al crear la base de datos por default se hace un grant de estos paquetes al usuario PUBLIC.
Por ejemplo
Mandar un correo:
(Primero probamos que haya conectividad con el servidor de correos)



C:\Documents and Settings\Erika>ping smtp.mydomain.com
Pinging smtp.xxxxx.XXXX.com [XXX.XX.XXX.X] with 32 bytes of data:

C:\Documents and Settings\Erika>telnet smtp.xxxxxx.com 25

220 xxxsmtp06.xxxxxx.hosting.xxxxMicrosoft ESMTP MAIL Service,
Version: 6.0.3790.3959 ready at  Wed, 30 Jul 2008 20:43:41 -0500

helo

250 xxxsmtp06.xxxx.hosting. xxxx Hello [201.163.32.139]

mail from: erika@mymail.com
250 2.1.0 erika@mymail.com....Sender OK

rcpt to: erika@mymail.com
250 2.1.5 erika@mymail.com data

354 Start mail input; end with .
Subject: Prueba
SMTP
.

250 2.6.0  Queued mail for delivery

quit

221 2.0.0 xxxsmtp06.xxxxx.hosting.xxxxx Service closing transmission channel
Connection to host lost.

C:\Documents and Settings\Erika>

Ahora, creo un usuario con los privilegios: create session, y create procedure ( a simple vista no parece ser un usuario con demasiados privilegios)




SQL> create user kika identified by kika;
    User created.
SQL> grant create session to kika;
    Grant succeeded.
SQL> grant create procedure to kika;
   Grant succeeded.
SQL> conn kika/kika
   Connected.
SQL>

/* PL/SQL OBTENIDO DE OTN */

Kika solo tiene create session y create procedure, como kika ejecuto lo siguiente:

DECLARE
c utl_smtp.connection;
PROCEDURE send_header(name VARCHAR2, header VARCHAR2) AS
BEGIN
 utl_smtp.write_data(c,name ':' header  UTL_TCP.CRLF);
END;
BEGIN
 c := utl_smtp.open_connection('smtp.xxxx.xxxx.com');
 utl_smtp.helo(c, 'xxxsmtp06.xxxxx.hosting.xxxx');
 utl_smtp.mail(c, ‘erika@mymail.com');
 utl_smtp.rcpt(c,’ erika@mymail.com’);
 utl_smtp.open_data(c);
 send_header('From', '"Sender" ');
 send_header('To', '"Recipient" ');
 send_header('Subject', 'Hello');
 utl_smtp.write_data(c, UTL_TCP.CRLF  'Hello, world!');
 utl_smtp.close_data(c);
 utl_smtp.quit(c);
EXCEPTION
 WHEN utl_smtp.transient_error OR utl_smtp.permanent_error THEN
   BEGIN
     utl_smtp.quit(c);
   EXCEPTION
     WHEN utl_smtp.transient_error
     OR utl_smtp.permanent_error THEN
       NULL;
   END;
   raise_application_error(-20000, SQLERRM);
END;
/

Después de esto como se imaginarán, recibí un correo.
Yo creo que estos privilegios son muy poderosos en manos de un usuario malintencionado o descuidado, Oracle recomienda que revoquemos los privilegios UTL_TCP, UTL_SMTP, UTL_HTTP, UTL_FILE , DBMS_CRYPTO y DBMS_OBFUSCATION_TOOLKIT del usuario PUBLIC, pero Oracle es quien se los dio desde un inicio.
Incluso, si revocamos estos privilegios de PUBLIC e instalamos un parche, podemos constatar que PUBLIC nuevamente tiene los privilegios, así que debemos tomar en cuenta esto cada vez que parchemos las bases de datos.

RMAN Recovery Catalog

2009-03-03T08:30:00.000-08:00

El recovery catalog es un repositorio de metadatos de los respaldos con RMAN. El recovery catalog se crea en un esquema de usuario en alguna base de datos Oracle, y no es mas que un conjunto de paquetes, tablas, índices y vistas.
Los datos en estas tablas se refrescan con información del control file a través del comando resync.
Por eso el recovery catalog es opcional, ya que la información a fin de cuentas es proporcionada por el controlfile.
La diferencia es que un catálogo de rman puede contener la información de todas las bases de datos que deseemos, y el controlfile solo contiene información de su propia base de datos.

Es sencillo crear el catálogo, sigamos unos cuantos pasos:

1.En alguna base de datos creamos el esquema dueño del catálogo, por tradición el esquema se nombra “rman” sin embargo puede ser algún otro esquema en la base de datos.
Para evitar confusiones yo nombré al usuario “catowner”.



SQL> create user catowner identified by catowner
  2  default tablespace catownertbs
  3  quota unlimited on catownertbs;

User created.

2.Al esquema seleccionado, se le otorga el permiso recovery_catalog_owner:



SQL> grant recovery_catalog_owner to catowner;
Grant succeeded.

3.Ahora vamos a crear el catálogo, para eso nos conectamos a rman y al esquema para catálogo que recién creamos:



C:\>rman
Recovery Manager: Release 10.1.0.4.2 - Production
Copyright (c) 1995, 2004, Oracle.  All rights reserved.

RMAN> connect catalog catowner/catowner@OAS
connected to recovery catalog database
recovery catalog is not installed
RMAN>

4.Como podemos ver, nos manda un mensaje RMAN diciendo que el recovery catalog no está instalado. Vamos a crearlo:



RMAN> connect catalog catowner/catowner@OAS
connected to recovery catalog database
recovery catalog is not installed

RMAN> create catalog;
recovery catalog created

5.A continuación, registramos la base de datos primary en el catálogo:



RMAN> connect target "sys/contraseña@primary"
connected to target database: PRIMARY (DBID=1517448076)

RMAN> register database;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
RMAN>

6.Como podemos observar, se hizo un resync completo, es decir se refrescaron las tablas del catálogo con información del controlfile.

7.Ahora podemos crear un sencillo respaldo a disco, utilizando nuestro catálogo.



C:\>rman target / catalog="catowner/catowner@OAS"

Recovery Manager: Release 10.1.0.4.2 - Production
Copyright (c) 1995, 2004, Oracle.  All rights reserved.
connected to target database: PRIMARY (DBID=1517448076)
connected to recovery catalog database

RMAN> run{
allocate channel c1 type disk format 'D:\backup\pimary\bkpriamry_%U.bk';
backup database plus archivelog;
release channel c1;
}

8.Es muy importante que sepamos realizar los respaldos, pero mas importante que podamos recuperar nuestra base de datos cuando sea necesario.
Una tarea de vital importancia es asegurarnos que nuestros respaldos sean efectivos, para eso contamos con el comando “restore database validate” El cual revisa si es posible en un momento dado restaurar la base de datos con los respaldos que tenemos, sin físicamente restaurarla, es decir, el comando simplemente simula si podemos restaurar la base de datos.



RMAN> restore database validate;

Starting restore at 03-MAR-09
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=124 devtype=DISK
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: restored backup piece 1
piece handle=D:\BACKUP\PIMARY\BKPRIAMRY_0LK902OJ_1_1.BK tag=TAG20090303T114418
channel ORA_DISK_1: validation complete
Finished restore at 03-MAR-09
RMAN>

Al no marcar error, podemos estar seguros de que nuestro respaldo es funcional para el caso de una restauración.

9.Si quisiéramos ver cuáles respaldos RMAN utilizaría en caso de una recuperación contamos con el comando “restore database preview”:



RMAN> restore database preview ;

Starting restore at 03-MAR-09
using channel ORA_DISK_1


List of Backup Sets
===================

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
647     Full    543M       DISK        00:01:25     03-MAR-09
        BP Key: 653   Status: AVAILABLE  Compressed: NO  Tag: TAG20090303T114418

        Piece Name: D:\BACKUP\PIMARY\BKPRIAMRY_0LK902OJ_1_1.BK
  List of Datafiles in backup set 647
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1       Full 392974     03-MAR-09 D:\ORADATA\PRIMARY\PRIMARY\SYSTEM01.DBF
  2       Full 392974     03-MAR-09 D:\ORADATA\PRIMARY\PRIMARY\UNDOTBS01.DBF
  3       Full 392974     03-MAR-09 D:\ORADATA\PRIMARY\PRIMARY\SYSAUX01.DBF
  4       Full 392974     03-MAR-09 D:\ORADATA\PRIMARY\PRIMARY\USERS01.DBF
Finished restore at 03-MAR-09

RMAN>

En un post siguiente escribiré sobre la base de datos auxiliar y como hacer una clonación en caliente.

Matar sesiones Oracle en Windows

2009-02-27T23:18:00.000-08:00

A veces necesitamos matar sesiones de la base de datos Oracle, muchas veces estas sesiones se quedan “colgadas” e inactivas incluso por dias, otras veces aunque están en estado activo se nos pide que las eliminemos.

Para matar una sesión contamos con el comando ALTER SYSTEM KILL SESSION 'sid, serial#'

Previamente debo de conocer el sid y el serial# de la sesión que deseo eliminar, en este caso quiero matar al usuario QUICK:


SQL> select sid, serial#, username, status from v$session;


       SID    SERIAL# USERNAME   STATUS
---------- ---------- ---------- --------
       370        226            ACTIVE
       373        557 QUICK      INACTIVE
       381         90 SYS        ACTIVE
       383          1            ACTIVE
       385          1            ACTIVE
       386          7            ACTIVE
       389          3            ACTIVE
       390          3            ACTIVE
       391          4            ACTIVE
       393          1            ACTIVE
       394          1            ACTIVE
       395          1            ACTIVE
       396          1            ACTIVE
       397          1            ACTIVE
       398          1            ACTIVE
       399          1            ACTIVE
       400          1            ACTIVE

17 rows selected.

El comando para eliminar el sid 373 es el siguiente:



SQL> alter system kill session '373,557';

System altered.

Sin embargo hay ocasiones en que ALTER SYSTEM KILL SESSION no libera los bloqueos que tenía la sesión que matamos.
Esto sucede cuando una sesión no puede ser interrumpida hasta que terminie la operación que está realizando.
En este caso, la sesión mantiene todos los recursos que obtuvo de nuestro servidor hasta que termina la operación.
Normalmente, la sesión que ejecutó el ALTER SYSTEM KILL SESSION recibe el mensaje: “the session has been marked to be terminated”.
Y la sesión aparece en v$session con status “KILLED”



SQL> select sid, serial#, username, status from v$session;

       SID    SERIAL# USERNA STATUS
---------- ---------- ------ --------
       370        108        ACTIVE
       373        557 QUICK  KILLED
       381         90 SYS    ACTIVE
       383          1        ACTIVE
       385          1        ACTIVE
       386          7        ACTIVE
       389          3        ACTIVE
       390          3        ACTIVE
       391          4        ACTIVE
       393          1        ACTIVE
       394          1        ACTIVE
       395          1        ACTIVE
       396          1        ACTIVE
       397          1        ACTIVE
       398          1        ACTIVE
       399          1        ACTIVE
       400          1        ACTIVE

17 rows selected.

En linux tenemos la ventaja de poder matar el proceso del usuario con un kill -9, conociendo previamente el proceso del usuario.

La arquitectura de Windows no nos permite observar los distintos procesos que tiene Oracle, solo percibimos un oracle.exe, en el cual existen varios threads.

Para que en Windows nos podamos liberar de la sesión que quedó en estatus “KILLED”, podemos hacer cualquiera de las siguientes opciones:
1.Shutdown/Startup de la base de datos
2.Utilizar la utilería ORAKILL para eliminar threads.

Primeramente encontramos el thread con el siguiente query (debemos de conocer el thread previamente a ejecutar el comando ALTER SYSTEM KILL SESSION, de otra manera Oracle perdería la referencia al thread en cuestión):



SQL> select p.spid Thread, s.username Username, s.program
  2  from   v$process p, v$session s
  3  where  p.addr = s.paddr and s.username is not null;

THREAD       USERNAME   PROGRAM
------------ --------  -------------
364          SYS       sqlplus.exe
4524         QUICK     sqlplus.exe


SQL> exit



C:\Documents and Settings\Erika>orakill -h


Usage:  orakill sid thread

  where sid = the Oracle instance to target
  thread = the thread id of the thread to kill

  The thread id should be retrieved from the spid column of a query such as:

        select spid, osuser, s.program from
        v$process p, v$session s where p.addr=s.paddr

El comando por lo tanto sería:



C:\Documents and Settings\Erika>orakill OAS 4524

Kill of thread id 4524 in instance OAS successfully signalled.

Puesto que mi servicio se llama OAS.

A continuación en v$session vemos que ya no existe la sesión del usuario QUICK



SQL> select sid, serial#, username, status from v$session;


       SID    SERIAL# USERNAME   STATUS
---------- ---------- ---------- --------
       370        226            ACTIVE
       381         90 SYS        ACTIVE
       383          1            ACTIVE
       385          1            ACTIVE
       386          7            ACTIVE
       389          3            ACTIVE
       390          3            ACTIVE
       391          4            ACTIVE
       393          1            ACTIVE
       394          1            ACTIVE
       395          1            ACTIVE
       396          1            ACTIVE
       397          1            ACTIVE
       398          1            ACTIVE
       399          1            ACTIVE
       400          1            ACTIVE

16 rows selected.

Hay que tener cuidado porque al utilizar el comando ORAKILL para matar un thread corremos el riesgo de matar el proceso ORACLE.EXE