Asignación de permisos (ROLES) a los programas PLSQL

Con anterioridad a la versión 12c de la base de datos Oracle, un procedimiento PLSQL o unidad de programa con privilegios definidos a través de la cláusula AUTHID DEFINER siempre se ejecutaba con los privilegios del propietario del programa. Por otro lado, cuando la misma unidad de programa se definía utilizando la cláusula AUTHID CURRENT_USER, dicho programa siempre se ejecutaba con los privilegios del usuario que lo ejecutaba.

Disponer de solo estas dos formas de utilización de la cláusula AUTHID limitaba bastante la funcionalidad de las bases de datos Oracle en cuestión de seguridad, ya que cuando un usuario necesitaba ejecutar un programa PL/SQL determinado, dicho usuario tenía que tener los mismos privilegios que el propietario del programa. El problema de seguridad se agravaba mucho más cuando eran todos los usuarios los que necesitan tener acceso a dicho programa.

¿Qué es la creación diferida de segmentos (Deferred Segment Creation)?

En las versiones anteriores a la release 2 de la base de datos Oracle 11g, cuando se creaba cualquier objeto en la base de datos utilizando una sentencia SQL o PL/SQL, ya fuera un tabla, un índice o cualquier otro objeto que requiriese ser almacenado, el gestor de la base de datos creaba los segmentos necesarios y asignaba un tamaño inicial a los mismos, un tamaño que podía ser pequeño, de unos 64 Kbytes mínimo, pero dicho espacio ya no podía ser utilizado para otras necesidades. En los tiempos actuales, un tamaño de 64 Kbytes no es nada, pero si algo tan pequeño se tienen que repetir muchas veces, entonces el consumo de recursos de almacenamiento puede llegar a ser bastante grande.

Por ejemplo, podemos pensar en alguna aplicación que necesitase crear cientos o miles de tablas, tablas que nunca van a ser utilizadas pero cuyos segmentos de almacenamiento tienen que ser creados de todas formas. Algunos pueden preguntarse por qué un aplicación puede necesitar crear tablas que nunca van a ser utilizadas, este hecho no es tan extraño ya que existen muchas aplicaciones, como por ejemplo Oracle Financials, que ofrecen funcionalidades que requieren el uso de determinadas tablas y dichas tablas sólo contienen datos cuando se hace uso de dichas funcionalidades. Para evitar el consumo de almacenamiento en este tipo de situaciones, la release 2 de la base de datos Oracle 11g incorpora una nueva funcionalidad conocida como creación diferida de segmentos (Deferred Segment Creation), funcionalidad que a continuación explicaremos y analizaremos.

Cláusula WITH FUNCTION

Uso de funciones PLSQL dentro de una sentencia SELECT

Ya hace bastante tiempo que los programadores de bases de datos Oracle podemos llamar a nuestras propias funciones PL/SQL desde una sentencia SQL. Por ejemplo, supongamos que definimos la función PORCENTAJE que realiza una serie de cálculos para devolver un porcentaje. La función puede ser algo tan sencillo como:

FUNCTION porcentaje (
  val1 IN NUMBER,
  val2 IN NUMBER
)
RETURN NUMBER
IS
BEGIN
  RETURN (val1*100/(val1+val2));
END;

Bucles y problemas de rendimiento (performance)

El lenguaje PL/SQL permite la construcción de bucles, esta funcionalidad es, sin duda, extremadamente útil. No obstante, utilizar bucles puede causar problemas de rendimiento en nuestras rutinas, aunque ciertamente estos problemas son fáciles de determinar y corregir.

Imaginemos que una rutina PL/SQL contiene una sentencia select y los registros que devuelve son utilizados para actualizar otra tabla dentro de un bucle. Por ejemplo:

FOR bucle1 IN (
  SELECT articulo
  FROM articulos
  WHERE descripcion = '%zapato%'
) LOOP
  UPDATE precios
  SET precio = precio * 1.05
  WHERE articulo = bucle1.articulo;
END LOOP;

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.