Aracılığıyla paylaş

SQL Server dosyaları için işletim sistemi hataları 665 ve 1450 bildiriliyor

Bu makale, veritabanı dosyaları yürütülürken DBCC CHECKDB, Veritabanı Anlık Görüntüsü oluşturulurken veya dosya büyümesi oluşturulurken veritabanı dosyaları için 1450 ve 665 işletim sistemi hatalarının bildirilmesi sorununu çözmenize yardımcı olur.

Özgün ürün sürümü: SQL Server
Özgün KB numarası: 2002606

Belirtiler

SQL Server çalıştıran bir bilgisayarda aşağıdaki eylemlerden birini gerçekleştirdiğinizden emin olun:

  • Büyük bir veritabanında veritabanı anlık görüntüsü oluşturursunuz. Ardından, kaynak veritabanında çok sayıda veri değişikliği veya bakım işlemi gerçekleştirirsiniz.
  • Yansıtma veritabanında veritabanı anlık görüntüsü oluşturursunuz.
  • Büyük bir veritabanının DBCC CHECKDB tutarlılığını denetlemek için komut ailesini yürütür ve ayrıca bu veritabanında çok sayıda veri değişikliği gerçekleştirirsiniz.

Not

SQL Server şu işlemler için seyrek dosyalar kullanır: veritabanı anlık görüntüsü ve DBCC CHECKDB.

Bu işlemlerin sonucunda, SQL Server'ın üzerinde çalıştığı ortama bağlı olarak SQL Server Hata günlüğünde bildirilen bu hatalardan bir veya daha fazlasını görebilirsiniz.

The operating system returned error 665(The requested operation could not be completed due to a file system limitation) to SQL Server during a write at offset 0x00002a3ef96000 in file 'Sam.mdf:MSSQL_DBCC18'

The operating system returned error 1450 (Insufficient system resources exist to complete the requested service.) to SQL Server during a write at offset 0x00002a3ef96000 in file with handle 0x0000000000000D5C. This is usually a temporary condition and the SQL Server will keep retrying the operation. If the condition persists, then immediate action must be taken to correct it.`

Bu hatalara ek olarak, aşağıdaki Mandal Zaman Aşımı hatalarını da fark edebilirsiniz:

Timeout occurred while waiting for latch: class *'DBCC_MULTIOBJECT_SCANNER'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.  

Timeout occurred while waiting for latch: class *'ACCESS_METHODS_HOBT_COUNT'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.

Ayrıca ve sys.dm_os_waiting_tasksgibi sys.dm_exec_requests çeşitli dinamik yönetim görünümlerini (DMV) görüntülediğinizde de engelleme fark edebilirsiniz.

Nadir durumlarda, SQL Server hata günlüğünde bildirilen ve SQL Server'ın bir bellek dökümü oluşturduğu verimsiz bir zamanlayıcı sorunu gözlemleyebilirsiniz.

Neden

Ntfs'de yoğun şekilde parçalanmış bir dosyanın bakımını yapmak için çok sayıda ATTRIBUTE_LIST_ENTRY örnek gerekiyorsa bu sorun oluşur. Alan, dosya sistemi tarafından zaten izlenen bir kümenin yanındaysa, öznitelikler tek bir girdide sıkıştırılır. Ancak, alan parçalanmışsa, birden çok öznitelikle izlenmesi gerekir. Bu nedenle, ağır dosya parçalanması öznitelik tükenmesine ve sonuçta oluşan 665 hatasına yol açabilir. Bu davranış şu KB makalesinde açıklanmıştır: NTFS birimindeki yoğun parçalanmış bir dosya belirli bir boyutun ötesine geçmeyebilir.

SQL Server veya diğer uygulamalar tarafından oluşturulan hem normal hem de seyrek dosyalar, bu anlık görüntü dosyalarının ömrü boyunca büyük miktarda veri değişikliği gerçekleştiğinde bu düzeylere parçalanabilir.

Tümü aynı birimde bulunan bir dizi dosya arasında veritabanı yedeklemeleri gerçekleştirirseniz veya verileri aynı birimdeki birden çok dosyaya toplu olarak kopyalarsanız (BCP-ing) yazma işlemleri bitişik konumlara gelebilir ancak farklı dosyalara ait olabilir. Örneğin, bir akış 201 ile 400 arasında kaydırmak için yazar, diğer akış 401 ile 600 arasında yazar, üçüncü akış 601 ile 800 arasında yazabilir. Bu işlem diğer akışlar için de devam eder. Bu, aynı fiziksel medyada dosya parçalanmasına neden olur. Yedekleme dosyalarının veya BCP çıkış akışlarının her biri bitişik depolama alanı almadığından öznitelik depolama alanını tüketebilir.

SQL Server Altyapısı'nın NTFS seyrek dosyalarını ve alternatif veri akışlarını nasıl kullandığına ilişkin tam bir arka plan için bkz . Daha fazla bilgi.

Çözüm

Bu sorunu çözmek için aşağıdaki seçeneklerden birini veya daha fazlasını kullanmayı göz önünde bulundurun:

  1. Veritabanı dosyalarını NTFS ile aynı ATTRIBUTE_LIST_ENTRY sınırlara sahip olmayan Dayanıklı Dosya Sistemi (ReFS) birimine yerleştirin. Geçerli NTFS birimini kullanmak istiyorsanız, veritabanı dosyalarınızı geçici olarak başka bir yere taşıdıktan sonra ReFS kullanarak yeniden biçimlendirmeniz gerekir. ReFS kullanmak, bu sorunla başa çıkmak için en iyi uzun vadeli çözümdür.

    Not

    SQL Server 2012 ve önceki sürümlerde anlık görüntüler oluşturmak CHECKDB için seyrek dosyalar yerine adlandırılmış dosya akışları kullanılmıştır. ReFS dosya akışlarını desteklemez. ReFS'de SQL Server 2012 dosyalarında çalıştırmak DBCC CHECKDB hatalara neden olabilir. Daha fazla bilgi için DBCC CHECKDB'nin SQL Server 2014'le başlayan bir iç anlık görüntü veritabanı oluşturma başlığındaki nota bakın.

  2. Veritabanı dosyalarının bulunduğu birimin parçalarını kaldırın. Birleştirme yardımcı programınızın işlemsel olduğundan emin olun. SQL Server dosyalarının bulunduğu sürücüleri birleştirme hakkında daha fazla bilgi için bkz . SQL Server veritabanı sürücülerini birleştirirken alınacak önlemler ve Öneriler. Bu işlemi dosyalar üzerinde gerçekleştirmek için SQL Server'ı kapatmanız gerekir. Dosyaları bir güvenlik önlemi olarak birleştirmeden önce tam veritabanı yedeklemeleri oluşturmanızı öneririz. Birleştirme, katı hal sürücüleri (SSD) medyada farklı çalışır ve genellikle sorunu çözmez. Dosyaları kopyalamak ve SSD üretici yazılımının fiziksel depolamayı yeniden paketlemesine izin vermek genellikle daha iyi bir çözümdür. Daha fazla bilgi için bkz. İşletim Sistemi Hatası (665 - Dosya Sistemi Sınırlaması) Artık yalnızca DBCC için değil.

  3. Dosya kopyalama - baytlar işlem sırasında sıkı bir şekilde paketlenmiş olabileceğinden dosyanın bir kopyasının gerçekleştirilmesi daha iyi alan elde edilmesine olanak tanıyabilir. Dosyanın kopyalanması (veya farklı bir birime taşınması) öznitelik kullanımını azaltabilir ve işletim sistemi hatası 665'i engelleyebilir. Veritabanı dosyalarından birini veya daha fazlasını başka bir sürücüye kopyalayın. Ardından, dosyayı yeni birimde bırakabilir veya özgün birime geri kopyalayabilirsiniz.

  4. Büyük bir FRS elde etmek için /L seçeneğini kullanarak NTFS birimini biçimlendirin. Bu seçim, sorunu daha büyük hale getirdiğinden ATTRIBUTE_LIST_ENTRY bu sorunu rahatlatabilir. Bu seçenek kullanılırken DBCC CHECKDB yararlı olmayabilir çünkü ikinci seçenek veritabanı anlık görüntüsü için seyrek bir dosya oluşturur.

    Not

    Windows Server 2008 R2 ve Vista çalıştıran sistemler için, komutuyla seçeneği kullanmadan önce 967351 KB makalesindeki düzeltmeyi /L format uygulamanız gerekir.

  5. Büyük bir veritabanını daha küçük dosyalara ayırın. Örneğin, 8 TB'lık bir veri dosyanız varsa, bunu sekiz adet 1 TB veri dosyasına bölebilirsiniz. Bu seçenek, daha küçük dosyalarda daha az değişiklik olacağından ve bu nedenle öznitelik tükenmesine neden olma olasılığı daha düşük olduğundan yardımcı olabilir. Ayrıca, verileri taşıma işleminde dosyalar küçük bir şekilde düzenlenir ve parçalanma azaltılır. Aşağıda, işlemin ana hatlarını oluşturan üst düzey adımlar bulunur:

    1. Yedi yeni 1 TB dosyayı aynı dosya grubuna ekleyin.
    2. Mevcut tabloların kümelenmiş dizinlerini yeniden derleyin. Bu dizinler, her tablonun verilerini otomatik olarak sekiz dosyaya yayar. Bir tablonun kümelenmiş dizini yoksa, bir dizin oluşturun ve aynı şeyi gerçekleştirmek için bırakın.
    3. Şu anda yaklaşık %12 dolu olan özgün 8 TB dosyasını küçültün.

  6. Veritabanı Otomatik büyütme ayarı: Otomatik büyüme artışı veritabanı ayarını, üretim performansına ve NTFS özniteliklerinin paketlenmesine uygun boyutları almak için ayarlayın. Otomatik büyüme oluşumları ne kadar az sıklıkta olursa ve büyüme artış boyutu ne kadar büyük olursa, dosya parçalanma olasılığı o kadar az olur.

  7. Performans geliştirmelerini kullanarak komutların DBCC CHECK ömrünü azaltın ve 665 hatalarından kaçının: DBCC CHECKDB komutuna yönelik geliştirmeler, PHYSICAL_ONLY seçeneğini kullandığınızda daha hızlı performansa neden olabilir. Anahtarla PHYSICAL_ONLY çalıştırmanın DBCC CHECKDB bu hatayı önlemeniz için bir garanti sağlamadığını, ancak çoğu durumda bu olasılığı azaltacağını unutmayın.

  8. Birçok dosyada (şerit kümesi) veritabanı yedeklemesi gerçekleştiriyorsanız, dosya MAXTRANSFERSIZE sayısını dikkatlice planlayın ve BLOCKSIZE (bkz . YEDEKLEME). Amaç, genellikle büyük bayt öbeklerini bir dosyaya yazarak gerçekleştirilen dosya sistemindeki parçaları azaltmaktır. Daha hızlı performans ve parçalanmanın azaltılması için dosyaları birden çok birime ayırmayı düşünebilirsiniz.

  9. Aynı anda birden çok dosya yazmak için BCP kullanıyorsanız, yardımcı program yazma boyutlarını ayarlayın, örneğin BCP toplu iş boyutunu artırın. Ayrıca, parçalanmayı önlemek veya paralel yazma sayısını azaltmak için farklı birimlere birden çok akış yazmayı göz önünde bulundurun.

  10. yürütmek DBCC CHECKDBiçin bir Kullanılabilirlik Grubu veya Günlük Gönderimi/Bekleme sunucusu ayarlamayı düşünebilirsiniz. Alternatif olarak, işi boşaltmak ve seyrek dosyaların ağır parçalanmasından kaynaklanan sorunlarla karşılaşmamak için komutları çalıştırabileceğiniz DBCC CHECKDB ikinci bir sunucu kullanın.

  11. yürütürken DBCC CHECKDBkomutunu veritabanı sunucusunda çok az etkinlik olduğu bir zamanda çalıştırırsanız seyrek dosyalar hafifçe doldurulur. Dosyalara daha az yazma işlemi, NTFS'de özniteliklerin tükenme olasılığını azaltır. Daha az etkinlik, mümkün olduğunda ikinci bir salt okunur sunucuda çalıştırmanın DBCC CHECKDB başka bir nedenidir.

  12. SQL Server 2014 çalıştırıyorsanız en son Hizmet Paketine yükseltin. Daha fazla bilgi için bkz . DÜZELTME: SQL Server 2014'te columnstore dizini içeren veritabanı için DBCC CHECKDB komutunu yürütürken işletim sistemi hatası 665.

Daha Fazla Bilgi

  • Last updated on