Anuncios en tutorial de programación PLSQL

jueves, 7 de septiembre de 2017

El optimizador PL/SQL basado en normas (Rule-Based Optimizer)

Diagrama del optimizador Oracle PL/SQL basado en normasEn este artículo voy a mencionar algunas de las características del optimizador PL/SQL basado en normas (Rule-Based Optimizer). Lo primero que quiero mencionar es que Oracle recomienda utilizar el optimizador PLSQL basado en costes (cost-based optimizer), no obstante, en algunos casos, el hecho de tener que activar las estadísticas de la base de datos para poder utilizar este último optimizador, puede hacer que resulte interesante utilizar el optimizador basado en normas y dejar las estadísticas desactivadas para no afectar al rendimiento de la base de datos.

lunes, 28 de agosto de 2017

Cambios de rendimiento en una sentencia SQL al activar el trazado

PLSQL y SQL esperando a que windows arranqueHace unos días un lector del blog me enviaba un email contándome un "extraño" problema de rendimiento que tenía con una sentencia SQL o PL/SQL. Dicha sentencia SQL tardaba mucho tiempo en devolver resultados y, tras activar la utilidad de trazado SQL (SQL_TRACE=TRUE), el problema desaparecía y la respuesta de la sentencia SQL era inmediata.

La verdad es que el fenómeno no es tan extraño una vez que se conoce la causa. Cuando se activa el trazado haciendo SQL_TRACE=TRUE, lo que ocurre es que la sesión Oracle utiliza una nueva área de SQL compartido. Esto supone que el parsing (ver artículo sobre las fases durante el procesamiento de una sentencia SQL) de cualquier sentencia SQL que se ejecute después de activar el trazado vuelva a tener lugar o que, de existir una versión de dicha sentencia SQL ya parseada en la nueva área de SQL compartido, dicha versión no coincida con la versión existente cuando el trazado no está activo. Esto causa que, cuando la sentencia SQL utiliza variables (bind variables), puesto que los valores reales de dichas variables son tomados en el momento del parsing, muy probablemente, los planes de ejecución de la misma sentencia SQL sean diferentes antes y después de activar el trazado al haberse generado utilizando valores de variable distintos.

martes, 18 de julio de 2017

El refresco de las vistas materializadas en SQL y PL/SQL

Como quedó un teclado después del refresco (refresh) de vistas materializadas (Materialized views) en las bases de datos OracleYa he hablado en otro artículo acerca del funcionamiento básico de las vistas materializadas (materialized views), en éste voy a exponer los distintos tipos de refresco en SQL y PLSQL que se pueden utilizar para actualizar una vista materializada con los cambios provocados por las actualizaciones en las tablas base utilizadas en la misma. El tipo de refresco que debemos elegir dependerá de la frecuencia de actualización de las tablas base y de las necesidades que tengamos de disponer de datos exactos.


viernes, 9 de junio de 2017

La claúsula WITH en SQL y PL/SQL

Esposa reclama la atención del programador PL/SQL con la claúsula WITH del SQLLa versión 9i de las bases de datos Oracle permite el uso de la claúsula WITH en SQL y PLSQL. Este comando permite reusar una consulta SELECT cuando esta hay que utilizarla más de una vez en una sentencia o consulta SQL compleja. Los resultados de la consulta definida en la claúsula WITH son almacenados en una tabla temporal pudiendo de esta forma mejorar el rendimiento de la sentencia principal.

martes, 16 de mayo de 2017

SQL y PL/SQL - La sentencia INSERT multitabla

La vaca de SQL y PLSQL y la sentencia INSERT multitablaLa versión 9i de las bases de datos Oracle ha introducido la posibilidad de utilizar sentencias INSERT multitabla. Así pues, la sentencia SQL o PLSQL INSERT... SELECT ha cambiado ligeramente su sintaxis, de manera que ahora permite la inserción de datos en más de una tabla de la base de datos de forma paralela. Existen dos formas de utilizar el comando INSERT multitabla: no condicional y condicional. En la forma no condicional, una cláusula compuesta INTO se ejecuta cada vez que la consulta SELECT devuelve un registro. En la forma condicional, las cláusulas compuestas INTO figuran dentro de cláusulas WHEN a partir de las que se determina si la correspondiente cláusula compuesta INTO se ejecuta o no.

viernes, 21 de abril de 2017

Generador de números aleatorios en PL/SQL

Seguridad en PLSQLEs posible que en alguna ocasión necesitéis utilizar un generador de números aleatorios en un programa PL/SQL. Oracle proporciona el paquete estándar DBMS_RANDOM para este propósito. Obviamente podemos escribir nuestra propia rutina PLSQL que genere números aleatorios, pero paquete estándar de Oracle DBMS_RANDOM es más rápido ya que llama al generador de números aleatorios interno de la base de datos Oracle.

jueves, 9 de marzo de 2017

Las funciones PL/SQL LPAD, RPAD, REPLACE, TRANSLATE, TRIM, LTRIM y RTRIM (manejo de cadenas de caracteres II)

En este artículo encontraréis toda la información necesaria para que desde vuestros programas PLSQL podáis realizar tres operaciones básicas con las cadenas de caracteres: rellenar dicha cadena con espacios u otros caracteres, reemplazar un determinado carácter o grupo de caracteres dentro de dicha cadena, o eliminar un determinado carácter o grupo de caracteres en la mencionada cadena.

Sintaxis de las funciones PLSQL LPAD y RPAD

Las bases de datos Oracle proporcionan diferentes funciones que pueden utilizarse en bloques SQL y PLSQL para realizar estas operaciones. Las funciones de las que estamos hablando son LPAD, RPAD,

viernes, 3 de marzo de 2017

El paquete DBMS_PARALLEL_EXECUTE, procesamiento en paralelo desde PL/SQL

En muchas ocasiones nos encontraremos con la necesidad de realizar operaciones DML (UPDATE, INSERT, etcétera) sobre millones de registros de una tabla. Escribir el código PL/SQL encargado de realizar estas operaciones no tiene por qué ser complicado, pero el manejo de los segmentos de rollback y conseguir que el rendimiento de dicho código sea bueno, es decir, que termine en un tiempo aceptable, puede ser harina de otro costal.

Procesamiento en paralelo en las bases de datos Oracle

Todas las nuevas versiones de las bases de datos Oracle incluyen una amplia variedad de nuevas funcionalidades que amplían su capacidad. La release 2 de la versión 11g de las bases de datos Oracle no es una excepción a esta norma e incluye más de cincuenta nuevos paquetes PLSQL, siendo uno de ellos el DBMS_PARALLEL_EXECUTE.

viernes, 20 de enero de 2017

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.

Arbol jerárquico

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.

viernes, 30 de diciembre de 2016

Diferencias entre restricciones PLSQL (cláusula CONSTRAINT) a nivel de tabla y a nivel de columna

Diferencias entre restricciones PLSQL (cláusula CONSTRAINT) a nivel de tabla y a nivel de columnaResulta de perogrullo decir que una restricción PLSQL (cláusula CONSTRAINT) a nivel de columna sólo aplica a la columna sobre la que se ha definido, mientras que una restricción a nivel de tabla puede incluir todas las columnas de dicha tabla. Esta es la diferencia básica en PL/SQL, pero también conviene señalar que cualquier restricción a nivel de columna puede definirse también a nivel de tabla, sin embargo, no todas las restricciones a nivel de tabla pueden definirse a nivel de columna.

Ojo, no estoy diciendo que todas las restricciones deban definirse a nivel de tabla, simplemente estoy diciendo que es posible hacerlo. De hecho, mi opinión es que, siempre que se pueda expresar una restricción utilizando una CONSTRAINT PLSQL a nivel de columna, debemos hacerlo de esta manera. Una razón evidente es que una restricción a nivel de columna es sintácticamente más clara ya que resulta obvio que aplica a sólo una columna, mientras que si utilizamos una CONSTRAINT a nivel de tabla para definir la misma restricción, deberemos prestar más atención al código PL/SQL para comprender lo que hace. Pero esta no es la única razón, las hay todavía de mayor peso.