El diccionario de datos PL/SQL en las bases de datos Oracle

Si habéis llegado hasta este artículo es muy probable que tengáis que escribir en algunas ocasiones código PLSQL. Esto quiere decir que también, al menos ocasionalmente, necesitaréis analizar dicho código contestando cuestiones como:

• ¿De qué objetos de la base de datos depende mi programa?
• ¿Cuáles de mis paquetes PL/SQL contienen llamadas a subprogramas en otros paquetes o referencias a variables globales?
• ¿Contiene alguno de mis subrutinas PLSQL parámetros con tipos de datos que no se deberían seguir utilizando?
• ¿Están todo mi código compilado con el suficiente nivel de optimización?

Obviamente, siempre podréis utilizar las funcionalidades de búsqueda de vuestro editor PL/SQL o de vuestro sistema integrado de desarrollo para navegar a través de los múltiples objetos y ficheros de la base de datos Oracle tratando de encontrar específicos pedazos de texto. Pero esto no sería suficiente para poder contestar todas las preguntas anteriores y algunas más que os pudieran surgir. Con este artículo y algunos más que escribiré más adelante podréis conocer las respuestas a dichas preguntas, y para ello hay que conocer en que consiste el diccionario de datos PLSQL de las bases de datos Oracle.

Gestión de errores en PL/SQL: generación de excepciones desde el código

En la mayoría de los casos, cuando una de nuestras aplicaciones PLSQL genera una excepción, es la base de datos Oracle la encargada de notificarlo automáticamente. Es decir, un programa PL/SQL reportará un error si durante la ejecución del mismo ocurre algún tipo de problema que la base de datos Oracle no puede manejar por si sola y nuestro código no tiene control sobre el mismo (ver artículo sobre el manejo de excepciones con PL/SQL).

Lo que muchos programadores desconocen es que PLSQL permite generar excepciones desde el propio código. ¿Por qué el código PL/SQL permite esto? Porque no todos los errores en una aplicación son debidos a fallos de procesamiento internos de la base de datos Oracle. También es posible que determinadas condiciones en los datos constituyan un error para nuestra aplicación, en cuyo caso necesitaremos parar nuestro programa y, con mucha probabilidad, notificar al usuario de que algo va mal.

¿Cómo elegir un dominio web sólido para entornos profesionales, proyectos técnicos y aplicaciones empresariales?

Cuando planificas un proyecto técnico o empresarial, el dominio web no es un simple nombre bonito. Su elección influye directamente en la infraestructura digital que sostendrá tus servicios, afectando DNS, certificados de seguridad y despliegues automáticos. Seleccionar un dominio adecuado desde el inicio evita dolores de cabeza posteriores y mejora la percepción profesional de tu proyecto.

Además, un buen dominio ayuda a mantener ordenadas las dependencias entre entornos de desarrollo, staging y producción, mientras que una estructura de nombres pensada facilita la integración con sistemas cloud y pipelines de CI/CD. Esta organización evita conflictos entre subdominios y facilita la escalabilidad del proyecto a medida que crece la base de usuarios o servicios.

La vista ALL_IDENTIFIERS, usos y funcionalidades (2)

Ya escribí con anterioridad un articulo introductorio sobre la vista ALL_IDENTIFIERS. ALL_IDENTIFIERS muestra información relevante sobre todos los identificadores de los objetos PL/SQL o unidades de programa almacenados en la base de datos Oracle a los que tiene accesos un determinado usuario.

Las columnas clave de la vista ALL_IDENTIFIERS son:

• OWNER: El propietario de objeto PL/SQL o unidad de programa que contiene el identificador.
• NAME: Nombre del identificador.
• TYPE: Tipo de identificador (por ejemplo, FORALL OUT, CONSTANT, PACKAGE o RECORD).
• SIGNATURE: Cadena única asignada a cada identificador, útil para poder distinguir entre los diferentes identificadores que tienen el mismo nombre.
• OBJECT_NAME: Nombre del objeto o unidad de programa que contiene el identificador.
• OBJECT_TYPE: Tipo del objeto o unidad de programa que contiene el identificador (por ejemplo, PACKAGE, TRIGGER o PROCEDURE).
• USAGE: Tipo de uso del dentificador.
• USAGE_ID: Identificador único del uso del identificador.
• USAGE_CONTEXT_ID: Clave foránea que identifica el USAGE_ID de su registro padre (por ejemplo, el registro padre de un parámetro de una función o procedimiento dentro de un paquete PLSQL sería la propia función o procedimiento).
• LINE: Número de la línea de programa donde aparece el identificador.
• COL: Número de columna en la línea de programa donde aparece el identificador.

Vistas USER_ARGUMENTS y DBA_ARGUMENTS para analizar los argumentos de funciones y procedimientos

USER_ARGUMENTS y DBA_ARGUMENTS son dos vistas realmente útiles para los programadores de PL/SQL. Contienen información sobre los argumentos, también llamados parámetros, de cada uno de los programas almacenados en nuestro esquema (USER_ARGUMENTS) o en toda la base de datos Oracle (DBA_ARGUMENTS, el acceso a esta vista suele estar restringido a los administradores de la base de datos). Al mismo tiempo, ofrece una gran cantidad de información muy bien diseccionada y estructurada.

Las columnas clave de esta vista son:

Gestión de errores en PLSQL - Visión general

Incluso si fuéramos capaces de escribir un programa PL/SQL absolutamente perfecto, es altamente probable que algo pueda ir mal y se produzcan errores durante la ejecución. La manera en que nuestro código responde frente a estos errores, a menudo determina la diferencia entre una aplicación que funciona correctamente y otra que da continuos problemas a los usuarios y a los encargados de su mantenimiento.

Este es el primer artículo de una serie que escribiré sobre la gestión de errores en PLSQL. En ellos podréis leer sobre: los diferentes tipos de excepciones que se pueden dar; cuándo, cómo y por qué se generan excepciones; cómo definir nuestras propias excepciones; como manejar las excepciones cuando estas se producen; y cómo es posible informar a los usuarios cuando aparece un problema.

Tablas externas en PL/SQL

Las tablas externas en PLSQL permiten hacer consultas desde una base de datos Oracle sobre datos almacenados en un fichero de texto como si dicho fichero fuera una tabla de la base de datos. En Oracle 9i, sólo se podían realizar operaciones de lectura con las tablas externas; en cambio, desde la versión Oracle 10g, se puede también escribir datos en una tabla externa que será creada en ese momento, es decir, no se puede utilizar una tabla externa que ya existe para realizar esta operación.

Aunque se pueden hacer consultas sobre las tablas externas, éstas no permiten todas las funcionalidades que permite Oracle sobre tablas normales. Por ejemplo, no es posible realizar algunas operaciones DDL (sentencias de definición de objetos como revoke, grant, etc.) sobre tablas externas aparte de la creación y actualización de la definición de la misma; por lo tanto no es posible crear índices sobre una tabla externa.

Inicialización y asignación de valores a colecciones PL/SQL

Cuando se trabaja en PLSQL con tablas anidadas y varrays (ver artículo sobre los tipos de dato colección del PL/SQL), es necesario inicializar la variable colección antes de que pueda ser utilizada. Para conseguir esto se puede utilizar la denominada función constructora, una función que la base de datos Oracle crea de forma automática cuando se declara la variable colección.

Los que hace la función constructora es construir una instancia del tipo correspondientes al de la función. La función puede ser llamada sin utilizar argumento alguno, aunque también se le pueden pasar una o más expresiones del mismo tipo que sean elementos de la colección PL/SQL, elementos que se insertarán en la colección.

Consultas jerárquicas en PL/SQL (cláusulas START WITH y CONNECT BY PRIOR)

Cuando nos encontramos ante una tabla en la que los datos se encadenan siguiendo una estructura jerárquica (es decir, existen registros padre y registros hijo), puede llegar a ser necesario recuperar los datos de forma recursiva, mostrando la estructura jerárquica o la relación existente entre unos datos y otros.

Si todavía no tenéis claro de que estoy hablando, sólo tenéis que mirar a la estructura tipo árbol que aparece en la figura, donde vemos que del presidente de una empresa (nodo principal) cuelgan tres directores (nodos descendientes de primer nivel), de estos 6 supervisores (nodos descendientes de segundo nivel) y así hasta llegar a los empleados que no tienen gente a su cargo.

Uso de Rollback Segments por sentencias SELECT

En alguna ocasión algún lector me ha preguntado, con cierta sorpresa, acerca del por qué una sentencia SELECT le fallaba con el mensaje de error "No es posible ampliar el segmento de rollback" ("Unable to extend rollback segment"). La sorpresa proviene del hecho de que son muchos los desarrolladores PL/SQL los que piensan que los segmentos de rollback sólo se utilizan cuando se emplean sentencias PLSQL en las que se modifican o actualizan datos dentro de la base de datos Oracle. Bajo este tipo de pensamiento es normal que, cuando se produce el error mencionado anteriormente al ejecutar una sentencia SELECT, uno se pregunte: ¿utiliza la base de datos Oracle segmentos de rollback al ejecutar sentencias SELECT?

Bueno, en mi opinión, lo primero que hay que hacer es reformular la pregunta y cambiarla por la siguiente: ¿una sentencia SELECT necesita crear o leer segmentos de rollback? La pregunta formulada de esta manera seguro que nos ayudará a comprender mejor este artículo, ya que el verbo "utilizar" usado en la primera pregunta no es lo suficientemente específico.