El disco del sistema se queda sin espacio al ejecutar consultas SQL pesadas en SQL Server 2012


14

Soy bastante nuevo en SQL Server 2012, agradecería si alguien puede ayudar. He restaurado una copia de una gran base de datos en SQL Server 2012 e intenté ejecutar algunas consultas simples en su contra.

Estoy tratando de ejecutar una consulta SELECT en una tabla de 136898115líneas de base de datos . Esta SELECTconsulta solo tiene una WHEREcláusula simple . Cada vez que ejecuto esta consulta, falla porque el disco del sistema (la partición donde está instalado Windows C:\) se queda sin espacio (esta partición tiene solo 6GB de espacio libre), y no entiendo por qué. Definí mi tempdb para estar en una unidad diferente, que tiene más de 14 terabytes de espacio libre. Por supuesto, mi base de datos también se encuentra en una unidad diferente.

¿Qué hace que mi partición del sistema se quede sin espacio? ¿Es el archivo de la página?


2
me estoy quedando sin espacio del sistema, estoy ejecutando SSMS, pero es la misma máquina. Estoy usando SSMS en el servidor SQL real.
royv

2
En general, se recomienda no ejecutar ninguna otra aplicación en un cuadro de Windows de SQL Server ( no SSMS), o asegurarse de que la configuración de memoria máxima sea lo suficientemente baja como para permitir suficiente RAM libre. Vea mi respuesta aquí: dba.stackexchange.com/a/19776/2718
Jon Seigel

Respuestas:


12

Los resultados de la consulta SSMS se almacenan en caché en la unidad C: de forma predeterminada. Vaya a Herramienta \ Opciones. Ver adjunto. Cambie esto a otro volumen con más almacenamiento y debería estar bien.

ingrese la descripción de la imagen aquí


1
Si selecciona Resultados en archivo, ahí es donde se abre el cuadro de diálogo Guardar como por defecto. No creo que SSMS guarde los conjuntos de resultados en el disco de forma predeterminada, pero podría estar equivocado.
Jon Seigel

1
Los resultados que obtiene en su ventana de consulta se almacenan en caché según mi publicación. Verifique su unidad, ejecute una consulta grande en SSMS y verifique nuevamente. Verá la pérdida de almacenamiento en su unidad C: si no ha especificado lo contrario.
Eric Higgins el

1
es verdad. no está relacionado con mi archivo de página. moví mi archivo de página a otra unidad, y aún así mi unidad C: se quedó sin espacio.
royv

11

Bien, lo descubrí: ¡ Eric y yo teníamos razón!

  • La ruta en el cuadro de diálogo es, como dije, solo una ruta predeterminada para guardar los resultados de la consulta.
  • Los resultados de la consulta se almacenan en caché en el disco (estaba equivocado), pero en la carpeta temporal del perfil local ( C:\Users\<UserName>\AppData\Local\Tempen mi caso aquí). Lo comprobé y no parece haber una forma obvia de desactivar este almacenamiento en caché.

Entonces las conclusiones son:

  • Evite ejecutar SSMS directamente en el cuadro SQL
  • No SELECT *desde una tabla enorme en SSMS a menos que el conjunto de resultados pueda caber en la carpeta de perfil
  • Asegúrese de que la configuración de memoria máxima de SQL Server esté configurada correctamente (puede o no haber contribuido a este problema con respecto al crecimiento del archivo de página)

7

Acabo de sufrir el mismo problema. Después de leer las respuestas anteriores, encontré lo siguiente.

Herramientas | Las opciones no son la respuesta. La mía se configuró en Y: unidad, pero vi cómo se ejecutaba mi consulta y el espacio en la unidad C: se redujo de 2.9GB a 5.04MB (antes de eliminar la consulta).

Así que pensé que probablemente sean resultados de almacenamiento en caché (ya que son muy grandes con cada fila devuelta que contiene una gran parte de XML) al directorio Temp, que es lo que dijo Jon, sin embargo, no estaba seguro de cómo cambiaría eso.

Lo que hice para cambiar el lugar donde se escriben los archivos temporales fue abrir mis Variables de entorno y editar las variables de usuario TEMP y TMP (ambas configuradas en C: \ Temp) para escribir en Z: \ Temp.

Puedo confirmar que después de este cambio, vi la consulta crear un archivo muy grande en mi directorio Z: \ Temp.


Excelente información cuando hay un proceso por el que tiene que pasar para actualizar el espacio HD de su vm y tener mucho almacenamiento en la red. Sin embargo, tengo un poco de curiosidad, si tiene problemas de red con tasas de transferencia de archivos de cuello de botella, ¿podría moverse fuera de su rendimiento de consulta lenta c: \?
GibralterTop

Eso fue hace 3 años y no puedo recordar exactamente cuáles eran las circunstancias en ese momento. Ahora tengo una computadora portátil con una cantidad patética de RAM y potencia de procesamiento, que es otra historia. Estoy bastante seguro de que la unidad Z: era solo otra unidad "local" en mi VM. No estoy seguro de por qué no lo etiquetaron D: o E: pero esa parte estaba fuera de mi control. Entonces, para mí no había realmente un problema de red.
Nick Ryan
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.