Todo aquel, especialmente DBA's de Oracle, que suele mirar informes de rendimiento AWR en Oracle para analizar problemas de rendimiento, suele tener su propio procedimiento de lectura y aproximación a todos los datos que nos muestra este informe, pero como DBA siempre he echado en falta alguna herramienta que te facilite la lectura de todos los datos.

La he encontrado! “AWR Formatter” desarrollado por el Oracle DBA Tyler Muth permite facilitar esta lectura. Fantástico, debéis probarlo.

AWR Formatter es una extensión de Chrome (fichero con extensión .crx) gratuita que una vez instalado en el navegador, cada vez que visualizas un report AWR en html, te ofrece la posibilidad de formatearlo para ayudarte a ver toda su información.

Una vez formateado el texto, el HTML se ve en el navegador en distintas pestañas. Destaco las siguientes funcionalidades que te ofrece el formato añadido:

• Posibilidad de realizar dinámicamente conversiones de KB/MB/GB/TB en los distintos indicadores
• Posibilidad de consultar el significado de un determinado evento de espera, parámetro, etc… (esto es realmente útil)
• Tablas formateadas ordenables, casi como un Excel…
• Posibilidad de ver el texto de los comandos SQL’s…

Total, nada que ver con el mega fichero html estándar… una maravilla. Os lo podéis bajar gratuitamente del siguiente link:

https://dl.dropbox.com/u/4131944/AWR-Format/AWR-Format.crx

Una de las pestañas llamada “Observations”, pretende dar indicaciones de la lectura del report, pero es una primera aproximación, y por supuesto, cada Oracle DBA debe seguirlo según su responsabilidad.

Espero que lo disfrutéis,

Oscar Paredes

IT Manager
Oracle DBA

oscar.paredes@dataprix.com

Para acceder desde una base de datos Oracle a objetos de otra base de datos Oracle la manera más sencilla es utilizar un DBLink (que sea la más sencilla no significa que siempre sea la más aconsejable, el abuso de los dblinks puede generar muchos problemas, tanto de rendimiento como de seguridad)

Para ello es necesario, con un usuario que posea el privilegio CREATE DATABASE LINK, crear el DBLINK en la base de datos Oracle origen (A) mediante una sencilla sentencia como la siguiente:

SQL> Create database link LNK_DE_A_a_B connect to USUARIO identified by CONTRASEÑA USING 'B'; 

'LNK_DE_A_a_B' es el nombre del link, 'USUARIO' y 'CONTRASEÑA' son los identificadores del usuario que utilizará el database link para conectarse, los permisos del cual heredarán todos los accesos a través del db link, y B es el nombre de la instancia de la base de datos.

A través del dblink se puede conectar con los objetos de la base de datos remota con los permisos que tenga el usuario que se ha proporcionado en la sentencia de creación.

Para referenciar un objeto de la base de datos remota se ha de indicar el nombre del objeto, concatenado con el carácter '@' y el nombre que se le ha dado al DBLINK.

Ejemplo de consulta de select sobre una tabla a través de una database link:

SQL> select * from TABLA@LNK_DE_A_a_B 

Para ampliar información sobre la creación y utilización de database links se puede consultar la documentación de Oracle que se proporciona online en documentacion oracle create database.

Si lo que se quiere es acceder a una base de datos de otro fabricante, se puede crear el DBLink utilizando Heterogeneous Services. Se puede consultar cómo hacerlo con SQLServer en el artículo Heterogeneous services: Conexión desde Oracle a SQLServer

Libros de Administración Oracle (DBA) y PL/SQL

¿Quieres profundizar más en PL/SQL de Oracle o en administración de bases de datos Oracle? Puedes hacerlo consultando alguno de estos libros de Oracle.

Abro este tema a proposito de una consulta de Monica sobre Backups de BBDD Oracle.

Como la creación y gestión de copias de seguridad es un tema muy amplio y puede dar para muchas aportaciones y discusiones mejor dedicarle un tema específico de este foro de BBDD Oracle. 

Oracle normalmente no lo acostumbraremos a encontrar en Pymes sino más bien en empresas grandes. Esto hace que nos tengamos que poner las pilas en términos de seguridad, no aplicar una simple configuración sino, como buenos DBA's, realizar un buen y detallado estudio.

Qué mejor que ayudarnos de un checklist de seguridad para poder aplicar una buena configuración y que no se nos pase absolutamente nada.

Es por ello que adjunto uno en formato pdf y que básicamente se divide en cuatro apartados:

• Reforzamiento
• Actualizaciones de Seguridad
• Contraseñas por defecto
• Puertos por defecto utilizados por Oracle.

Descarga el Checklist de Seguridad en Oracle adjunto.

Espero que os guste..

A fin de obtener una lista aproximada de las tablas con más movimientos de la base de datos podemos consultar el contenido de la tabla dba_tables y cruzarlo con el estado actual de cada tabla en la bbdd. Esto puede tener sentido cuando queremos confeccionar una lista de tablas a las que se debe actualizar estadísticas periódicamente o queremos controlar la cantidad de información que genera alguna aplicación en concreto. Los datos que obtenemos por cada tabla son siempre respecto al último analisis de la misma.

La siguiente forma de hacerlo es un poco "rupestre" pero útil a la vez:

1. Nos conectamos a la base de datos como system y ejecutamos la siguiente consulta que nos devolvera una lista de selects con todas las tablas de la base de datos (es mejor filtrar para no incluir las tablas de sistema o incluir solo las de un usuario en concreto). En el ejemplo obtendremos solo las de un usuario en concreto:
   
   
   select 'select ''' || table_name || ''' as TABLA, ''' || sysdate ||
       ''' as FECHA_ACTUAL, ''' || last_analyzed ||
       ''' as ULTIMO_ANALISIS, count(*) as RECUENTO,' || num_rows ||
       ' as RECUENTO_ANALISIS ,  to_date(''' || sysdate ||
       ''', ''DD/MM/YYYY'') - to_date(''' || last_analyzed ||
       ''',''DD/MM/YYYY'') as DIAS_DESDE_ANALISIS , count(*) - ' || num_rows ||
       ' as DIFERENCIA_RECUENTO, (count(*) - ' ||
       num_rows || ')/(to_date(''' || sysdate ||
       ''', ''DD/MM/YYYY'') - to_date(''' || last_analyzed ||
       ''',''DD/MM/YYYY'')) as INCREMENTO_DIARIO   from ' || owner || '.' ||
       table_name || ' union '
  from dba_Tables
where owner = 'USUARIO'
   
   Ejemplo del resultado con plsql:
   

    

2. Copiamos toda la columna en el portapapeles y quitamos el último union. Obtendremos el siguiente resultado:

   

   Podemos ver la tabla con los datos del último analisis de la tabla respecto a los actuales y la variación con su media diaria en número de registros (teniendo en cuenta que un insert(1row) + delete(1row) = 0movimientos )
    

Si a esto le sumamos otros datos como tamaños de fila, si la tabla tiene índices y lo que se nos ocurra podemos hacer otros "trabajos manuales" como acumular esos resultados en una tabla para ver que se cuece en nuestra base de datos.  Eso sí, cada uno puede adaptar esta técnica a su gusto para cubrir sus necesidades

Si pasais a ocupar el puesto de DBA o administrador de Oracle y la persona saliente no os deja anotadas las contraseñas de los usuarios sys y system de la base de datos se puede proceder de la siguiente manera para intentar recuperarlas. Si tenemos el usuario root, podemos cambiar la contraseña de sys y system de Oracle.

Primero debemos conectarnos con SQLPlus al servidor Oracle con el usuario en el que corre la base de datos o root (conectar as sysdba).

A continuación cambiaremos la contraseña del usuario sys de Oracle:

$ sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.1.0 - Production on Mon Apr 5 15:32:09 2004
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production

SQL> show user
USER is "SYS"

SQL> passw system
Changing password for system
New password:
Retype new password:
Password changed
SQL> quit

Luego cambiaremos la contraseña del usuario system de Oracle: 

$ sqlplus "/ as system"

SQL*Plus: Release 9.2.0.1.0 - Production on Mon Apr 5 15:36:45 2004
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

SP2-0306: Invalid option.
Usage: CONN[ECT] [logon] [AS {SYSDBA|SYSOPER}]
where <logon>  ::= <username>[/<password>][@<connect_string>] | /
 Enter user-name: system
Enter password:
Connected to:

Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production

SQL> passw sys

Changing password for sys
New password:
Retype new password:
Password changed

SQL> quit

Ahora ya deberíamos poder conectarnos a nuestra base de datos Oracle como usuario sys y system, utilizando los nuevos passwords que hemos introducido desde SQLPlus.

Libros de Administración Oracle (DBA) y PL/SQL

¿Quieres profundizar más en PL/SQL de Oracle o en administración de bases de datos Oracle? Puedes hacerlo consultando alguno de estos libros de Oracle.

Vamos a ver en tres sencillos pasos cómo crear un esquema de Oracle. Para poder crear un nuevo esquema de Oracle siguiendo estos pasos es necesario iniciar la sesión en la base de datos con un usuario con permisos de administración. Lo más sencillo es utilizar directamente el usuario SYSTEM:

• Creación de un tablespace para datos y otro para índices. Estos tablespaces son la ubicación donde se almacenarán los objetos del esquema de Oracle que vamos a crear.

Tablespace para datos, con tamaño inicial de 1024 Mb, y auto extensible

CREATE TABLESPACE "APPDAT" LOGGING
DATAFILE '/export/home/oracle/oradata/datafiles/APPDAT.dbf' SIZE 1024M
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO

Tablespace para índices, con tamaño inicial de 512 Mb, y auto extensible

CREATE TABLESPACE "APPIDX" LOGGING
DATAFILE '/export/home/oracle/oradata/datafiles/APPIDX.dbf' SIZE 512M
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO

La creación de estos tablespaces no es obligatoria, pero sí recomendable, así cada usuario de la BD tendrá su propio espacio de datos.

• Creación del usuario que va a trabajar sobre estos tablespaces, y que será el propietario de los objetos que se se creen en ellos

CREATE USER "APP" PROFILE "DEFAULT" IDENTIFIED BY "APPPWD"
DEFAULT TABLESPACE "APPDAT" TEMPORARY TABLESPACE "TEMP" ACCOUNT UNLOCK;

Si no se especifica un tablespace, la BD le asignará el tablespace USERS, que es el tablespace que se utiliza por defecto para los nuevos usuarios.
Se puede apreciar también que no hay ninguna referencia al tablespace de índices APPIDX que hemos creado. Si queremos mantener datos e índices separados habrá que acordarse de especificar este tablespace en las sentencias de creación de índices de este usuario, si no se hace éstos se crearán en APPDAT:

CREATE INDEX mi_indice ON mi_tabla(mi_campo)
TABLESPACE APPIDX;

• Sólo falta asignarle los permisos necesarios para trabajar. Si se le asignan los roles 'Connect' y 'Resource' ya tiene los permisos mínimos, podrá conectarse a la base de datos y realizar las operaciones más habituales de consulta, modificación y creación de objetos en su propio esquema.

GRANT "CONNECT" TO "APP";
GRANT "RESOURCE" TO "APP";

Completamos la asignación de permisos con privilegios específicos sobre objetos del esquema Oracle para asegurarnos de que el usuario pueda realizar todas las operaciones que creamos necesarias

GRANT ALTER ANY INDEX TO "APP";
GRANT ALTER ANY SEQUENCE TO "APP";
GRANT ALTER ANY TABLE TO "APP";
GRANT ALTER ANY TRIGGER TO "APP";
GRANT CREATE ANY INDEX TO "APP";
GRANT CREATE ANY SEQUENCE TO "APP";
GRANT CREATE ANY SYNONYM TO "APP";
GRANT CREATE ANY TABLE TO "APP";
GRANT CREATE ANY TRIGGER TO "APP";
GRANT CREATE ANY VIEW TO "APP";
GRANT CREATE PROCEDURE TO "APP";
GRANT CREATE PUBLIC SYNONYM TO "APP";
GRANT CREATE TRIGGER TO "APP";
GRANT CREATE VIEW TO "APP";
GRANT DELETE ANY TABLE TO "APP";
GRANT DROP ANY INDEX TO "APP";
GRANT DROP ANY SEQUENCE TO "APP";
GRANT DROP ANY TABLE TO "APP";
GRANT DROP ANY TRIGGER TO "APP";
GRANT DROP ANY VIEW TO "APP";
GRANT INSERT ANY TABLE TO "APP";
GRANT QUERY REWRITE TO "APP";
GRANT SELECT ANY TABLE TO "APP";
GRANT UNLIMITED TABLESPACE TO "APP";

Ahora el usuario ya puede conectarse a la base de datos y comenzar a trabajar sobre su nuevo esquema Oracle.

Si tienes el usuario de sistema con el que se ha instalado la base de datos Oracle puedes entrar en SQL plus como usuario DBA y sin introducir ninguna contraseña de la siguiente manera:

1. Entra en el sistema con este usuario.
2. Desde la linea de comandos, entra en SQLplus poniendo:

> sqlplus "/as sysdba"

Si has necesitado entrar así porque no recordabas la contraseña de algún usuario, ya puedes modificarla/s para poder utilizarlo/s después:

SQL> alter user nombre_usuario identified by nuevo_password;

Te puede pasar que haya más de una Base de datos Oracle instalada en el servidor, por lo que tendrás que asegurarte de que las variables de entorno del usuario de Oracle están apuntando a la base de datos que te interesa.

Para comprobar que has entrado en la base de datos correcta antes de tocar nada puedes ejecutar esta sentencia SQL:

SQL> select name from v$database;

Libros de Administración Oracle (DBA) y PL/SQL

¿Quieres profundizar más en PL/SQL de Oracle o en administración de bases de datos Oracle? Puedes hacerlo consultando alguno de estos libros de Oracle.

La instrucción grant se utiliza para conceder determinados permisos genéricos o bien permisos sobre objetos a usuarios de bases de datos Oracle.

La sintaxis de GRANT para conceder permisos genéricos es la siguiente:

GRANT [privilegios_de_sistema | roles] 
TO [usuarios | roles |PUBLIC] {WITH GRANT OPTION } 

La sintaxis de GRANT para conceder  premisos sobre objetos es la siguiente:

GRANT [ALL {PRIVILEGES} | SELECT | INSERT | UPDATE | DELETE] ON objeto 
TO [usuario | rol | PUBLIC] {WITH GRANT OPTION} 

La sintaxis de GRANT es muy sencilla, y los privilegios los puede conceder el usuario propietario de los objetos, o un usuario con privilegios de concesión de permisos sobre objetos que no son suyos (DBA's).

Lo que quería comentar es la utilización de la opción de grant WITH GRANT OPTION, que permite que el usuario al que le han concedido permisos pueda a su vez concederlos a otros usuarios.

Ejemplo de GRANT WITH GRANT OPTION

Mostraré la utilidad de esta opción con un ejemplo:

Imaginemos que tenemos un usuario 'U_VISTA', que crea una vista con una consulta que consulta información de un objeto de otro usuario 'U_DATOS'. Hasta aquí es sencillo, ya que con un GRANT del usuario 'U_DATOS' al usuario 'U_VISTA' sobre esos objetos el tema está solucionado. U_DATOS:

SQL> GRANT SELECT ON TABLA TO U_VISTA;

El problema vendría si tenemos un tercer usuario 'U_CONSULTA', que tiene que utilizar esta vista. Se podría pensar que con dar permisos de acceso a este usuario a la consulta por parte de 'U_VISTA', y permisos de acceso a los objetos que consulta la vista por parte de 'U_DATOS' ya estaría todo bien: U_VISTA:

SQL> GRANT SELECT ON VISTA TO U_CONSULTA;

U_DATOS:

SQL> GRANT SELECT ON TABLA TO U_CONSULTA;

Pues no, no es suficiente porque para acceder a estos datos a través de la vista ha de ser el propio propietario de la vista quien conceda los permisos a un tercero. Digamos que para la concesión de privilegios no se cumple la propiedad transitiva.

Para que 'U_CONSULTA' pueda trabajar sobre la VISTA sin que la base de datos le devuelva un error ORA-00942, el propietario de los objetos (o un usuario DBA) ha de conceder privilegios sobre esos objetos al otro usuario, pero con permisos para que este pueda a su vez concederlos a otros usuarios (grant with grant option):

U_DATOS:

SQL> GRANT SELECT ON TABLA TO U_VISTA WITH GRANT OPTION;

U_VISTA:

SQL> GRANT SELECT ON U_DATOS.TABLA TO U_CONSULTA;
SQL> GRANT SELECT ON VISTA TO U_CONSULTA;

U_CONSULTA:

SQL> SELECT * FROM VISTA;

Y eso es todo, U_CONSULTA ya puede consultar los datos de la vista gracias a la opción WITH GRANT OPTION del GRANT.

Coméntalo en el foro

Libros de Administración Oracle (DBA) y PL/SQL

¿Quieres profundizar más en PL/SQL de Oracle o en administración de bases de datos Oracle? Puedes hacerlo consultando alguno de estos libros de Oracle.

Este artículo para DBA's de Oracle explica como configurar los servicios de conexión heterogeneous de Oracle para poder visualizar bases de datos SQL Server desde un esquema Oracle, como si fueran objetos propios de Oracle.

En versiones antiguas de Oracle, esta conectividad se podía realizar a través de “Gateways” que se licenciaban de manera independiente del servidor Oracle, pero la posibilidad de realizar lo mismo en sentido contrario a través de SQL Server, posibilitó la aparición de los “Heterogeneous Services” de manera gratuita en Oracle.

Para poder realizar la configuración es necesario contar con los objetos necesarios del catálogo. Por defecto están instalados, pero en determinadas instalaciones puede ser necesario realizarlo manualmente. Para ello, ejecutar como SYS el fichero caths.sql del directorio %ORACLE_HOME%/rdbms/admin. Después, el DBA de Oracle sólo ha de seguir los siguientes pasos:

• Crear un conector ODBC de SQL Server (System DSN) en el administrador de ODBC de Microsoft (por ejemplo, “sqlcon”)
   
• Ajuste del fichero de inicialización de Heterogeneous Services
  Este fichero reside en ORACLE_HOME/HS/ADMIN, y su nombre depende del SID que se asigne al servicio. El nombre usado tipicamente es: hsodbc, de manera que el fichero se llamaría: inithsodbc.ora. Este fichero debe contener como mínimo los siguientes parámetros:

# Nombre de la conexión ODBC
HS_FDS_CONNECT_INFO = sqlmis
HS_FDS_TRACE_LEVEL = 0
HS_OPEN_CURSORS = 300

• Configuración del fichero TNSNAMES.ORA
  Se debe añadir la siguiente entrada:

hsodbc =
    (DESCRIPTION =
       (ADDRESS_LIST =
       (ADDRESS = (PROTOCOL = TCP)(HOST = <IP_SERVIDOR> ) (PORT = 1521))
    )
    (CONNECT_DATA = (SID = hsodbc))
    (HS=OK)
    )

• Configuración del fichero del Listener
  LISTENER.ORA: Se debe añadir a la SID_List el siguiente descriptor:

(SID_DESC =
    (SID_NAME = hsodbc)
    (ORACLE_HOME = C:\oracle\ora92)    # el ORACLE_HOME correspondiente
    (PROGRAM = hsodbc )
)

• Reinicio del listener
  En los servicios del servidor reiniciar el servicio del listener.
   
• Conectarse con un SQL*Plus a la instancia ORACLE, y crear un database link contra el SQL Server a través de HS:

SQL> create database link hsodbc connect to "usuario" identified by "password" using 'hsodbc'

El usuario y el password deben ser los usuarios de conexión a la BBDD de SQL Server. 
Por ejemplo, si el usuario es el “sa” los objetos a los que se llegará serán los objetos de la BBDD de sistema “master”.

Una vez configurado se puede acceder desde un esquema ORACLE a las tablas (objetos en general) de una BBDD SQL Server.
A modo de ejemplo, la sintaxis necesaria para realizar una simple join entre 2 tablas una Oracle y la otra SQL Server sería:

SELECT e.name, d.dept
FROM emp e, dept@hsodbc d
where e.id_dept=d.id_dept;

Oscar Paredes

IT Manager
Oracle DBA

oscar.paredes@dataprix.com

A partir de la versión 11g Oracle permite la creación de índices llamados invisibles que permiten llevar realizar cosas realmente interesantes.

Esta invisibilidad se refiere a que el optimizador no tiene en cuenta la existencia de estos índices para la generación de los planes de ejecución.

Esto puede resultar muy interesante en bases de datos en Producción por ejemplo para:

• En el caso de probar nuevos índices sin afectar a las sentencias SQL de las aplicaciones que atacan a la base de datos, puesto que se pueden activar/desactivar de manera muy rápida.
• En el caso de querer probar ciertas sentencias SQL de aplicaciones sin índice sin tener que borrar el índice y perder tiempo recreándolo..

A partir de la versión 11g Oracle permite la creación de índices llamados invisibles que permiten llevar realizar cosas realmente interesantes.

Esta invisibilidad se refiere a que el optimizador no tiene en cuenta la existencia de estos índices para la generación de los planes de ejecución.

Esto puede resultar muy interesante en bases de datos en Producción por ejemplo para:

• En el caso de probar nuevos índices sin afectar a las sentencias SQL de las aplicaciones que atacan a la base de datos, puesto que se pueden activar/desactivar de manera muy rápida.
• En el caso de querer probar ciertas sentencias SQL de aplicaciones sin índice sin tener que borrar el índice y perder tiempo recreandolo.

Mientras un índice permanece invisible se va actualizando con las sentencias DDL (insert, update, ...), de manera que, los hace perfectos para este tipo de pruebas.

Un índice invisible se puede crear invisible o se puede alterar para que sea visible o invisible. Se puede consultar en que estado está un índice mediante la columna "visibility" de la vista DBA_INDEXES.

Un nuevo parámetro de inicialización controla la visibilidad o no de los índices invisibles "optimizer_use_invisible_indexes". Es decir, que aunque un índice sea invisible, si esta parámetro tiene el valor TRUE, el optimizador los ve y los puede usar sin problemas. Por lo que, recomiendo dejarlo siempre con el valor por defecto FALSE.
 

Ejemplo:

1) Verificamos el valor del parámetro que controla la visibilidad de los índices invisibles:

SQL> show parameter optimizer_use_invisible_indexes

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
optimizer_use_invisible_indexes boolean FALSE

2) Creamos una tabla de ejemplo con un indice visible:

SQL> create table prueba as select * from dba_tables;

SQL> create index i_prueba on prueba (table_name);

3) Consultamos su visibilidad

SQL> select index_name , visibility from dba_indexes where index_name = 'I_PRUEBA';

INDEX_NAME VISIBILITY
------------------------------ ------------------------------ ---------
I_PRUEBA VISIBLE

4) Consultamos su plan de ejecución forzando el uso del índice: Al ser visible el índice lo usará sin problemas.

SQL> explain plan
2> select /*+ index(prueba i_prueba) */ * from t where table_name

Explained.

SQL> select * from table(DBMS_XPLAN.DISPLAY);
Plan hash value: 2609566873

----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 18 | 1 (0)| 00:00:02 |
|* 1 | INDEX UNIQUE SCAN |I_PRUEBA | 1 | 18 | 1 (0)| 00:00:02 |
----------------------------------------------------------------------------------------

5) Hacemos invisible el índice

SQL> alter index I_PRUEBA invisible;

6) Consultamos su plan de ejecución forzando el uso del índice con un HINT: El optimizador no tiene en cuenta el índice invisible.

----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 93 | 1008 | 31 (0)| 00:00:20 |
|* 1 | TABLE ACCESS FULL | T | 93 | 1008 | 31 (0)| 00:00:20 |
----------------------------------------------------------------------------------------

Oscar Paredes

IT Manager
Oracle DBA

oscar.paredes@dataprix.com

Alguien sabe si en bases de datos Oracle hay alguna manera de limitar el número de conexiones por usuario, o el número de cursores abiertos por conexión de un usuario?

La cláusula loggin/nologging añadida cuando creamos una tabla, índice, tablespace... determina si se crea registro de la sentencia en los redo log y su correcta restauración desde backup. Tiene guasa porque si creamos una tabla con opción nologging efectivamente no se crea registro pero de alguna manera esta si se tiene en cuenta en el diccionario de datos.

Ejemplo cronológico con malas consecuencias:
06:00 Hacemos backup con rman
09:00 Creamos tabla XXX (nologging)
09:45 Se pierde el datafile de la tabla
09:53 Recuperamos la base de datos (desde la copia, o desde la copia y archive)

Al terminar la recuperación los bloques correspondientes a la tabla/índice son marcados como corruptos y cuando intentemos acceder obtendremos un error como el siguiente:
ORA-01578: bloque de datos ORACLE corrupto (archivo número 43, bloque número 222806)
ORA-01110: archivo de datos 43: '/db/PROD/idatafiles/INDX3_20.dbf'
ORA-26040: Se ha cargado el bloque de datos utilizando la opción NOLOGGING

Casos como el anterior dan que pensar y debemos recapitular para tener más claro cuando hacerlo y cuando no. Debemos tener en cuenta:

• Recuperación/Standby
  -Si la base de datos trabaja en modo archivelog. Si no es el caso tiene menos sentido usar la opción logging y por temas de rendimiento o volumen nos conviene más "probar suerte" y hacerlo con nologging.
  -Si las copias las hacemos con rman. Si trabajamos en modo archivelog y usarmos rman para hacer backups lo más lógico sería hacerlo todo con la opción logging para reducir la perdida de datos al mínimo.
  -Si tenemos una base de datos standby sincronizada mediante aplicación de archive logs. Es un caso como el anterior pero con más razón. Lo más lógico será hacer logging para que los objetos también se creen en el servidor en standby, tenemos que pensar que aquí podemos partir de una copia rman específica de hace tiempo y seguramente no estamos restaurandola cada semana ni cada mes.
  -Velocidad de recuperación. En la creación de índices podemos precindir del logging pero debemos considerar que luego puede tocar recrearlos en la base de datos restaurada.
   
• Rendimiento
  -El tiempo necesario para la creación de la tabla/índice. Obviamente si no dejamos log ganamos en velocidad pero aumentamos el riesgo.
  -Lo asumible que es la pérdida de esa tabla índice mientras no sea recuperable. Si es una tabla que puede sobrar o prescindible (tabla de traza de cualquier aplicación) pues no pasa nada.

Con todo lo anterior y alguna cosa más que se queda en el tintero puede que nos decidamos a forzar el logging y quitarle ese poder de decisión al que ejecuta la sentencia de creación del objeto (más vale prevenir que curar, que luego vienen los llantos...). Aunque quizás no esté en sus manos, puede usar un ERP que es el intermediario en la creación de objetos de la base de datos y se los crea sin poder cambiar esa opción.

Mucho cuidado!! No vaya a ser que montemos una base de datos en standby y en el momento de la verdad cuando la vayamos a usar no tenga la mitad de las tablas.

Siguiendo con el post anterior creo necesario comentar que existen otros tipos de bloqueo que se producen por un diseño conflictivo que se une a las peculiaridades de oracle.

Dejo primero la traza de ejemplo:

*** ACTION NAME:() 2011-04-21 14:08:01.227
*** MODULE NAME:(MiPrograma.exe) 2011-04-21 14:08:01.227
*** SERVICE NAME:(SYS$USERS) 2011-04-21 14:08:01.227
*** CLIENT ID:() 2011-04-21 14:08:01.227
*** SESSION ID:(1636.58026) 2011-04-21 14:08:01.227
DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TM-0001f1b8-00000000        99    1636    SX   SSX       92    1461    SX   SSX
TM-0001f1b8-00000000        92    1461    SX   SSX       99    1636    SX   SSX
session 1636: DID 0001-0063-0003159E    session 1461: DID 0001-005C-000375B1
session 1461: DID 0001-005C-000375B1    session 1636: DID 0001-0063-0003159E
Rows waited on:
Session 1461: no row
Session 1636: no row

Aquí lo que primero nos llama la atención es que ya tenemos registros bloqueados como se ve abajo. Además el tipo de bloqueo es distinto (antes X o modo exclusivo, ahora SX o exclusivo compartido?). En la documentación podemos ver más de los tipos.

Aquí el tema está en que deadlocks con bloqueo tipo SX se producen al manipular tablas con claves foraneas donde el campo no está indexado (en la fk, no la pk de la tabla primaria) y estamos intendo hacer update/delete sobre la tabla principal. Por decirlo de alguna manera oracle necesita mantener la integridad referencial y consulta la hija para que se siga cumpliendo.

Solución en este caso? Crear siempre la clave primaria en la tabla principal, un indice y una foregin key en la tabla secundaria. Nada más...

De vez en cuando puede pasar que dos sesiones que se pisen se bloqueen al intentar hacer cambios en los mismos datos (a nivel de registro o a nivel de tabla). En sistemas no concurrentes y/o bien diseñados no tiene por que pasar ya que las aplicaciones suelen estar mínimamente pensadas para evitarlo; o en todo caso en pruebas pre-producción ya se detecta y se corrige. El caso es que incluso aunque se planee evitarlos se pueden producir. En la mayoría de casos se resuelven solitos al acabar de realizar los cambios la sesión bloqueante, incluso ni nos daremos cuenta. En otros casos más infrecuentes se producen bloqueos circulares irresolubles, “deadlocks”, donde se acaba haciendo rollback de una transacción y se genera una entrada en el fichero de alerta:

ORA-00060: Deadlock detected. More info in file /opt/oracle/admin/XXX/udump/XXX_ora_28205.trc

Si consultamos el fichero de traza encontraremos información más detallada: sesiones involucradas, objeto, registro, consulta que lo provoca, etc... Aquí incluyo algunas partes de un fichero de ejemplo. En la primera parte del fichero vemos que sesión sufrirá el rollback(marcada en negrita) y más abajo vemos el bloqueo circular (donde la 1706 espera a la 1693 y viceversa):

...
*** ACTION NAME:() 2011-01-27 08:07:36.110
*** MODULE NAME:(Servicio.exe) 2011-01-27 08:07:36.110
*** SERVICE NAME:(SYS$USERS) 2011-01-27 08:07:36.110
*** SESSION ID:(1693.30703) 2011-01-27 08:07:36.110
DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TX-00090022-00173f07        82    1693     X             21    1706           X
TX-00030014-0013a2dd        21    1706     X             82    1693           X
Rows waited on:
Session 1706: obj - rowid = 0000CF1C - AAAM8cAA5AAACX+AAF
  (dictionary objn - 53020, file - 57, block - 9726, slot - 5)
Session 1693: obj - rowid = 0000CF1C - AAAM8cAA5AAACX+AAI
  (dictionary objn - 53020, file - 57, block - 9726, slot - 8)
…

Con esta información también podemos saber exactamente que objetos y registro/s es el origen de la disputa. Si es algo que se repite de forma cíclica podemos ayudar al responsable de la aplicación dandole más datos (además de las consultas) para que lo resuelva. Para saber que registro de que tabla:

1. Convertimos a decimal el obj que se indica al final en hex (0000CF1C->53020)
2. Obtenemos el nombre del objeto del diccionario de datos:
        SELECT owner, object_name, object_type FROM dba_objects WHERE object_id = 53020;
3. Consultamos la tabla obtenida buscando el registro por el rowid:
       SELECT * FROM tabla WHERE rowid=’AAAM8cAA5AAACX+AAF’’

Un poco más abajo del fichero también se puede ver que consultas han provocado el deadlock y otra información como la cantidad de “waits” de la session en cuestión etc...

Todo esto me hace gracia comentarlo porque a veces desarrolladores mal acostumbrados nos piden que comprobemos si existen bloqueos entre usuarios porque tienen algo que no va tan rápido como siempre. En contraposición también tenemos a usuarios muy impacientes, que cierran a saco sus aplicaciones... Si a ti te pillan en horario, te vienen a preguntar, lo miras sin renegar, miras si existe y si la sessión bloqueante sigue trabajando... Si es el caso y hay que esperar, ¿que le dices? La primera vez le explicas de que va el tema, la segunda vez se lo recuerdas y la tercera que se vaya a tomar un café...

Al administrar nuestra base de datos tenemos que lidiar a veces con aplicaciones de terceros(ERPs, etc...) o desarrolladas dentro de la empresa que a veces pueden tener mal planteados algunos procesos o por el motivo que sea traten la base de datos como si fuera exclusivamente suya. Voy a mostraros un ejemplo:

Entorno:
-servidor con dos puntos de montaje. El del sistema operativo donde también residen los archivos de datos de la base de datos y un disco secundario donde tenemos los archivos de copia rman más los archivelogs.
-base de datos Oracle10g funcionando en modo archivelog.
-política de retención de copias de 3 días y 60 archive logs al día de media.

Sintoma:
-Nos quedamos sin espacio donde metemos los backups de la base de datos debido al crecimiento de la generación de más archivelogs de la cuenta.

Detectar la causa:
Si tenemos bien dimensionada la política de retención de backups pero de repente en nuestra base de datos se estan generando más archivelogs de la cuenta puede ser debido a una acividad "extra-ordinaria" en la base de datos. Para detectarla primero podemos consultar el número de ficheros que se generan por hora consultando la tabla v$log_history:

select to_char(FIRST_TIME,'DY, DD-MON-YYYY') day,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'00',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'00',1,0))) d_0,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'01',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'01',1,0))) d_1,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'02',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'02',1,0))) d_2,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'03',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'03',1,0))) d_3,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'04',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'04',1,0))) d_4,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'05',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'05',1,0))) d_5,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'06',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'06',1,0))) d_6,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'07',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'07',1,0))) d_7,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'08',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'08',1,0))) d_5,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'09',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'09',1,0))) d_9,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'10',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'10',1,0))) d_10,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'11',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'11',1,0))) d_11,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'12',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'12',1,0))) d_12,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'13',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'13',1,0))) d_13,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'14',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'14',1,0))) d_14,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'15',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'15',1,0))) d_15,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'16',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'16',1,0))) d_16,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'17',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'17',1,0))) d_17,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'18',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'18',1,0))) d_18,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'19',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'19',1,0))) d_19,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'20',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'20',1,0))) d_20,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'21',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'21',1,0))) d_21,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'22',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'22',1,0))) d_22,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'23',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'23',1,0))) d_23,
       count(trunc(FIRST_TIME)) Total
 from v$log_history
 group by to_char(FIRST_TIME,'DY, DD-MON-YYYY')
 order by to_date(substr(to_char(FIRST_TIME,'DY, DD-MON-YYYY'),5,15) )
 

(RESULTADO DE EJEMPLO)

Con esto ya vemos que hay un pico el lunes 1 de julio desde horas "intempestivas" hasta las 10:00 de la mañana. Si queremos informarnos más antes de hablar con los responsables podemos consultar la v$sqlarea para detectar consultar repetitivas y pesadas para conocer el sql, número de ejecucuciones, coste , etc... Una consulta ejemplo seria la siguiente:

SELECT sql_text "Sql",
         executions "Ejecuciones",       
         ceil(cpu_time/greatest(executions,1)) "Avg Cpu",
         ceil(elapsed_time/greatest(executions,1)) "Avg Disk",
         ceil(elapsed_time/greatest(executions,1)) "Avg Time"
  FROM v$sqlarea
  ORDER BY ceil(elapsed_time/greatest(executions,1)) desc,
           ceil(cpu_time/greatest(executions,1)) desc,
           ceil(disk_reads/greatest(executions,1)) desc;

De esta manera conoces la tabla que se está "populando" de forma masiva y puedes preguntar al desarrollador cubriendote la espalda de antemano ya que no siempre le conocemos, le tenemos confianza o simplemente sabemos que nos acabará ocultando lo que ha hecho... o peor aún NO SABE LO QUE ESTÁ HACIENDO!!
 

Normalmente para analizar lo que pasa unas horas antes bastaría con consultar los datos históricos del Enterprise Manager pero no tenemos datos como el detalle de sesiones activas (si la cantidad total) o el estado o programa de cada una de ellas. También consultar las instantáneas en la consola web pero el problema sigue siendo el mismo, la falta de detalle. Pero no todo es insalvable y podemos en tres pasos completar esta información con algo más de detalle.

Paso 1: Crear una tabla con los datos que necesitaremos con un campo fecha.

Paso 2: Crear un procedimiento para alimentar la tabla con datos.

Paso 3: Crear un job con el usuario indicado para acumular datos.

Esta técnica puede ser “cutre” pero muchas veces sirve para analizar con más detalle y a nuestro gusto ciertas estadísticas que son visibles mediante vistas v$ que muestran el estado actual de la base de datos y que directamente no muestran un estado anterior en el tiempo.

Ejemplo para ver que está pasando con la apertura de conexiones y quién las hace:

Os podéis encontrar que en vuestra base de datos que tengáis problemas causados por la mala gestión de conexiones o choque entre aplicaciones que derivan en miles de conexiones abiertas. A esto se le puede sumar que esto ocurre fuera de horario y cuando sucede estamos normalmente en casa, sentados en el sofá viendo la tele.

Creación de la tabla:

create table AUDITORIA_SESIONES AS

(

select s.USERNAME, s.MACHINE, s.STATUS, count(*) as SESIONES, sysdate as FECHA
 from v$session s
group by s.USERNAME, s.MACHINE, s.STATUS

);

Creación del procedimiento:

create or replace procedure AUDITAR_SESIONES AS

begin

insert into AUDITORIA_SESIONES

(

select s.USERNAME, s.MACHINE, s.STATUS, count(*) as SESIONES, sysdate as FECHA
 from v$session s
group by s.USERNAME, s.MACHINE, s.STATUS

)

commit;

end;

En este caso se debe tener en cuenta que solo puede hacerse con el usuario sys y programar el job con su usuario. Ahora ya solo falta crear el job y consultar los datos cuando los necesitemos.

Ahora, ya depende de cada uno el uso que se le quiera dar. Esta manera de proceder nos puede sacar de un apurillo pero no es cuestión de llenar de basurilla la base de datos.

Pasos que sigue Oracle para procesar una consulta:

1) Validación Sintáctica
2) Validación Semántica
3) Optimización
4) Generación del QEP (Query Execution Plan)
5) Ejecución del QEP (Query Execution Plan)

En algunos entornos nos podemos encontrar con aplicaciones que realizan ciertas consultas (y digo consultas) de forma muy reetiva de forma continua. Cuando el catálogo es muy amplio, continuo e inevitable debemos tener en cuenta dos parámetros de inicialización de la base de datos: open_cursors y session_cached_cursors.

Open_cursors nos permite establecer el límite de cursores por sesión y su seteo es muy directo. Si se necesitan 1000 y no hay nada que optimizar pues 1000 pondremos. En cambio Session_cached_cursors es algo más complejo y requiere analizarse en base al número máximo de cursores (open_cursors) y la cantidad actual de cursores que se mantienen en "cache" actualmente.

Consulta:

select
'session_cached_cursors'  parameter,
lpad(value, 5)  value,
decode(value, 0, '  n/a', to_char(100 * used / value, '990') || '%')  usage
from
( select
    max(s.value)  used
  from
    sys.v_$statname  n,
    sys.v_$sesstat  s
  where
    n.name = 'session cursor cache count' and
    s.statistic# = n.statistic#
),
( select
    value
  from
    sys.v_$parameter
  where
    name = 'session_cached_cursors'
)
union all
select
'open_cursors',
lpad(value, 5),
to_char(100 * used / value,  '990') || '%'
from
( select
    max(sum(s.value))  used
  from
    sys.v_$statname  n,
    sys.v_$sesstat  s
  where
    n.name in ('opened cursors current', 'session cursor cache count') and
    s.statistic# = n.statistic#
  group by
    s.sid
),
( select
    value
  from
    sys.v_$parameter
  where
    name = 'open_cursors'
) ;

Ejemplo:
PARAMETER              VALUE           USAGE
---------------------- --------------- -----
session_cached_cursors   100            100%
open_cursors             300             57%

Si con el valor actual observamos que el uso es del 100% podemos incrementar de forma moderada el parámetro session_cached_cursors y observar el resultado. Siempre que este por debajo estamos reutilizando todos los que son posibles y estamos optimizando al evitar el "hard parse" de la consulta reduciendo el uso de cpu. Pero cuidado, tampoco vale igualar este parámetro al número máximo de cursores ya que no es oro todo lo que reluce y cuanto más grande sea este valor mayor memoria estamos consumiendo y en servidores cortitos de harware puede pasar factura por otro sitio.

Por el motivo que sea nos podemos encontrar que en nuestra base de datos Oracle tenemos muchos tablespace y para hacer un poquito de limpieza decidamos resumir los que estén duplicados. Entoces nos dirigimos a OEM y vemos una maravillosa liista de 50 tablespace con nombres sin sentido, algunos vacíos y otros por triplicado por que han llegado al tamaño que consideran máximo (en lugar de tres datafiles) etc etc... Llega el momento de ponerse manos a la obra.

Recordar que para ver el contenido de un tablespace nos podemos dirigir a Oracle Enterprise Manager y en la sección Administración>tablespaces marcar el que queramos, seleccionar en el desplegable Mostrar Dependencias y luego pulsando Ir. Luego veremos una segunda pestaña Dependientes. Ahí se muestran todos los objetos dependientes del tablespace (contenidos, vamos).

Ejemplo a) Solo índices

Nos encontramos que tenemos tres tablespaces IDX1, IDX2 e IDX3 que contiene índices creados por el mismo usuario APL y que son de la misma aplicación; lo que queremos hacer es resumirlos en un único tablespace IDX1. Para hacerlo podemos:

a)Hacer un export/import
b)Modificar indice por índice con la siguiente sql:
ALTER INDEX [indice] REBUILD TABLESPACE [nuevo tablespace]

La opción b) es una buena manera de hacerlo ya que aunque se tarde más el usuario seguro que no se dá ni cuenta.

Ejemplo b) Tablas e índices

Tenemos dos tablespace DAT1 y DAT2, y queremos mover las tablas de DAT2 a DAT1. Opciones:

a)Hacer un export/import
b)Modificar tabla por tabla (más sus índices*).
ALTER TABLE [tabla] MOVE TABLESPACE [nuevo tbspace];
ALTER INDEX [indice] REBUILD;

*En el caso de las tablas, al moverlas de un tablespace a otro hay que reconstruir los índices ya que quedan en estado “unusable”. Cualquier inserción posterior al traslado de tablespace sin la reconstrucción del indice producirá un error ORA.

Hola!

Puede alguien explicarme brevemente la utilidad de los global_names? Por lo que he visto existe un parámetro para activar o desactivar su uso. También existe una variable donde se guarda el nombre global de la base de datos actual.

¿Que se puede ver afectado si los desactivas?

¿Que puede verse afectado si cambias el nombre actual?

Puede suceder que después de instalar Oracle o configurar una nueva base de datos nos demos cuenta de que el juego de carácteres elegido durante la instalación no es el correcto. Lo que se nos puede ocurrir en casos como este es borrar la base de datos y reconfigurarla o cosas peores... Pero no hace falta. Podemos cambiar el juego de carácteres parando la base de datos, levantandola de forma restrictiva, cambiando la configuración y reiniciado la base de datos.  Howto:

--Primero nos conectamos con la base de datos
$ sqlplus sys/pwd@prod as sysdba

--Paramos la base de datos
SQL>SHUTDOWN IMMEDIATE;

--Levantamos de forma restrictiva*
SQL>STARTUP MOUNT;
SQL>ALTER SYSTEM ENABLE RESTRICTED SESSION;
SQL>ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
SQL>ALTER DATABASE OPEN;

--Cambiamos el mapa de carácteres
SQL>ALTER DATABASE CHARACTER SET <nuevo mapa de carácteres>;

--Reiniciamos la base de datos y yata
SQL>SHUTDOWN IMMEDIATE;
SQL>STARTUP;

Para comprobar que los cambios han surtido efecto podemos consultar la vista v$nls_parameters y comprobar el valor de nls_characterset. Debemos saber que según el cambio de codificación que hagamos podemos perder datos (si es que los hay)  dependiendo del cambio.

*También es útil saber que levantar la base de datos en modo restrictivo es muy útil para realizar tareas de mantenimiento de la base de datos que se pueden hacer más rápido cuando no hay actividad de usuario (como puede ser reconstrucción de índices, reducción de segmentos, etc).

Una base de datos Oracle en Standby es una copia exacta de una base de datos operativa en un servidor remoto, usada como backup, como copia para consulta, recuperación de desastres, etc.

Una base de datos en modo Standby es algo más que un backup normal ya que se puede poner en producción en caso de desastre en un tiempo menor que si tuvieramos que restaurar una copia (ya sea desde rman o un simple export).

Restaurar una copia desde fichero tarda tiempo, y durante este periodo el sistema no está disponible. Con una base de datos adicional en modo standby no hay nada (o casi nada que restaurar) en caso de desastre. En cuestión de minutos se hace el cambio permitiendo continuidad en el servicio. No nos ofrece las ventajas de rendimiento de un cluster o la seguridad del espejo pero la relación de costes de tiempo y licencia versus ventajas me parece correcta.

Desde un punto de vista global:

• Disponemos de una copia de la base de datos de forma remota, que podemos contabilizar como segundo juego de copias.
• A diferencia de un simple backup, la copia se mantiene viva y los datos son actualizados con mayor frecuencia.
• En caso de desastre la podemos usar en cuestión de minutos sin esperar a restaurar un backup entero, ya sea lógico(export) o físico(rman).
• Sirve como entorno de pruebas más real para la prueba de parches y estimación de tiempos. El volumen de datos es idéntico.
• Tengo entendido que una base de datos en standby se puede usar hasta 10 dias al año sin coste de licencia (aunque mira por donde Microsoft te deja 30 dias... )

Desde un punto de vista técnico:

• Los cambios en la base de datos principal se captura en los archivos de redo log.
• Los archivos de redo no son permanentes, son sobreescritos de forma rotativa (en este estado aún no se copia al segundo servidor).
• Se hace una copia del redo log. La copia permanente se llama archive log.
• Los archive logs(copias de redo log) se transfieren al servidor en standby. En sistemas linux por ejemplo podemos hacerlo mediante rsync.
• Se aplican los archive logs transferidos a la base de datos en standby quedando actualizada.

A nivel global los pasos a seguir para montar el chiringuito pueden ser los siguientes:

1. Configurar la base de datos principal para que funcione en modo archivelog.
2. Preparar un script para hacer una copia en caliente (usando rman).
3. Crear un fichero de control standby (control file) en la base de datos principal.
4. Copiarlo todo (fichero de configuración, de control y copia rman) en el segundo servidor (donde montamos la base de datos en standby).
5. Reconfigurar rutas (usando DB_FILE_NAME_CONVERT en init.ora o a manita).
6. Iniciar la segunda base de datos en modo mount standby database.
7. Restaurar datos (recover database).
8. Sincronizar de forma periódica(cron) transportando (rsync?) y aplicando los archive logs.

En otro post intentaré entrar en más detalle con un ejemplo... y las utilidades que le podemos dar.

El modo archivelog de una base de datos Oracle protege contra la pérdida de datos cuando se produce un fallo en el medio físico y es el primer paso para poder hacer copias de seguridad(en caliente!!) con rman. Para poner la base de datos en modo archivelog (sin usar la flash recovery area) debemos hacer básicamente dos cosas, añadir dos parámetros nuevos al fichero de configuración, reiniciar la base de datos y cambiar el modo trabajo a archivelog.

Como poner la base de datos Oracle 10g en modo archivelog

1. Editamos el init.ora para añadir los siguientes parámetros
   *.log_archive_dest='/ejemplo/backup/'
   *.log_archive_format='SID_%r_%t_%s'
    
2. Reiniciamos la base de datos para que coja los cambios y nos aseguramos.
   SQL> shutdown immediate
   Database closed.
   Database dismounted.
   ORACLE instance shut down.
   SQL> startup mount pfile='/ejemplo/pfile/init.ora
   ORACLE instance started.
    
   Total System Global Area  272629760 bytes
   Fixed Size                   788472 bytes
   Variable Size             103806984 bytes
   Database Buffers          167772160 bytes
   Redo Buffers                 262144 bytes
   Database mounted.
   SQL> alter database archivelog;
   Database altered.
   SQL> alter database open;
   Database altered.
   SQL> create spfile;
   SQL> shutdown immediate;
   Database closed.
   Database dismounted.
   ORACLE instance shut down.
   SQL> startup

Backups con RMAN
 
Una vez tenemos la base de datos funcionando en modo archivelog ya podemos plantearnos hacer los backups con rman. Para hacerlos basta con editar un script donde básicamnte hacemos la copia y mantenemos archives en base a cuantos copias queremos mantener y cada cuando ejecutaremos el script. Solo debemos tener cuidado y dimensionar correctamente el número de copias y archivelog que mantemos en base al espacio disponible en el disco. Para saber cuanto espacio necesitaremos podemos aplicar la siguiente formula, suponiendo que la copia sea diaria:

Espacio necesario = (num_backups_rman_mantenidos*tamanyo_backups_rman)+(media_num_redos_al_dia)*(dias_mantenidos).
 

Pasos para empezar a hacer backups:

1. Editamos el script de sistema para el lanzamiento (/ejemplo/scripts/rman.sh) :
   #!/bin/bash
   export ORACLE_HOME=/opt/oracle/product/10.2/db_1/
   export ORACLE_SID=SID
   /opt/oracle/product/10.2/db_1/bin/rman @/ejemplo/scripts/rman.sql > /backup/scripts/rman.log
    
2. Script sql que lanzaremos con el sh anterior (/ejemplo/scripts/rman.sql). No hace falta comentarlo porque es muy fácil leer lo que está haciendo en cada paso. Vereis también donde se indica la caducidad de los backups y los archives.

   connect target root/password@SID
   run {
   CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;

   CONFIGURE CONTROLFILE AUTOBACKUP ON;
   CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/ejemplo/backup/%F';

   CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/ejemplo/backup/%d_%Y%M%D%U';
   CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO COMPRESSED BACKUPSET;
   CONFIGURE MAXSETSIZE TO 8000M;

           backup database
           include current controlfile
           plus archivelog;

   CROSSCHECK BACKUP completed before 'sysdate - 4';       
   DELETE NOPROMPT OBSOLETE;                               
   DELETE NOPROMPT ARCHIVELOG UNTIL TIME "SYSDATE - 4";
   delete noprompt expired backup;
   delete noprompt expired archivelog all;
   report schema;
   }
   exit;
    

3. Programamos la tarea (crontab?) y listo!!
    

Para más información sobre los archive redo logs aquí.

En Oracle 10g existe una nueva funcionalidad para DBA's de Oracle para a la recuperación del espacio ocupado por una tabla sin necesidad de recrearla: SHRINK TABLE

Es habitual en versiones anteriores a la versión 10g el problema generado por el borrado de registros de una tabla y la generación de “huecos” a nivel de los bloques que componen esa tabla. A modo de ejemplo: es habitual para un DBA de Oracle la duda tras el borrado masivo de muchos registros de una tabla (o de todos) y la comprobación tras la eliminación de los registros de que la tabla ocupa exactamente lo mismo (misma HWM – High Water Mark).

Esta situación también se da en sistemas OLTP donde con el tiempo, y con las inserciones/borrados de registros en determinadas tablas, se van generando espacio no reutilizables por las nuevas inserciones por falta de espacio en los bloques incompletos, y a la larga caídas de rendimiento en los sistemas.

El método tradicional para recuperar este espacio consistía en realizar periódicamente export/import de la tabla en cuestión o recreación de la misma. Eso conllevaba una serie de problemas en la práctica como invalidación de índices, vistas, procedimientos…

En Oracle 10g surge la funcionalidad shrink table, que no sólo permite la recuperación de este espacio y recuperación del acceso óptimo a la misma, sino que permite realizarlo en 2 fases diferenciadas disminuyendo el tiempo de afectación a los usuarios.

Para que el DBA lleve a cabo esta recuperación de espacio puede seguir los siguientes pasos:

• Habilitación de movimientos de filas:

SQL> ALTER TABLE tabla ENABLE ROW MOVEMENT; 

• Movimiento de las filas:

SQL> ALTER TABLE tabla SHRINK SPACE COMPACT; 

• Reseteo HWM

SQL> ALTER TABLE tabla SHRINK SPACE; 

Tan solo durante el último punto del procedimiento existe bloqueo de tabla, pero sin duda el punto 2 es el más costoso en tiempo y se puede hacer totalmente online.

Oscar Paredes

IT Manager
Oracle DBA

oscar.paredes@dataprix.com

En éste post os adjunto varios documentos PDF relacionados con la seguridad y administración de Oracle. Por una parte, sabiendo que incluso el sistema de contraseñas en Oracle 11g es débil, os linko un documento PDF publicado por NGSSoftware y que trata de ayudar a proteger Oracle bajo los ataques de fuerza bruta contra las contraseñas y además donde presenta la herramienta de fuerza bruta: OraBrute.

Por otra parte os linko otro documento PDF dónde explica cómo proteger Oracle en tan sólo 20 minutos que, aunque no es un sistema para proteger completamente la base de datos, sirve como mínimo para tapar aquellos agujeros más evidentes.

Finalmente una pequeña herramienta para aquellos técnicos que viajan de empresa en empresa y puedan aprovecharla. Se llama WinSID y es un sencillo descubridor de instancias de Oracle pero que para su ejecución no es necesario tener el cliente de Oracle instalado. Permite determinar si un servidor remoto tiene una base de datos Oracle y, en caso de encontrarla, obtiene información de servicios, el SID, estadísticas del listener, conexiones establecidas... y además genera un TSNNAMES.ORA para la conexión encontrada. ¿Qué os parece?

A partir de la release 1 de Oracle 11g, Oracle ofrece a los DBA's la posibilidad de encriptar los tablespaces al completo, para proteger datos sensibles en su interior y accesibles desde Sistema Operativo. Es decir, el objetivo de esta nueva funcionalidad no es proteger datos sensibles de usuarios de la Base de Datos, sino de proteger la información de los datafiles de tablespaces.

Para explicar la utilidad de esta funcionalidad, lo mejor es explicar situaciones en las que sin esta funcionalidad nuestros datos serian vulnerables. Por ejemplo, en el caso de que el fichero de un backup físico de un tablespace de base de datos llegase a manos no deseadas, podría ver algunos datos “en claro” sin problemas. A modo de ejemplo, una simple edición del tablespace (o un simple “cat”) que contuviera la tabla empleados, nos mostraría los campos varchar2 en claro, pudiendo extraer datos sensibles (no os lo creéis, probadlo!).

Para esta funcionalidad, Oracle utiliza el TDE – Transparent Data Encryption, mediante la creación de una Oracle Wallet que se almacena en disco. Por defecto, en la localización $ORACLE_BASE/admin/$ORACLE_SID/wallet, pero es recomendable cambiar su localización mediante el uso del parámetro ENCRYPTION_WALLET_LOCATION en el sqlnet.ora.

Para la creación de esta Wallet:

ALTER SYSTEM SET ENCRYPTION KEY AUTHENTICATED BY "myPassword";

El tablespace encriptado se puede crear de la siguiente manera:

CREATE TABLESPACE seguro_tbs 

DATAFILE '/oradata/seguro_ts01.dbf.dbf' SIZE 1M

ENCRYPTION USING 'AES256'

DEFAULT STORAGE(ENCRYPT);

Si no se indica lo contrario, el algoritmo de encriptación usado es el AES256 (Advanced Encryption Standard), pero los siguientes algoritmos también están permitidos:

AES256, AES192, AES128 y 3DES168 

Al reiniciar la base de datos, deberemos abrir la wallet para poder consultar los datos de los tablespaces encriptados:

ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY "myPassword";

También podemos cerrarla en cualquier momento:

 ALTER SYSTEM SET WALLET CLOSE;

Si no abrimos una wallet, el resultado de cualquier query sobre alguna tabla de dicho tablespace es el error ORA-28365 “wallet is not open”.

La consulta de si un tablespace está encriptado o no, se puede realizar desde la misma vista dba_tablespaces:

SQL> SELECT tablespace_name, encrypted FROM dba_tablespaces;

 TABLESPACE_NAME                ENCRYPTED

------------------------------ ---------

SYSTEM                         NO

SYSAUX                         NO

UNDOTBS1                       NO

TEMP                           NO

SEGURO_TBS                     YES

Espero que os sea útil.

Oscar Paredes

IT Manager
Oracle DBA

oscar.paredes@dataprix.com

Cómo utilizar los sinónimos de Oracle para que un usuario pueda ver/utilizar objetos de un esquema que pertenezca a otro usuario. Es algo muy sencillo y realmente útil. Lo único que hay que hacer es crear un sinónimo para cada objeto que queramos 'compartir', y después asignar los permisos que interese al esquema que quiere acceder al objeto.

 -- Creación del sinónimo 

CREATE PUBLIC SYNONYM "MI_TABLA" FOR "YO"."MI_TABLA"; 

Utilizamos un sinónimo público para compartirlo para diferentes esquemas. La asignación de permisos sí que es específica para cada esquema que tenga que acceder al objeto

 -- Asignación de permisos para el usuario EL 

GRANT SELECT ON "YO"."MI_TABLA" TO "EL";
GRANT UPDATE ON "YO"."MI_TABLA" TO "EL";
GRANT INSERT ON "YO"."MI_TABLA" TO "EL";
GRANT DELETE ON "YO"."MI_TABLA" TO "EL"; 

-- Si se quiere dar acceso sólo de consulta a esta misma tabla para otro usuario, bastaría con hacer

GRANT SELECT ON "YO"."MI_TABLA" TO "ELLA"; 

Ahora "EL" y "ELLA" ya pueden trabajar sobre "MI_TABLA" cada uno con los permisos que el propietario de la tabla ha decidido