Eladio Rincón

Disponible para descargar la CTP5 (la de Noviembre) de SQL Server 2008

Donde está un buen link que se quiten todas las palabras… la CTP5 ya está disponible para todo el mundo:

Microsoft SQL Server 2008 CTP, November 2007

Brief Description
Download the latest SQL Server 2008 Community Technology Preview (CTP) and try out the latest features of SQL Server 2008! The SQL Server development team uses your CTP feedback to help refine and enhance product features. Download it today and send your feedback.

http://www.microsoft.com/downloads/details.aspx?FamilyId=3BF4C5CA-B905-4EBC-8901-1D4C1D1DA884&displaylang=en

Acabando con los mitos: Memoria usada por bases de datos

Hola,

Al hilo del post anterior sobre las DMVs de memoria, me gustaría aclarar el siguiente mito:

"Lecturas a una base de datos (BD1), desde distintas bases de datos (BD2, BD3), implican que en la caché de datos existan varias copias de la información leída de BD1.". La afirmación es errónea, y es lo que quiero demostrar en este post J

¿Cómo lo podemos comprobar?

• Limpiaremos el caché de datos.
• Comprobamos que realmente se ha limpiado
• Consultaremos sobre tablas de Adventureworks desde varias bases de datos.
• Usaremos la DMV del post anterior para medir las páginas en caché.
  • Con el monitor de rendimiento se pueden obtener las páginas de datos totales, pero no a nivel de base de datos que es lo que estamos buscando.

1; limpiamos el caché de datos con la siguiente instrucción:

dbcc dropcleanbuffers

2; Comprobamos que realmente se ha limpiado:

SELECT
count(*) AS cached_pages_count
, count(*) * 8. / 1024 AS MB
FROM sys.dm_os_buffer_descriptors

Que en mi caso me devuelve 91 páginas (poco más de 500Kb).

3; Ejecutamos consultas sobre distintas bases de datos:

use master;
select count(*) from AdventureWorks.Sales.SalesOrderHeader;

go

use Tempdb;
select count(*) from AdventureWorks.Sales.SalesOrderDetail;
select count(*) from AdventureWorks.Sales.SalesOrderHeader;

go

use Northwind;
select count(*) from AdventureWorks.Sales.SalesOrderDetail;

4; Comprobamos el uso y distribución de la memoria:

SELECT
count(*) AS cached_pages_count
, count(*) * 8. / 1024 AS MB
,CASE database_id
WHEN 32767 THEN 'ResourceDb'
ELSE db_name(database_id)
END AS Database_name
FROM sys.dm_os_buffer_descriptors
WHERE db_name(database_id) IN
('master', 'Adventureworks', 'Northwind', 'Tempdb')
GROUP BY db_name(database_id) ,database_id
ORDER BY cached_pages_count DESC

Donde podemos comprobar que a pesar de realizar consultas desde distintas bases de datos (master, tempdb, y Northwind), a otra base de datos (AdventureWorks), las páginas en caché corresponden a solo Adventureworks.

Disclaimer1: después de limpiar los buffers, en mi sistema, el número de páginas en caché se mantiene estable en 91 páginas durante unos segundos, instantes después, crece superando las 800; la distribución que aparece en mi sistema es la siguiente:

Aunque no me quita el sueño, no acabo de entender por qué msdb, Northwind, y Adventureworks adquieren esos cientos… lo investigaré J

Disclaimer2: Cuidado con la DMV sys.dm_os_buffer_descriptors, que es bastante consumidora de recursos.

Una razon mas para deshabilitar la propiedad auto-shrink en las bases de datos

La semana pasada durante TechEd-Dev en Barcelona, un delegado se acercó a stand de Ask The Experts, con una duda a la que no era capaz de encontrar respuesta:

• Tengo una tabla T1 en la que nadie realiza modificaciones (los usuarios sólo leen de la tabla).
• La tabla T1 que se reindexa por la noche dejando su fragmentación por debajo del 1%.
• Sin razones aparentes, a lo largo del día, la tabla aparece muy fragmentada (valores superiores al 90%).

Comprobando la configuración de su base de datos, notamos que tenía habilitada la opción auto-shrink ON; le pedimos al delegado que deshabilitara la opción, y al día siguiente la tabla ya no estaba fragmentada.

¿Qué le estaba pasando? La reducción automática de la base de datos, le estaba pasando una mala jugada al cliente.

Fíjate que aunque pienses que tu estas libre del problema porque no tienes habilitada la opción auto-shrink, si utilizas el comando DBCC SHRINKDATABASE puedes ser víctima del mismo problema.

Reproducirlo es muy sencillo; lo único que tienes que conseguir es que poner a funcionar el comando DBCC SHRINKDATABASE con espacio para liberar; por ejemplo, create dos tablas muy grandes, borra la primera, comprueba la fragmentación (DMV sys.dm_db_index_physical_stats), lanza el DBCC, y vuelve a comprobar la fragmentación. Te asombrarás con los resultados!

Corolarios:

• Deshabilita la opción auto-shrink en tus bases de datos
• Revisa tus planes de mantenimiento dando especial atención a los comandos DBCC de reducción de ficheros/base de datos.

Nos gustan las DMVs: Paginas de datos en memoria por base de datos

Hace un par de meses estuvimos trabajando en un proyecto de escalabilidad de bases de datos, y entre otras cosas, uno de los datos que necesitábamos conocer era la memoria utilizada por cada base de datos en una instancia de SQL Server.

El escenario era el siguiente: una instancia de SQL Server daba servicio a un número de bases de datos que estaban distribuidas de la siguiente forma:

• Una base de datos "general" que era compartida por todas las aplicaciones que usaban el servidor de base de datos.
• Una base de datos por empresa que hacía uso del servicio.

Necesitábamos conocer cuanta memoria usaba cada base de datos "de empresa", porque parte del trabajo consistía en conocer a cuantas bases de datos podría dar servicio la instalación. El objetivo era grosso modo, conocer cuantas páginas de datos utilizaba cada base de datos de la instalación.

Para ello usamos la siguiente consulta (extraído de BOL) que devuelve las páginas de datos asignadas a cada BD:

SELECT
count(*) AS cached_pages_count
, count(*) * 8. / 1024 AS MB
, CASE database_id
WHEN 32767 THEN 'ResourceDb'
ELSE db_name(database_id)
END AS Database_name
FROM sys.dm_os_buffer_descriptors
GROUP BY db_name(database_id) ,database_id
ORDER BY cached_pages_count DESC

A este dato obtenido hay que añadirle el resto de componentes de SQL Server; por ejemplo, memoria asignada para bloqueos, caché de procesos, servidores vinculados, etc. pero si nos da una aproximación muy real del porcentaje de memoria total que utiliza cada base de datos. Al fin y al cabo, es cuestión de contar habas J

En otro post, veremos caché de procesos, y otros componentes…