G/Ç sorunlarının neden olduğu yavaş SQL Server performans sorununu giderme

Şunlar için geçerlidir: SQL Server

Summary

Bu makale, disk G/Ç performans sorunlarının neden olduğu yavaş SQL Server performansını tanılamak ve çözmek için adım adım bir metodoloji sağlar. SQL Server bekleme türlerini, dinamik yönetim görünümünü ve Windows Performans İzleyicisi sayaçlarını kullanarak G/Ç gecikme süresini tanımlamayı sys.dm_io_virtual_file_stats açıklar. G/Ç alt sisteminin bunalmış olup olmadığını, SQL Server G/Ç'nin birincil sürücüsü olup olmadığını ve hangi donanım, sorgu, filtre sürücüsü veya uygulama düzeyi nedenlerinin araştırılmasını nasıl belirleyeceğinizi öğreneceksiniz. G/Ç gecikmesinin kaynağını yalıtmak ve şirket içi SQL Server dağıtımları için doğru düzeltmeyi uygulamak için bu kılavuzu kullanın.

Yavaş G/Ç performansını tanımlama

Performans izleyici sayaçları yavaş G/Ç performansını belirlemek için kullanılır. Bu sayaçlar, G/Ç alt sistemi hizmetlerinin her G/Ç isteğinin ortalama olarak saat süresi açısından ne kadar hızlı olduğunu ölçer. Windows'taki G/Ç gecikme süresini ölçen belirli Performans izleyicisi sayaçları Avg Disk sec/ Read, Avg. Disk sec/Write ve Avg. Disk sec/Transfer'dir (hem okuma hem de yazma işlemlerinin toplamı olarak değerlendirilir).

SQL Server'da işler aynı şekilde çalışır. Genellikle SQL Server'ın saat süresi (milisaniye) cinsinden ölçülen G/Ç performans sorunlarını bildirip bildirmediğine bakarsınız. SQL Server, , WriteFile(), ReadFile()ve WriteFileGather()gibi ReadFileScatter()Win32 işlevlerini çağırarak işletim sistemine G/Ç isteklerinde bulunur. SQL Server bir G/Ç isteği gönderdiğinde, isteğin süresini zamanlar ve bu süreyi bekleme türlerini kullanarak raporlar. SQL Server, ürünün farklı yerlerinde G/Ç beklemelerini belirtmek için bekleme türlerini kullanır. G/Ç ile ilgili bekleme süreleri şunlardır:

• / PAGEIOLATCH_SHPAGEIOLATCH_EX
• WRITELOG
• IO_COMPLETION
• ASYNC_IO_COMPLETION
• BACKUPIO

Bu bekleme süreleri 10-15 milisaniyeyi sürekli olarak aşıyorsa, G/Ç (Giriş/Çıkış) bir darboğaz olarak kabul edilir.

Not

Bağlam sağlamak için, Microsoft bir G/Ç isteğinin bir saniyeden fazla ve aktarım başına 15 saniyeye kadar sürdüğü SQL Server sistemleri gözlemlemiştir. Bu tür G/Ç sistemleri iyileştirme gerektirir. Buna karşılık Microsoft aktarım hızının aktarım başına bir milisaniyenin altında olduğu sistemleri de görmüştür. Günümüzün SSD ve NVMe teknolojisiyle, tanıtılan aktarım hızı aktarım başına onlarca mikrosaniye aralığındadır.

Aktarım rakamı başına 10-15 milisaniye, Windows ve SQL Server mühendisleri arasındaki kolektif deneyime göre seçilen yaklaşık bir eşiktir. Genellikle sayılar bu eşiğin ötesine geçtiğinde SQL Server kullanıcılar iş yüklerinde gecikmeyi görmeye başlar. Sonuç olarak, bir G/Ç alt sisteminin beklenen aktarım hızı üretici, model, yapılandırma, iş yükü ve diğer faktörler tarafından tanımlanır.

G/Ç performans sorunlarını yalıtmak için metodoloji

Bu makalenin sonundaki akış grafiğinde, SQL Server yavaş G/Ç sorunlarına yaklaşmak için yaygın olarak kullanılan metodoloji açıklanmaktadır. Bu metodoloji kapsamlı veya özel değildir, ancak sorunu yalıtma ve çözme için yararlıdır.

Metodoloji şu adımlarda özetlenmiştir:

1. Adım: SQL Server yavaş Girdi/Çıktı bildiriyor mu?

SQL Server G/Ç gecikme süresini çeşitli yollarla bildirebilir:

• Girdi/Çıktı bekleme türleri
• DMV (Motorlu Taşıtlar Dairesi) sys.dm_io_virtual_file_stats
• Hata günlüğü veya Uygulama Olay günlüğü

Girdi/Çıktı bekleme türleri

SQL Server bekleme türlerinin G/Ç gecikme süresi bildirip bildirmediğini denetleyin. , WRITELOGve ASYNC_IO_COMPLETIONdeğerleri PAGEIOLATCH_*ve diğer birkaç daha az yaygın bekleme türünün değerleri genellikle G/Ç isteği başına 10-15 milisaniyenin altında kalmalıdır. Bu değerler tutarlı bir şekilde bu aralığı aşarsa bir G/Ç performans sorunu oluşur ve daha fazla araştırma gerektirir. Aşağıdaki sorgu, sisteminizde bu tanılama bilgilerini toplamanıza yardımcı olabilir:

#replace with server\instance or server for default instance
$sqlserver_instance = "server\instance" 

for ([int]$i = 0; $i -lt 100; $i++)
{
   
  sqlcmd -E -S $sqlserver_instance -Q "SELECT r.session_id, r.wait_type, r.wait_time as wait_time_ms`
                                       FROM sys.dm_exec_requests r JOIN sys.dm_exec_sessions s `
                                        ON r.session_id = s.session_id `
                                       WHERE wait_type in ('PAGEIOLATCH_SH', 'PAGEIOLATCH_EX', 'WRITELOG', `
                                        'IO_COMPLETION', 'ASYNC_IO_COMPLETION', 'BACKUPIO')`
                                       AND is_user_process = 1"

  Start-Sleep -s 2
}

sys.dm_io_virtual_file_stats içindeki dosya istatistikleri

SQL Server'da bildirilen veritabanı dosya düzeyinde gecikme süresini görüntülemek için aşağıdaki sorguyu çalıştırın:

#replace with server\instance or server for default instance
$sqlserver_instance = "server\instance" 

sqlcmd -E -S $sqlserver_instance -Q "SELECT   LEFT(mf.physical_name,100),   `
         ReadLatency = CASE WHEN num_of_reads = 0 THEN 0 ELSE (io_stall_read_ms / num_of_reads) END, `
         WriteLatency = CASE WHEN num_of_writes = 0 THEN 0 ELSE (io_stall_write_ms / num_of_writes) END, `
         AvgLatency =  CASE WHEN (num_of_reads = 0 AND num_of_writes = 0) THEN 0 `
                        ELSE (io_stall / (num_of_reads + num_of_writes)) END,`
         LatencyAssessment = CASE WHEN (num_of_reads = 0 AND num_of_writes = 0) THEN 'No data' ELSE `
               CASE WHEN (io_stall / (num_of_reads + num_of_writes)) < 2 THEN 'Excellent' `
                    WHEN (io_stall / (num_of_reads + num_of_writes)) BETWEEN 2 AND 5 THEN 'Very good' `
                    WHEN (io_stall / (num_of_reads + num_of_writes)) BETWEEN 6 AND 15 THEN 'Good' `
                    WHEN (io_stall / (num_of_reads + num_of_writes)) BETWEEN 16 AND 100 THEN 'Poor' `
                    WHEN (io_stall / (num_of_reads + num_of_writes)) BETWEEN 100 AND 500 THEN  'Bad' `
                    ELSE 'Deplorable' END  END, `
         [Avg KBs/Transfer] =  CASE WHEN (num_of_reads = 0 AND num_of_writes = 0) THEN 0 `
                    ELSE ((([num_of_bytes_read] + [num_of_bytes_written]) / (num_of_reads + num_of_writes)) / 1024) END, `
         LEFT (mf.physical_name, 2) AS Volume, `
         LEFT(DB_NAME (vfs.database_id),32) AS [Database Name]`
       FROM sys.dm_io_virtual_file_stats (NULL,NULL) AS vfs  `
       JOIN sys.master_files AS mf ON vfs.database_id = mf.database_id `
         AND vfs.file_id = mf.file_id `
       ORDER BY AvgLatency DESC"

AvgLatency Gecikme süresi ayrıntılarını anlamak için ve LatencyAssessment sütunlarına bakın.

Hata günlüğünde veya Uygulama Olay günlüğünde bildirilen hata 833

Bazı durumlarda, hata günlüğünde 833 SQL Server has encountered %d occurrence(s) of I/O requests taking longer than %d seconds to complete on file [%ls] in database [%ls] (%d) hatasını gözlemleyebilirsiniz. Aşağıdaki PowerShell komutunu çalıştırarak sisteminizdeki SQL Server hata günlüklerini de kontrol edebilirsiniz:

Get-ChildItem -Path "c:\program files\microsoft sql server\mssql*" -Recurse -Include Errorlog |
   Select-String "occurrence(s) of I/O requests taking longer than Longer than 15 secs"

Bu hata hakkında daha fazla bilgi için MSSQLSERVER_833 bölümüne bakın.

2. Adım: Perfmon Sayaçları G/Ç gecikmesini gösteriyor mu?

SQL Server G/Ç gecikmesi bildiriyorsa işletim sistemi sayaçlarına bakın. Gecikme sayacını Avg Disk Sec/Transferinceleyerek G/Ç sorunu olup olmadığını belirleyebilirsiniz. Aşağıdaki kod parçacığı, bu bilgileri PowerShell aracılığıyla toplamanın bir yolunu gösterir. Tüm disk birimlerinde sayaçları toplar: "_total". Belirli bir sürücü birimine geçin (örneğin, "D:"). Veritabanı dosyalarınızı barındıran birimleri bulmak için SQL Server'ınızda aşağıdaki sorguyu çalıştırın:

#replace with server\instance or server for default instance
$sqlserver_instance = "server\instance" 
sqlcmd -E -S $sqlserver_instance -Q "SELECT DISTINCT LEFT(volume_mount_point, 32) AS volume_mount_point `
                                     FROM sys.master_files f `
                                     CROSS APPLY sys.dm_os_volume_stats(f.database_id, f.file_id) vs"

Seçtiğiniz hacimle ilgili ölçümleri toplayın Avg Disk Sec/Transfer :

clear
$cntr = 0 

# replace with your server name, unless local computer
$serverName = $env:COMPUTERNAME

# replace with your volume name - C: , D:, etc
$volumeName = "_total"

$Counters = @(("\\$serverName" +"\LogicalDisk($volumeName)\Avg. disk sec/transfer"))

$disksectransfer = Get-Counter -Counter $Counters -MaxSamples 1 
$avg = $($disksectransfer.CounterSamples | Select-Object CookedValue).CookedValue

Get-Counter -Counter $Counters -SampleInterval 2 -MaxSamples 30 | ForEach-Object {
$_.CounterSamples | ForEach-Object {
   [pscustomobject]@{
      TimeStamp = $_.TimeStamp
      Path = $_.Path
      Value = ([Math]::Round($_.CookedValue, 5))
         turn = $cntr = $cntr +1
         running_avg = [Math]::Round(($avg = (($_.CookedValue + $avg) / 2)), 5)  
         
   } | Format-Table
     }
   }

   write-host "Final_Running_Average: $([Math]::Round( $avg, 5)) sec/transfer`n"
  
   if ($avg -gt 0.01)
   {
     Write-Host "There ARE indications of slow I/O performance on your system"
   }
   else
   {
     Write-Host "There is NO indication of slow I/O performance on your system"
   }

Bu sayacın değerleri tutarlı olarak 10-15 milisaniyenin üzerindeyse, daha fazla araştırmanız gerekir. Bazı ani artışlar çoğu durumda sayılmaz, ancak ani artışın süresini iki kez kontrol edin. Ani artış bir dakika veya daha fazla sürdüyse, bu daha çok bir plato gibidir.

Performans İzleyicisi sayaçları gecikme süresi bildirmiyorsa ancak SQL Server bildiriyorsa, sorun SQL Server ile Bölüm Yöneticisi arasında, yani filtre sürücüleri arasındadır. Bölüm Yöneticisi, işletim sisteminin Perfmon sayaçlarını topladığı bir G/Ç katmanıdır. Gecikme süresini gidermek için filtre sürücülerinin düzgün dışlanmasını sağlayın ve filtre sürücüsü sorunlarını çözün. Virüsten koruma yazılımı, Yedekleme çözümleri, Şifreleme, Sıkıştırma ve benzer yazılımlar gibi programlar filtre sürücülerini kullanır. Sistemlerdeki ve bunların bağlı olduğu birimlerdeki filtre sürücülerini listelemek için bu komutu kullanın. Ardından, Ayrılan filtre rakımları makalesinde sürücü adlarını ve yazılım satıcılarını arayın.

fltmc instances

Daha fazla bilgi için bkz . SQL Server çalıştıran bilgisayarlarda çalıştırılacak virüsten koruma yazılımını seçme.

Zaman uyumsuz G/Ç'yi zaman uyumlu ve dolayısıyla daha yavaş hale getirdiklerinden dolayı Şifreleme Dosya Sistemi (EFS) ve dosya sistemi sıkıştırmayı kullanmaktan kaçının. Daha fazla bilgi için Windows'da zaman uyumsuz disk G/Ç, zaman uyumlu olarak görünüyor makalesine bakın.

3. Adım: G/Ç alt sistemi kapasitesini aşmış mı?

SQL Server ve işletim sistemi G/Ç alt sisteminin yavaş olduğunu gösteriyorsa, bunun nedeninin sistemin kapasitenin ötesinde aşırı yüklenmiş olup olmadığını denetleyin. G/Ç sayaçlarına Disk Bytes/SecDisk Read Bytes/Sec, veya Disk Write Bytes/Secbakarak kapasiteyi de kontrol edebilirsiniz. SAN'nız (veya diğer G/Ç alt sisteminiz) için beklenen aktarım hızı belirtimleri için sistem yöneticinize veya donanım satıcınıza danışın. Örneğin, 2 GB/sn'lik HBA kartı veya SAN anahtarındaki 2 GB/sn ayrılmış port üzerinden en fazla 200 MB/sn G/Ç aktarabilirsiniz. Donanım üreticisi tarafından tanımlanan beklenen aktarım hızı kapasitesi, buradan nasıl devam ettiğinizi tanımlar.

clear

$serverName = $env:COMPUTERNAME
$Counters = @(
   ("\\$serverName" +"\PhysicalDisk(*)\Disk Bytes/sec"),
   ("\\$serverName" +"\PhysicalDisk(*)\Disk Read Bytes/sec"),
   ("\\$serverName" +"\PhysicalDisk(*)\Disk Write Bytes/sec")
   )
Get-Counter -Counter $Counters -SampleInterval 2 -MaxSamples 20 | ForEach-Object  {
$_.CounterSamples | ForEach-Object       {
   [pscustomobject]@{
      TimeStamp = $_.TimeStamp
      Path = $_.Path
      Value = ([Math]::Round($_.CookedValue, 3)) }
    }
 }

4. Adım: SQL Server yoğun G/Ç etkinliğini mi kullanıyor?

G/Ç alt sistemi kapasitesinin üzerine çıktıysa, belirli bir örnekte SQL Server'ın suçlu olup olmadığını öğrenmek için Buffer Manager: Page Reads/Sec (en yaygın suçlu) ve Page Writes/Sec (çok daha az yaygın) öğelerine bakın. ana G/Ç sürücüsü SQL Server ve G/Ç hacmi sistemin işleyebildiğinin ötesindeyse, uygulama geliştirme ekipleriyle veya uygulama satıcısıyla birlikte çalışarak şunları yapın:

• Sorguları ayarlayın, örneğin: daha iyi dizinler, güncelleştirme istatistikleri, sorguları yeniden yazma ve veritabanını yeniden tasarlama.
• Maksimum sunucu belleğini artırın veya sisteme daha fazla RAM ekleyin. Daha fazla RAM, diskten sık sık yeniden okuma yapmadan daha fazla veri veya dizin sayfasını önbelleğe alır ve bu da G/Ç etkinliğini azaltır. Artan bellek, kullanılabilir sınırlı bellekte daha fazla veritabanı sayfası depolama ihtiyacı sıkça ortaya çıktığında "Lazy Writer" temizlemelerinin oluşturduğu Lazy Writes/sec yükünü de azaltabilir.
• Sayfa yazma işlemlerinin yoğun G/Ç etkinliğinin kaynağı olduğunu fark ederseniz, Buffer Manager: Checkpoint pages/sec öğesini inceleyerek bunun, kurtarma aralığı yapılandırması taleplerini karşılamak için gereken büyük sayfa boşaltmalarından kaynaklanıp kaynaklanmadığını kontrol edin. G/Ç'yi zaman içinde eşitlemek veya donanım G/Ç aktarım hızını artırmak için Dolaylı denetim noktalarını kullanabilirsiniz.

SQL Server G/Ç gecikmesinin yaygın kök nedenleri

Genel olarak, AŞAĞıDAKI sorunlar SQL Server sorgularının G/Ç gecikmesinden muzdarip olmasının üst düzey nedenleridir:

• Donanım sorunları:

  • SAN yanlış yapılandırması (anahtar, kablolar, HBA, depolama)

  • G/Ç kapasitesi aşıldı (yalnızca arka uç depolamada değil, tüm SAN ağı genelinde dengesizlik var)

  • Sürücüler veya üretici yazılımı sorunları

  Bu aşamada donanım satıcılarıyla ve sistem yöneticileriyle etkileşime geçin.

• Sorgu sorunları: SQL Server disk birimlerini G/Ç istekleriyle doygunluğa çıkarır ve G/Ç alt sistemini kapasitenin ötesine gönderir ve bu da G/Ç aktarım oranlarının yüksek olmasını sağlar. Bu durumda, çok sayıda mantıksal okumaya (veya yazmaya) neden olan sorguları bulun ve disk G/Ç'sini en aza indirmek için bu sorguları ayarlayın. Uygun dizinleri kullanmak bunu yapmak için ilk adımdır. Ayrıca, sorgu iyileştiricisine en iyi planı seçmek için yeterli bilgi sağladığından istatistikleri güncel tutun. Yanlış veritabanı tasarımı ve sorgu tasarımı G/Ç sorunlarında artışa neden olabilir. Bu nedenle sorguların ve bazen tabloların yeniden tasarlanması G/Ç'nin geliştirilmesine yardımcı olabilir.

• Filtre sürücüleri: Dosya sistemi filtre sürücüleri yoğun G/Ç trafiğini işlerse, SQL Server G/Ç yanıtını ciddi şekilde etkileyebilir. G/Ç performansı üzerindeki etkiyi önlemek için, dosyaları virüsten koruma taramasının dışında tutun ve yazılım satıcıları tarafından doğru filtre sürücüsü tasarımından emin olun.

• Diğer uygulamalar: aynı makinede SQL Server olan başka bir uygulama, G/Ç yolunu aşırı okuma veya yazma istekleriyle doyurabilir. Bu durum G/Ç alt sistemini kapasite sınırlarının ötesine itebilir ve SQL Server için G/Ç yavaşlığına neden olabilir. G/Ç yığını üzerindeki etkisini ortadan kaldırmak için uygulamayı belirleyin ve ayarlayın veya başka bir yere taşıyın.

Metodolojinin grafik gösterimi

G/Ç ile ilgili bekleme türleri hakkında bilgi

Aşağıdaki açıklamalar, disk G/Ç sorunları bildirildiğinde SQL Server gördüğünüz yaygın bekleme türlerini kapsar.

PAGEIOLATCH_EX

Bir görev G/Ç isteğindeki bir veri veya dizin sayfası (arabellek) için bir mandal beklerken gerçekleşir. Mandal isteği Özel Kullanım modundadır. Arabellek diske yazılırken Özel Kullanım modu kullanılır. Uzun beklemeler, disk alt sistemiyle ilgili sorunları gösterebilir.

PAGEIOLATCH_SH

Bir görev G/Ç isteğindeki bir veri veya dizin sayfası (arabellek) için bir mandal beklerken gerçekleşir. Mandal isteği Paylaşılan moddadır. Diskten arabellek okunurken Paylaşılan modu kullanılır. Uzun beklemeler, disk alt sistemiyle ilgili sorunları gösterebilir.

PAGEIOLATCH_UP

Bir görev G/Ç isteğindeki arabellek için bir mandal beklerken gerçekleşir. Mandal isteği Güncelleştirme modundadır. Uzun beklemeler, disk alt sistemiyle ilgili sorunları gösterebilir.

WRITELOG

Bir görev, işlem günlüğü temizleme işleminin tamamlanmasını bekliyorsa meydana gelir. Günlük Yöneticisi geçici içeriğini diske yazdığında bir boşaltma gerçekleşir. Günlük boşaltmalarına neden olan yaygın işlemler, işlem işlemeleri ve denetim noktalarıdır.

Uzun bekleme sürelerinin WRITELOG yaygın nedenleri şunlardır:

• İşlem günlüğü diski gecikme süresi: Bu, beklemelerin en yaygın nedenidir. Genellikle, verilerin ve günlük dosyalarının ayrı birimlerde tutulması önerilmektedir. İşlem günlüğü yazma işlemleri sıralı yazma işlemleridir; veri dosyasından veri okuma veya yazma rastgeledir. Bir sürücü biriminde (özellikle geleneksel dönen disk sürücüleri) veri ve günlük dosyalarının karıştırılması aşırı disk kafası hareketlerine neden olur.

• Çok fazla VLF: Çok fazla sanal günlük dosyası (VLF) beklemelere yol açabilir WRITELOG. Çok fazla VLF, uzun süreli bir kurtarma süreci gibi diğer tür sorunlara neden olabilir.

• Çok fazla küçük işlem: Büyük işlemler engellemeye neden olsa da, çok fazla küçük işlem başka bir sorun kümesine yol açabilir. Açıkça bir işlem başlatmazsanız, herhangi bir ekleme, silme veya güncelleştirme işlemine neden olur (biz bu otomatik işlemi çağırırız). Döngüde 1.000 ekleme yaparsanız 1.000 işlem oluşturulur. Bu örnekteki her işlemin işlenmesi gerekir ve bu da işlem günlüğünün boşaltılması ve 1.000 işlem boşaltılmasıyla sonuçlanan bir işlemdir. Mümkün olduğunda, tek tek güncelleme, silme veya ekleme işlemlerini daha büyük bir işlemde birleştirerek işlem günlüğü boşaltmalarını azaltın ve performansı artırın. Bu işlem daha WRITELOG az beklemeye neden olabilir.

• Zamanlama sorunları, Günlük Yazıcı iş parçacıklarının yeterince hızlı zamanlanmamasına neden olur: SQL Server 2016'nın öncesinde, tek bir Günlük Yazıcı iş parçacığı tüm günlük yazma işlemlerini gerçekleştirirdi. İş parçacığı zamanlamasıyla ilgili sorunlar varsa (örneğin, yüksek CPU kullanımı) hem Günlük Yazıcı iş parçacığı hem de günlük boşaltma işlemleri gecikebilir. SQL Server 2016'da, günlük yazma aktarım hızını artırmak için dört adete kadar Günlük Yazıcı iş parçacığı eklendi. Bkz . SQL 2016 - Yalnızca daha hızlı çalışıyor: Birden çok günlük yazıcı çalışanı. SQL Server 2019'da sekiz adede kadar Günlük Yazıcı iş parçacığı eklendi ve bu da aktarım hızını daha da iyileştiriyor. Ayrıca, SQL Server 2019'da her çalışan iş parçacığı, günlük yazma işlemlerini doğrudan yapabilir, günlük yazıcı iş parçacığına göndermek yerine. Bu geliştirmelerle, WRITELOG beklemeler zamanlama sorunlarıyla nadiren tetiklenebilir.

ASYNC_IO_COMPLETION

Aşağıdaki G/Ç etkinliklerinden bazıları olduğunda meydana gelir:

• Toplu Ekleme Sağlayıcısı ("Toplu Ekle") G/Ç gerçekleştirirken bu bekleme türünü kullanır.
• LogShipping'de Geri Alma dosyasını okuma ve Log Shipping için Asenkron G/Ç'yi yönlendirme.
• Veri yedekleme sırasında veri dosyalarından gerçek verileri okuma.

IO_COMPLETION

G/Ç işlemlerinin tamamlanmasını beklerken olur. Bu bekleme türü genellikle veri sayfalarıyla (arabellekler) ilgili olmayan G/Ç'leri içerir. Örnekler şunları içerir:

• Taşma sırasında diskten/diske sıralama/karma sonuçlarını okuma ve yazma (tempdb depolama performansını denetleyin).
• Diske eager spool'ları okuma ve yazma (tempdb depolama alanını kontrol edin).
• İşlem günlüğünden blokların okunması (günlüğün diskten okumasına neden olan herhangi bir işlem sırasında - örneğin, kurtarma).
• Veritabanı henüz ayarlanmamışsa diskten sayfa okuma.
• Sayfaları veritabanı snapshot'ına kopyalama (Copy-on-Write).
• Veritabanı dosyası ve dosya sıkıştırması kapatılıyor.

BACKUPIO

Bir yedekleme görevi, verileri beklediğinde veya verileri depolamak için bir arabellek beklediğinde gerçekleşir. Bu tür, bir görevin bant bağlamayı beklediği durumlar dışında tipik değildir.

İlgili içerik

• SQL Server bekleme türleri (sys.dm_os_wait_stats)
• İşlem Günlüğü (SQL Server)
• tempdb veritabanı
• MSSQLSERVER_833 Database Engine hatası