SQL Server 2012'de ağır SQL sorguları çalıştırırken sistem diskinde yer kalmadı

14

SQL Server 2012 için oldukça yeniyim, birisi yardımcı olabilirse minnettar olurum. SQL Server 2012'ye büyük bir veritabanının bir kopyasını geri yükledim ve buna karşı bazı basit sorgular çalıştırmayı denedim.

136898115Satırların veritabanı tablosu karşı bir SELECT sorgusu çalıştırmak çalışıyorum . Bu SELECTsorgunun yalnızca basit bir WHEREcümlesi vardır. Bu sorguyu her çalıştırdığımda, sistem diski (Windows'un yüklü olduğu bölüm - C:\) boş kaldığı için (bu bölümün yalnızca 6GB boş alanı var) başarısız oluyor ve nedenini anlamıyorum. Tempdb'imi 14 terabayttan fazla boş alana sahip farklı bir sürücüde tanımladım. Tabii ki veritabanım da farklı bir sürücüde bulunuyor.

Sistem bölümümü boş alan bitiren nedir? Sayfa dosyası mı?

sql-server tempdb

— royv
kaynak

2

im sistemden alan bitiyor im SSMS çalışıyorum, ama aynı makine. im gerçek SQL sunucusunda SSMS kullanarak.

— royv

2

Genellikle, SQL Server ( SSMS değil ) Windows kutusunda başka bir uygulama çalıştırmamanız veya maksimum bellek ayarının yeterli boş RAM'e izin verecek kadar düşük olduğundan emin olmanız önerilir . Cevabımı burada görebilirsiniz: dba.stackexchange.com/a/19776/2718

— Jon

12

SSMS sorgusu sonuçları varsayılan olarak C: sürücüsünün önbelleğine alınır. Araç \ Seçenekler'e gidin. Eke bakınız. Daha fazla depolama alanı ile başka bir birime değiştirin ve iyi olmalısınız.

resim açıklamasını buraya girin

— Eric Higgins
kaynak

1

Sonuçlar Dosyaya seçeneğini belirlerseniz, Farklı Kaydet iletişim kutusu varsayılan olarak açılır. SSMS'nin varsayılan olarak sonuç kümelerini diske kaydettiğini sanmıyorum, ama yanılmış olabilirim.

— Jon Seigel

1

Sorgu pencerenizde alacağınız sonuçlar yazıma göre önbelleğe alınır. Sürücünüzü kontrol edin, SSMS'de büyük bir sorgu çalıştırın ve tekrar kontrol edin. Aksi belirtmediyseniz C: sürücünüzde depolama kaybı görürsünüz.

— Eric Higgins

1

bu doğru. sayfa sayfamla ilgili değil. sayfa dosyamı başka bir sürücüye taşıdım ve hala C: sürücümün alanı bitti.

— royv

11

Tamam, anladım: Eric ve ben ikimiz de haklıydık!

Dediğim gibi, iletişim kutusundaki yol sadece sorgu sonuçlarını kaydetmek için varsayılan bir yoldur.
Sorgu sonuçları olan disk (yanılmışım) önbelleğe, ancak yerel profil içinde geçici klasörde ( C:\Users\<UserName>\AppData\Local\Tempburada benim durumumda). Kontrol ettim ve bu önbelleği kapatmanın açık bir yolu yok gibi görünüyor.

Yani paketler:

SSMS'yi doğrudan SQL kutusunda çalıştırmaktan kaçının
Do SELECT *sonuç kümesi profil klasöründe sığabilecek SSMS büyük bir tablodan sürece
SQL Server maksimum bellek ayarının doğru yapılandırıldığından emin olun (sayfa dosyasının büyümesiyle ilgili olarak bu soruna katkıda bulunmuş olabilir veya olmayabilir)

— Jon Seigel
kaynak

7

Ben sadece aynı sorunu yaşadım. Yukarıdaki cevapları okuduktan sonra aşağıdakileri buldum.

Araçları | Seçenekler cevap değildir. Benimki Y: sürücüsüne ayarlanmıştı ancak C: sürücüsünde 2.9GB'dan 5.04MB'ye (sorguyu öldürmeden önce) dalış alanı ve sorgumun çalışmasını izledim.

Bu yüzden büyük olasılıkla sonuçları önbelleğe aldığını düşündüm (XML'in büyük bir yığınını içeren her satırda çok büyük oldukları gibi) Jon'un Temp dizinine söylediği şey, ancak bunu nasıl değiştireceğinizden emin değildi.

Geçici dosyaların yazıldığı yeri değiştirmek için yaptığım şey, Ortam Değişkenlerimi açmak ve Z: \ Temp'e yazmak için TEMP ve TMP (her ikisi de C: \ Temp olarak ayarlanmış) kullanıcı değişkenlerini düzenlemekti.

Bu değişiklikten sonra, sorguyu Z: \ Temp dizinimde çok büyük bir dosya oluşturduğunu izledim.

— Nick Ryan
kaynak

Vm'nizin HD alanını yükseltmek ve bol miktarda ağ depolama alanına sahip olmak için geçmeniz gereken bir işlem olduğunda harika bilgiler. Ben biraz merak ediyorum, eğer ağ aktarım hızları darboğaz ağ sorunları varsa, c: \ yavaş sorgu performans dışında hareket olabilir?

— GibralterTop

Bu 3 yıl önceydi ve o sırada koşulların tam olarak ne olduğunu hatırlayamıyorum. Şimdi başka bir hikaye olan acıklı bir RAM ve işlem gücüne sahip bir dizüstü bilgisayarım var. Z: sürücünün VM'imde sadece başka bir "yerel" sürücü olduğundan eminim. Neden D: veya E: olarak etiketlemediklerinden emin değilim ama bu kısım kontrolüm dışındaydı. Yani, benim için gerçekten bir ağ sorunu yoktu.

— Nick Ryan