Escolar Documentos
Profissional Documentos
Cultura Documentos
1.1. Definicin La pgina es la unidad bsica del almacenamiento de datos en SQL Server. El espacio en disco asignado a un archivo de datos (.mdf o .ndf) de una base de datos, se divide lgicamente en pginas numeradas de forma contigua de 0 a n. Las operaciones de E/S de disco se realizan a nivel de pgina. Es decir, SQL Server lee o escribe pginas de datos enteras. El tamao de pgina es de 8 KB. Esto significa que las bases de datos de SQL Server tienen 128 pginas por megabyte. Existen 3 datos importantes para alinear nuestras particiones.
2.1. Definicin La TempDB es una base de datos del sistema que se instala por defecto y se utiliza para almacenar objetos temporales creados por el usuario como tablas temporales, vistas temporales, variables temporales u otro objeto temporal.
3.1. Definicin Cuando vamos a crear una base de datos, por lo general, solo pensamos en cmo se va a llamar y en qu servidor va a ser alojada y sobre esto, determinamos si tenemos espacio en disco para poder crearla. Pero las consideraciones que debemos de tener en cuenta son: - El tamao proyectado que va a tener nuestra base de datos. - La velocidad con la que podremos acceder a nuestra informacin. - La velocidad con la que podremos ingresar nuestra informacin. - El tipo de informacin que almacenar la base de datos.
3.2. Pasos en el Diseo de la Base de Datos Adems, podemos decir que uno de los pasos ms importantes en la creacin de una aplicacin que maneja una base de datos, es el diseo de la misma, ya que si no tenemos en cuenta unas buenas definiciones de nuestras tablas, tipos de datos y ubicacin de la base de datos podemos tener problemas de performance al momento de utilizar nuestra aplicacin. - Capacity Planning - Tamao de nuestra base de datos
1.1. Definicin
El tema ms importante en la elaboracin de reportes o extraccin de informacin de nuestra base de datos es el tiempo de procesamiento de las consultas que realizamos. Muchas veces, esto se debe al hardware, el software utilizado, el mal diseo de la base de datos, la mala formulacin de ndices y consultas. Por tal motivo, para mejorar este ltimo punto desarrollaremos algunas consideraciones que nos permitirn minimizar el impacto que tiene las consultas en el tiempo de procesamiento de nuestra aplicacin
1.2. Consideraciones
Siempre realizar la consulta dentro de un procedimiento almacenado ya que ste se ejecuta ms rpido que cualquier consulta externa fuera del motor de base de datos.
Buenas Practicas en la Construccin de Consultas
1.2. Consideraciones
La primera vez que se ejecuta el procedimiento almacenado es compilado lo que produce un plan de ejecucin que es un paso a paso de como el motor ejecutar las sentencias SQL El plan es colocado en memoria (Cached) para su reuso
1.2. Consideraciones
Otra ventajas: Seguridad: no se le da acceso a objetos internos de BD Administracin cualquier cambio se hace en el procedimiento no en la aplicacin Trfico de Red se reduce el trfico porque se trabaja sobre el motor de BD
Buenas Practicas en la Construccin de Consultas
1.2. Consideraciones
No se debe usar Select * puesto que con esto el motor lee primero toda la estructura de la tabla antes de ejecutar la sentencia. Otra desventaja es que el resultado variar si se agrega o quitan campos.
1.2. Consideraciones
Para hacer consultas entre tablas es preferible usar los JOIN, RIGTH JOIN y LEFT JOIN. Usar JOIN, RIGTH JOIN y LEFT JOIN ya que mientras el motor de base de datos va leyendo las tablas va verificando que relacin se necesita entre ellas y de este modo, ste lee menos registro y hace mas eficiente la consulta a diferencia del WHERE que hace que las tablas se lean en su totalidad y despus hace las relaciones
1.2. Consideraciones
En lugar de SELECT Nombre, Factura FROM Clientes, Facturacion WHERE IdCliente=IdClienteFacturado, usamos: SELECT Clientes.Nombre, Facturacion.Factura WHERE Clientes.IdCliente = Facturacion.IdClienteFacturado.
Buenas Practicas en la Construccin de Consultas
Cuando se realiza una consulta entre varias tablas el orden de estas debe ir de menor a mayor nmero de registros; dependiendo del numero de columnas y registros de la tabla se genera un resultado que puede llevar mucho tiempo para ser completado por parte del motor de base de datos.
Ej: Si deseamos saber cuantos alumnos se matricularon en el ao 1996 y escribimos: FROM Alumnos, Matriculas WHERE Alumno.IdAlumno = Matriculas.IdAlumno AND Matriculas.Ao = 1996 el gestor recorrer todos los alumnos para buscar sus matriculas y devolver las correspondientes. Si escribimos FROM Matriculas, Alumnos WHERE Matriculas.Ao = 1996 AND Matriculas.IdAlumno = Alumnos.IdAlumnos, el gestor filtra las matrculas y despus selecciona los alumnos, de esta forma tiene que recorrer menos registros.
1.2. Consideraciones
Operadores en el filtro:
Si utilizamos WHERE, los operadores a utilizar deben ser los de mejor rendimiento. El orden de rendimiento de los operadores de mayor a menor es: = >,>=, <=, < LIKE IN <>, NOT IN, NOT LIKE
Buenas Practicas en la Construccin de Consultas
1.2. Consideraciones
1.2. Consideraciones
Evitar el uso del comando LIKE con el siguiente wildcard %R ya que no permite el uso del indice si el campo lo tuviera, LIKE con el siguiente wildcard R% permite el escano parcial y el uso del ndice
El comando BETWEEN es ms eficiente que el IN porque el primero busca un rango de valores y el segundo varios valores puntuales provocando que la sentencia sea menos efectiva.
1.2. Consideraciones Cuando utilicemos los operadores AND es preferible empezar por los campos que sean parte de algn ndice para que la
informacin seleccionada sea mas selectiva y la cantidad de registros ledos sea mnimo.
Cuando se tenga la necesidad de ordenar los datos en una consulta se recomienda que los campos a ordenar sea el menor nmero posible, y tambin se sugiere crear un ndice de tipo clustered index sobre el campo que se esta utilizando.
1.2. Consideraciones No se recomienda el uso del INSERT INTO ya que esto origina que la tabla se bloquee mientras se esta llevando acabo el insert y de este modo se impide el uso del resto de datos a los usuarios.
Si dentro de una consulta se debe utilizar el comando HAVING se recomienda hacer todos los filtros posibles con el comando WHERE, de esta forma el trabajo que tiene que realizar el comando HAVING ser el menor posible.
1.2. Consideraciones Se procurar elegir en la clusula WHERE aquellos campos que formen parte del ndice de la tabla Adems se especificarn en el mismo orden en el que estn definidos en la clave. Filtrar siempre por campos que tengan ndices.
1.2. Consideraciones Si deseamos interrogar por campos pertenecientes a ndices compuestos es mejor utilizar todos los campos de todos los ndices. Si tenemos un ndice formado por el campo NOMBRE y el campo APELLIDO y otro ndice formado por el campo EDAD. La sentencia WHERE NOMBRE='Juan' AND APELLIDO Like '%' AND EDAD = 20 sera ms optima que WHERE NOMBRE = 'Juan' AND EDAD = 20 por que el gestor, en este segundo caso, no puede usar el primer ndice y ambas sentencias son equivalentes por que la condicin APELLIDO Like '%' devolvera todos los registros.
Buenas Practicas en la Construccin de Consultas
2.1. Definicin
Los HINTS son opciones que se interponen a los comandos Select, Insert, Update y Delete para especificar qu es lo que se tiene que hacer, en lugar que el motor de base de datos decida qu hacer. El lugar donde el motor decide cmo hacer la consulta, se llama optimizador de consultas y la forma cmo se ejecuta la consulta se llama Plan de ejecucin Existen 4 formas de aplicar los HINTS: JOIN HINTS: Que especifica el tipo de JOIN que se utilizar. INDEX HINTS: Que especifica el tipo de INDEX que se utilizar LOCK HINTS: Que especifica el tipo de bloqueo que se utilizar. PROCESSING HINTS: Que especifica la forma cmo se ejecutara el query..
SQL Hints
3.1. Definicin
Cuando trabajamos realizando consultas sobre nuestra base de datos tenemos que saber que siempre existirn consultas que son ms pesadas que otras, ya sea por que tenemos queries que consultan tablas que tiene ms registros que otras o por que los filtros que utilizamos invocan a una gran cantidad de registros entre tablas.
El objetivo de este punto es determinar cules son las consultas de mayor impacto en nuestro servidor y analizar qu podemos cambiar en ellas para mejorar la performance de nuestra base de datos. Optimizando Consultas
4.1. Definicin La performance de la aplicacin, por lo general, siempre est basada directamente, en el buen o mal diseo de nuestros ndices, ya que la funcin principal de stos es optimizar el acceso a los datos
ndices
ndices
5.1. Definicin Cuando ejecutamos una sentencia dentro de nuestra base de datos,
el motor internamente ejecuta una serie de operacin que varan segn la cantidad de datos, objetos y schemas. A estas operaciones en conjunto. se le conoce como Plan de Ejecucin .
5.2. Objetos de Planes de Ejecucin Dentro de los Planes de ejecucin se conocen los siguientes operadores:
Table Scan Clustered Index Scan Clustered Index Seek Index Seek Bookmark Lookup Index Scan Neested Loop Join Merge Join Hash Join Sort