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 (6 GB) pero muy importante a la que se accede un poco lento hasta que las páginas se almacenan en la memoria caché (el uso es muy aleatorio de E / S, 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á un tanto torpemente escrita (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 * desde 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é por este método (y modificar el script para interrogar índices y escriba las cláusulas WHERE apropiadas para almacenar en caché el complejo boil-the-ocean).

No, desafortunadamente no hay una manera 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%, de esta manera:

http://sqlserverpedia.com/wiki/Index_Maintenance

Tomará más tiempo e implicará 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.

Ok, no puedo comentar la respuesta de Brent (todavía, ya que no tengo suficientes repeticiones), pero si vas a ir por la ruta de desfragmentación, no necesariamente reconstruyas 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 tenga al menos el tamaño de sus índices y que su registro también tenga una tonelada de registros (dependiendo del modelo de recuperación). Si va a hacer la ruta de desfragmentación, haga ALTER INDEX ... REORGANIZAR, que no requiere 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 (según el despliegue) deberían ser muchos menos datos que el nivel de hoja.

¿Por qué los objetos de la base de datos se vacían de la caché en primer lugar? ¿Está reiniciando los servicios SQL o quitando la base de datos / en línea? ¿O están siendo expulsados ​​por el almacenamiento en caché de otras bases de datos?

Saludos,

SCM.

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

He tenido algunos escenarios en los que la actualización de estadísticas con FULLSCAN en tablas clave ha forzado los datos a la memoria caché e hizo que mis DML posteriores alrededor de esas tablas fueran mucho más rápidos. Y esto no fue el resultado de estadísticas desactualizadas ya que no resultó en cambios en los planes de ejecución.

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

Esto garantizará que sus otras bases de datos nunca saquen 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.

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

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

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