Aracılığıyla paylaş

Always On kullanılabilirlik grubunda günlük gönderme kuyruğa alma sorunlarını giderme

Bu makalede günlük gönderme kuyruğa alma ile ilgili sorunların çözümleri sağlanır.

Günlük gönderme kuyruğu nedir?

Birincil çoğaltmadaki bir kullanılabilirlik grubu veritabanında (, ve DELETEgibiINSERTUPDATE) yapılan değişiklikler işlem günlüğüne yazılır ve kullanılabilirlik grubu ikincil çoğaltmalarına gönderilir. Günlük Gönderme Kuyruğu, birincil veritabanının ikincil çoğaltmalara gönderilmemiş günlük dosyalarındaki günlük kayıtlarının sayısını tanımlar.

Günlük gönderme kuyruğa alma belirtileri ve etkisi

Günlük gönderme kuyruğu tüm güvenlik açığı olan verileri depolar

Birincil çoğaltma ani bir olağanüstü durumda kaybolursa ve bu değişikliklerin henüz gelmedikleri ikincil çoğaltmaya yük devrederseniz, bu değişiklikler veritabanının yeni birincil çoğaltma kopyasında görünmez. Bu, tam veritabanı ve günlük yedeklemeleri çalıştırıldığında depolanan tüm değişiklikleri dışlar.

Artan günlük gönderme kuyruğu, işlem günlüğü dosyasının büyümesine neden oluyor

Kullanılabilirlik grubunda tanımlanan bir veritabanı için, Microsoft SQL Server'ın henüz ikincil çoğaltmalara teslim edilmemiş işlem günlüğündeki tüm işlemleri birincil çoğaltmada tutması gerekir. Günlük gönderme kuyruğu, birincil çoğaltmada günlüğe kaydedilen ve normal günlük kesme olayları sırasında (örneğin, veritabanı günlük yedeklemesi sırasında) kesilmeyecek olan değişikliklerin miktarını temsil eder. Büyük ve büyüyen günlük gönderme kuyruğu, veritabanı günlük dosyasını barındıran sürücüde boş alan tüketebilir veya yapılandırılan işlem günlüğü dosyası boyutunu aşabilir. Daha fazla bilgi için bkz . İşlem günlüğü büyük olduğunda hata 9002.

Çeşitli tanılama özellikleri rapor kullanılabilirlik grubu günlüğü gönderme kuyruğa alma

SQL Server Management Studio'daki Always On panosu günlük gönderme kuyruğunu raporlar. Kullanılabilirlik grubunun iyi durumda olmadığını bildirebilir.

Günlük gönderme kuyruğa alma denetimi

Günlük gönderme kuyruğu, veritabanı başına bir ölçümdür. Bu değeri, birincil çoğaltmadaki Always On panosunu veya birincil veya ikincil çoğaltmadaki dinamik yönetim görünümlerini (DMV) sys.dm_hadr_database_replica_states kullanarak denetleyebilirsiniz. Performans İzleyicisi sayaçları, ikincil çoğaltmada günlük gönderme kuyruğu olup olmadığını denetlemek için kullanılır.

Sonraki birkaç bölümde kullanılabilirlik grubu veritabanı günlük gönderme kuyruğunuzu etkin bir şekilde izlemek için yöntemler sağlanır.

Sorgu sys.dm_hadr_database_replica_state

sys.dm_hadr_database_replica_states DMV, her kullanılabilirlik grubu veritabanı için bir satır raporlar. Bu rapordaki bir sütundur log_send_queue_size. Bu değer, kilobayt (KB) cinsinden günlük gönderme kuyruğu boyutudur. Günlük gönderme kuyruğu boyutundaki eğilimleri izlemek için aşağıdaki sorgu gibi bir sorgu ayarlayabilirsiniz. Sorgu birincil çoğaltmada çalıştırılır. İkincil çoğaltmanın verilerini raporlamak için koşulunu is_local=0 kullanır; burada ve log_send_rate ilgili olduğundalog_send_queue_size.

WHILE 1=1
BEGIN
  SELECT drcs.database_name, ars.role_desc, drs.log_send_queue_size, drs.log_send_rate,
ars.recovery_health_desc, ars.connected_state_desc, ars.operational_state_desc, ars.synchronization_health_desc, *
  FROM sys.dm_hadr_availability_replica_states ars JOIN sys.dm_hadr_database_replica_cluster_states drcs ON ars.replica_id=drcs.replica_id
  JOIN sys.dm_hadr_database_replica_states drs ON drcs.group_database_id=drs.group_database_id
  WHERE ars.role_desc='SECONDARY' AND drs.is_local=0
  waitfor delay '00:00:30'
END

Çıktı aşağıdaki gibi görünür.

Günlük gönderme kuyruğu boyutundaki herhangi bir eğilimin nasıl izleneceğini gösteren ekran görüntüsü.

Always On panosunda günlük gönderme kuyruğunu gözden geçirin

Günlük gönderme kuyruğunun gözden geçirilmesi için şu adımları izleyin:

  1. SSMS Nesne Gezgini bir kullanılabilirlik grubuna sağ tıklayarak SQL Server Management Studio'da (SSMS) Always On panosunu açın.

  2. Panoyu Göster'i seçin.

    Kullanılabilirlik grubu veritabanları en son listelenir ve veritabanlarında bildirilen bazı veriler vardır. Günlük Gönderme Sırası Boyutu (KB) ve Günlük Gönderme Hızı (KB/sn) varsayılan olarak listelenmese de, sonraki adımda ekran görüntüsünde gösterildiği gibi bunları bu görünüme ekleyebilirsiniz.

  3. Bu sütunları eklemek için kullanılabilirlik grubu veritabanı sütun başlığına sağ tıklayın ve kullanılabilir sütunlar listesinden seçim yapın.

  4. Günlük Gönderme Sırası Boyutu Eklemek için, aşağıdaki ekran görüntüsünde kırmızıyla vurgulanmış olarak gösterilen üst bilgiye sağ tıklayın.

    Günlük gönderme kuyruğu boyutu eklemeyi gösteren ekran görüntüsü.

    Varsayılan olarak Always On panosu bu verileri her 60 saniyede bir otomatik olarak yeniler.

    Always On panosunun her 60 saniyede bir verileri nasıl otomatik olarak yenileyeni gösteren ekran görüntüsü.

Performans İzleyicisi'da Günlük Gönderme Kuyruğu'na göz at

Günlük gönderme kuyruğu her ikincil çoğaltma veritabanına özgüdür. Bu nedenle, kullanılabilirlik grubu veritabanının günlük gönderme sırasını gözden geçirmek için şu adımları izleyin:

  1. İkincil çoğaltmada Performans İzleyicisi açın.

  2. Ekle (sayaç) düğmesini seçin.

  3. Kullanılabilir sayaçlar'ın altında SQLServer:Veritabanı Çoğaltması ve Günlük Gönderme Kuyruğu sayaçlarını seçin.

  4. Örnek liste kutusunda, günlük gönderme kuyruğu için denetlemek istediğiniz kullanılabilirlik grubu veritabanını seçin.

  5. Ekle ve Tamam'ı seçin.

    Günlük gönderme kuyruğa alma işleminin artması aşağıdaki gibi görünebilir.

    Günlük gönderme kuyruğundaki artışı gösteren ekran görüntüsü.

Günlük gönderme kuyruğa alma değerlerini yorumlama

Bu bölümde, günlük gönderme kuyruğu boyutunun değerlerini yorumlama açıklanmaktadır.

Günlük gönderme ne zaman hatalı? Ne kadar günlük gönderme kuyruğa alınmasına izin verilmelidir?

Günlük gönderme kuyruğu 0 değerini bildiriyorsa, bunun o rapor sırasında günlük gönderme kuyruğa alma işleminin gerçekleşmediğini varsayabilirsiniz. Ancak üretim ortamınız meşgul olduğunda günlük gönderme kuyruğunun iyi durumdaki AlwaysOn ortamında bile sıfır dışında bir değeri sık sık raporladığını gözlemlemeniz gerekir. Tipik üretim sırasında, bu değerin 0 ile sıfır olmayan bir değer arasında dalgalanmalar olduğunu gözlemlemeniz gerekir.

Zaman içinde günlük gönderme kuyruğa alma işleminin arttığını gözlemlerseniz, daha fazla araştırma yapmanız gerekir. Bu ek etkinlik bir şeyin değiştiğini gösterir. Günlük gönderme kuyruğunda ani bir büyüme gözlemlerseniz, aşağıdaki ölçümler sorun giderme için yararlıdır:

  • Günlük Gönderme Hızı (KB/sn) (AlwaysOn panosu)
  • sys.dm_hadr_database_replica_states (DMV)
  • Veritabanı Çoğaltması::Yansıtılmış İşlemler/sn (Performans İzleyicisi)

Günlük gönderme hızı ve yansıtılmış işlemler/sn için temel hızları alma

İyi durumdaki AlwaysOn performansı sırasında, meşgul kullanılabilirlik grubu veritabanlarınız için günlük gönderme hızını ve yansıtılmış işlemleri/sn değerlerini izleyin. Genellikle yoğun iş saatlerinde nasıl görünürler? Büyük işlemler sistemde daha yüksek işlem aktarım hızı sağladığında bakım dönemlerinde nasıl görünürler? Nelerin değiştiğini saptamaya yardımcı olmak için günlük gönderme kuyruğu büyümesini gözlemlerken bu değerleri karşılaştırabilirsiniz. İş yükü normalden büyük olabilir. Günlük gönderme hızı normalden düşükse nedenini belirlemek için daha fazla araştırma yapılması gerekebilir.

İş yükü birimleri önemlidir

Büyük iş yükleriniz (örneğin, 1 milyon satıra karşı bir UPDATE deyim, 1 terabaytlık bir tabloda dizin yeniden derlemesi veya milyonlarca satır ekleyen bir ETL toplu işlemi) varsa, hemen veya zaman içinde bazı günlük gönderme kuyruğu büyümesi görmeyi beklemeniz gerekir. Kullanılabilirlik grubu veritabanında birden çok değişiklik yapıldığında bu durum beklenir.

Günlük gönderme kuyruğa alma tanılama

Belirli bir kullanılabilirlik grubu veritabanı için günlük gönderme kuyruğa alma işlemini belirledikten sonra, aşağıdaki bölümlerde açıklandığı gibi sorunun birkaç farklı olası kök nedenini denetlemeniz gerekir.

Önemli

Anlamlı bekleme türü çıkışı için, aşağıdaki koşulları izlerken önceki bölümlerde açıklanan yöntemlerden birini kullanarak günlük gönderme kuyruğunda bir artış olup olmadığını denetleyin.

Sistem çok meşgul

Birincil çoğaltmadaki iş yükünün sistemin CPU'larını aşırı yükleyip yüklemediğini denetleyin. Günlük gönderme kuyruğunda bir artış görürseniz DMV'yi sorgulayın sys.dm_os_schedulers ve için high runnable_tasks_countizleyin. Bu sayı, o sırada çalıştırıldığını bekleyen görevleri gösterir.

SELECT scheduler_address, scheduler_id, cpu_id, status, current_tasks_count, runnable_tasks_count, current_workers_count, active_workers_count
FROM sys.dm_os_schedulers

Aşağıdaki tabloda sonuç örneği verilmiştir. Değerdeki runnable_tasks_count artış, çok sayıda görevin CPU süresini beklediğini gösterir.

scheduler_address scheduler_id cpu_id durum current_tasks_count runnable_tasks_count current_workers_count active_workers_count
0x000002778D 200040 0 0 ÇEVRIMDıŞı GÖRÜNÜR 1 0 2 1
0x000002778D 220040 1 1 ÇEVRİmİÇİ GÖRÜNÜR 108 12 115 107
0x000002778D 240040 2 2 ÇEVRİmİÇİ GÖRÜNÜR 113 2 123 113
0x000002778D 260040 3 3 ÇEVRİmİÇİ GÖRÜNÜR 105 11 116 105
0x000002778D 480040 4 4 ÇEVRİmİÇİ GÖRÜNÜR 108 15 117 108
0x000002778D 4A0040 5 5 ÇEVRİmİÇİ GÖRÜNÜR 100 25 110 99
0x000002778D 4C0040 6 6 ÇEVRİmİÇİ GÖRÜNÜR 105 23 113 105
0x000002778D 4E0040 7 7 GÖRÜNÜR 109 25 116 109
0x000002778D 700040 8 8 ÇEVRİmİÇİ GÖRÜNÜR 98 10 112 98
0x000002778D 720040 9 9 ÇEVRİmİÇİ GÖRÜNÜR 114 1 130 114
0x000002778D 740040 10 10 ÇEVRİmİÇİ GÖRÜNÜR 110 25 120 110
0x000002778D 760040 11 11 ÇEVRİmİÇİ GÖRÜNÜR 83 8 93 83
0x000002778D A00040 12 12 ÇEVRİmİÇİ GÖRÜNÜR 104 4 117 104
0x000002778D A20040 13 13 ÇEVRİmİÇİ GÖRÜNÜR 108 32 118 108
0x000002778D A40040 14 14 ÇEVRİmİÇİ GÖRÜNÜR 102 12 113 102
0x000002778D A60040 15 15 ÇEVRİmİÇİ GÖRÜNÜR 104 16 116 103

Çözüm: Yüksek runnable_task_countalgılarsanız, sistemdeki iş yükünü azaltın veya sistem için kullanılabilir CPU sayısını artırın.

Ağ gecikmesi

Bu durum özellikle ikincil çoğaltma birincil çoğaltmadan fiziksel olarak uzaksa yaygındır. Çok siteli kullanılabilirlik grupları, müşterilerin olağanüstü durum kurtarma ve raporlama için iş verilerinin kopyalarını birden çok siteye dağıtmasına olanak sağlar. Bu, üretim verilerinin uzak konumlardaki kopyalarında neredeyse gerçek zamanlı değişiklikler olmasını sağlar.

İkincil çoğaltma birincil çoğaltmadan uzakta barındırılıyorsa günlük gönderme kuyruğu, ağ gecikme süresinden ve değişiklikleri birincil çoğaltma veritabanında üretilmekte olan uzak ikincil öğeye gönderememekten kaynaklanabilir.

Önemli

SQL Server, değişiklikleri birincil çoğaltmadan ikincil çoğaltmalara eşitlemek için tek bir bağlantı kullanır. Bu nedenle, ikincil çoğaltma uzaksa, kanalın genişliği SQL Server'ın gönderebileceği veri miktarını etkilemez. Bunun yerine, bu miktar kanaldaki ağ gecikme süresine (bağlantı hızı) daha bağlıdır.

Ağ gecikme süresini test edin

  • Akış denetimi ayarlarının ağ gecikmesine katkıda bulunup bulunmadığını denetleyin

    Microsoft SQL Server kullanılabilirlik grupları, tüm kullanılabilirlik çoğaltmalarında ağ kaynaklarının, belleğin ve diğer kaynakların aşırı tüketimini önlemek için akış denetimi geçitlerini kullanır. Bu akış denetimi geçitleri, kullanılabilirlik çoğaltmalarının eşitleme sistem durumunu etkilemez. Ancak, bunlar RPO dahil olmak üzere kullanılabilirlik veritabanlarınızın genel performansını etkileyebilir.

    SQL Server'ın sonraki sürümleri, akış denetiminin girildiği eşikleri değiştirir. Bu, akış denetiminin günlük gönderme kuyruğa alma gibi belirtiler üzerindeki etkisini hafifletmeye yardımcı olabilir. Akış denetimi ve akış denetimi eşiklerindeki değişikliklerin geçmişi hakkında daha fazla bilgi için bkz . Akış denetimi geçitleri.

    Birincil çoğaltmadaki verileri yakalamak için Performans İzleyicisi kullanarak akış denetimini izleyebilirsiniz. Veritabanı akışı denetimini izlemek için SQLServer:Database Replica sayaçlarını ekleyin ve Veritabanı Akış Denetimi Gecikmesi ve Veritabanı Akış Denetimleri/sn sayaçlarını seçin. Örnek iletişim kutusunda, veritabanı akışı denetimini denetlemek istediğiniz kullanılabilirlik grubu veritabanını seçin. Kullanılabilirlik çoğaltması akış denetimini algılamak ve izlemek için SQLServer:Kullanılabilirlik Çoğaltması sayaçlarını ekleyin ve Akış Denetim Zamanı (ms/sn) ve Akış Denetimi/sn sayaçlarını seçin.

  • Windows Yeniden Başlatma tıkanıklığının ağ gecikmesine katkıda bulunup bulunmadığını denetleyin

    Günlük gönderme kuyruğuna neden olan ağ performansı sorunları, Tıkanıklık Windows Yeniden Başlatma TCP ayarı True olarak ayarlanarak tetiklenebilir. Bu, Windows Server 2016'da varsayılan ayardı. Günlük gönderme kuyruğu gözlemlenen kullanılabilirlik grubu çoğaltmalarını barındıran Windows sunucularında Tıkanıklık Penceresi Yeniden Başlatma'nın False olarak ayarlandığından emin olun.

    PS C:\WINDOWS\system32> Get-NetTCPSetting | Select SettingName, CwndRestart

    Windows Yeniden Başlatma tıkanıklığının ağ gecikmesine katkıda bulunulduğunu gösteren ekran görüntüsü.

    TCP Tıkanıklığı Windows Yeniden Başlatma özelliğini False olarak ayarlama hakkında daha fazla bilgi için bkz. Set-NetTCPSetting (NetTCPIP).

    Eşitleme işlemi hakkında bilgi için bkz . Always On kullanılabilirlik grupları için performansı izleme. Bu makalede ayrıca bazı önemli ölçümlerin nasıl hesaplanması gösterilmektedir ve bazı yaygın performans sorun giderme senaryolarına bağlantılar sağlanmaktadır.

  • Gecikme süresi örneği almak için ping kullanma

    node1 (birincil çoğaltma), ping node2 (ikincil çoğaltma) üzerindeki bir komut satırında:

    C:\Users\customer>ping node2
Pinging node2.customer.corp.company.com [<ip address>] with 32 bytes of data:
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=94ms
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=97ms
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=94ms
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=119ms

Ping statistics for 2<ip address>:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 94ms, Maximum = 119ms, Average = 101ms

  • Bağımsız aracı kullanarak birincilden ikincile ağ aktarım hızını test etme

    Tek bir bağlantı kullanarak birincil ve ikincil çoğaltmalar arasındaki ağ aktarım hızını bağımsız olarak algılamak için NTttcp gibi bir araç kullanın. Ağ gecikmesi, günlük gönderme kuyruğa alma işleminin yaygın bir nedenidir. Aşağıdaki adımlarda ağ aktarım hızını ölçmek için NTttcp gibi bağımsız bir aracın nasıl kullanılacağı gösterilmektedir.

    Önemli

    SQL Server, değişiklikleri tek bir bağlantı kullanarak birincil çoğaltmadan ikincil çoğaltmaya gönderir. Aşağıdaki bölümde, aktarım hızını doğru bir şekilde karşılaştırmak için NTttcp'yi tek bir bağlantı (SQL Server ile aynı şekilde) kullanacak şekilde yapılandırıp çalıştıracağız.

    NTttcp'i Github - microsoft/ntttcp adresinden indirebilirsiniz.

    NTttcp'yi çalıştırmak için şu adımları izleyin:

    1. Aracı indirip birincil ve ikincil SQL Server tabanlı sunuculara kopyalayın.

    2. İkincil çoğaltma sunucusunda yükseltilmiş bir komut istemi penceresi açın, dizini NTttcp araç klasörü olarak değiştirin ve aşağıdaki komutu çalıştırın:

      ntttcp.exe -r -m 1,0,<secondaryipaddress>-a 16 -t 60

      Not

      Bu komutta, <secondaryipaddress> ikincil çoğaltma sunucusunun gerçek IP adresi için bir yer tutucudur.

    3. Birincil çoğaltma sunucusunda, yükseltilmiş bir komut istemi penceresi açın, dizini NTttcp araç klasörü olarak değiştirin ve ardından ikincil çoğaltma sunucusunun gerçek IP adresini belirterek aşağıdaki komutu yeniden çalıştırın:

      ntttcp.exe -s -m 1,0,<secondaryipaddress>-a 16 -t 60

      Aşağıdaki ekran görüntüleri, ikincil ve birincil çoğaltmalarda çalışan NTttcp'yi gösterir. Ağ gecikme süresi nedeniyle araç yalnızca 739 KB/sn veri gönderebilir. SQL Server'ın gönderebilmesini bekleyebilirsiniz.

      İkincil Çoğaltmada NTttcp

      İkincil çoğaltmada çalışan NTttcp'yi gösteren ekran görüntüsü.

      Birincil Çoğaltmada NTttcp

      Birincil çoğaltmada çalışan NTttcp'nin gösterildiği ekran görüntüsü.

Performans İzleyicisi sayaçlarını gözden geçirme

NTttcp raporlarını doğrulayın. Birincil çoğaltmada SQL Server'da büyük bir işlem çalıştırılır. Birincil çoğaltmada Performans İzleyicisi başlattıktan sonra Ağ Arabirimi::Gönderilen Bayt/sn sayacını ekleyin. Bu sayaç, birincil çoğaltmanın yaklaşık 777 KB/sn veri gönderebileceğini onaylar. Bu, NTttcp testi tarafından bildirilen 739 KB/sn değerine benzer.

başlangıç Performans İzleyicisi gösteren ekran görüntüsü.

İkincil çoğaltmadaki aynı veritabanı için birincil çoğaltmadaki SQL Server::D atabases::Log Bytes Flushed/sec değerini SQL Server::D atabase Replica::Log Bytes Received/sec ile karşılaştırmak da yararlıdır. Ortalama olarak "agdb" veritabanında oluşturulan yaklaşık 20 MB/sn değişiklik gözlemliyoruz. Ancak, ikincil çoğaltma ortalama olarak yalnızca 5,4 MB değişiklik alıyor. Bu, veritabanı işlem günlüğünde henüz ikincil çoğaltmaya gönderilmemiş bekleyen değişikliklerin birincil çoğaltmasında günlük gönderme kuyruğuna neden olur.

"agdb" veritabanı için Boşaltılan Birincil Çoğaltma Günlük Baytları/sn

Boşaltılan birincil çoğaltma günlüğü baytlarının miktarını gösteren ekran görüntüsü.

Agdb veritabanı için alınan İkincil Çoğaltma Günlük Baytları/sn

Alınan ikincil çoğaltma günlük baytlarının miktarını gösteren ekran görüntüsü.

  • Last updated on