Aprendiendo SQL Server

La MSDN nos explica cual es la forma correcta de referenciar a los objetos en tus consultas, y es la siguiente: Esquema.Nombre ¿Por qué? Hay diversos motivos y, aunque parezca algo trivial, pueden evitarnos acceder a objetos incorrectos, errores en consultas para usuarios de la base de datos distintos al que creó el objeto e incluso problemas de rendimiento . Resolución de nombres Cuando ejecutamos una consulta, el servidor SQL realiza un proceso llamado resolución de nombres ( name resolution , en inglés) para identificar los objetos referidos en ella. Si identificamos cada objeto por su nombre completo ( fully qualified name ) , SQL sabrá determinar inmediatamente a qué objeto nos referimos y si existe o no. Por el contrario, si solamente especificamos su nombre, el motor de bases de datos tendrá que determinar a qué objeto nos referimos . Para ello usará el default schema del usuario conectado. Esquema por defecto o Default schema Cada usuario de una base de d...

Definición En SQL Server las tablas pueden tener o no tener un índice clustered . El índice clustered es por el que SQL ordena físicamente los datos (las filas de las tablas) en disco. El índice clustered le sirve a SQL para buscar, ordenar y agrupar registros de manera eficiente. Así, no tener un índice clustered en una tabla puede llevarnos a problemas de rendimiento . Cuando una tabla no tiene índice clustered , se llama heap . El problema Los heaps  mantienen los registros en las páginas de datos en el mismo orden en el que se han insertado. Esto hace que los heaps  resulten más rápidos a la hora de realizar un INSERT, ya que no han de insertarse en una posición en concreto, sino directamente a continuación del último registro existente para la tabla en cuestión. Sin embargo, cualquier otra operación que requiera un orden en los datos será más lenta . Esto se aplica a SELECT, DELETE y UPDATE, salvo que se quieran efectuar estas operaciones sobre la ta...

En algunas ocasiones, buscando problemas de rendimiento en bases de datos, nos enfrentamos a una lista de consultas que son las causantes de dichos problemas. Una vez obtenida esa lista de consultas, el problema a resolver es: ¿ Dónde están codificadas esas consultas ? ¿Forman parte del código de nuestra aplicación o, por el contrario, su código T-SQL está en alguno de nuestros objetos de la base de datos; véase un trigger, un procedimiento almacenado, una función o una vista? Si se da el segundo caso, y no somos capaces de reconocer el objeto que está ejecutando la consulta que buscamos, disponemos de una vista de sistema (entre las vistas de objetos del catálogo) que nos ayudará a encontrar dónde se esconde: sys.sql_modules . Así, una consulta como la siguiente es la que necesitamos para encontrar el código: * Si tu versión de SQL Server es anterior a SQL Server 2005, hay que usar la tabla de sistema sys.syscomments .

En algunas ocasiones podemos vernos con la necesidad de conocer qué tablas de nuestra base de datos están ocupando más espacio en disco. Por ejemplo, si disponemos de SQL Server Express , cuyas bases de datos están limitadas a 4GB o 10GB, según la versión que estemos usando -4, hasta 2005; 10, a partir de 2008-, aparte de usar las opciones de comprimir la base de datos, poner el log en el modo simple de recuperación o ajustar las políticas de crecimiento automático de nuestros ficheros, podemos necesitar averiguar qué tablas crecen más para tomar las decisiones oportunas.

Una de las configuraciones que debemos revisar en nuestras bases de datos es la que corresponde a los parámetros de crecimiento automático ( autogrowth ) de sus ficheros. Nuestras bases de datos crecen con el uso y SQL Server reserva espacio en disco duro para los ficheros que la componen, pidiéndole al sistema operativo más espacio cuando el que tenía asignado deja de estar disponible. Cada vez que esto ocurre, el rendimiento de nuestra base de datos se ve afectado , ya que el servidor debe bloquear la actividad en ella mientras obtiene el nuevo espacio. Así pues, es deseable configurar las opciones de crecimiento de los ficheros de la base de datos de tal manera que: Los eventos de crecimiento ocurran con poca frecuencia No nos excedamos en la cantidad de disco reservada a los ficheros de una base de datos, ya que podría no ser necesario y estaríamos consumiendo recursos útiles para otras bases de datos en el mismo disco o sistema de discos.

Los índices son objetos de la base de datos diseñados de manera similar a los índices que usamos en los libros para encontrar contenidos en el mismo. Éstos ordenan los datos en nuestras tablas , permitiendo un acceso más rápido y eficiente a aquéllos que estemos consultando, modificando o eliminando. Por ello, la actualización de los registro de las tablas de la base datos obliga al servidor SQL a realizar ciertas operaciones que nos garanticen el orden de los datos en los índices. Debido a esta actualización, la información almacenada en los índices se ve fragmentada con su uso. Esta fragmentación depende de parámetros como el fill factor , número de páginas, tamaño del índice y frecuencia de actualización. En definitiva, un índice sobre un tabla, debido a actualizaciones sobre ésta, puede perder eficacia y, con ello,  nuestras consultas volverse más lentas y su rendimiento deteriorarse.