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

  • Makale

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ğiniz varsayılır:

  • 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.

  • Veritabanlarını yedekleme veya geri yükleme.
  • Paralel BCP yürütmeleri kullanarak ve aynı birime yazarak BCP aracılığıyla birden çok dosyaya toplu kopyalama gerçekleştirebilirsiniz.

Bu işlemlerin sonucunda, SQL Server çalıştığı ortama bağlı olarak SQL Server Hata günlüğünde bildirilen bu hatalardan birini 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 gibi sys.dm_exec_requestssys.dm_os_waiting_tasksç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 bellek dökümü oluşturan verimsiz bir zamanlayıcı sorunu gözlemleyebilirsiniz.

Neden

Ntfs'de yoğun olarak parçalanmış bir dosyayı korumak 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 girişte 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 ortaya çıkan 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 bölünebilir.

Aynı birimde bulunan bir dizi dosya arasında veritabanı yedeklemeleri gerçekleştirirseniz veya verileri aynı birimde 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 eksiksiz 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'nin sunduğu sınırlarla aynı ATTRIBUTE_LIST_ENTRY 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ümler, anlık görüntüler oluşturmak CHECKDB için seyrek dosyalar yerine adlandırılmış dosya akışları kullanıyordu. 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'te başlayan bir iç anlık görüntü veritabanını oluşturma başlığı altındaki nota bakın.

  2. Veritabanı dosyalarının bulunduğu birimin parçasını kaldırın. Birleştirme yardımcı programınızın işlemsel olduğundan emin olun. SQL Server dosyaların bulunduğu sürücüleri birleştirme hakkında daha fazla bilgi için bkz. Veritabanı sürücülerini SQL Server birleştirirken alınacak önlemler ve Öneriler. Dosyalarda bu işlemi 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ülerinde (SSD) farklı çalışır ve genellikle sorunu çözmez. Dosyaları kopyalamak ve SSD üretici yazılımının fiziksel depolama alanını 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, veritabanı anlık görüntüsü için seyrek bir dosya oluşturduğundan kullanırken DBCC CHECKDB yararlı olmayabilir.

    Not

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

  5. Büyük bir veritabanını daha küçük dosyalara ayırma. Örneğin, bir 8 TB 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 az 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. İşlemin ana hatlarını oluşturan üst düzey adımlar şunlardır:

    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 tabloda kümelenmiş dizin 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 olursa ve büyüme artışı boyutu ne kadar büyük olursa, dosya parçalanma olasılığı da o kadar düşüktür.

  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 hatadan kaçınmanız için bir garanti sağlamadığını, ancak çoğu durumda olasılığı azaltacağını unutmayın.

  8. Veritabanı yedeklemelerini birçok dosya arasında gerçekleştiriyorsanız (şerit kümesi), dosya MAXTRANSFERSIZE sayısını dikkatle planlayın ve BLOCKSIZE (bkz . YEDEKLEME). Amaç, genellikle büyük bayt öbeklerini bir dosyaya birlikte yazarak gerçekleştirilen dosya sistemindeki parçaları azaltmaktır. Daha hızlı performans ve parçalanmayı azaltmak 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 ayarlayabilirsiniz. Ya da 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. komutunu 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 bir diğer 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