El rendimiento de una base de datos relacional, y en particular una base de datos Oracle, depende principalmente del rendimiento de las sentencias SQL que en ella se ejecutan. A partir de la versión 10g Release 2, Oracle declara obsoleto el optimizador basado en la regla (“RULE”), es decir, desde la versión 10.2.0.1, en adelante, el único optimizador soportado por Oracle, es aquel basado en el costo (“COST”).

En la optimización por costo de sentencias SQL, Oracle determina los planes de ejecución óptimos de cada sentencia, a partir de estadísticas de tablas e índices involucrados en cada instrucción SQL. Dichas estadísticas deben ser recolectadas previamente, y actualizadas en forma periódica.

Nunca me imaginé que yo podria estar escribiendo estas palabras en homenaje a nuestro querido amigo Alejandro Hernandez Ladrón de Guevara (QEPD). Una repentina enfermedad y la voluntad de Dios, hizo que él ya no esté fisicamente con nosotros. Tantas cosas buenas se han dicho de Alejandro y tantas cosas buenas se dijeron de él en su funeral. Yo quisiera recordar algunas de ellas, aquí, en este blog, en el cual Alejandro hizo uno de sus tantos aportes.

Como se ha visto en clases, es posible renombrar (o mover) un Datafile posterior a su creación, por ejemplo cuando se crea un nuevo Tablespace, o cuando éste se modifica agregando nuevos archivos utilizando la sentencia:

SQL> ALTER TABLESPACE <nombre> ADD DATAFILE ‘/path’ SIZE <n> M;

Si por ejemplo, se ha cometido un error en el nombre o la extensión del archivo no sigue la norma definida  (que típicamente es *.dbf) es posible hacer el cambio de nombre, sin necesidad de bajar la BD realizando los 4 pasos siguientes:

1. Poner el Tablespace en modo OFFLINE, por ejemplo:

SQL> ALTER TABLESPACE DATOS OFFLINE;

2.  Renombrar el archivo físico, por ejemplo en linux sería:

$ mv  datos02.dfb  datos03.dbf

3. Modificar el Tablespace para que reconozca el nuevo archivo:

Como una manera de satisfacer algunas dudas de nuestros visitantes, escribo este pequeño post.

La “i” aparece por primera vez en el lanzamiento de Oracle 8i (8.1.7.x), que revolucionó el mercado por ahi por 1998. La “i” simplemente significa Internet. Estamos en plena revolución de las empresas .COM, y todo lo que tuviera relación con Internet era “fashion”. Oracle lanza la primera base de datos para soporte de aplicaciones internet. Esto significa que viene con características de mayor alta disponibilidad -las aplicaciones internet son por definición 7×24-, además de traer java embebido en el motor, un lenguaje que nace para construir aplicaciones internet. El motor trae una seria de APIs que le permiten a los desarrolladores  la construcción de aplicaciones web. Además, el motor viene preparado para manejar todo tipos de datos multimedial (opción oracle intermedia), tales como documentos, imágenes, sonido, propio del mundo internet. Si a esto le agregamos el soporte para guardar datos en XML, un lenguaje de marcas que generaliza el HTML de los navegadores, hace de esta versión oracle 8i una de las más populares y robusta. Mucha de la arquitectura actual del motor fue concebida en esta versión. A pesar de que esta versión ya se encuentra largamente desoportada, muchos clientes mantienen operando aplicaciones basadas en esta versión producto de su estabilidad y buenas prestaciones.

1. Crear Usuarios y asignar privilegios en Oracle

El siguiente es un resumen de algunas consideraciones al momento de crear un usuario o cuenta en Oracle, y los privilegios y roles que le podemos asignar.

• El nombre de usuario no debe superar 30 caracteres, no debe tener caracteres especiales y debe iniciar con una letra.
• Un método de autentificación. El mas común es una clave o password, pero Oracle 10g soporta otros métodos (como biometric, certificado y autentificación por medio de token).
• Un Tablespace default, el cual es donde el usuario va a poder crear sus objetos por defecto, sin embargo, esto no significa que pueda crear objetos, o que tenga una cuota de espacio. Estos permisos se asignan de forma separada, salvo si utiliza el privilegio RESOURCE el que asigna una quota unlimited, incluso en el Tablespace SYSTEM!  Sin embargo si esto ocurre, ud. puede posteriormente mover los objetos creados en  el SYSTEM a otro Tablespace.

Hoy día existe un amplio consenso entre los gerentes de empresas y gerentes de las áreas de TI sobre la importancia que tiene la información y por ende, la importancia que tiene toda la infraestructura que permite mantener segura y disponible esa información para los diferentes agentes de la organización que la requieran. Esta información se encuentra en su mayor parte en plataformas de bases de datos que prestan variados servicios tales como seguridad, alta disponibilidad, manejo de concurrencia de usuarios y otras importantes prestaciones.

No obstante la claridad anterior que manifiestan los gerentes de las áreas de TI, no existe tanta claridad sobre las características, habilidades y conocimientos que debe tener el profesional que garantice el correcto manejo de estas bases de datos (DBA). El artículo que a continuación se desarrolla resume algunas ideas acerca de las viejas  y nuevas responsabilidades del Administrador de Bases de Datos, denominadas DBA 1.0 y DBA 2.0 respectivamente.

Frecuentemente el dba oracle debe cambiar la ubicación de la base de datos, ya sea por mantención, o por una migración a una nueva plataforma. La técnica para realizar esto es montar la base de datos con el archivo de control ya ubicado en su posición final, e informarle al archivo de control sobre la nueva ubicación que tienen los datafiles (V$DATAFILE) y redolog files (V$LOGFILE). Se debe recordar que el archivo de control es el que guarda la metadata de estructura física de la base de datos. Esto se hace con el siguiente comando:

SQL> ALTER DATABASE RENAME FILE ‘/u01/app/oracle/oradata/sirio/system01.dbf’ TO ‘/u02/oradata/sirio/system01.dbf’ ;

Donde ‘/u01/app/oracle/oradata/sirio/system01.dbf’ es el nombre original del archivo y ‘/u02/oradata/sirio/system01.dbf’ es el nuevo nombre y ubicación del archivo.

En versiones anteriores a Oracle 11g, al añadir columnas con propiedad not null con valor default a una tabla con muchos registros suele ser costoso para la base de datos ya que al realizar esta acción se producen ciertos eventos que afectan a la performance de esta, como por ejemplo la generación de redologs switch, undo, aumento excesivo del SCN de la bd.

He aquí una demostración realizada en una base de datos versión 10gR2, sobre una tabla con una cantidad de registros más o menos considerable.

SQL> select count(1) from datos_prueba;

COUNT(1)

———-

2000000

Transcurrido: 00:00:00.07

• · Verificando la secuencia de redolog switch de la instancia.

SQL> archive log list

Es muy común que los DBAs traten dentro de los ambientes OLTP evitar este tipo de accesos a los datos. Sabemos que este acceso es lento para tablas grandes, pero también sabemos que es muy usado en tablas pequeñas. Veamos como podemos sacar provecho de la eliminación o uso del no muy bien ponderado full table scan.

Vamos a empezar a ver algún ejemplo práctico: Vamos a crear una tabla mas o menos masiva a partir de otra ya existente:

[oracle@antares ~]$ sqlplus “/as sysdba”

SQL*Plus: Release 9.2.0.8.0 – Production on Tue Mar 3 17:06:31 2009

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
Connected to:
Oracle9i Release 9.2.0.8.0 – Production
JServer Release 9.2.0.8.0 – Production

A menudo sucede que en instancias de SQL Server que poseen bastantes jobs programados, la tarea de buscar las causantes de estas fallas se hace engorrosa. La información y la causa del error de la ejecución de algún job es dificil de visualizar desde enterprise manager tomando en cuenta que este no nos dá mayor detalle de que fue lo que ocurió bajo esas circunstancias:

Ese problema se puede solucionar a través de la siguiente query, solo válida para SQL Server 2000. Esta devuelve Los trabajos que fallaron, algunas características del job y también la causa de que el Job fallara. Este script es bastante útil, ya que aunque se nos olvide escribir la salida del proceso al event log de Windows o a una tabla de sistema, con este pequeño script podremos averiguar lo que sucedió: