Está en la página 1de 10

UNIVERSIDAD TECNOLÓGICA DE HONDURAS

CAMPUS CHOLUTECA.

CATEDRÁTICO: Ing. Kevin Eduardo Funez Funez

CÁTEDRA: Base de Datos II - Virtual.

ALUMNO: Oscar Eduardo Ordoñez Escaño – 201710110393.

TRABAJO: Investigación 1 – Plan De Ejecución SQL Server.

Choluteca 12 de Julio del 2020


Introducción

En un mundo totalmente globalizado, donde los avances de la tecnología y la generación

grandes cantidades de información son elementos cada vez más importantes en las

organizaciones, por lo tanto la eficiencia y la eficacia juegan un papel importante dentro del

procesamiento de estas enormes cantidades de datos en los diversos manejadores de base de

datos que se conocen y para ello han surgido herramientas y estrategias que han mejorado el

análisis, el tratamiento y la ejecución de cada instrucción que se realiza minuto a minuto a la

data. Es por ello que en el presente informe se introducirá a la investigación sobre los planes de

ejecución en SQL Server.


Objetivos

 Expandir conocimientos por medio de la investigación y práctica sobre los Planes de

Ejecución.

 Mejoramiento del análisis del estudiante al momento de realizar querys.

 Mejoramiento del rendimiento de ejecución y/o respuesta de cada instrucción que se

realiza a la base de datos.

 Aprender, identificar e interpretar los diversos operadores que utiliza el Plan de

Ejecución de SQL Server.


PLAN DE EJECUCIÓN SQL SERVER

Un plan de ejecución consiste en la forma en la que un motor de base de datos considera cual

es la mejor manera de ejecutar una instrucción o query en la que se denota o se pone ya sea en

juego o en ejecución toda la información y recursos que posee el motor de base de datos así

mismo de los recursos del ordenador y que estos puedan ocupar la menor cantidad de recursos y

efectuar dichas consultas o querys en el menor tiempo posible desarrollándolo paso a paso

mostrando como SQL Server resolvería cada una de las instrucciones a ejecutar.

Dentro del SQL Server, (precisamente en el SSMS) podremos hacer uso de dicho plan de

ejecución antes de que se ejecute un query y ver desde la lectura de las tablas, las

transformaciones, uso de índices y cantidades de datos permitiendo encontrar fallas siendo una

gran herramienta que puede permitir hacer mejoras en relación con el uso de recursos estimado.
LABORATORIO

1.

SELECT ProductName, ProductID, UnitPrice, UnitsInStock


FROM Products
WHERE SupplierID IN(SELECT SupplierID
FROM Suppliers
WHERE CompanyName IN('Mayumi''s', 'Pavlova. Ltd.',

'Bigfoot Breweries','Leka Trading'));

2.

SELECT S.Country, COUNT(P.ProductID) 'N° Productos', SUM(P.UnitsInStock) 'Cantidad'


FROM Products P INNER JOIN Suppliers S ON P.SupplierID = S.SupplierID
WHERE P.CategoryID=(SELECT CategoryID
FROM Categories
WHERE CategoryName = 'Condiments')
GROUP BY S.Country;
Lista De Operadores Identificados

Es un operador físico que realiza las operaciones lógicas de

combinación interna, combinación externa izquierda,

semicombinación izquierda y anti semicombinación. Las

Nested combinaciones de bucles anidados realizan una búsqueda en la tabla

Loops interna por cada fila de la tabla externa, normalmente mediante un

índice. El procesador de consultas decide, en función de los costos

anticipados, si debe ordenar o no la entrada externa para mejorar la

ubicación de las búsquedas en el índice sobre la entrada interna.


Es un operador lógico y físico examina el índice agrupado

especificado en la columna Argument del plan de ejecución de

consulta. Si hay un predicado WHERE:() opcional, solo se devuelven

Clustered las filas que lo cumplen. Si la columna Argument contiene la cláusula

Index ORDERED, el procesador de consultas ha solicitado que la salida de

Scan las filas se devuelva en el orden en que las haya ordenado el índice

clúster. Si no hay una cláusula ORDERED, el motor de

almacenamiento recorre el índice de la forma óptima (sin tener que

ordenar el resultado).
Es un operador lógico y físico que evalúa una expresión para

generar un valor escalar calculado. que se puede devolver al usuario,


Compute
hacer referencia a él en cualquier otra parte de la consulta, o ambas
Scalar
cosas a la vez, por ejemplo, en un predicado de filtro o de

combinación. Compute Scalar.


Stream Es un operador físico que agrupa las filas por una o varias

Aggregat columnas y, a continuación, calcula una o varias expresiones


agregadas devueltas por la consulta. El resultado de este operador

puedes ser utilizado por operadores posteriores de la consulta,


e
devuelto al cliente, o ambas cosas. El operador Stream Aggregate

requiere una entrada ordenada por las columnas dentro de sus grupos.
Es un operador físico y lógico que ordena todas las filas entrantes.

La columna Argument contiene un predicado DISTINCT ORDER

BY:() si esta operación elimina las réplicas, o bien un predicado

Sort ORDER BY:() con una lista de las columnas, separadas por comas,

que se van a ordenar. Las columnas llevan como prefijo el valor ASC,

si el orden de las columnas es ascendente, o el valor DESC, si es

descendente.
Consiste en una búsqueda de marcadores en una tabla con un

índice clúster. La columna Argument contiene el nombre del índice

clúster y la clave de agrupación en clústeres utilizada para buscar la

fila en el índice clúster. Key Lookup está siempre acompañado por un


Key
operador Nested Loops. El uso de un operador Key Lookup en un
Lookup
plan de consulta indica que la consulta puede beneficiarse de la

optimización del rendimiento. Por ejemplo, el rendimiento de las

consultas se puede mejorar al agregar un índice de cobertura.

Assert Es un operador físico que comprueba una condición. Por ejemplo,

valida la integridad referencial o se asegura de que una subconsulta

escalar devuelve una fila. Por cada fila de entrada, el operador Assert

evalúa la expresión de la columna Argument del plan de ejecución. Si

la expresión da como resultado NULL, la fila se pasa a través del


operador Assert y continúa la ejecución de la consulta. Si la expresión

da como resultado un valor distinto a NULL, se generará el error

apropiado.
Conclusiones

Al momento de ejecutar querys sin previa inspección de ellas se deja por ignorado el

rendimiento que cada una de ellas llega a tener en cuanto a tiempo de respuesta y uso de recursos

que provoca una instrucción sin tratamiento que a la larga se ven reflejados en nuestros

programas y ordenadores.

Por medio de esta práctica se demuestra que existen herramientas, estrategias y

procedimientos que nos ayudan a mejorar la estructuración de nuestros querys al conocer los

operadores disponibles y en ejecución que el mismo SQL Server toma para dar ejecución a

dichos querys.

También podría gustarte