Anyone who usually look at AWR performance reports to analyze Oracle performance problems, often have their own reading process and approach to all data that shows this report, but I always missed a tool that make easier reading all data.

I've found! "AWR Formatter" developed by the DBA Tyler Muth facilitates this reading. Fantastic, you must try.

AWR Formatter is an extension of Chrome (file with. Crx) free once installed in the browser, each time you view an AWR report in HTML, gives you the option to format to help you see all your information. Once formatted text, HTML is seen in browser in different tabs. Highlight the following features that gives you the added format:

• Possibility of performing conversions dynamically KB / MB / GB / TB in the various indicators
• Possibility of searching the meaning of a pending event, parameter, etc ... (this is really useful)
• Formatted tables sortable, much like an Excel ...
• Ability to view the text of the SQL command's ...

Overall, nothing compared to the large standard html file ... wonderful. You can download it free from the following link:

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

A tab called "Observations", aims to give reading indications reading of the report, but it is a first approach, and of course, each DBA should follow it as their responsibility.

Hope you enjoy,

Oscar Paredes - 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?

It may happen that after you install or configure a new Oracle database we realize that the character set chosen during installation is not correct. What we may happen in cases like this is to delete the database and reconfigure it or worse ...But you do not. We can change the character set stopping the database, looking up strictly by changing the settings and restart the database. Howto:
 

- First we connect to the database 

$ sqlplus sys/pwd@prod as sysdba
 

- We stop the database 

SQL>SHUTDOWN IMMEDIATE;

- We raise strictly * 

SQL>STARTUP MOUNT;
SQL>ALTER SYSTEM ENABLE RESTRICTED SESSION;
SQL>ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
SQL>ALTER DATABASE OPEN;

- Change the character map 

SQL>ALTER DATABASE CHARACTER SET <new characters map>;

- Restart the database and yata 

SQL>SHUTDOWN IMMEDIATE;
SQL>STARTUP;

To verify that changes have taken effect can query the view v $ nls_parameters and check the value of nls_characterset. We know that according to changes in coding that we can lose data (if any) depending on the change.

* It is also useful to know to get up the database in restricted mode is very useful to carry out maintenance of the database that can be done faster when no user activity (such as rebuilding indexes, reduction of segments , etc).
 

An Oracle database in Standby is an exact copy of an operational database on a remote server, used as a backup, and copy for reference, disaster recovery, etc..

A database in the Standby mode is more than a normal backup because it can be put into production disaster in less time than if we had to restore a copy (either from a simple rman or export).Restore a copy from file takes time, and during this period the system is unavailable. With an additional database in standby mode there is nothing (or almost nothing to restore) in case of disaster. Within minutes, allowing the change is continuity of service. It offers the performance advantages of a cluster or safety of the mirror but the ratio of costs versus benefits and leave time seems right to me.

From a global perspective:

"We have a copy of the database remotely, we can count as a second set of copies. "Unlike a simple backup, the copy is kept alive and the data is updated more frequently. "In a disaster we can use in minutes, without waiting to restore a full backup, either logical (export) or physical (RMAN). -Serves as a more realistic test environment to test patches and estimated time. The volume of data is identical. "I understand that a standby database can use up to 10 days a year without license fee (though you look at where Microsoft leaves 30 days ...)

From a technical standpoint:

"Changes in the primary database are captured in the redo log files. Redo-files are not permanent, are overwritten by rotation (in this state is not yet copied to the second server). "It makes a copy of redo log. The permanent copy log file is called. "The archive logs (copies of redo log) is transferred to the standby server. In systems such as Linux can do this by rsync. -Apply the archive logs are transferred to the standby database will be updated.

Globally the steps to mount the kiosk can be:

1. Set the primary database to run in archivelog mode.

2. Prepare a script to make a hot copy (using rman).

3. Create a standby control file (control file) in the main database.

4. Copy everything (configuration file, and copy control rman) on the second server (where we mount the database in standby).

5. Reconfiguring routes (DB_FILE_NAME_CONVERT in init.ora or using small hand).

6. Starting the second database mount standby database mode.

7. Restore Data (recover database).

8. Synchronize periodically (cron) transporting (rsync?) And applying the archive logs.

In another post I will try to go into more detail with an example ...and utilities that you can give.

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?

Since the release 1 of Oracle 11g, Oracle provides the ability to encrypt tablespaces in full, to protect sensitive data inside and accessible from the OS. That is, the objective of this new functionality is not to protect sensitive data of users of the database, but to protect the information of the tablespace datafiles.

To explain the usefulness of this feature, it is best to explain situations in which our data without this functionality would be vulnerable. For example, in the case file of a physical backup of a database tablespace were to wrong hands, could see some data "clear" without problems. For example, a single edition of tablespace (or a simple "cat") containing the Employees table, we show clear varchar2 fields can extract sensitive data (you do not believe, try it!).

For this functionality, Oracle uses the TDE - Transparent Data Encryption, by creating an Oracle Wallet that is stored on disk.By default, the location $ ORACLE_BASE / admin / $ ORACLE_SID / wallet, but you should change your location by using the parameter in the sqlnet.ora ENCRYPTION_WALLET_LOCATION.

For the creation of the Wallet: 

ALTER SYSTEM SET ENCRYPTION KEY AUTHENTICATED BY "myPassword";

The encrypted tablespace can be created as follows:

CREATE TABLESPACE seguro_tbs 

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

ENCRYPTION USING 'AES256'

DEFAULT STORAGE(ENCRYPT);

Unless stated otherwise, the encryption algorithm used is AES256 (Advanced Encryption Standard), but these algorithms are also allowed:

AES256

AES192

AES128

3DES168

When you restart the database, we open the wallet for consulting data encrypted tablespaces:

 ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY "mypassword"; 

We can also close it at any time:

  ALTER SYSTEM SET WALLET CLOSE; 

If you don't open a wallet, the result of any query on any table that is the tablespace ORA-28365 error "is not open wallet."

Consulting if tablespace is encrypted or not can be made from the same view dba_tablespaces:

SQL> SELECT tablespace_name, encrypted FROM dba_tablespaces;

 TABLESPACE_NAME                ENCRYPTED

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

SYSTEM                         NO

SYSAUX                         NO

UNDOTBS1                       NO

TEMP                           NO

SEGURO_TBS                     YES

I hope you find it useful,

Oscar Paredes

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

Es bastante habitual si se trabaja con bases de datos que a menudo se tenga que realizar alguna tarea de creación o alteración de estructuras, análisis, recompilación, etc. sobre objetos de la base de datos. Para ello se suele crear un script con numerosas sentencias DDL, en las que la mayoría de las veces lo único que cambia es el nombre del objeto a tratar.

Crear sentencia Oracle SQL que genera sentencias Oracle

En estos casos puede ahorrarnos mucho trabajo la utilización del diccionario de la base de datos para construir estas sentencias dinámicamente. Pondremos como ejemplo la creación de un nuevo campo para almacenar la fecha de creación de los registros en todas las tablas de un esquema de una base de datos ORACLE. Para ello utilizaríamos la siguiente sentencia de SQL Oracle:

SELECT 'ALTER TABLE ' || OWNER || '.' || TABLE_NAME || ' ADD FECHA_CREACION DATE DEFAULT SYSDATE;' 
FROM ALL_TABLES WHERE OWNER ='HR'; 

El resultado de esta sentencia SQL Oracle sería algo como esto, las sentencias SQL que queremos utilizar en realidad:

ALTER TABLE HR.DEPARTMENTS ADD FECHA_CREACION DATE DEFAULT SYSDATE;
ALTER TABLE HR.EMPLOYEES ADD FECHA_CREACION DATE DEFAULT SYSDATE;
ALTER TABLE HR.JOB_HISTORY ADD FECHA_CREACION DATE DEFAULT SYSDATE;
ALTER TABLE HR.JOBS ADD FECHA_CREACION DATE DEFAULT SYSDATE;
ALTER TABLE HR.LOCATIONS ADD FECHA_CREACION DATE DEFAULT SYSDATE;
ALTER TABLE HR.REGIONS ADD FECHA_CREACION DATE DEFAULT SYSDATE;
ALTER TABLE HR.COUNTRIES ADD FECHA_CREACION DATE DEFAULT SYSDATE;

Crear script con Oracle SQL para ejecutar sentencias SQL

Ahora sólo restaría guardar estas sentencias en un script y ejecutarlo, o lanzarlas directamente desde la aplicación que utilicemos para interactuar con nuestra base de datos.

Para el que tenga que (o prefiera) trabajar desde un terminal o linea de comandos, la manera de hacer esto mismo con SQLPLUS sería la siguiente:

SQL> SET HEADING OFF
SQL> SET FEEDBACK OFF
SQL> SPOOL C:\campo_auditoria.sql
SQL> SELECT 'ALTER TABLE ' || OWNER || '.' || TABLE_NAME || ' ADD FECHA_CREACION DATE DEFAULT SYSDATE;'
     FROM ALL_TABLES WHERE OWNER ='HR';
SQL> SPOOL OFF;
SQL> SET FEEDBACK ON
SQL> SET HEADING ON 

Y finalmente ejecutar el script generado, aunque es recomendable una revisión previa de las sentencias generadas:

 SQL> @C:\campo_auditoria.sql 

Con este script de Oracle SQL se crea una tabla DIM_TIEMPO y se rellena con los valores comprendidos entre las fechas que se indiquen en las variables FechaDesde y FechaHasta. Puede ser muy útil para la creación de la tabla de tiempo de cualquier Data Warehouse.

Esta es la versión para una base de datos Oracle, con Oracle SQL, que se suma a las que han creado anteriormente il_masacratore y Dario Bernabeu para Microsoft SQL Server y Oracle MySQL en sus respectivos blogs:

Estructura de la Dimensión Tiempo y Script de carga para Ms SQL Server

Estructura de la Dimensión Tiempo y Procedure de carga para MySQL

Como cada uno se adaptará el formato de las fechas al que más le convenga, aprovecho para adjuntar esta tabla de ayuda obtenida de Oradev. Contiene descripciones de la sintaxis que se puede utilizar en las máscaras de formato de fechas de las funciones TO_CHAR y TO_DATE de Oracle:

Para hacer un insert con Oracle SQL desde una tabla de una base de datos TablaBD1 a otra base de datos TablaBD2 a través de un dblink debería haber dos maneras:
 

1- Crear el database link en la base de datos origen BD1 y hacer el insert hacia la tabla de la base de datos destino BD2 a través de este dblink

SQL en la base de datos Oracle BD1:

CREATE [PUBLIC] DATABASE LINK BD1toBD2_dblink
CONNECT TO usuario2
IDENTIFIED BY password2
USING 'BD2';

INSERT INTO TablaBD2@BD1toBD2_dblink
(SELECT * FROM TablaBD1);

* Para simplificar suponemos que las tablas tienen la misma estructura
 

2- Crear el database link en la base de datos destino BD2 y hacer el insert seleccionando los registros de la tabla de la base de datos origen BD1 a través de este dblink:

SQL en la base de datos Oracle BD2:

CREATE [PUBLIC] DATABASE LINK BD2toBD1_dblink
CONNECT TO usuario1
IDENTIFIED BY password1
USING 'BD1';

INSERT INTO TablaBD2
(SELECT * FROM TablaBD1@BD2toBD1_dblink);

Yo hasta ahora he utilizado siempre el SQL de la segunda opción para enlazar bases de datos Oracle, supongo que porque parece más simple utilizar un dblink para seleccionar datos de una tabla de una base de datos remota que para insertarlos remotamente. Pues parece que lo mejor es buscar las cosas simples porque he podido comprobar que la primera opción no funciona, por lo menos a mi.

He probado a hacerlo creando con SQL un dblink entre dos bases de datos Oracle 10g y la inserción no se realizaba. Lo curioso es que la sentencia SQL, en lugar de devolverme un error me devolvía un mensaje de '0 registros insertados', cuando haciendo la SELECT sí que obtenía registros.

Yo he llegado a la conclusión de que la opción de insertar datos directamente en una tabla de una base de datos Oracle remota a través de un database link no funciona, hay que hacer una SELECT desde la base de datos 'destino'. Para simplificar, la @ ha de estar en la tabla de la sentencia SQL de SELECT, no en la de INSERT.

Si alguien tiene una explicación mejor le agradecería que lo comentara, porque el tema me parece bastante curioso.

In batch runs to make a massive data dump into the same table using an INSERT or UPDATE for register within a block, the process can be optimized with the use of parameters (if client supports it) or if we use ODBC with bind variables.
Recall the steps taken by Oracle to process a query:
1) Sintactic Validation 
2) Semantic Validation
3) Optimization 
4) Generation of the QEP (Query Execution Plan)
5) Implementation of the QEP (Query Execution Plan)
Sentences can pick up the parameters by value (where salary > 1000) or once the sentence is compiled using Bind Variables (where salary>: b1). The advantage of the second option is that Oracle compile the sentence only one-time and reuses the compiled code for each of the values for the parameters.
But we must be aware because in the latter case because Oracle can't calculate the degree of selectivity of a query and, instead, apply a degree of selectivity by default (associated with each type of operation), which can give in wrong decisions.
Therefore, is inadvisable to use Bind Variables if you work with costs, except that we work with sentences to be executed repeatedly and not offering many doubts as to the possible access plans.
In proven cases like this, the execution time is reduced by up to 90% on an insert of 100.000 records ...

Creating the necessary table for testing:

Loading parameters by value:

Loading parameters using bind variables

I enclose the test results before applying changes in production (on a Friday afternoon )

Revisamos brevemente en este post la funcionalidad flashback query que aporta el gestor de BBDD de Oracle desde su versión 9i.

Básicamente se trata de un tipo de sql de Oracle que accede a datos que existían en la base de datos en un momento anterior, pero que en el momento en el que se ejecuta la sql pueden no existir o haber sufrido modificaciones. Para ello, Oracle utiliza los datos que quedan disponibles durante un tiempo en el segmento de UNDO. Este segmento, como es sabido, almacena los datos anteriores a una serie de modificaciones. Se utiliza para asegurar la consistencia en la lectura de una consulta previa a la confirmación de las modificaciones (commit) y pueden ser utilizados en una posible recuperación (rollback).

La sentencia de Oracle SQL flashback query nos permite ver datos de la tabla que han sido borrados o modificados. Ejecutando una flashback query accedemos a datos de una foto de datos consistentes en un punto determinado, especificando para ello la hora del sistema o bien el número de cambio del sistema (SCN). La base de datos debe estar configurada para trabajar en  Automatic Undo Management (AUM). Para ello revisar los siguientes parámetros de la base de datos Oracle:

undo_management = auto
undo_tablespace = UNDOTBS001   (tablespace que alberga el segmento de undo)
undo_retention = 3600 (tiempo en segundos que tenemos retenido el dato en el segmento de undo)

Hay que tener en cuenta respecto al parámetro undo_retention que si el tablespace de UNDO no es lo suficientemente grande como para mantener ese tiempo todas las transacciones, el gestor de base de datos las va a sobreescribir. Igualmente, considerar que para poder ejecutar el comando flashback query de Oracle SQL debemos tener permisos sobre el package BDMS_FLASHBACK. Para ello:

 sys> grant execute on dbms_flashback to usuario1;

Veamos un ejemplo. Supongamos que queremos realizar una consulta SQL sobre una tabla que contiene facturas de clientes y queremos acceder a los datos de un cliente que previamente hemos borrado:

sys> select to char(sysdate, ‘dd-mm-yyyy hh24:mi’) fecha_sistema from dual;
fecha_sistema
-------------------------
12-09-2011 12:05

sys> delete from t_facturas where cod_cliente = ‘00125’;
4 registros borrados

sys> commit;

Media hora después ejecutamos:

sys> select to char (sysdate, ‘dd-mm-yyyy hh24:mi’) fecha_sistema from dual
fecha_sistema
-------------------------
12-09-2011 12:35
sys>  exec dbms_flashback.enable_at_time (to_date('12-09-2011 12:05, 'DD-MM-YYYY HH24:MI'));

sys> select to char (sysdate, ‘dd-mm-yyyy hh24:mi’) fecha_sistema from dual
fecha_sistema
-------------------------
12-09-2011 12:35
sys> exec dbms_flashback.enable_at_time (to_date(’12-09-2011 12:05, ‘DD-MM-YYYY HH24:MI’)); 
Procedimiento PL/SQL terminado correctamente.

sys> select * from t_facturas where cod_cliente = ‘00125’;
……
……
……
…… 
4 registros seleccionados.

sys> execute dbms_flasback.disable; 

sys> select count(*) from t_facturas where cod_cliente = ‘00125’; 
count(*) 
------ 
0 

Se puede obtener lo mismo accediendo por el número de cambio SCN:

sys> select dbms_flashback.get_system_change_number from dual; 
GET_SYSTEM_CHANGE_NUMBER 
------------------------ 
1307125 

sys> exec dbms_flashback.enable_at_system_change_number(1307125); 
Procedimiento PL/SQL terminado correctamente

Existe también la posibilidad de emplear la sentencia ‘select ... as of...’: 

sys> select * from t_facturas where cod_cliente = ‘00125’ as of timestamp to_timestamp (’12-09-2011 12:05', ‘DD-MM-YYYY HH24:MI’);
sys> select * from t_facturas where cod_cliente = ‘00125’ as of scn 1307125; 

Hay que tener en cuenta que mientras la sesión está en el modo Flashback Query, solo podemos ejecutar sentencias SELECT. Las sentencias SQL de actualización (insert, delete y update) no están permitidas.

En el trabajo diario con esta opción es útil el uso de tablas temporales para trabajar con los datos recuperados:

sys> create table t_facturas_ant as      (select * from t_facturas       where cod_cliente = ‘00125’       as of timestamp to_timestamp (’12-09-2011 12:05, ‘DD-MM-YYYY HH24:MI’);

Otras opciones Flashback Query

A continuación listamos algunas funcionalidades que aporta Oracle relacionadas con operaciones Flashback Query:

• Flashback Version Query: Acceso al histórico de cambios de una tabla.
• Flashback Transaction Query: Acceso al histórico de cambios de una transacción determinada.
• Flashback Table: Acceso a datos anteriores, pero para una única tabla.
• Flashback Drop: Recuperar una tabla borrada (‘papelera reciclaje’).
• Flashback Database: Permite dejar la BBDD tal y como se encontraba en un tiempo pasado. Similar a restaurar un backup, pero con las limitaciones temporales de los procesos flashback, aunque mucho más rápido que recuperar la copia del backup.  Es necesario tener el modo flashback activado, así como la flash recovery area.

Algunas de estas opciones requieren que el gestor sea 'Enterprise Edition'.

Se trata, como se ha dicho, de una sentencia de Oracle SQL bastante útil, con múltiples opciones de “rebobinado” y que nos puede sacar de más de un apuro.

www.datademy.es

Don't you have a chop with useful queries to use in your daily adventures and desventures with the database?

I include in this first post a list of queries, most of them over Oracle metadata dictionary, and extracted from the site Cibermanuales.com.

I encourage everyone that has his own useful queries or scripts to share it answering to this post. The objective is to create a little online repository that we could consult when we are working with the database.

•• Oracle SQL query over the view that shows database state:
select * from v$instance

•• Oracle SQL query that shows if database is opened
select status from v$instance

•• Oracle SQL query over the view that show Oracle database general parameters
select * from v$system_parameter

•• Oracle SQL query to know Oracle version
select value from v$system_parameter where name = 'compatible'

•• Oracle SQL query to know the path and name of spfile
select value from v$system_parameter where name = 'spfile'

•• Oracle SQL query to know the localization and number of control files
select value from v$system_parameter where name = 'control_files'

•• Oracle SQL query to show the database name.
select value from v$system_parameter where name = 'db_name'

•• Oracle SQL query over the view that shows actual Oracle conections. 
•• To use it the user need administrator privileges.select osuser, username, machine, program
from v$session
order by osuser

•• Oracle SQL query that show the opened conections group by the program that opens the connection.
select program Aplicacion, count(program) Numero_Sesiones
from v$session
group by program
order by Numero_Sesiones desc

•• Oracle SQL query that shows Oracle users connected and the sessions number for user
select username Usuario_Oracle, count(username) Numero_Sesiones
from v$session
group by username
order by Numero_Sesiones desc

•• Objects owners number of objects for owner
select owner, count(owner) Numero
from dba_objects
group by owner
order by Numero desc

•• Oracle SQL query over the data Dictionary (includes all views and tables of the database)
select * from dictionary

•• Oracle SQL query that shows definition data from a specific table 
•• (in this case, all tables with string "XXX")
select * from ALL_ALL_TABLES where upper(table_name) like '%XXX%'

•• Oracle SQL query to know tables from actual user
select * from user_tables

•• Oracle SQL query to know all the objects of the connected user
select * from user_catalog

•• Oracle SQL query for Oracle DBA that shows tablespaces, disk used, free space and datafiles:
SELECT t.tablespace_name "Tablespace", t.status "Estado",       ROUND(MAX(d.bytes)/1024/1024,2) "MB Tamaño",       ROUND((MAX(d.bytes)/1024/1024) -       (SUM(decode(f.bytes, NULL,0, f.bytes))/1024/1024),2) "MB Usados",       ROUND(SUM(decode(f.bytes, NULL,0, f.bytes))/1024/1024,2) "MB Libres",       t.pct_increase "% incremento",       SUBSTR(d.file_name,1,80) "Fichero de datos"FROM DBA_FREE_SPACE f, DBA_DATA_FILES d, DBA_TABLESPACES tWHERE t.tablespace_name = d.tablespace_name AND      f.tablespace_name(+) = d.tablespace_name      AND f.file_id(+) = d.file_id GROUP BY t.tablespace_name,      d.file_name, t.pct_increase, t.status ORDER BY 1,3 DESC

•• Oracle SQL query to know Oracle products installed and version number.
select * from product_component_version

•• Oracle SQL query to know roles and roles privileges
select * from role_sys_privs

•• Oracle SQL query to know integrity rules
select constraint_name, column_name from sys.all_cons_columns

•• Oracle SQL query to know tables owned by a user, in this case "xxx":SELECT table_owner, table_name from sys.all_synonyms where table_owner like 'xxx'

•• Oracle SQL query for the same as last query

SELECT DISTINCT TABLE_NAME
FROM ALL_ALL_TABLES
WHERE OWNER LIKE 'HR'
•• Oracle parameters, actual value and its description.
SELECT v.name, v.value value, decode(ISSYS_MODIFIABLE, 'DEFERRED',
'TRUE', 'FALSE') ISSYS_MODIFIABLE, decode(v.isDefault, 'TRUE', 'YES',
'FALSE', 'NO') "DEFAULT", DECODE(ISSES_MODIFIABLE, 'IMMEDIATE',
'YES','FALSE', 'NO', 'DEFERRED', 'NO', 'YES') SES_MODIFIABLE,
DECODE(ISSYS_MODIFIABLE, 'IMMEDIATE', 'YES', 'FALSE', 'NO',
'DEFERRED', 'YES','YES') SYS_MODIFIABLE , v.description
FROM V$PARAMETER v
WHERE name not like 'nls%' ORDER BY 1

•• Oracle SQL query that shows Oracle users and his data
Select * FROM dba_users

•• Oracle SQL query to know tablespaces and its owner:
select owner, decode(partition_name, null, segment_name,
segment_name || ':' || partition_name) name,
segment_type, tablespace_name,bytes,initial_extent,
next_extent, PCT_INCREASE, extents, max_extents
from dba_segments
Where 1=1 And extents > 1 order by 9 desc, 3

•• Last SQL queries executed on Oracle and user:
select distinct vs.sql_text, vs.sharable_mem,
vs.persistent_mem, vs.runtime_mem, vs.sorts,
vs.executions, vs.parse_calls, vs.module,
vs.buffer_gets, vs.disk_reads, vs.version_count,
vs.users_opening, vs.loads,
to_char(to_date(vs.first_load_time,
'YYYY-MM-DD/HH24:MI:SS'),'MM/DD HH24:MI:SS') first_load_time,
rawtohex(vs.address) address, vs.hash_value hash_value ,
rows_processed , vs.command_type, vs.parsing_user_id ,
OPTIMIZER_MODE , au.USERNAME parseuser
from v$sqlarea vs , all_users au
where (parsing_user_id != 0) AND
(au.user_id(+)=vs.parsing_user_id)
and (executions >= 1) order by buffer_gets/executions desc

•• Oracle SQL query to know all the tablespaces:
select * from V$TABLESPACE

•• Oracle SQL query to know free and used Shared_Pool
select name,to_number(value) bytes
from v$parameter where name ='shared_pool_size'
union all
select name,bytes
from v$sgastat where pool = 'shared pool' and name = 'free memory'
Cursores abiertos por usuario
select b.sid, a.username, b.value Cursores_Abiertos
from v$session a,
v$sesstat b,
v$statname c
where c.name in ('opened cursors current')
and b.statistic# = c.statistic#
and a.sid = b.sid
and a.username is not null
and b.value >0
order by 3

•• Oracle SQL query to know cache hits (it must be more than 1%)
select sum(pins) Ejecuciones, sum(reloads) Fallos_cache,
trunc(sum(reloads)/sum(pins)*100,2) Porcentaje_aciertos
from v$librarycache
where namespace in ('TABLE/PROCEDURE','SQL AREA','BODY','TRIGGER');

•• Complete SQL queries executed with a specific text in SQL sentence.
SELECT c.sid, d.piece, c.serial#, c.username, d.sql_text
FROM v$session c, v$sqltext d
WHERE c.sql_hash_value = d.hash_value
and upper(d.sql_text) like '%WHERE CAMPO LIKE%'
ORDER BY c.sid, d.piece 

•• A SQL query (filtered by sid)
SELECT c.sid, d.piece, c.serial#, c.username, d.sql_text
FROM v$session c, v$sqltext d
WHERE c.sql_hash_value = d.hash_value
and sid = 105
ORDER BY c.sid, d.piece

•• Oracle SQL query to know the database size
select sum(BYTES)/1024/1024 MB from DBA_EXTENTS

•• Oracle SQL query to calculate the size of the database data files
select sum(bytes)/1024/1024 MB from dba_data_files

•• Oracle SQL query to calculate the size of a concrete table excluding the indexes
select sum(bytes)/1024/1024 MB from user_segments
where segment_type='TABLE' and segment_name='TABLENAME'

•• Oracle SQL query to calculate the size of a concrete table including the indexes
select sum(bytes)/1024/1024 Table_Allocation_MB from user_segments
where segment_type in ('TABLE','INDEX') and
(segment_name='TABLENAME'or segment_name in
(select index_name from user_indexes where table_name='TABLENAME'))

•• Oracle SQL query to know the memory used by a column in a table
select sum(vsize('COLUMNNAME'))/1024/1024 MB from 'TABLENAME'

•• Oracle SQL query to calculate memory used by a user
SELECT owner, SUM(BYTES)/1024/1024 MB FROM DBA_EXTENTS
group by owner

•• Oracle SQL query to calculate size from the diferent segments 
•• (tables, indexes, undo, rollback, cluster, ...)
SELECT SEGMENT_TYPE, SUM(BYTES)/1024/1024 MB FROM DBA_EXTENTS
group by SEGMENT_TYPE

•• Oracle SQL query to obtain all the Oracle functions: NVL, ABS, LTRIM, ...
SELECT distinct object_name
FROM all_arguments
WHERE package_name = 'STANDARD'
order by object_name

•• Oracle SQL query to calculate the size of all the database objects, ordering from more to less
SELECT SEGMENT_NAME, SUM(BYTES)/1024/1024 MB FROM DBA_EXTENTS
group by SEGMENT_NAME
order by 2 desc 

Hasta el momento desconozco exactamente como o donde se detalla cada tipo de error en la ejecución de un informe de reporting services de Microsoft SQL Server. He tratado con derivados de falta de permisos, procesados incompletos de cubos pero hasta ahora ningun #Error en una celda por que sí.

El error en cuestión me aparece en la ejecución de un pequeño informe que tira de un origen de datos ODBC contra una base de datos Oracle donde se muestran totales (sumas, no porcentajes) y me ha sorprendido mucho la falta de detalle sobre el error que se produce. Para más dificultad, encima es en una combinación de parámetros concreta (las n ejecuciones anteriores han funcionado) y no en toda la columna sino en una celda. Además arrastra todo subtotal o total en el que se incluya...

Después de mirar el log del servidor de Reporting Services, después de comprobar la consulta en un cliente externo con la misma, tras pensar mal del formato me da por comprobar en el diseñador de informes el origen de datos, me hago una prueba con parámetros al tuntun y bien, pero al poner los valores problemáticos consigo que se al menos aparezca el error:

Pues nada, encontrado esto ya estoy más feliz ya que el error es que ado.net+oracle+odbc no lleva muy bien los números de 38 digitos...

Para esto podemos hacer un workaround que consiste en usar en la consulta la función trunc(número, decimales) de Oracle SQL para que nos trunque el valor en su parte decimal donde nosotros decidamos.

With 9.7 DB2 LUW version, IBM makes a nod to all Oracle DBAs, much more numerous in the DB2 market.

For this reason, 9.7 version has introduced Oracle compatibility modes that let you perform tasks in DB2 with the ease and knowledge that all Oracle DBAs have. However, it is important to know the terminology's translation between Oracle and DB2 if you intend to get into the DB2 world.

In this first article, I relate a number of items from which this introduction is simple and can be read DB2 documentation easily, including general terminology, updates, utilities, and views.

I hope you find it useful.

Oscar Paredes

www.db2util.es

Supongamos que queremos actualizar en nuestra base de datos ORACLE el campo de costes de la tabla de hechos FAC_TABLE con el coste unitario de nuestra tabla de COSTES.

Con Oracle SQL podemos hacerlo de dos maneras:

• Consulta Lenta, pero si es para pocos datos o para lanzarlo esporádicamente nos puede valer

update FAC_TABLE ft set COSTE_UNITARIO =
   (select distinct COSTE_UNITARIO
    from COSTES ct
    where (ft.id_articulo = ct.id_articulo); 

• La mejor manera es esta, y el rendimimento es óptimo si tiene constraints)

UPDATE (SELECT ft.COSTE_UNITARIO AS old_coste,
               ct.COSTE_UNITARIO AS new_coste 
        FROM FAC_TABLE ft INNER JOIN COSTES ct ON ft.id_articulo = ct.id_articulo)
       ) SET old_coste = new_coste;

Para que esta segunda opción funcione necesitamos tener UNIQUE or PRIMARY KEY constraint en ct.id_articulo.

Si no tienes esta constraint, puedes utilizar el hint /*+BYPASS_UJVC*/ después de la palabra UPDATE (bypass update join view constraint).

El rendimiento aumenta si tenemos la constraint pero aún sin ella debe correr mucho más que la primera opción.

Espero que os ayude.

Héctor Minguet.

Como las cargas de un Data warehouse se realizan de manera periódica, y además es habitual la creación de tablas agregadas para mejorar la eficiencia y tiempo de respuesta de nuestros informes, un recurso de optimización física que puede aportar grandes mejoras es la utilización de vistas materializadas.

Qué es una vista materializada 

La vista materializada no es más que una vista, definida con una sentencia SQL de Oracle, de la que además de almacenar su definición, se almacenan los datos que retorna, realizando una carga inicial y después cada cierto tiempo un refresco de los mismos.

Así, si tenemos un Datawarehouse que se actualiza diariamente, podríamos utilizar vistas materializadas para ir actualizando tablas intermedias que alimenten nuestros esquemas de DWH, o directamente para implementar tablas agregadas que se refrescarán a partir de nuestras tablas base. 

La creación de este tipo de vistas con Oracle SQL no es tan compleja como puede parecer, lo más importante es tener claro cada cuánto tiempo queremos actualizar la información de las vistas, y qué método de refresco utilizar.

También tendremos que asegurarnos de que nuestra licencia de base de datos nos permite utilizarlas (ha de ser una versión Enterprise).

Sintaxis básica de Oracle SQL para la creación de una vista materializada

CREATE MATERIALIZED VIEW mi_vista_materializada
 [TABLESPACE mi_tablespace]
 [BUILD {IMMEDIATE | DEFERRED}] 
 [REFRESH {ON COMMIT | ON DEMAND | [START WITH fecha_inicio] NEXT fecha_intervalo } | 
          {COMPLETE | FAST | FORCE} ] 
 [{ENABLE|DISABLE} QUERY REWRITE] AS 
     SELECT t1.campo1, t2.campo2 
     FROM mi_tabla1 t1 , mi_tabla2 t2 
     WHERE t1.campo_fk = t2.campo_pk AND …

Comentarios sobre las diferentes opciones de la sentencia Oracle SQL de creación de la vista:

• Carga de datos en la vista

BUILD IMMEDIATE:
  Los datos de la vista se cargan en el mismo momento de la creación

BUILD DEFERRED:
  Sólo se crea la definición, los datos se cargarán más adelante. Para realizar esta carga se puede utilizar la función REFRESH del package DBMS_MVIEW:
      begin
         dbms_mview.refresh('mi_vista_materializada');
      end; 

• Método y temporalidad del refresco de los datos

 Cada cuánto tiempo se refrescarán:

REFRESH ON COMMIT:
  Cada vez que se haga un commit en los objetos origin definidos en la select 

REFRESH ON DEMAND:
  Como con la opción DEFERRED del BUILD, se utilizarán los procedures REFRESH, REFRESH_ALL_MVIEWS o REFRESH_DEPENDENT del package DBMS_MVIEW 

REFRESH [START WITH fecha_inicio] NEXT fecha_intervalo:
  START WITH indica la fecha del primer refresco (fecha_inicio suele ser un SYSDATE)
                  NEXT indica cada cuánto tiempo se actualizará (fecha_intervalo podría ser SYSDATE +1 para realizar el refresco una vez al día)

• De qué manera se refrescarán

REFRESH COMPLETE:
El refresco se hará de todos los datos de la vista materializada, la recreará completamente cada vez que se lance el refresco

REFRESH FAST:
El refresco será incremental, es la opción más recomendable, lo de fast ya da una idea del porqué.
Este tipo de refresco tiene bastantes restricciones según el tipo de vista que se esté creando.
Se pueden consultar en General Restrictions on Fast Refresh de la documentación oficial de Oracle

Una de las cosas importantes a tener en cuenta es que para poder utilizar este método casi siempre es necesario haber creado antes un LOG de la Vista materializada, indicando los campos clave en los que se basará el mantenimiento de la vista.

Se utiliza la instrucción de Oracle SQL "CREATE MATERIALIZED VIEW LOG ON":

   CREATE MATERIALIZED VIEW LOG ON mi_tabla_origen      
   WITH PRIMARY KEY      
   INCLUDING NEW VALUES; 

REFRESH FORCE:
Con esta opción se indica que si es posible se utilice el metodo FAST, y si no el COMPLETE. 

Para saber si una vista materializada puede utilizar el método FAST, el package DBMS_MVIEW proporciona el procedure EXPLAIN_MVIEW 

• Activación de la reescritura de consultas para optimizar el Data warehouse

ENABLE QUERY REWRITE:
Se permite a la base de datos la reescritura de consultas

DISABLE QUERY REWRITE:
Se desactiva la reescritura de consultas

La opción QUERY REWRITE es la que más vamos a utilizar si queremos las vistas materializadas para optimizar nuestro Data warehouse.
Esta opción permite crear tablas agregadas en forma de vistas materializadas, y que cuando se lance una SELECT la base de datos pueda reescribirla para consultar la tabla o vista que vaya a devolver los datos solicitados en menos tiempo, todo de manera totalmente transparente al usuario

Lo único que hay que hacer es crear las tablas agregadas como vistas materializadas con QUERY REWRITE habilitado.

Ejemplos de vistas materializadas de Oracle

Son muchas combinaciones, pero la sentencia final no es tan compleja.

Primer paso de la ETL de un Data warehouse

Si quisiéramos crear con SQL de Oracle una vista materializada de una tabla que se refresque un día a la semana, y de manera incremental haríamos lo siguiente: 

CREATE MATERIALIZED VIEW LOG ON mi_tabla_origen
WITH PRIMARY KEY INCLUDING NEW VALUES;

CREATE MATERIALIZED VIEW mi_vista_materializada
REFRESH FAST NEXT SYSDATE + 7 AS
   SELECT campo1, campo2, campo8
   FROM mi_tabla_origen
   WHERE campo2 > 5000;

Esta vista podría servirnos para alimentar la carga de un Data Mart que se realizara semanalmente. Podríamos programarla para que se refrescara justo antes del inicio del proceso de carga, o como primer paso en la ETL, y ya tendríamos los datos necesarios actualizados, e independientes del origen de datos (no tendríamos que molestar más al operacional). Otra ventaja a tener en cuenta es que si hay algún problema con el acceso a los datos de origen, si no los hemos eliminado, en la vista materializada aún tendremos los datos del último refresco, con lo que aunque el refresco fallara no nos encontraríamos un error que truncara la carga de nuestro Data Warehouse, o una tabla vacía.

Por supuesto, en las condiciones del WHERE de la sentencia SQL de creación podríamos seleccionar sólo los registros necesarios, sólo los del último mes, etc.

Tablas agregadas para optimizar el Data Warehouse

Otro ejemplo importante sería la utilización de vistas materializadas para la creación de tablas agregadas. 

-- Oracle SQL para crear agregadas con materilized views
CREATE MATERIALIZED VIEW ventas_agregadas_mv
BUILD IMMEDIATE REFRESH COMPLETE
ENABLE QUERY REWRITE AS
   SELECT id_producto, sum(importe) total_ventas
   FROM ventas GROUP BY id_producto;

Con esta sencilla sentencia de Oracle SQL se crearía una tabla agregada de total de ventas por producto de una supuesta tabla de ventas que seria la tabla de hechos.

A nivel de sesión también habría que asegurarse de que la opción QUERY_REWRITE estuviera activada. Por si acaso, desde SQL Plus, se puede habilitar con la sentencia SQL:

SQL> ALTER SESSION SET QUERY_REWRITE_ENABLED=TRUE;

Si ahora dentro de esta sesión se ejecuta la sentencia SQL

SQL> SELECT sum(importe)
     FROM ventas;

la base de datos preparará el plan de ejecución teniendo en cuenta la vista materializada creada e internamente realizará la selección sobre la vista ventas_agregadas_mv.

Una manera sencilla de comprobarlo, aparte de examinar el plan de ejecución, o de comparar tiempos antes y después de la creación de la vista, o desactivando el QUERY_REWRITE, es comprobar que esta query SQL devuelve resultados en el mismo tiempo que la query

SELECT sum(importe)
FROM ventas_agregadas_mv;

Para consultar más detalles, o la sintaxis SQL completa de la creación de vistas materializadas Oracle, el capítulo Create Materialized View del manual de referencia SQL de Oracle es un buen recurso.

Con Oracle Enterprise Manager (OEM), o con la consola web de la base de datos también se pueden crear las vistas materializadas de una manera más asistida, pero igualmente es importante tener claros los conceptos antes de hacerlo.

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.

Los libros que ves a continuación son una selección de los que a mi me parecen más interesantes para aprender administración y desarrollo PL/SQL, teniendo en cuenta precio y temática, espero que te puedan ser de utilidad:

• eBooks de Oracle gratuítos para la versión Kindle, o muy baratos (menos de 4€):

Cuando hablamos de bases de datos, normalmente nos imaginamos un gran servidor, com grandes cantidades de información en su interior. Ahora bien, también existen bases de datos minúsculas para entornos donde el espacio, tanto de almacenaje como de proceso, es muy importante.

Dentro del proyecto Apache existe un proyecto llamado Derby. Derby es una base de datos relacional, implementada totalmente en Java que tiene la particularidad del pequeño tamaño que supone. Sun, a partir de Apache Derby, ha desarrollado su propia base de datos llamada JavaDB.

Así mismo, Oracle ha adquirido la base de datos Sleepy cat, desarrollada incialmente en la universidad de Berkeley.

Em ambos casos, sorprende el rendimiento, tanto en velocidad como en capacidad, y la funcionalidad.

En el site www.ajpdsoft.com se publica el manual online Instalacion Oracle 9i sobre Windows, donde se explica paso a paso y con captura de pantallas cómo instalar una BD Oracle 9i sobre windows, cómo solucionar algunos de los errores típicos que suelen aparecer durante la instalación, cómo levantar el listener, comprobar el estado de la base de datos, y alguna cosa más..

La gente de Debian Administration nos muestra como instalar en pocos pasos un Oracle 10g Express.
El proceso de instalacion se realiza via Apt , y tb nos explican como dejarlo a punto para su utilizacion.
El articulo podemos encontrarlo aqui

Para instalar una base de datos Oracle sobre una distribución Linux lo mejor es seguir las indicaciones de Oracle. En Oracle by example - Oracle database 10g on a single instance Oracle explica de una manera bastante clara cómo hacerlo.

Una cosa importante a tener en cuenta es que cada distribución LINUX tiene sus peculiaridades, y que no todo sirve para todas. Lo más recomendable es utilizar las que están certificadas por Oracle, eso no garantiza que no surgan problemas, pero por lo menos Oracle los documenta. Oracle suele certificar para distribuciones SUSE en su versión empresarial (SLES) y RedHat.

Una buena opción, si queremos tener lo más parecido a las versiones empresariales, y poder ir actualizando nuestro SO, puede ser utilizar Open SUSE o CentOS. Otra puede ser utilizar su propia distribución Oracle Enterprise Linux

Debido a la gratuidad de esta versión de Oracle suele ser común su uso para instalaciones masivas en múltiples PC's, TPV's...

Este artículo orientado a DBA's de Oracle y desarrolladores resume brevemente como realizar una instalación desatendida de Oracle XE.

Esta instalación es tan sencilla como ejecutar el instalador de Oracle XE con los siguientes parámetros:

> oraclexe /s /f1"fichero_respuesta.iss" /f2"fichero_de_log"

El primer fichero indica los parámetros básicos de la instalación, y el segundo será el log resultante de la instalación.

Los parámetros configurables en el fichero de respuesta de la instalación son:

** szDir - Path de instalación del software y de ficheros de datos

** TNSPort - Puerto Listener BBDD

** MTSPort - Puerto MTS

** HTTPPort - Puerto HTTP consola

** SYSPassword - Password del usuario SYS

** bOpt1 - 1 or 0 : Ejecución o no al final de la consola a través del navegador

El resultado de la instalación se puede consultar en el fichero de log. Sin embargo, en caso de problemas este fichero no resulta muy útil, para ello se puede consultar el fichero generado en el directorio %systemroot% (en Windows C:\WINDOWS).

Además de una instalación desatendida también es posible realizar una desinstalación o reparación desatendida.

Oscar Paredes

IT Manager
Oracle DBA

oscar.paredes@dataprix.com

Navegando por la red he encontrado en PHP y otras yerbas un artículo que habla de un manual de PHP y Oracle. Conocía las siglas LAMP, pero no las siglas LAOP.

Resumiendo, un manual sencillo y creado por el equipo de Oracle para todos aquellos que tienen pensado una posible migración de MySql a Oracle en su gestor de contenidos, sobre todo, los de caracter empresarial.

In Oracle 11g release 2, Oracle introduced a new product Oracle Real Application Clusters One Node (Oracle RAC One Node)

A rapid definition of the product is:

An Oracle RAC' s instance but executed in one single node. May be run on different physical servers, not only one (this is common) but a database instance is running only on the same node  simultaneously  (* but we'll see later that this is not completely true).

It's more easy to understand seeing this diagram:

In this scheme, we have 3 physical servers containing 5 total instances running on  Oracle RAC One Node .  Each node has an OS, so there aren't different virtual machines.

The most notable advantages are:

• It enables high availability of a database instance, both server failure, or DB level (for example, VMware only provide hardware-level server). That is, in the example above, a fall or a problem of unavailability of Server 2, would make the database DB-C moved to another physical server automatically.

• Allow distribution of physical resources online (Instance Caging). For example, in the example above,  if Server 1 had 4 physical processors, we could allocate 3 to that DB-A instance and only assign 1 to the DB-B instance . Furthermore, it could allocate dynamically without restart, if any instance needs more processor.

• In case of manteinance of a physical server (eg, by need of applying patches, it may move its instances dynamically and without loss of service. This feature is done by Oracle Omotion. To avoid loss of service, during brief instants, Oracle RAC One Node runs a new instance on target server, so in that period time there are 2 instances on the same database (like Oracle RAC).

• It can upgrade Oracle RAC at any time without service interruption.

As you can see, the storage should be shared.

Like Oracle RAC, Oracle RAC One Node clustering software uses Oracle Clusterware to control clusterized resources in the different nodes.This does, of course, that compatibility with other clustering software (Veritas, Sun Cluster, etc. ..) is not possible.

To sell the product, Oracle insists on the advantages of having n-physical machines Oracle RAC One Node compared to having them in a VMware farm. These advantages can be summarized as follows:

• More efficient use of resources, by not using the hypervisor layer.
• Easy patches installation (except operating systems and ability to change the server that manage the service)
• CPU Dynamic modification without having to reboot.

The licensing is cheaper than Oracle RAC, so this product can be seen as a lower-cost approach, and later upgrade to Oracle RAC:

I hope you find it useful.

Oscar Paredes - oscar.paredes @ dataprix.com

Oracle ofrece una versión gratuita de su base de datos, con el principal objetivo de introducir en el 'mundo Oracle' a desarrolladores, DBAs, estudiantes y formadores, y vendedores de hardware y software que quieran distribuir junto con sus productos una base de datos sin costes de licencia. El producto es Oracle 10g Express Edition (Oracle Database XE) y, obviamente, tiene sus limitaciones.

Sólo puede utilizar 1 procesador del servidor donde esté instalada, un máximo de 1 Gb de RAM, y tiene limitado el almacenamiento a 4 Gb de datos de usuario. Cuando se superen estas limitaciones, Oracle ofrece un sencillo proceso de actualización a otras versiones más completas, y en las que sí que hay que pagar licencias.

De todas maneras es una opción muy válida para quien quiera practicar con bases de datos Oracle, o para quien necesite una base de datos limitada en cuanto a tamaño, pero fiable y eficiente, y gratuita.

Con la base de datos, Oracle incluye también Oracle Application Express, un entorno sencillo e intuitivo que permite realizar gráficamentes las tareas básicas de administración de la base de datos.

Se puede descargar esta base de datos, o consultar información más concreta sobre la misma en Oracle Database XE.

Recomiendo consultar antes de la instalación el Datasheet de Oracle Database XE, y las características de Oracle Application Express.

Tradicionalmente las bases de datos Oracle de una cierta envergadura se han ido instalando sobre servidores con SO UNIX, y también sobre sistemas servidores windows.

Con el reconocimiento de Linux como un SO suficientemente fiable para su utilización en grandes servidores, las grandes corporaciones comienzan a plantearse la utilización de este sistema por la flexibilidad, y acceso al código fuente que ofrece, y por la ausencia de costes en licencias.

Así, una opción que cada vez ganará más adeptos es la instalación de BBDD Oracle sobre Linux.

En el caso de éxito descrito por Oracle en el pdf adjunto se muestra el interesante ejemplo del Grupo Gas Natural, donde se tomó la decisión de migrar la base de datos Oracle que albergaba el Data Warehouse corporativo desde potentes máquinas en plataforma UNIX a servidores más modestos en cluster sobre una plataforma Linux.

Concretamente, la base de datos se migró a Oracle 9i con Real Application Cluster sobre Linux RedHat.

Con esta solución se consiguió una reducción de los costes, a la vez que mejoraban tanto el rendimiento como la escalabilidad del sistema.

Estaba navegando por la web de Oracle, concretamente unos apartados para principiantes como yo: "Getting Started". Éstos apartados te guían en muchos temas, incluso puedes encontrar un buen checklist de configuración de seguridad, para principiantes.

Además de ésto he encontrado unos Tool Kits para que en poco tiempo puedas montarte en tu escritorio Windows una VMWare con GNU/Linux y con el Oracle Database 10g preconfigurado. Los Tool Kits están disponibles con Red Hat o Novell. Y además viene acompañado de una guía que explica incluso cómo instalar VMWare.

Todo ésto bajo licencia de evaluación está claro. Si hay alguien que lo ha probado o que lo va a testear, que exponga sus opiniones al respecto.

Para los que quieren estar siempre a la última y para los amantes del riesgo, desde el 4 de mayo está disponible la última versión del servidor de base de datos de Oracle para Windows Vista. Se puede descargar en Oracle Database 10g Release 2 para Windows Vista

Si alguien se anima y la prueba puede ser interesante cualquier comentario al respecto..

Cesar Cerrudo, de Black Hat muestra como con herramientas libres buscar bugs dentro de una base de datos.
La noticia , aqui

El error ORA-30926 suele producirse cuando se realizan operaciones Merge, y lo normal es que nos deje algo descolocados, ya que la descripción del mismo no da demasiada información sobre lo que está pasando:
ORA-30926: unable to get a stable set of rows in the source tables.

Normalmente este error se produce cuando en la operación Merge a una fila destino que hay que actualizar le corresponden más de una fila en la tabla origen. Como el motor no sabe qué registro escoger devuelve un error. Es un problema de duplicidad en la tabla origen.

Ejemplo:

• Tenemos:
  TABLA_ORIGEN con los valores
  ID    Descripcion
  1     'El primer valor'
  1     'El valor con id duplicado'
  2     'Otro valor'

  Y TABLA_DESTINO con los valores
  ID   Descripcion
  1    'Valor a actualizar'
  2    'Este no dará problemas'
  3    'Este se queda igual'
   

• Queremos hacer un merge utilizando la siguiente sentencia:

      MERGE into TABLA_DESTINO dest 
      USING TABLA_ORIGEN ori ON (dest.ID = ori.ID) 
      WHEN MATCHED THEN UPDATE SET a.Descripcion = b.Descripcion;

Con estos datos obtendríamos el siguiente error sobre TABLA_ORIGEN:
ORA-30926: no se ha podido obtener un juego de filas estable en las tablas de origen

• Ante este error tenemos 3 opciones:

  1-. Eliminar los registros duplicados de la tabla origen:

       DELETE FROM TABLA_ORIGEN WHERE id=1 AND Descripcion='El valor con id duplicado'
 

2-. Revisar las claves por las que hacemos la join en el merge:

Si utilizamos también el campo Descripcion en el enlace ya sólo habrá cero o un registro origen para cada destino:

      MERGE into TABLA_DESTINO dest 
      USING TABLA_ORIGEN ori ON (dest.ID = ori.ID AND dest.Descripcion=ori.Descripcion) 
      WHEN MATCHED THEN UPDATE SET a.Descripcion = b.Descripcion;

(En este ejemplo no tiene mucho sentido porque la tabla son sólo estos dos campos, y además la join no encontrará coincidencias)

3-. Utilizar en lugar del MERGE un UPDATE con JOIN y el HINT /*+BYPASS_UJVC */  para saltarnos la validación del motor, y cruzar los dedos:

UPDATE /*+ BYPASS_UJVC */
( SELECT ori.ID ori_ID,
ori.Descripcion ori_Descripcion,
dest.ID dest_ID,
dest.Descripcion dest_Descripcion
FROM TABLA_ORIGEN ori, TABLA_DESTINO dest
WHERE ori.ID = dest.ID)
SET dest_Descripcion = ori_Descripcion;

Obviamente las más recomendables son la primera o la segunda, según el caso. La tercera opción, desde que la versión 11g R2 de Oracle ya no acepta el hint BYPASS_UJVC por considerarlo Deprecated, es ya totalmente desaconsejable para entornos de producción porque aunque ahora funcione por ser versiones anteriores a la 11g, las queries que incorporen este hint fallarán cuando se actualice la base de datos a una versión a partir de la 11g R2.

Otra buena opción para evitar el error ORA-30926 en operaciones de MERGE es modificar la sentencia aplicando un distinct para evitar los duplicados, o utilizando un group by y una función de agregación Min, Max o Sum, por ejemplo, sobre los campos que contengan los valores duplicados.

ORA-01555 Snapshot too old

La base de datos de una compañia normalmente tiene que aguantar algunas transacciones largas y pesadas. Si la base de datos es Oracle, está recien instalada y poco manipulada esas transacciones y sus primeras ejecuciones tienen pocas probabilidades de éxito. Es entonces cuando acaba apareciendo el fatídico ORA-01555, alias "... snapshot to old".

La gestión de consultas largas en Oracle viene limitada por el tamaño del tablespace de deshacer (undotbs). A mayor tamaño sera posible gestionar las transacciones más largas y pesadas. En Oracle 10g recien instalado el tamaño de este tablespace se reducido y uno no se suele dar cuenta hasta que falla la cosa.

Si la versión es la 10 se puede modificar directamente desde Oracle Enterprise Manager (consola web) en el apartado de administración, "Gestión de Deshacer". Allí tenemos el tiempo de retención, el tamaño del tablespace y podemos usar también el asesor para ver el tiempo de retención posible en base al tamaño en mb del tablespace.

Algo así:

En resumidas cuentas, le asignamos un tamaño mayor al tablespace que tengamos de "deshacer" y a ver si vale...

Para más información dejo aquí el Link de Oracle: https://www.oracle.com/technetwork/oramag/index.html

Cuando se produce este error el listener de nuestra base de datos Oracle está rechazando conexiones y no nos podemos conectar de ninguna manera con la base de datos. Para ver que está pasando podemos consultar el log del listener en /opt/oracle/product/10.2/db_1/network/log/listener.log para ver que nos cuenta el sistema. En el caso que nos ocupa podemos encontrar una entrada como la siguiente:

"TNS-12518: TNS:listener could not hand off client connection"

En el caso que me he encontrado este error puede producirse porque el número de procesos actuales de la base de datos está muy cerca del límite establecido en la configuración (por defecto 150). Inmediatamente se puede solucionar reiniciando el listener pero es recomendable revisar el valor del parámetro processes para incrementarlo. El valor máximo que le asignemos a este parámetro es trivial pero si lo modificamos debemos recalcular el valor de transacctions y sessions para que tengan en cuenta las sessiones de sistema de esta manera:

processes=x
transacctions=x*1.1
sessions=(processes*1.1)+5

Si con esto vemos que no se soluciona o queremos investigar más podemos activar la traza del listener para saber más sobre lo que acontece...

Este error de la consola de Oracle 10gR2 con Suse Enterprise (confirmado versión 10) hace que durante la navegación por la consola vayan apareciendo errores en la parte superior con el mensaje:

java.lang.Exception: Failed to get Number of users

La solución que puede aplicar el DBA de Oracle pasa por realizar los siguientes pasos:

1. Parar la consola de Oracle:
   >emctl stop dbconsole
   
   
2. Ir al directorio:
   
            >cd $ORACLE_HOME/sysman/admin/scripts
   
   
3. Realizar backup del fichero osLoad.pl
    
4. Editar el fichero osLoad.pl y cambiar las siguientes lineas:
   
   >>> my $loadavg = NIL;
   
   <<< my $loadavg = "0.46, 0.66, 0.61";
   
      
   >>>> my $nusers = NIL;
   
   <<<< my $nusers = 1;
   
   
5. Grabar el fichero y arrancar la consola
   >emctl start dbconsole

Oscar Paredes

IT Manager
Oracle DBA

oscar.paredes@dataprix.com

El error ORA-1031 - Insuficient privileges es uno de los errores más comunes que se puede encontrar un DBA de Oracle durante la conexión como SYSDBA a entornos Windows no administrados de manera cotidiana.

Además tiene la característica de que siempre aparece cuando más puede molestar ;-)

Oscar Paredes

IT Manager
Oracle DBA

oscar.paredes@dataprix.com

Oracle, aparte de su famoso gestor de base de datos, dispone de un gran catálogo de productos de software, muchos desarrollados internamente y otros adquiridos mediante la compra de otras compañías. Dentro del entorno del Business Intelligence este hecho es aún más notable, ya que justamente varias de las últimas adquisiciones de Oracle han sido operaciones de compra de fabricantes de software de BI.

El resultado es que, aunque cada herramienta de BI tiene unas características y un mercado más apropiado, existen muchos solapamientos, y cuesta un poco situarse a la hora de elegir qué software o conjunto de herramientas podríamos utilizar para nuestro proyecto de Business Intelligence.

Para acabar de complicarlo hay que pensar también en las condiciones del licenciamiento y que el software suele comercializarse en suites que agrupan diferentes herramientas bajo un criterio que puede favorecernos o no.

Un buen ejemplo del efecto que esta situación puede provocar es el post Confusión con Oracle Business Intelligence, de Business Intelligence fácil

Yo tampoco soy un experto en el software BI de Oracle, pero voy a hacer un resumen de lo que conozco y me parece importante tener en cuenta de las tres suites que comercializa Oracle para Business Intelligence.

Cabe decir que este no es el único software de BI de Oracle, y que después de la adquisición de Hyperroll aún se complicará más el panorama, pero creo que con esto analizaremos las soluciones más utilizadas.

Las suites de BI Oracle siguen la nomenclatura de las diferentes ediciones de bases de datos que ya conocemos, por lo que ayuda mucho si ya estamos familiarizados con ella. Tenemos una Oracle BI Standard Edition 1 (BISE1), que es la más modesta y orientada a pymes. Después viene la Oracle BI Standard Edition (BISE), que en teoría correspondería a la versión intermedia. La versión más completa es la Oracle BI Enterprise Edition Plus (BIEE), orientada a la gran empresa.

Oracle Business Intelligence Standard Edition (BISE)

Comienzo con la BI Standard Edition porque se diferencia mucho de las otras dos. Esta suite es la que tiene más historia. Es la evolución de las clásicas herramientas de reporting de Oracle, con Discoverer a la cabeza. Es la que tiene el coste menor por usuario nominal, pero no incluye la base de datos. Utiliza IAS para proveer el acceso web a los informes y cuadros de mando.

Oracle BISE Puede encajar en entornos en los que se trabaja casi exclusivamente con Oracle, y no se quiera hacer una inversión demasiado grande para el BI o el reporting. De todas maneras, aunque Discoverer ha mejorado bastante, y ahora hasta puede funcionar en modo OLAP, creo que sigue estando lejos del nivel de herramientas de BI como BI Answers o Hyperion, que Oracle ofrece en las otras suites, y que son fruto de sus adquisiciones. 

De hecho, aunque la suite se sigue comercializando, es bastante complicado encontrarla en la web de Oracle, no parece que la intención sea apostar por ella para el futuro. 

Estos son los productos que incorpora:

• Oracle BI Discoverer: Acceso a los datos tanto Relacional como OLAP y cuadros de mando personalizables.
• Oracle BI Spreadsheet Add-in: Acceso OLAP a los datos desde hojas de cálculo Excel.
• Oracle BI Beans: Para construir aplicaciones de business intelligence a medida.
• Oracle Reports Services: Reporting empresarial de alto nivel de detalle.

Oracle Business Intelligence Standard Edition 1 (BISE1)

Esta es la suite más modesta, muy asequible para pymes. Incluye todo lo necesario para tener funcionando en poco tiempo un sistema de Business Intelligence. Eso si, se ha de instalar todo en un servidor, y este ha de ser un Windows Server.

La licencia no permite utilizar más de dos CPU's del servidor y sólo permite utilizar otra fuente de datos directa aparte de la BD que incluye. El licenciamiento es obligatoriamente por usuario nominal, y se pueden licenciar entre 5 y 50 usuarios. La licencia es fácilmente transformable a una Enterprise, ya que esta última incluye el software de la Standard.

La instalación de Oracle BISE1 se realiza fácilmente, y en un sólo proceso instala en el servidor la base de datos, la herramienta de ETL Oracle Warehouse Builder (la versión básica), el servidor de BI y el resto de aplicaciones.

Este servidor de BI permite acceder por web a la herramienta de reporting analítico y de cuadros de mando, tanto para diseño como para explotación. Todo este entorno viene de la adquisición de Siebel que Oracle hizo ya hace algún tiempo, y su anterior denominación era Siebel Analytics.

Es un entorno de BI muy completo y fácil de utilizar, aunque no utiliza estructuras propias de OLAP, trabaja directamente sobre el modelo Relacional de la base de datos.

Las herramientas que incluye la suite son las siguientes:

• Oracle BI Server: Acceso centralizado a los datos y motor de cálculo que se apoya en un modelo lógico de información empresarial común (nivel de abstracción de los metadatos)
• Oracle BI Server Administrator: Creación de los metadatos y niveles de abstracción
• Oracle BI Answers: Autoservicio ad-hoc que permite a los usuarios finales crear fácilmente diagramas, tablas dinámicas, informes y cuadros de mando, y navegar con capacidades de drill up/down.
• Oracle BI Interactive Dashboards: Cuadros de mando interactivos para entornos de análisis.
• Oracle BI Publisher (también conocido como XML Publisher): Reporting operacional empresarial y distribución de informes con gran nivel de detalle.
• Oracle Database Standard Edition One: Base de datos
• Oracle Warehouse Builder (core ETL): Diseño de base de datos y de extracción, transformación y carga (ETL) que ayuda a gestionar el ciclo de vida de los datos y metadatos.

El proceso básico para llegar a crear informes analíticos o dashboards con esta suite sería:

1. Diseño de la ETL y creación de estructuras dimensionales en tablas con OWB
2. Definición de metadatos y capas Física, de Negocio y de Presentación con Oracle BI Server Administrator
3. Creación de informes analíticos y cuadros de mando con BI Answers e Interactive Dashboards

Para crear y distribuir informes operacionales se puede utilizar de manera autónoma BI Publisher.
Los informes se diseñan con Microsoft Word o Adobe Acrobat (instalando un add-in) y después también se pueden publicar y editar mediante servidor web WebDav.
Este software, aunque se integra con el portal de BI Dashboards es propio de Oracle, y es un poco más engorroso de utilizar. No se suele usar a menos que existan necesidades específicas que no se puedan solucionar con BI Answers. 

Se puede obtener más información sobre Oracle BISE1 en la sección del producto de la web de Oracle.

Para aprender en poco tiempo cómo empezar a trabajar con esta suite, con el apoyo de esquemas de ejemplo que se cargan al instalar el producto, recomiendo especialmente seguir el Tutorial de Oracle Business Intelligence Edition One. 

Oracle Business Intelligence Enterprise Edition Plus (BIEE)

Esta es la suite orientada a la gran empresa y a trabajar con múltiples orígenes de datos.

Está compuesta por todas las herramientas de Oracle BISE1 (exceptuando la base de datos) más algunas complementarias aplicables al mismo entorno, y que amplian la funcionalidad de la misma con utilidades de CPM, monitorización y alertas o para poder utilizar las funciones analíticas en modo desconectado. 

[[ad]] Lo del Plus viene por el software de Hyperion, que se ha añadido para ampliar más aún la funcionalidad disponible, sobretodo en cuanto a utilidades de Reporting Financiero, una de sus mejores bazas. Este software funciona muy bien en modo OLAP, aunque para ello necesita apoyarse en un motor multidimensional, y Oracle BI Server no lo es, aunque con la versión empresarial sí que se pueda conectar a motores OLAP y otros tipos de orígenes de datos . 

En todo caso, para sacar el máximo partido a las aplicaciones de Hyperion lo más indicado es disponer de o adquirir también una base de datos MOLAP como Essbase. También se pueden utilizar otros orígenes Multidimensionales como SAP BW, o Microsoft OLAP.

Si la suite se licencia por usuarios el mínimo es 50, y también se puede licenciar por procesador. No está limitada en cuanto a número de orígenes de datos, usuarios o CPU's más que por el presupuesto disponible.

Como contiene todas las aplicaciones de la versión BISE1, especialmente el servidor de BI, el paso de la versión más modesta a la Enterprise es inmediato, aunque si se quieren utilizar las aplicaciones de Hyperion la cosa se complica un poco más.

Este es el listado de aplicaciones que la componen: (marco en gris las que también forman parte de Oracle BISE1)

• Oracle BI Server: Acceso centralizado a los datos y motor de cálculo que se apoya en un modelo lógico de información empresarial común (nivel de abstracción de los metadatos)
• Oracle BI Server Administrator: Creación de los metadatos y niveles de abstracción
• Oracle BI Answers: Autoservicio ad-hoc que permite a los usuarios finales crear fácilmente diagramas, tablas dinámicas, informes y cuadros de mando, y navegar con capacidades de drill up/down.
• Oracle BI Interactive Dashboards: Cuadros de mando interactivos para entornos de análisis.
• Oracle BI Publisher (también conocido como XML Publisher): Reporting operacional empresarial y distribución de informes con gran nivel de detalle.

• Oracle BI Delivers: Alertas y monitorización proactivas de la actividad del negocio.
• Oracle BI Disconnected Analytics: Funcionalidad analítica completa en modo desconectado para profesionales 'móbiles'. Utiliza técnicas de replicación.
• Oracle BI Briefing Books: Instantáneas de páginas de cuadros de mando para visualizar y compartir en modo desconectado.
• Hyperion Interactive Reporting: Reporting ad-hoc intuitivo e interactivo.
• Hyperion SQR Production Reporting: Generación de informes con formatos de presentación de alta calidad, preparado para trabajar con grandes volúmenes
• Hyperion Financial Reporting: Reporting financiero y de gestión con formateado en 'calidad de libro'
• Hyperion Web Analysis: Análisis, presentación y reporting OLAP basado en web

Más información en la librería de documentación online de BIEE.

Finalmente, comentar que en cuanto a los procesos de ETL, para trabajar con Oracle BIEE lo habitual es adquirir también Oracle Data Integrator ya que esta ETL está preparada para trabajar con diferentes aplicaciones y orígenes o destinos de datos, y en proyectos que utilicen la versión empresarial éste suele ser el caso.

Oracle Warehouse Builder funciona bien y se puede utilizar libremente si se tiene alguna licencia de base de datos, pero está bastante limitado en cuanto a conectores con diferentes orígenes de datos empresariales, y el destino ha de ser siempre una base de datos Oracle. 

Además las referencias a OWB también están comenzando a desaparecer de las listas de productos de la web de Oracle.

De hecho pasan cosas curiosas como que si sigues un enlace a Warehouse Builder ( https://www.oracle.com/us/solutions/ent-performance-bi/index.html) te redirigen directamente a la sección de Oracle Data Integrator (https://www.oracle.com/us/products/middleware/data-integration/index.html), lo cual nos da una buena pista de la ETL de Oracle que va a evolucionar más.

Coméntalo en el foro

Tengo instalado un Oracle Warehouse Builder que está configurado 'a tres capas', con un Windows Server como BD servidora-repositorio principal, una BD destino sobre LINUX, y el cliente del Centro de Diseño un windows XP.
He definido un origen de datos de fichero y para la conexión, en la ubicación de archivos he especificado un directorio que 've' la máquina XP.

Esto me permite hacer todo correctamente, hasta que quiero iniciar la carga, momento en que el centro de control me devuelve el siguiente error:
Y:\Dimensiones\Geografia\CARGA_POBLACIONES.ctl (El sistema no puede hallar la ruta especificada)

Supongo que el problema es que hay que definir el origen del fichero con un path al que se pueda acceder desde el servidor del repositorio, o el de destino.

Estoy en lo cierto? Con copiar los archivos a uno de estos servidores tendría suficiente para poder preparar la carga?

Gracias por anticipado,

Para poder organizar y poder definir y automatizar flujos de proceso con los mappings de OWB hay que utilizar Oracle Workflow.

En teoría la instalación es muy sencilla, pero yo estoy teniendo bastantes problemas. Alguien conoce una guía sobre cómo hacerlo sobre un Linux?

Tampoco me aclaro mucho sobre las diferentes versiones que hay. Oracle lo tiene en su web directamente como producto Oracle Workflow Server, o como parte de la base de datos 10g, en el companion CD, aparte de la versión que viene embedida en Oracle E-Business Suite, que no sé si se corresponde a alguna de las anteriores o es otra 'especial'.

Además está la opción 'stand alone' y la 'middle tier', que no sé exactamente en qué consisten cada una, ni cómo decidir cuál quiero, pero me conformo con una que me funcione en la misma base de datos, y con el Warehouse Builder que tengo también en el mismo servidor, no necesito acceder por web.

Alguien sabe cómo lo tendría que hacer?

Oracle, tras la compra de la empresa Sunopsis, ha lanzado al mercado la nueva herramienta Oracle Data Integrator (ODI), basada en la que comerciaba esta compañía.

Esta herramienta entra en el segmento de las de E-LT, o de Extracción, Carga y Transformación (una evolución del concepto de ETL), y aporta más flexibilidad, mayor capacidad de integración con diferentes fuentes y destinos de datos, y realiza los procesos de transformación dentro de los mismos servidores de bases de datos, de ahí el cambio en el orden de las siglas E-LT, al realizarse así el proceso de Transformación normalmente después que el de Carga.

Se puede consultar más información sobre la misma en Lanzamiento de Oracle Data Integrator.

Con esta noticia queda claro porqué Oracle Warehouse Builder se puede utilizar libremente desde hace ya un tiempo si se ha adquirido la licencia de algún servidor de base de datos Oracle. Tenemos una nueva herramienta que nos va a hacer plantearnos si OWB se ha quedado obsoleto. Ahora sólo falta evaluar hasta qué punto las mejoras que aporta el nuevo software compensan el coste de adaptación y de la licencia.

En el enlace Managing Data Quality se puede acceder a un artículo de Ron Hardman sobre cómo realizar procesos de limpieza de datos con Oracle Warehouse Builder.

El artículo comienza con una introducción a la calidad de los datos y maneras de gestionarla, siendo una de ellas la utilización de las opciones de limpieza de datos de Oracle Warehouse Builder.

Lo interesante es que se muestra cómo descargar un script con datos de prueba, y cómo configurar la herramienta para probar las utilidades de Profiling, definición de Reglas (Data Rules), y corrección o limpieza de los datos. De esta manera se puede ver y probar de manera sencilla cómo implementar un proceso básico de Data Cleansing con esta herramienta.

El artículo original está en inglés pero buscando en la web de Oracle he encontrado los 3 documentos que adjunto, traducidos al castellano, y relacionados con OWB y la limpieza de datos:

• Informe Ejecutivo - Oracle Warehouse Builder 11g Versión 1 Información General
• Oracle Warehouse Builder Data Quality Option
• Oracle Warehouse Builder Enterprise ETL Option

We show a summary of capabilities of this tool integrated in the Oracle BI suite including the features included in version 11g.

There is also a standalone version of XML Publisher Enterprise independent from Oracle suite. Oracle BI Publisher allows to publish and distribute reports in the field of enterprise-wide operational reporting detail. These reports can be created from the same portal (DHTML editor). It has a graphical interface that greatly facilitates the work. In terms of SQL, allows you to write sentences directly or help a Query Builder. A major advantage of the tool is that the report design can be based on templates made with Microsoft Word, Excel or Adobe Acrobat. Oracle BI Publisher also offers support for Adobe Flex, so you can create Flex templates, format for creating interactive reports and forms. BI Publisher separates the creation of the data (XML) formatting. The engine can deal with any XML data, allowing integration with any system that generates XML as Web services or any JDBC data source. BI Publisher can merge different data sources into a single output document. As for distribution of reports counts with a scheduler that allows us to schedule delivery of the report. We have different distribution platforms as fax, print, mail and published on the site.
Similarly allows multiple output formats as: pdf, rtf, html, xml, xls, etc.. BI Publisher is based on the W3C XSL-FO standard. BI Publisher is a J2EE application that can be deployed in any J2EE container. To summarize is a great alternative to publish any report of high fidelity.

Oracle Data Integrator es la herramienta de integración de datos de Oracle. Es la apuesta de Oracle en cuestiones de integración de datos y sustituye a OWB (Oracle Warehouse Builder). Forma parte de la solución OFM (Oracle Fusion Middleware) y está totalmente integrada con otras soluciones Oracle relacionadas con la gestión de datos:

• Oracle Data Profiling
• Oracle Exadata
• Oracle Business Intelligence
• Oracle SOA Suite
• Oracle Database
• Oracle Data Warehousing
• Oracle Master Data Management

Repasamos brevemente las principales funcionalidades y novedades de la versión 11 de esta herramienta:

Conectividad:

La actual versión 11g, permite una extensa conectividad con la mayoría de las bases de datos, ERPs, CRMs, sistemas B2B, ficheros planos, ficheros XML, directorios LDAP, conexiones vía ODBC, JDBC y una muy conseguida integración con arquitecturas SOA.

Funcionalidades de integración de datos:

ODI simplifica bastante todas las tareas de integración y gestión de datos caben destacar los siguientes puntos:

• Población y actualización entornos Data Warehouse: Ejecución de procesos con alto volumen de datos, obteniendo excelentes tiempos de respuesta. Actualización de data warehouses, data marts, cubos OLAP y sistemas analíticos en general. Gestiona de forma transparente las cargas totales o incrementales, considera dimensiones SCD (Slowly Changes Dimensions), asegura la integridad y consistencia de datos y facilita la trazabilidad del dato (origen del dato, detalle de transformaciones y destino del dato). Procesos de integración de datos basados en datos de entrada, procesos batch, eventos y ejecución de servicios.
• Arquitecturas Orientadas a Servicios (SOA): Permite desarrollar servicios de integración de datos (acceso a datos, validaciones, transformación, volcado de datos, etc.) para su posterior integración de forma poco costosa en infraestructuras basadas en arquitecturas SOA, dotando a esta infraestructura de capacidades para gestionar altos volúmenes de datos, alto rendimiento en los procesos y volcados de datos masivos. 
• Master Data Management (MDM): Facilita la gestión de datos maestros con funcionalidades para la sincronización de datos. Permite la conexión entre los datos maestros y el Data Warehouse, asegurando la integridad entre las dimensiones y jerarquías MDM y las tablas de hechos del Data Warehouse. Actualización de MDM data hubs (concentradores de datos con tablas de referencias cruzadas a todos los sistemas fuente) para cada uno de los dominios de los maestros de datos (ejemplo : cliente, producto, etc..). Integración con procesos BPEL (Business Process Execution Language)y los servicios webs compuestos por este lenguaje de orquestación. 
• Procesos de migración de datos: Gestiona volcados de datos masivos entre sistemas antiguos y los nuevos sistemas de forma eficiente, pudiendo incluir en el movimiento de datos transformaciones complejas, así como la sincronización de datos entre ambos sistemas durante su periodo de coexistencia.

Arquitectura E-LT:

ODI modifica el tradicional concepto ETL (Extract, Transform, Load), pasando a E-LT (Extract – Load, Transform). La arquitectura E-LT extrae los datos de los sistemas fuente, los carga en base de datos y realiza todas las transformaciones en la propia base de datos. En el tradicional ETL el proceso de transformación puede ser realizado en un entorno hardware y software diferente al de la base de datos de destino, mientras que en un esquema E-LT la transformación y el volcado se realizan en una misma plataforma hardware y software. Lógicamente un esquema E-LT reduce el tráfico de datos, pero hay que dotar al motor de la base de datos de destino de capacidades de transformación y movimiento de datos potentes, capacidades que provee ODI. Así mismo, ODI permite realizar dentro de la base de datos transformaciones complejas al mismo nivel que el servidor que realiza la capa de transformación en un ETL convencional.

Considerar igualmente que una arquitectura E-LT se realiza toda la optimización de recursos (disco, memoria, proceso) en la base de datos, lo cual permite una configuración del rendimiento más centralizada. La propia ejecución de las transformaciones puede ser diferente en una arquitectura y otra, ya que hay herramientas ETL que evalúan las transformaciones registros a registro y en el caso E-LT se realiza por lotes de registros. ODI permite combinar la potencia del motor de la base de datos con las prestaciones hardware que Oracle puede ofrecer alcanzando una arquitectura E-LT de alto rendimiento.

Alta productividad en el diseño de procesos de integración de datos:

ODI introduce un entorno de desarrollo basado en JDeveloper que reduce los tiempos de desarrollo y permite diseñar de forma intuitiva procesos de transformación y volcado de datos complejos. Nuevas funcionalidades como ‘quick-edit’ implementan de forma sencilla actualizaciones masivas.

Uno de los principales objetivos de ODI es centrar a los desarrolladores y a los usuarios de negocio en describir las transformaciones a realizar, sin necesidad de invertir mucho tiempo en los aspectos técnicos relativos a la implementación de estas transformaciones. ODI plantea al desarrollador un diseño declarativo más centrado en las necesidades de transformación que en los procedimientos. Permite centrarse en ‘qué hacer’, en lugar de ‘cómo hacer’. El diseñador describe las fuentes origen y destino y los procesos de transformación e integración, ODI genera los procedimientos y el código necesario para implementarlos.

Alta disponibilidad y escalabilidad:

ODI se integra con la plataforma Oracle Fusion Middleware. En esta plataforma ODI ofrece sus componentes como aplicaciones Java EE, optimizados para aprovechar al máximo las capacidades de su servidor de aplicaciones Oracle WebLogic. Los componentes ODI están provistos de funcionalidades que permiten su despliegue en un entorno de alta disponibilidad, escalabilidad y seguridad. Los componentes de ODI desplegados en el servidor de aplicaciones WebLogic se benefician de las funcionalidades de este en cuestiones relativas a escalabilidad, pooling de conexiones JDBC y balanceo de carga de trabajo. Igualmente ODI puede beneficiarse de las capacidades de trabajo de bases de datos en grupo (clusters, grupos de máquinas) que permite Oracle RAC (Real Application Clusters), con todas las capacidades que conllevan un motor de base de datos de alta disponibilidad de estas características.

Gestión y administración centralizadas (consola ODI):

La consola de ODI se realiza en un entorno bajo un framework Ajax que mejora la experiencia de usuario (ADF Oracle Application Development Framework). Desde esta consola se pueden crear entornos de trabajo, realizar exports e imports de repositorios de datos, controlar procesos, monitorizar sesiones, control y seguimiento de errores, diseñar procesos, realizar informes de trazabilidad, etc..

Esta interfaz se integra con la Enterprise Manager Fusion Middleware Control y permite a los administradores monitorizar no sólo los componentes de integración de datos ODI, sino todos los componentes de la plataforma Oracle Fusion Middleware.

ODI Knowledge Modules:

Los Knowledge Modules son el núcleo de la arquitectura ODI. Proveen a la arquitectura Oracle de flexibilidad, modularidad y fácil ampliación. Soportan plataformas de terceros, heterogéneas fuentes de datos y data warehousing appliances. Los KM implementan los flujos de datos y definen plantillas para generación de código involucrando diferentes sistemas y plataformas. Los KM permiten la creación de flujos de datos sin que la complejidad de las reglas de transformación cambie su diseño. Por otro lado, son muy específicos ya que los procesos y el código generado están orientados y optimizados a la tecnología de base con la que se integran. ODI dispone de una librería de módulos KM para adaptarlos a medida definiendo unas mejores prácticas.

Lista de KM disponibles:

Generic SQL,Hypersonic SQL,IBM DB2/400, DB2 UDB, Informix, JD Edwards Enterprise One, JMS, Microsoft Access, Microsoft SQL, Netezza, Oracle Database, Oracle Data Quality for Data Integrator, Oracle E-Business Suite, Oracle Enterprise Service Bus, Oracle GoldenGate, Oracle Hyperion Essbase, Financial Management, Planning, Oracle OLAP, Oracle PeopleSoft , Oracle Siebel CRM , SalesForce, SAP ERP & BW , SAS, Sybase ASE, Sybase IQ  y Teradata.

Información más extensa sobre la herramienta en la propia site de productos de Oracle: 'https://is.gd/lY8xD9'

Oracle SQL Developer es la herramienta gráfica gratuita que proporciona Oracle para que no sea necesario utilizar herramientas de terceros (como el conocido TOAD, o el PL/SQL Developer) para desarrollar, o simplemente para ejecutar consultas o scripts SQL, tanto DML como DDL, sobre bases de datos Oracle.

[[ad]] La apariencia y funcionalidad es similar a la de otras herramientas de este tipo, por lo que es una buena opción si no tenemos especial predilección por otras herramientas.

Además en las últimas versiones ha incorporado mejoras como permitir conectar con bases de datos no Oracle, como SQLServer, MySQL o Access. La conexión con MySQL o SQLServer se realiza a través de JDBC, y de manera bastante sencilla. Una vez establecida la conexión se pueden explorar los objetos de las bases de datos como si se tratara de una de Oracle, y ejecutar sobre ellas sentencias SQL, aunque en cuanto a funcionalidades más avanzadas como la creación de estructuras este tipo de conexión estará mucho más limitada.

Se puede consultar más información o descargar la herramienta en www.oracle.com/technology/software/products/sql/index.html

Conectar Oracle SQL Developer con MySQL

A modo de ejemplo comentaré los sencillos pasos que se pueden seguir para poder utilizar SQL Developer con una BD MySQL:

• Descargar y descomprimir el driver JDBC para MySQL, que se puede obtener en la zona de descargas de conectores de la web de MySQL.
• En el directorio generado localizar el archivo .jar, que es el binario que contiene el conector. El nombre ha de ser algo así como 'mysql-connector-java-...-bin.jar'. Para que lo tengáis aún más fácil adjunto la versión 5.1.7, que es la que yo he utilizado ahora.
• En la opción de menú Herramientas, entrar en Preferencias.. y abrir las opciones de Base de datos y seleccionar Controladores JDBC de Terceros. Hacer click sobre el botón Agregar Entrada, y con el explorador de archivos seleccionar el archivo .jar que hemos descargado.
• Después de esto, en la ventana que se abre al agregar conexiones os debería aparecer una nueva pestaña MySQL que permite definir una conexión con MySQL.

Conectar Oracle SQL Developer con SQL Server y Sybase

Comento también los pasos que se pueden seguir para poder utilizar SQL Developer con una BD SQL Server o Sybase, aunque lo único que cambia es el driver que se utiliza:

• Descargar y descomprimir el driver JDBC para SQL Server/ Sybase. El proyecto open source jTDS proporciona un driver que sirve para ambas bases de datos. Sólo hay que seleccionarlo de la sección de Download
• En el directorio generado localizar el archivo .jar, que es el binario que contiene el conector. El nombre ha de ser algo así como 'jtds-... .jar'. Para que lo tengáis aún más fácil adjunto la versión 1.2.3, que es la que yo he utilizado ahora.
• En la opción de menú Herramientas, entrar en Preferencias.. y abrir las opciones de Base de datos y seleccionar Controladores JDBC de Terceros. Hacer click sobre el botón Agregar Entrada, y con el explorador de archivos seleccionar el archivo .jar que hemos descargado.
• Después de esto, en la ventana que se abre al agregar conexiones os debería aparecer una nueva pestaña MySQL que permite definir una conexión con MySQL.

Coméntalo en el tema Oracle SQL Developer del foro