it-swarm-es.com

SQL Server - ¿Forzar DB en memoria?

Tenemos un robusto servidor Windows 2008 x64 (CPU de 4 x 4 núcleos, 32 GB de RAM) que ejecuta SQL Server 2005 de 64 bits. Tenemos una base de datos pequeña (6GB) pero muy importante a la que es algo lento acceder hasta que las páginas se almacenan en caché en la memoria (el uso es una E/S muy aleatoria, por lo que las probabilidades son muy bajas de que una página determinada esté en la memoria y los usuarios finales quejarse de la lentitud inicial). Los discos son lo suficientemente rápidos (SAS local de 15K) pero supongo que la aplicación está escrita de forma algo torpe (es una solución COTS), así que me pregunto si hay una manera de "forzar" una base de datos en la memoria en SQL Server 2005 (2008 no es compatible por el proveedor, por lo que no deberíamos actualizar a eso todavía) para ayudar a evitar el blues inicial de llenado de caché?

Mi método actual es que ejecuto un SELECT * de cada tabla en un script para obtener páginas de datos en la memoria, pero algunos objetos (índices, búsqueda de texto completo, etc.) no se almacenan en caché con este método (y modifico el script para interrogar índices y escribir cláusulas WHERE apropiadas para almacenar en caché es el complejo hervir el océano).

14
Matt Rogish

No, desafortunadamente no hay forma de forzar una base de datos en caché. Su método de fuerza bruta es probablemente el más sencillo. Es posible que pueda acercarse utilizando scripts de desfragmentación de índice con una configuración de umbral muy baja, como decir reconstruir el índice si está fragmentado al 1%, así:

http://sqlserverpedia.com/wiki/Index_Maintenance

Tomará más tiempo e involucrará más escrituras en el disco, pero tendrá el efecto secundario de desfragmentar sus índices y actualizar las estadísticas, lo cual es una buena idea de todos modos.

15
Brent Ozar

Ok, no puedo comentar sobre la respuesta de Brent (todavía, ya que no tengo suficientes repeticiones), pero si va a seguir la ruta de desfragmentación, no necesariamente reconstruya el índice, ya que eso generará nuevos índices, posiblemente haciendo crecer la base de datos si no hay suficiente espacio libre, y garantizando que su próxima copia de seguridad del registro sea al menos del tamaño de sus índices y que su registro también tenga una tonelada de registros de registro (según el modelo de recuperación). Si va a hacer la ruta de desfragmentación, haga un ALTER INDEX ... REORGANIZE, que no requiere ningún espacio libre (bueno, una página de 8k) pero leerá el nivel de hoja en la memoria y solo operará en el fragmentado páginas. Los niveles que no son de hoja deberían aparecer rápidamente después de algunas consultas y (dependiendo de la distribución) deberían tener muchos menos datos que el nivel de hoja.

9
Paul Randal

He tenido algunos escenarios en los que la actualización de estadísticas con FULLSCAN en tablas clave ha obligado a los datos a almacenar en caché y ha hecho que mis DML posteriores alrededor de esas tablas sean mucho más rápidos. Y esto no fue el resultado de estadísticas desactualizadas, ya que no generó cambios en los planes de ejecución.

1
user172049

¿Por qué los objetos de la base de datos se vacían de la caché en primer lugar? ¿Está reiniciando los servicios SQL o desactivando/conectando la base de datos? ¿O se eliminan mediante el almacenamiento en caché de otras bases de datos?

Saludos,

SCM.

1
SuperCoolMoss

Si la base de datos es tan pequeña, ¿considera instalarla en SSD?

1
Roger Lipscombe

¿Por qué no instala un segunda instancia de SQL Server con solo esa base de datos y establece el memoria mínima para esa instancia en 6GB?

Esto garantizará que sus otras bases de datos nunca roben memoria de su base de datos "pequeña pero muy importante".

También significará que puede desconectar la otra instancia y su pequeña base de datos permanecerá en la memoria.

0
Portman

Usaría profiler para verificar su sql. Compare las lecturas "lógicas" con las lecturas "físicas". El servidor SQL es inteligente y utilizará la RAM que necesita para obtener los resultados más eficientes.

También verifique que sus autoestados estén actualizados.

Sin más idea del tipo de consulta y los tamaños de la tabla db, suena un poco extraño.

0
Guy