blog de Oscar_Paredes

A mediados del mes de Marzo de este año, Oracle anunciaba que dejaba de desarrollar productos para plataformas con procesador Itanium. Indicaba que otros fabricantes ya lo estaban haciendo (Red Hat y Microsoft), y apelaba a conversaciones con Intel para tomar su decisión.

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

En la release 2 de Oracle 11g, se introduce un nuevo producto Oracle Real Application Clusters One Node (Oracle RAC One Node).

La definición rápida del producto seria: es una instancia de Oracle RAC pero ejecutado en 1 único nodo. No es que sea una única máquina física, puede estar corriendo en diversos servidores físicos (de hecho, es lo habitual) sino que una instancia de Base de Datos está ejecutándose únicamente en 1 nodo al mismo tiempo (* aunque ya veremos que está afirmación no es del todo cierta).

Lo más fácil es ver un esquema para entenderlo a la perfección:

En este esquema, tenemos 3 servidores físicos que contienen un total de 5 instancias Oracle ejecutándose con Oracle RAC One Node.  Cada nodo tiene un S.O., es decir, no son máquinas virtuales distintas.

Cuáles son sus ventajas más destacables:

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

Con la versión 9.7 de DB2 LUW, IBM hace un guiño a todos los DBA's de Oracle, mucho más numerosos en el mercado que los de DB2.

Para ello, en la versión 9.7 ha introducido modos de compatibilidad de Oracle que permiten realizar tareas en DB2 con la facilidad y conocimiento que todos los DBA's de Oracle tienen. Sin embargo, es importante conocer la traslación de terminología entre Oracle y DB2 si tienes la intención de meterte en el mundo IBM DB2.

En este primer artículo, relaciono una serie de elementos para que esa introducción sea sencilla y se pueda leer documentación de DB2 fácilmente. Entre ellos, terminología general, versiones, utilidades y vistas.

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

A partir de la información de las instantáneas, se puede obtener el tamaño de las tablas en bases de datos IBM DB2 (datos, longs, lobs) y de todos sus indices.
 

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...
 

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:

    ....

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 anterior 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 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...