Anuncios en tutorial de programación PLSQL

lunes, 16 de abril de 2018

Funciones de grupo en SQL (SUM, AVG, COUNT, MAX y MIN)

Las llamadas group functions o funciones de grupo son funciones que operan sobre múltiples registros de una sentencia SELECT. En este artículo hablaré sobre las funciones de grupo más comunes del SQL (en un artículo posterior también hablaré sobre las cláusulas GROUP BY y HAVING muy relacionadas con este tipo de funciones).

Funciones de grupo en SQL

Lo primero que hay que saber de las funciones de grupo es que hacen cálculos sobre un grupo de registros devolviendo un resultado único, por lo que permiten, por ejemplo, obtener totales.

viernes, 16 de marzo de 2018

Gestión de errores y ROLLBACKS, lo que hay que saber

Es importante conocer el hecho de que cuando se produce un error PLSQL no gestionado dentro de una sección EXCEPTION, este hecho no supone que automáticamente se realice un ROLLBACK y que todos los cambios realizados en la base de datos Oracle desde el último COMMIT se deshagan.

Error PLSQL

De hecho, a menos que nuestro código incluya de forma explícita la sentencia ROLLBACK dentro de una sección EXCEPTION, o que el error no gestionado lo propaguemos hasta la aplicación desde la que estamos ejecutando nuestro código PL/SQL, no se producirá ningún ROLLBACK.

viernes, 23 de febrero de 2018

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.

Gestión de errores

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.

lunes, 12 de febrero de 2018

El paquete PL/SQL DBMS_SCHEDULER para programación de trabajos

DBMS_SCHEDULER programación de trabajos y procesos en PLSQLDBMS_SCHEDULER es el paquete PLSQL que reemplazó en la versión de la base de datos Oracle 10g al paquete DBMS_JOB. Aunque el paquete DBMS_JOB sigue existiendo por razones de compatibilidad, no debe utilizarse ya que es muy probable que deje de existir en futuras versiones de la base de datos Oracle. El paquete DBMS_SCHEDULER permite programar la ejecución, en los instantes que deseemos, de bloques PLSQL, así como de procedimientos y funciones PL/SQL. Por otro lado, también permite programar la ejecución de binarios y shell-scripts.

miércoles, 31 de enero de 2018

Sentencia CASE en PL/SQL de Oracle

La sentencia CASE en PLSQL y un chiste de ordenadores y ratonesLas versiones de base de datos Oracle 9i y posteriores incluyen la posibilidad de utilizar la sentencia CASE dentro de una sentencia SQL (SELECT, UPDATE, etcétera). La sentencia CASE permite realizar las mismas operaciones que las sentencias de control PL/SQL IF-THEN-ELSIF-ELSE pero con la particularidad de que pueden utilizarse dentro de una sentencia SQL. La sintaxis de la sentencia CASE es como sigue:



jueves, 18 de enero de 2018

Problemas con los triggers SQL

Programador PL/SQL en la camaMucha gente piensa que los triggers PL/SQL son una de las más potentes herramientas de las bases de datos Oracle. De hecho lo son, pero existen dos razones fundamentales por las que, personalmente, trato de evitar la utilización de triggers a la hora de implementar mis proyectos en PL/SQL.

martes, 9 de enero de 2018

Tablas Oracle: Claves naturales o claves sustitutivas

¿Usar claves naturales o sustitutivas con tablas Oracle?En algunas ocasiones me he encontrado con bases de datos en las que se aplica la norma de, a la hora de diseñar una tabla nueva, utilizar siempre una clave sustitutiva (surrogate key) , incluso existiendo una clave natural perfectamente aplicable. Cuando he preguntado por el motivo de crear tales claves sustitutivas, la razón ha sido casi siempre la de aumentar la eficiencia de la base de datos eliminando la posibilidad de tener que enlazar dos tablas utilizando más de una columna.

viernes, 15 de diciembre de 2017

Vistas materializadas y la funcionalidad "Query Rewrite"

PL/SQL - La funcionalidad de reescritura de consultas y las vistas materializadasYa he escrito anteriormente un par de artículos sobre vistas materializadas (materialized views): uno sobre los aspectos generales de las vistas materializadas en SQL y PLSQL y otro sobre el refresco de las vistas materializadas en SQL y PL/SQL. En este artículo voy a tratar una de las funcionalidades soportadas por las vistas materializadas, funcionalidad conocida como QUERY REWRITE.

Funcionalidad de reescritura de una consulta

Esta claro que acceder a una vista materializada puede ser significativamente más rápido que acceder a todas las tablas base utilizadas al crear dicha vista materializada. Es por esta causa por la que, si así lo hemos indicado al crear la vista materializada, el optimizador Oracle, si la consulta o query lo permite, puede reescribir el plan de ejecución de dicha consulta para acceder a la vista en lugar de a las tablas base. Obviamente, la reescritura de la consulta es transparente a las aplicaciones que la estén utilizando. Así pues, de alguna manera, el uso del QUERY REWRITE es similar al uso de un índice.

viernes, 24 de noviembre de 2017

Tuning o puesta a punto de consultas SELECT COUNT(*) en PL/SQL

Tuning o puesta a punto de consultas SELECT en PL/SQLDe vez en cuando recibo consultas sobre cómo sería posible mejorar el rendimiento de sentencias PL/SQL concretas. En la mayoría de los casos contestar a estas preguntas puede ser poco menos que imposible, más que nada porque realizar el tuning de una consulta PL/SQL sin conocer el contexto en que se ejecuta dicha consulta resulta muy complicado. Cada vez que esto ocurre siempre me asaltan preguntas como: ¿por qué se ejecuta dicha consulta?, ¿puede eliminarse la consulta y ser incluida en otro proceso?, ¿está la consulta dentro de un bucle LOOP y realmente debe formar parte del bucle?, ¿están creados todos los índices que podrían acelerar su ejecución? Por si esto fuera poco, una vez que tenemos la respuesta a preguntas como las antes mencionadas, sin duda, surgirán nuevas preguntas.

No obstante, el otro día un asiduo lector de este blog me envió una consulta SELECT bastante sencilla que, aún utilizando los índices de forma adecuada y ejecutándose bastante rápido, terminaba consumiendo muchos recursos de CPU en su base de datos Oracle debido a que era ejecutaba con mucha frecuencia dentro un procedimiento PLSQL. Dicho lector me pedía ayuda para realizar el tuning o puesta a punto de la mencionada consulta.

jueves, 9 de noviembre de 2017

Cláusula ACCESSIBLE BY (mejoras en la versión 12c de la base de datos Oracle)

La mayoría de la aplicaciones basadas en programas PL/SQL están constituidas por numerosos paquetes, algunos de los cuales son APIs de alto nivel que pueden ser utilizadas por los desarrolladores a la hora de implementar los requerimientos de los usuarios, y otros son paquetes de ayuda que son utilizados y llamados por otros paquetes dentro de la aplicación.

Versión 12c de la base de datos Oracle

Antes del reciente nacimiento de la versión 12c de las bases de datos Oracle, el código PL/SQL no podía restringir al esquema de una sesión el uso de aquellos subprogramas que se encontrasen en un paquete PLSQL para el que dicho esquema tuviese permisos de ejecución (GRANT EXECUTE). Con la llegada de la versión 12c de la base de datos Oracle, las unidades de programa PL/SQL pueden utilizar la nueva cláusula ACCESSIBLE BY que posibilita al desarrollador especificar un “lista blanca” de unidades PLSQL que tendrán acceso a la unidad PLSQL que está creando o modificando.