SQL Server 2005 Memoria Presión y tempdb escribe problema

Question

Estamos teniendo algunos problemas con nuestro servidor SQL de producción.

Servidor: Dual Xeon Quad Core 8 GB de RAM RAID Individual 10 Matriz Windows 2003 Server de 64 bits SQL Server 2005 Standard 64-Bit

Hay alrededor de 250 MB de memoria RAM libre en la máquina en este momento . SQL Server tiene alrededor de 6 GB de RAM, y nuestro software de monitoreo dice que solo la mitad de la RAM asignada por SQL Server se está usando.

Nuestra base de datos principal es de aproximadamente 20 GB, con aproximadamente 12 GB en uso con cualquier frecuencia. Nuestro tempdb está a 700MB. Ambos se encuentran en la misma matriz de discos físicos.

Además, utilizando Filemon, pude ver que el archivo tempdb tenía 100 o 1000 de escrituras de longitud 65536. La longitud de la cola del disco era más de 100 casi el 80% del tiempo.

Por lo tanto, aquí están mis preguntas-

1. Lo que haría que todos esos escribe en el tempdb? No estoy seguro de si siempre hemos tenido tanta actividad, pero parece excesiva y estos problemas son recientes.

2. ¿Debo agregar más memoria al servidor?

3. En servidores de alta carga, ¿los archivos tempdb y db deben ubicarse en matrices separadas?

Answer 1

Una longitud de cola de disco alta no significa que tenga un cuello de botella de E/S si tiene una SAN o NAS, es posible que desee ver otros contadores adicionales. Consulte SQL Server Urban Legends discussed para obtener más detalles.

1: Las siguientes operaciones se emplean mucho tempdb

• repetida crear y gota de tablas temporales (locales o globales)
• variables de tabla que utilizan tempdb con fines de almacenamiento
tablas
• de trabajo asociados con los cursores
• Tablas de trabajo asociadas con una cláusula ORDER BY
• Tablas de trabajo asociadas con una cláusula GROUP BY
• archivos de trabajo asociados con HASH PLANES

Estas características de SQL Server 2005 también utilizan tempdb en gran medida:

• nivel de versiones de filas (snapshotisolation)
• índice en línea re-construcción de

Como mencionado en otras respuestas de SO lea this article sobre las mejores prácticas para aumentar el rendimiento de tempdb.
2: Mirando la cantidad de RAM libre en el servidor, es decir, mirando el contador WMI Memoria-> Mbytes disponibles no ayuda, SQL Server almacenará las páginas de datos en RAM, por lo que cualquier servidor db que se ejecute tendrá poca RAM libre.
Los contadores que usted debe mirar que tienen más sentido en que le dice si la adición de memoria RAM para el servidor ayudará son:
instancia de SQL Server: Buffer Manager-> Página Esperanza de vida (en segundos) Un valor por debajo de 300- 400 segundos significará que las páginas no están en la memoria por mucho tiempo y que los datos se leen continuamente desde los discos. Los servidores que tienen una baja esperanza de vida de la página se beneficiarán de RAM adicional.
y
instancia de SQL Server: Buffer Manager-> Buffer de aciertos de caché Esto le indica el porcentaje de páginas que se lee desde la RAM que no tiene que incurrir en una lectura desde el disco, una proporción de aciertos de caché más bajo entonces 85 significará que el servidor se beneficiará de RAM adicional

3: Sí, no puede salir mal aquí.Se recomienda tener tempdb en un conjunto separado de discos. Mire this KB article bajo el título: Moviendo la base de datos tempdb sobre cómo hacer esto.

Answer 2

excelente pregunta, 1

tempdb se utiliza mucho más fuertemente en SQL 2005+. Al menos : niveles de aislamiento de instantáneas, índice en línea reconstruir, lectura insertadas/suprimidas en disparadores

Esto además del orden habitual de cláusulas, etc. tablas temporales

Usted (utilizado para leer el archivo de registro!) Probablemente sería mejor dividir sus archivos de registro y datos (también para la capacidad de recuperación). Más memoria siempre es buena, pero vea esto 64 bit specific stuff, Grumpy Old DBA a continuación.

Por último, y tal vez más importante, probablemente, puede hacer que la contención de la asignación de espacio en tempdb: Explicaciones de Linchi Shea y SQL Server storage team

Late edición:

Paul Randall añade una entrada "Comprehensive tempdb blog post series", que ofrece una buena enlaces

Answer 3

Sí, la recomendación en servidores de alta carga es poner TempDB en un conjunto separado de unidades de las bases de datos de usuario:

SQL Server 2005 Books Online: Optimizing tempdb Performance

Answer 4

1. escribe en el tempdb puede ser cualquier cosa. Tablas hash internas, tablas temporales, variables de tablas, llamadas a procedimientos almacenados, etc.

2. Si solo tiene 250 Megas de RAM libre, entonces sí, más RAM sería bueno.

3. Siempre se recomienda dividir las bases de datos tempdb y de usuario en diferentes discos.

Todas las escrituras en el tempdb tendrán un tamaño de 64k ya que ese es el tamaño de cada extensión de base de datos.

Answer 5

No respondiste directamente a tu pregunta, pero podría ser un buen consejo: al reiniciar tu instancia de SQL Server se borrará la tempdb, esto podría ser un buen comienzo al investigar las acciones que se realizan en tempdb.