¿Errores de memory en SQL 2000 con SP4?

Tengo un server del SQL 2000 con un package de DTS que se estrella con errores de memory insuficientes, donde nunca hemos tenido un problema antes.

El package DTS devuelve el error "No hay suficiente memory del sistema para ejecutar esta consulta." El logging de errores de SQL muestra cosas como: (líneas duplicadas recortadas para simplificar)

BPool::Map: no remappable address found. Buffer Distribution: Stolen=198908 Free=779 Procedures=349 Inram=0 Dirty=10291 Kept=0 Buffer Counts: Commited=917376 Target=917376 Hashed=717340 InternalReservation=174 ExternalReservation=24 Min Free=1024 Visible= 199856 Procedure Cache: TotalProcs=17 TotalPages=349 InUsePages=340 Dynamic Memory Manager: Stolen=164278 OS Reserved=1048 OS Committed=1026 OS In Use=1024 Query Plan=416 Optimizer=141466 General=16874 Buffer Counts: Commited=917376 Target=917376 Hashed=717340 Utilities=5840 Connection=206 InternalReservation=174 ExternalReservation=24 Min Free=1024 Visible= 199856 Procedure Cache: TotalProcs=17 TotalPages=349 InUsePages=340 Utilities=5840 Connection=206 Global Memory Objects: Resource=1272 Locks=279 SQLCache=52 Replication=2 LockBytes=2 ServerGlobal=23 Xact=35 Query Memory Manager: Grants=1 Waiting=0 Maximum=35238 Available=270 

¿Puede alguien ayudarme a interpretar / descifrar algunos de estos numbers de memory?

Se trata de un server Windows2003 dedicado que ejecuta SQL2000 Enterprise Edition, build 8.00.2282 (SP4). Tiene un total de 8GB de RAM. La instancia de SQL está configurada con Min Memory = 0, Max Memory = 7167. AWE está habilitado.

He encontrado un montón de artículos que parecen un poco relacionados:

  • KB 838459 – Pero ya estamos en SP4, y esto no es un reindex.
  • KB 815114 – Parece relevante, ya que nuestra consulta tiene MUCHAS tablas en la combinación, más de la mitad con una LEFT OUTER, pero como ya he dicho, ya estamos en SP4.
  • KB 831999 – Ditto. Ya en SP4.

Reconozco que esta es una gran consulta peluda, pero hemos ejecutado la consulta idéntica durante años sin problemas, e incluso si la consulta no es realmente óptima, no debe bloquear el server, o no ejecutar, ¿verdad?

¿Algunas ideas? ¿Debemos probar el indicador de traza 3940 mencionado en kb838459, aunque el escenario no es exactamente el mismo?

Sí, hemos estado animándolos a actualizar a SQL2008 de 64 bits, pero eso es un rato.

Como he publicado en mi comentario a la pregunta, nos topamos con este problema cuando uno de nuestros serveres SQL estaba recibiendo más de la cantidad normal de uso. Al boost el file de la página, pudimos proporcionar un poco más de resources a los usuarios durante este período de time.

Esta no fue nuestra solución permanente, ya que después de este punto pudimos reevaluar las necesidades de performance de la máquina y le dio algunas pequeñas mejoras. Yo no recomendaría el uso de esta solución a grandes problemas en curso, pero fue una banda suficiente para nosotros.