Memorias de un DBA

Un blog dedicado a contribuir a la comunidad SQL Server en español

Arquitectura del Motor de Base de Datos

leave a comment »

Para que una persona pueda tomar buenas decisiones al momento de diseñar una base de datos o al momento de elaborar una consulta, es necesario que tenga en mente que todas las consultas enviadas al motor de base de datos deben ser procesadas por el mismo, el cual tiene una arquitectura definida. Esta arquitectura no es muy conocida ni difundida en la comunidad de SQL Server en español, la verdad no entiendo el porqué, casi ninguno de los libros habla de ella. Yo particularmente buscando en una serie de libros de MVPs y MCMs pude por fin encontrar esas definiciones que no las encontraba en otras partes y es por eso que ahora la tratare de difundir en nuestra comunidad.

En mi opinión personal, conocer la arquitectura del motor de base de datos es muy importante debido a que con este conocimiento uno puede saber y entender lo que sucede tras bambalinas en el interior del motor de base de datos, lo cual conlleva a poder tomar mejores decisiones con respecto al diseño y a la construcción de consultas sobre el servidor de base de datos.

Primero comenzaremos indicando que el motor de SQL Server esta básicamente formado por dos motores o “engines” internos. El primero es el motor relacional, o “Relational Engine”, el cual se encarga de procesar las consultas de la base de datos, optimizarlas y ejecutarlas. El segundo es el motor de almacenamiento, o “Storage Engine”, el cual es responsable de realizar todas las operaciones de I/O de la data, administrar las transacciones, y de manejar el “Buffer Pool”. A continuación se presenta un grafico representando a estos dos motores y a sus componentes internos, de los cuales hablaremos más adelante.

Relational Engine

Este es el primer motor interno de SQL Server, el cual está encargado como ya hemos mencionado de poder procesar las sentencias T-SQL enviadas desde los clientes. Este motor tiene a su vez tres componentes internos los cuales le permiten hacer su trabajo. A continuación explicaremos un poco más las funciones que tiene cada uno de estos componentes internos.

Command Parser: Este componente es el primero en recibir las sentencias T-SQL enviadas desde el cliente al servidor de base de datos. Lo primero que hace este componente es revisar que la sintaxis T-SQL sea correcta, si no lo es, enviara directamente un error al cliente. Si la sintaxis es correcta entonces el siguiente paso es generar un plan de ejecución, para poder realizar esto el “Command Parser”, primero genera un “hash” a partir de la sentencia T-SQL a procesar para poder determinar si es que ya existe algún plan que se ajuste a ésta dentro del “Plan Cache”, la cual es un área dentro del “Buffer Pool” utilizada para poder almacenar los planes de ejecución. Si no encuentra un plan adecuado, entonces genera un “Query Tree” basado en la sentencia T-SQL a procesar, un “Query Tree” es una estructura interna donde cada nodo en el árbol representa una operación en la sentencia SQL que necesita ser ejecutada. Una vez que se tiene generado el “Query Tree”, éste es pasado al siguiente componente, el “Query Optimizer”.

Query Optimizer: Este componente es la pieza más preciada y más compleja dentro de SQL Server. A este componente también se le denomina “Cost-BasedOptimizer”, debido a que evalúa múltiples formas de ejecutar una sentencia T-SQL, y escoge el método que le costó menos. La descripción anterior podría llevarnos a pensar que la función del “Query Optimizer” es encontrar el mejor plan para nuestra consulta, pero en realidad su función principal es encontrar un buen plan en un periodo de tiempo razonable, en vez de encontrar el mejor plan, se podría decir que el objetivo principal de este componente es encontrar el plan más eficiente, en relación al costo y al tiempo. Si el “Query Optimizer” intentara encontrar el *mejor* plan, quizás la generación del plan demoraría más que la misma ejecución de la consulta, entonces, es por esto que se intenta encontrar un balance entre costo y tiempo de generación del plan. Una vez que se tiene el plan de ejecución generado, éste es enviado al siguiente componente que es el “QueryExecutor”.

Query Executor: La función principal de este componente es ejecutar las consultas, para ser mas específicos ejecutar los planes de ejecución interactuando directamente con el “Storage Engine” para obtener y modificar la data, y finalmente enviar el resultado al cliente.

Storage Engine

Una vez que el “Query Executor” comienza a ejecutar el plan de ejecución para la consulta, necesita trabajar en conjunto con el “Storage Engine” que es el encargado de manejar las operaciones de I/O de la data, ademas de las transacciones y el “Buffer Pool”. El “Query Executor” interactúa con este motor a través de uno de sus componentes que es el “Access Methods”.

Access Methods: Este componente tiene como objetivo fundamental el de permitir la comunicación entre el “Relational Engine” y el “Storage Engine”. Este componente recibe las instrucciones enviadas en el plan de ejecución y verifica si hay algún bloqueo con el “Transaction Manager”, si no es así procede con el “BufferManager”.

Buffer Manager: Este es el encargado de buscar las páginas de datos en el “BufferCache”, el cual es un área dentro del “Buffer Pool” donde se guardan las páginas de datos en la memoria, en el caso de que la pagina no se encuentre en esa sección de memoria, procederá a extraerla de la base de datos en el disco duro, y traerá a memoria las páginas de datos necesarias, una vez que ya tiene las paginas en el “Buffer Cache” recién envía el resultado devuelta al “AccessMethods”, el cual es el que forma el set de datos resultante y finalmente lo devuelve al componente “Query Executor” del “Relational Engine” para que este a su vez lo envíe al cliente. Es importante recordar que para que una página pueda ser leída y/o modificada, ésta debe encontrarse antes en la memoria del servidor “Buffer Cache”.

Transaction Manager: Este componente esta divido internamente en dos sub-componentes los cuales son el “Lock Manager” y el “Log Manager”.

Lock Manager: Este es el responsable de mantener la concurrencia en la data a través de los diferentes tipos de bloqueos de la base de datos. Permite mantener la data consistente entre las diferentes sesiones a través de la administración de los diferentes bloqueos que se obtienen en cada una de las operaciones de la base de datos.

Log Manager: Este componente es crucial en el caso de que se hagan modificaciones a la data, debido a que antes de realizar algún cambio en las páginas de datos, este necesita estar guardado en el log de la base de datos, en su archivo físico en el disco duro. Esta es la única vez durante el ciclo normal de ejecución de transacciones T-SQL en la que el motor de base de datos ira al disco duro a guardar los cambios. Una vez que este componente confirma que el cambio ha sido guardado en el log de base de datos, el cambio a las paginas lo realizara el “Buffer Manager” dentro del “Buffer Cache”, lo cual permite tener una mejor performance durante las transacciones porque todas las operaciones se hacen en la memoria del servidor y muy poco se baja a disco.

En conclusión como se habrá podido observar el motor de base de datos se vale a través de sus dos motores internos para poder entregar al cliente los resultados de sus transacciones en la base de datos. Es importante tener en claro todo el recorrido que tienen las consultas T-SQL para poder entender mejor el comportamiento  del servidor de base de datos. Finalmente me gustaría dejar la referencia del libro que me ayudo mucho a entender estos conceptos, en realidad es un magnífico libro, y es Professional SQL Server 2008 Internals and Troubleshooting.

Written by dbamemories

agosto 8, 2011 a 10:04 am

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: