Vous êtes sur la page 1sur 7

Infraestructura tecnológica de la organización

Andrés Danilo Vásquez Murcia

Instructor

Cesar Manuel Castillo Rodríguez

Técnicas para la optimización de bases de datos

Sena

Gestión y seguridad de bases de datos

Bogotá

Octubre de 2019

INTRODUCCION

La creación de una base de datos, depende de las necesidades de una organización y de sus dependencias, es por esto que debemos de analizar las necesidades y además de esto debemos de establecer un caso de estudio donde la prioridad sea mantener, administrar y mejorar la base de datos.

OPTIMIZACION DE UNA BASE DE DATOS MEDIANTE LA OPTIMIZACION DE UN MOTOR DE BASES DE DATOS

Optimización de bases de datos: La optimización del acceso a los datos es vital

para el tiempo de carga de la página, debido a que suele ser el factor que más afecta

al tiempo que tiene que esperar el navegador para recibir el HTML. Este tiempo de

espera es muy importante, ya que el resto de recursos de la página (imágenes, scripts y hojas de estilo), no se empiezan a bajar hasta que el navegador no lee el HTML desde el que se hace referencia a estos recursos.

Este tipo de optimización es probablemente la más compleja de todas, en primer lugar porque depende de dos factores variables en el tiempo: por un lado, de cómo y de qué tipo son las consultas que se van a realizar y, por otro, de la carga de trabajo que tenga que soportar el servidor o servidores. En segundo lugar por la gran cantidad de conocimientos que hay que tener para saber reescribir consultas, reescribir el código que ejecuta las consultas, crear índices, vistas materializadas, particiones horizontales y verticales, réplicas, tablas de apoyo, saber elegir los tipos de datos a usar, saber optimizar el esquema sin perder la lógica del modelo de negocio, saber ajustar los parámetros de configuración del SGBD, conocer y saber usar sistemas de caché externos.

Optimización de consultas

Cambiar los OR por IN, cuando tenemos más de un valor para comparar.

Minimizar el coste de los JOIN: La concatenación natural o JOIN es la operación más costosa de las bases de datos relaciones, ya que requiere realizar una multiplicación cartesiana y una selección de valores. Algunas técnicas que podemos usar para minimizar su efecto consisten en:

Reordenarlos para concatenar primero las relaciones con menos filas para reducir

el número de cruces.

Crear subconsultas en donde se filtren o limiten el número de filas de las relaciones grandes antes de realizar los siguientes JOINs.

A veces, dividir una consulta en varias, es mejor que hacerlo todo con una sola

consulta, de forma que podemos obtener en una primera consulta unos pocos identificadores que podemos pasar con un IN a la siguiente consulta, en lugar de realizar un JOIN.

Cambiar los JOIN por EXISTS si no se va a mostrar ningún dato de la relación con

la que se realiza el cruce.

Tener en cuenta el problema del N + 1: El n+1 se produce normalmente cuando tenemos un listado en el que para mostrarlo como queremos, por cada ítem necesitamos realizar una consulta adicional (el más uno del n+1). En este caso, suele ser mejor realizar uno o varios JOIN adicionales, en la consulta que recupera el listado de ítems. De esta forma obtenemos el listado tal y como lo necesitamos, y no se tienen que lanzar consultas adicionales para cada ítem.

Especificar siempre los nombres de las columnas en las SELECT, si no el SGBD leerá todas las filas del disco. El asterisco se debe usar sí y solo sí se utiliza COUNT, en cuyo caso el SGBD sabrá que no tiene que leer todas las columnas.

Crear índices: los índices permiten un acceso a los datos no secuencial mucho más rápido, pero son costosos de crear, así que no es conveniente su uso si tenemos muchas más lecturas que escrituras. Debemos analizar el plan de ejecución de las consultas (cada SGBD tiene su manera de verlo) para saber dónde debemos crear índices.

Normalmente, crearemos los índices en claves ajenas y en las columnas que se usen con ORDER BY o WHERE. Si se crean índices compuestos, se deben poner las columnas en el mismo orden que se vayan a usar en las consultas.

OPTIMIZACION DE BASES DE DATOS CON SQL SERVER 2012

El Asistente para la optimización de motor de base de datos de Microsoft (DTA) analiza las bases de datos y hace recomendaciones que puede usar para optimizar el rendimiento de las consultas. Puede usar el Asistente para la optimización de motor de base de datos a fin de seleccionar y crear un conjunto óptimo de índices, vistas indizadas o particiones de tabla sin necesidad de conocer detalladamente la estructura de la base de datos ni el funcionamiento interno de SQL Server. Con DTA, puede realizar las siguientes tareas.

Solucionar problemas del rendimiento de una consulta específica

Optimizar un conjunto grande de consultas en una o varias bases de datos

Realizar análisis condicionales de exploración de posibles cambios de diseño físicos

Administrar el espacio de almacenamiento.

VENTAJAS

El Asistente para la optimización de motor de base de datos de Microsoft (DTA) analiza las bases de datos y hace recomendaciones que puede usar para optimizar el rendimiento de las consultas. Puede usar el Asistente para la optimización de motor de base de datos a fin de seleccionar y crear un conjunto óptimo de índices, vistas indizadas o particiones de tabla sin necesidad de conocer detalladamente la estructura de la base de datos ni el funcionamiento interno de SQL Server. Con DTA, puede realizar las siguientes tareas.

Solucionar problemas del rendimiento de una consulta específica

Optimizar un conjunto grande de consultas en una o varias bases de datos

Realizar análisis condicionales de exploración de posibles cambios de diseño físicos

Administrar el espacio de almacenamiento

Ventajas del Asistente para la optimización de motor de base de datos

La optimización del rendimiento de las consultas puede ser difícil sin un conocimiento completo de la estructura de la base de datos y de las consultas que se ejecutan en ella. El Asistente para la optimización de motor de base de datos puede facilitar esta tarea mediante el análisis de la memoria caché de plan de consulta actual o de la carga de trabajo de las consultas de Transact-SQL que crea, y con la recomendación de un diseño físico adecuado. Para administradores de bases de datos más avanzadas, DTA expone un mecanismo eficaz para realizar análisis condicionales de exploración de diferentes alternativas de diseño físico. DTA puede proporcionar la siguiente información.

Recomendar la mejor combinación de índices para las bases de datos mediante el uso del optimizador de consultas para analizar las consultas de una carga de trabajo.

Recomendar particiones alineadas y no alineadas para las bases de datos a las que se hace referencia en una carga de trabajo.

Recomendar vistas indizadas para las bases de datos a las que se hace referencia en una carga de trabajo.

Analizar los efectos de los cambios propuestos en aspectos tales como el uso de ííndices, la distribución de consultas entre tablas y el rendimiento de las consultas de la carga de trabajo.

Recomendar métodos para optimizar la base de datos con respecto a un pequeño conjunto de consultas problemáticas.

Permitirle personalizar la recomendación mediante la especificación de opciones avanzadas como, por ejemplo, las restricciones de espacio en disco.

LIMITANTES

El asistente nos limita, ¿En qué?

No puede agregar o quitar índices únicos o índices que aplican restricciones PRIMARY KEY o UNIQUE.

No puede analizar una base de datos que esté configurada en modo de usuario único.

Si especifica un espacio en disco máximo en las recomendaciones de optimización que supere el espacio disponible real, el Asistente para la optimización de motor de base de datos usa el valor especificado. Sin embargo, al ejecutar el script de recomendaciones para implementarlo, el script puede generar un error si antes no se agrega más espacio en disco. El espacio en disco máximo puede especificarse mediante la opción -B de la utilidad dta o especificando un valor en el cuadro de diálogo Opciones avanzadas de optimización.

Por motivos de seguridad, el Asistente para la optimización de motor de base de datos no puede optimizar una carga de trabajo de una tabla de seguimiento que resida en un servidor remoto. Para evitar esta limitación, puede usar un archivo de seguimiento en lugar de una tabla de seguimiento o copiar la tabla de seguimiento en el servidor remoto.

Al imponer restricciones, como las impuestas al especificar el espacio en disco máximo en las recomendaciones de optimización (mediante la opción -B o el cuadro de diálogo Opciones avanzadas de optimización), el Asistente para la optimización de motor de base de datos puede verse forzado a quitar algunos índices existentes. En ese caso, la recomendación resultante del Asistente para la optimización de motor de base de datos puede producir lo contrario a la mejora esperada.

Al especificar una restricción para limitar el tiempo de optimización (mediante la opción -A con la utilidad dta o activando Limitar tiempo de optimización en la pestaña Opciones de optimización), el Asistente para la optimización de motor de base de datos puede exceder ese límite de tiempo para generar la mejora esperada exacta e informes de análisis de la parte de la carga de trabajo que se ha consumido hasta ahora.

CACHEAR LAS CONSULTAS MAS FRECUENTES

Activar la caché

más

frecuentemente.

Si el volumen de datos es alto y se actualiza frecuentemente, estaremos siempre escribiendo en la caché en lugar de leer de ella. Así que normalmente es preferible recurrir a un sistema de caché externo, en el cual podamos controlar que se van a cachear realmente los datos más frecuentes y más frescos. Si el sistema de caché no nos provee de esta funcionalidad, podemos implementarla nosotros. Una buena forma de hacerlo sin el sobrecoste de almacenar el número de veces que se accede a una consulta, es generar un número aleatorio y cachear la consulta si ese número pasa de cierto valor.

rendimiento.

datos del SGBD a veces puede empeorar el

de base

depende

de

Esto

del

volumen

de

datos

al

que

se

acceda

Por ejemplo, supongamos que generamos un número aleatorio entre 1 y 100 y la consulta se cachea si dicho número es menor que 10, de esta forma se guardará la consulta en caché con una probabilidad del 10% en cada petición, así si la consulta tiene más peticiones, será más probable que se guarde en caché.

del 10% en cada petición, así si la consulta tiene más peticiones, será más probable que