AlwaysOn Kullanılabilirlik Gruplarının yük devretme sorunlarını giderme

Summary

Bu makale, SQL Server’da Always On kullanılabilirlik grubunuzun neden yük devrettiğini belirlemenize yardımcı olacak sorun giderme adımlarını sunar. Windows küme günlüğündeki sistem durumu olaylarını tanımlama, küme durumu olayları, kira zaman aşımları, sistem durumu denetimi zaman aşımları ve SQL Server sistem durumu sorunları gibi yaygın nedenleri tanılama ve her biri için düzeltmeleri uygulama adımlarını gösterir.

Not

Bu makalede açıklanan el ile yapılan çözümlemeyi otomatikleştirmek için bkz. Kullanılabilirlik grubu sistem durumu olaylarını tanılamak için AGDiag kullanma.

Always On sistem durumu sorunları ve yük devretme iş yüklerini nasıl etkiler?

Always On, birincil çoğaltmayı barındıran Microsoft SQL Server örneğinin, altyapıdaki kümenin ve sistem sağlığının durumunu güvence altına almak için farklı mekanizmalar aracılığıyla kapsamlı sistem durumu izleme gerçekleştirir. Bir Windows kümesi veya Always On sistem durumu sorunu belirlendiğinde üretim iş yükü kısa bir süre kesintiye uğrar.

Bir sağlık durumu tespit edildiğinde, genellikle aşağıdaki olaylar dizisi gerçekleşir. Bu sorun giderici boyunca, sistem durumu olaylarından aşağıdaki olaylara atıfta bulunularak söz edilir:

• Kullanılabilirlik grubu çoğaltmaları ve veritabanları birincil rolden çözüm rolüne geçiş gerçekleştirir.

• Kullanılabilirlik grubu veritabanları çevrimdışına geçirilir ve artık erişilebilir değildir.

• Windows Kümesi, kümelenmiş kullanılabilirlik grubu kaynağını başarısız olarak işaretler.

• Windows Kümesi, kullanılabilirlik grubu rolünü yeniden çevrimiçi duruma getirmeye çalışır (orijinal veya otomatik yük devretme iş ortağı replikasında).

• Always On ve Windows Kümesi sistem durumu izlemesi tarafından iyi durumda olduğu algılanırsa kullanılabilirlik grubu rolü başarıyla çevrimiçi olur.

Başarılı olursa, kullanılabilirlik grubu çoğaltmaları ve veritabanları birincil role geçirilir ve kullanılabilirlik grubu veritabanları çevrimiçi olur ve uygulamanız tarafından erişilebilir.

Uygulamalar kullanılabilirlik grubu veritabanlarına erişemiyor

Sistem bir sistem durumu koşulu algıladığında, kullanılabilirlik grubu çoğaltması ve veritabanları Çözümleme rolüne geçer ve kullanılabilirlik grubu veritabanları çevrimdışı olur. Çoğaltı, birincil rolde çevrimiçi duruma geldikten sonra (orijinal çoğaltı sunucusunda veya yük devretme iş ortağı çoğaltı sunucusunda), çoğaltı ve veritabanları yeniden çevrimiçi duruma geçer. Çoğaltma ve veritabanları çözümlenirken ve çevrimdışıyken, bu kullanılabilirlik grubu veritabanlarına erişmeye çalışan uygulamalar başarısız olur ve "Hata 983" iletisi oluşturur: Unable to access availability database.... SQL Server başarısız oturum açma girişimlerini kaydedecek şekilde yapılandırılmışsa, bu hatayı Microsoft SQL Server hata günlüğüne de kaydeder.

Logon Error: 983, Severity: 14, State: 1.

Logon Unable to access availability database '<databasename>' because the database replica is not in the PRIMARY or SECONDARY role. Connections to an availability database is permitted only when the database replica is in the PRIMARY or SECONDARY role. Try the operation again later.

Kullanılabilirlik grubunun, birincil rolde yeniden çevrimiçi duruma gelmeden önce Çözümleme rolünde olduğu süre genellikle yalnızca birkaç saniye, hatta bir saniyeden kısa sürer.

Always On kullanılabilirlik grubu sistem durumu olaylarını veya yük devretmeyi tanımlama ve tanılama

Always On sağlık eğilimlerini belirleyin

Tek bir Always On sistem sağlığı olayını araştırıyor olabilirsiniz ya da yakın zamanda ortaya çıkan veya hâlen süren, üretimi zaman zaman kesintiye uğratan bir sistem sağlığı sorunları eğilimi söz konusu olabilir. Aşağıdaki sorular, üretim ortamınızda bu sistem durumu sorunlarıyla ilgili olabilecek son değişiklikleri daraltmanıza ve ilişkilendirmenize yardımcı olabilir:

• Always On veya küme durumu olaylarındaki eğilim ne zaman başladı?
• Sistem sağlığı olayları belirli bir günde mi gerçekleşir?
• Sağlık olayları günün belirli bir saatinde gerçekleşiyor mu?
• Sağlık olayları ayın belirli bir günü veya haftası içinde mi gerçekleşir?

Bir eğilim fark ederseniz, sistemdeki zamanlanmış bakımı (sanal bir ortamda ana bilgisayar sistemini), ETL toplu işlerini ve bu sistem sağlığı olaylarıyla ilişkili olabilecek diğer işleri kontrol edin. Sistem bir sanal makineyse, kesintiler sırasında ortaya çıkmış olabilecek değişiklikler için konak sistemini araştırın.

Sistem sağlığıyla ilgili sorunların ortaya çıktığı zamanlarla çakışabilecek yoğun, geçici üretim iş yüklerini göz önünde bulundurun (örneğin, kullanıcıların sisteme ilk kez giriş yaptığı veya öğle yemeğinden döndüğü zamanlarda).

Not

Bu, hafta ve ay boyunca performans verilerini toplama planını göz önünde bulundurmak için iyi bir zamandır. Sistemin en yoğun olduğu zamanları daha iyi anlamak için , Processor Information::% Processor Timeve Memory::Available MBytesgibi MSSQLServer:SQL Statistics::Batch Requests/secWindows performans izleyici sayaçlarını ölçebilirsiniz.

Küme günlüğünü gözden geçirme

Windows Kümesi günlüğü, Always On veya küme durumu olayının türünü ve olaya neden olan algılanan sistem durumu durumunu tanımlamaya yönelik en kapsamlı günlükdür. Küme günlüğünü oluşturmak ve açmak için şu adımları izleyin:

Sağlık olayı sırasında birincil replikayı barındıran küme düğümünde Windows küme günlüğünü oluşturmak üzere Windows PowerShell'i kullanın. Örneğin, SQL Server tabanlı sunucu adı olarak kullanarak sql19agn1 yükseltilmiş bir PowerShell penceresinde aşağıdaki cmdlet'i çalıştırın:

get-clusterlog -Node sql19agn1 -UseLocalTime     

Not

Varsayılan olarak, günlük dosyası %WINDIR%\cluster\reports içinde oluşturulur.

Küme günlüğünde sistem durumu olayını bulun

Always On kullanılabilirlik grubunun sağlığını izlemek için çeşitli sağlık izleme mekanizmaları kullanır. Windows Kümesi sistem durumu olayına ek olarak (Windows Kümesi küme düğümleri arasında bir sistem durumu sorunu algılar), Always On'un dört farklı sistem durumu denetimi türü vardır:

• SQL Server hizmeti çalışmıyor
• SQL Server kira sözleşmesi zaman aşımı
• SQL Server sistem durumu denetiminde zaman aşımı
• SQL Server iç sistem sağlığı sorunu

Küme günlüğünde [hadrag] Resource Alive result 0 dizesini arayarak Always On’a özgü bu durum olaylarından herhangi birini bulabilirsiniz. Küme günlüğü, bu olaylardan herhangi birini algıladığında bu dizeyi kaydeder. Örneğin:

00001334.00002ef4::2019/06/24-18:24:36.153 ERR [RES] SQL Server Availability Group : [hadrag] Resource Alive result 0.

Always On sistem durumu sorunlarının özet raporunu oluşturmak için, küme günlüğündeki tüm sistem durumu olaylarını bulmaya yönelik bir araç kullanabilirsiniz. Bu rapor, kronolojik eğilimleri saptamanıza ve belirli bir Always On sistem sağlığı durumunun tekrarlanıp tekrarlanmadığını belirlemenize yardımcı olabilir. Aşağıdaki ekran görüntüsünde, küme günlüğünde dizeyi içeren tüm satırları bulmak için bir metin düzenleyicisinin (bu örnekte Not Defteri++) nasıl kullanılacağı gösterilmektedir [hadrag] Resource Alive result 0 :

Yük devretmeyi tetikleyen sağlık sorununu belirleyin ve düzeltin

Birincil çoğaltmanın küme günlüğündeki sistem durumu sorunlarını belirlemek için, bunları aşağıdaki bölümlerde açıklanan sorunlarla karşılaştırın. AG yük devretmenin yaygın nedenleri şunlardır:

• Küme sağlık olayı
• SQL Server hizmeti çalışmıyor (bir Always On sistem durumu olayı)
• Kira zaman aşımı (AlwaysOn sistem durumu olayı)
• Sistem durumu denetim zaman aşımı (Always On sistem durumu olayı)
• SQL Server sistem durumu (Always On sistem durumu olayı)

Küme sağlığı olayları

Microsoft Windows Kümesi, kümedeki üye sunucuların durumunu izler. Bir sistem durumu sorunu algılarsa, küme üyesi sunucuyu kümeden kaldırır. Kaldırılan küme üyesi sunucuda barındırılan kullanılabilirlik grubu rolü de dahil olmak üzere küme kaynakları, otomatik yük devretme için yapılandırılmışsa kullanılabilirlik grubu yük devretme ortağı replikasına taşınır.

Belirtiler

İşte küme günlüğündeki bir küme sağlığı olayına ilişkin bir örnek. Bunu bulmak için, Lost quorum veya Cluster service has terminated ifadesini aratın; çünkü kullanılabilirlik grubu rol değişikliği veya yük devretme sırasında bunlardan biri mevcut olabilir.

00000fe4.00001628::2022/12/15-14:26:02.654 WARN [QUORUM] Node 1: Lost quorum (1)
00000fe4.00001628::2022/12/15-14:26:02.654 WARN [QUORUM] Node 1: goingAway: 0, core.IsServiceShutdown: 0
00000fe4.00001628::2022/12/15-14:26:02.654 WARN lost quorum (status = 5925)
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [NETFT] Cluster Service preterminate succeeded.
00000fe4.00001628::2022/12/15-14:26:02.654 WARN lost quorum (status = 5925), executing OnStop
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [DM]: Shutting down, so unloading the cluster database.
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [DM] Shutting down, so unloading the cluster database (waitForLock: false).
000019cc.000019d0::2022/12/15-14:26:02.654 WARN [RHS] Cluster service has terminated. Cluster.Service.Running.Event got signaled.

Windows sistem olay günlüğünde arama yaparak da bu olayı tanımlayabilirsiniz.

Critical SQL19AGN1.CSSSQL 1135 Microsoft-Windows-FailoverClusterin Node Mgr NT AUTHORITY\SYSTEM Cluster node 'SQL19AGN2' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
Critical SQL19AGN1.CSSSQL 1177 Microsoft-Windows-FailoverClusterin Quorum Manager NT AUTHORITY\SYSTEM The Cluster service is shutting down because quorum was lost. This could be due to the loss of network connectivity between some or all nodes in the cluster, or a failover of the witness disk. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapter. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.

Küme durumu olayını tanılama

Windows olay günlüğündeki hatalar (Olaylar 1135 ve 1177) ağ bağlantısının olayın bir nedeni olduğunu gösterir. Bu durum, bir küme sağlığı sorununun algılanmasının en yaygın nedenidir. Aşağıdaki örnekte, diğer küme üyesi sunucuların kullanılabilirlik grubu birincil çoğaltmasını barındıran bu sunucuyla iletişim kuramadığı ve bu sorunun kümeden küme düğümünün kaldırılmasını tetiklediği gösterilmektedir:

00000fe4.00001edc::2022/12/14-22:44:36.870 INFO [NODE] Node 1: New join with n3: stage: 'Attempt Initial Connection' status (10060) reason: 'Failed to connect to remote endpoint <endpoint address>'
00000fe4.00001620::2022/12/15-14:26:02.050 INFO [IM] got event: Remote endpoint <endpoint address> unreachable from <endpoint address>
00000fe4.00001620::2022/12/15-14:26:02.050 WARN [NDP] All routes for route (virtual) local <local address> to remote <remote address> are down
00000fe4.0000179c::2022/12/15-14:26:02.053 WARN [NODE] Node 1: Connection to Node 2 is broken. Reason GracefulClose(1226)' because of 'channel to remote endpoint <endpoint address> is closed'

Düğüme bağlantı hatasının kanıtı için küme günlüğünde arama yapabilirsiniz. Küme günlüğünde Lost quorum öğesini bulduğunuz konumdan başlayarak, Failed to connect to remote endpoint, unreachable ve is broken gibi dizeleri geriye doğru arayın.

Çözüm

Küme durumu izlemenin konak ortamı için uygun olduğundan emin olun. Microsoft Azure'da barındırılan SQL Server Always On kullanılabilirlik grupları hakkında daha fazla bilgi için bkz: Windows Server Yük Devretme Kümesine genel bakış - Azure VM'lerinde SQL Server.

Gerekirse, bir destek olayı açmak için Microsoft Windows Yüksek Kullanılabilirlik desteğine başvurmayı göz önünde bulundurun.

SQL Server hizmeti çalışmıyor: Always On sistem durumu olayı

Always On sistem durumu izleme, kullanılabilirlik grubu birincil çoğaltmasını barındıran SQL Server hizmetinin artık çalışıp çalışmadığını algılayabilir.

Belirtiler

QueryServiceStatusEx bir işlem kimliği 0 döndürdüğü için bir hataya işaret eden 'ag' kullanılabilirlik grubu rolüne ait küme günlüğü raporunun bir örneği aşağıda verilmiştir:

00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] QueryServiceStatusEx returned a process id 0
00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] SQL server service is not alive
00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] Resource Alive result 0.
00001898.0000185c::2023/02/27-13:27:41.121 WARN [RHS] Resource ag IsAlive has indicated failure.

SQL Hizmeti kapatma olaylarını tanılama

Beklenmeyen bir SQL Server kapanması için Windows sistem olay günlüğünü ve SQL Server hata günlüğünü kontrol edin.

SQL Server bir sistem kapatma veya yönetici kapatması tarafından kapatıldıysa, SQL Server hata günlüğünde aşağıdaki girdiyi görürsünüz:

2023-03-10 09:38:46.73 spid9s SQL Server is terminating in response to a 'stop' request from Service Control Manager. This is an informational message only. No user action is required.

Windows sistem olay günlüğü aşağıdaki hata girişini gösterir:

Information 3/10/2023 9:41:06 AM Service Control Manager 7036 None The SQL Server (MSSQLSERVER) service entered the stopped state.

SQL Server beklenmedik bir şekilde kapanırsa Windows sistem olay günlüğü aşağıdaki hata girdisini gösterir:

Error 3/10/2023 8:37:46 AM Service Control Manager 7034 None The SQL Server (MSSQLSERVER) service terminated unexpectedly. It has done this 1 time(s).

İpuçları için SQL Server hata günlüğünün sonunu denetleyin. Hata günlüğü aniden biterse, bu koşul zorunlu kapatmanın oluştuğu anlamına gelir. Örneğin, SQL Server Görev Yöneticisi kullanılarak sonlandırıldıysa, SQL Server hata raporu işlemin kapanmasına neden olmuş olabilecek iç sorunlar hakkında herhangi bir bilgi göstermez.

Çözüm

SQL Server hizmetinin beklenmeyen sonlandırmalarını en aza indirmek için yetkili veritabanı ve sistem yöneticilerinin sisteme erişimi olduğundan emin olun. Olay günlüklerini inceledikten sonra, bir hizmetin neden beklenmedik şekilde sonlandırılması gerektiğini araştırın.

SQL Server’ın iç sağlığıyla ilgili bir sorun, SQL Server’ın beklenmedik şekilde kapanmasına neden olduysa, SQL hata günlüğünün sonunda olası bir ölümcül özel duruma ilişkin ipuçları bulunabilir (buna bellek dökümü tanılama dosyasının oluşturulması da dahildir). İpuçlarını gözden geçirin ve gerekli eylemi gerçekleştirin. Döküm dosyası bulursanız Microsoft SQL Server desteğine başvurun ve daha fazla araştırma için SQL Server hata günlüğü ve döküm dosyası içeriğini sağlayın.

Kiralama zaman aşımı: Bir Always On sistem durumu olayı

Always On, SQL Server yüklü olduğu bilgisayarın durumunu izlemek için bir "kiralama" mekanizması kullanır. Varsayılan kira zaman aşımı 20 saniyedir.

Belirtiler

Aşağıda küme günlüğünden AlwaysOn kiralama zaman aşımının örnek bir çıktısı verilmişti. Küme günlüğünde kiralama zaman aşımını bulmak için bu dizelerde arama yapabilirsiniz.

00001a0c.00001c5c::2023/01/04-15:36:54.762 ERR [RES] SQL Server Availability Group : [hadrag] Availability Group lease is no longer valid 
00001a0c.00001c5c::2023/01/04-15:36:54.762 ERR [RES] SQL Server Availability Group : [hadrag] Resource Alive result 0. 
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] Lease timeout detected, logging perf counter data collected so far
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:35:57.0, 98.068572, 509227008.000000, 0.000395, 0.000350 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:7.0, 12.314941, 451817472.000000, 0.000278, 0.000266 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:17.0, 17.270742, 416096256.000000, 0.000376, 0.000292 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:27.0, 38.399895, 416301056.000000, 0.000446, 0.000304 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:37.0, 100.000000, 417517568.000000, 0.001292, 0.000666

Kiralama zaman aşımı hakkında daha fazla bilgi için, Always On kullanılabilirlik gruplarında kiralama, küme ve sistem durumu denetimi zaman aşımlarının işleyişi ve yönergeleri içindeki Kiralama Mekanizması bölümüne bakın.

Always On kira zaman aşımı olaylarını tanılama ve düzeltme

İki ana sorun kiralama zaman aşımını tetikleyebilir:

• SQL Server bellek dökümü: SQL Server erişim ihlali, onay veya zamanlayıcı kilitlenmesi gibi bazı iç sistem durumu olayları algıladığında, SQL Server \LOG klasöründe bir tanılama döküm dosyası (.mdmp) oluşturur. Bellek dökümü oluşturma işlemi SQL Server yürütmesini kısa bir süre askıya alır. Bu dönemde, kiralama mekanizması hizmet yanıtı ve tetikleyici eylemi eksikliğini algılayabilir. Daha fazla bilgi için Döküm oluşturmanın etkisi konusuna bkz.

• Sistem genelinde bir performans sorunu: Kiralama zaman aşımı, her zaman SQL Server’ın durumu ile ilgili bir soruna işaret etmez. Bunun yerine, SQL Server tabanlı sunucunun durumunu da etkileyen sistem genelinde bir sistem durumu sorununu gösterebilir.

  • Sistemde yüksek CPU kullanımı (%100'e yakın).
  • Bellek yetersizliği durumları - düşük sanal bellek ve/veya işlemlerden biri sayfalanıyor.
  • WSFC, quorum kaybı nedeniyle çevrimdışı duruma geçiyor.
  • Performansı etkileyen ve kiralama süresinin dolmasına neden olan VM kısıtlaması.

Çözüm

Ayrıntılı sorun giderme adımları için bkz . MSSQLSERVER_19407. En yaygın iki sorun şunlardır:

1. SQL Sunucusu döküm dosyası tanılama

SQL Server, erişim ihlali, doğrulama hatası veya kilitlenmiş zamanlayıcılar gibi dahili bir sağlık sorunu algılayabilir. Bu durumda, program tanılama için SQL Server işleminin SQL Server \LOG klasöründe bir mini döküm dosyası (.mdmp) oluşturur. Mini döküm dosyası diske yazılırken SQL Server işlemi birkaç saniye boyunca dondurulur. Bu süre boyunca, SQL Server işlemi içindeki tüm iş parçacıkları donmuş durumdadır; buna, Always On sistem durumu izleme tarafından izlenen lease iş parçacığı da dahildir. Bu nedenle Always On kiralama zaman aşımı algılayabilir.

**Dump thread - spid = 0, EC = 0x0000000000000000
***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\LOG\SQLDump0001.txt
* *******************************************************************************
*
* BEGIN STACK DUMP:
*   11/02/14 21:21:10 spid 1920
*
* Deadlocked Schedulers
*
* *******************************************************************************
* -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000002BA
Error: 19407, Severity: 16, State: 1.
The lease between availability group 'ag' and the Windows Server Failover Cluster has expired. A connectivity issue occurred between the instance of SQL Server and the Windows Server Failover Cluster. To determine whether the availability group is failing over correctly, check the corresponding availability group resource in the Windows Server Failover Cluster.

Bu sorunu çözmek için, kök nedeni için bellek dökümü dosyası tanılamasını inceleyin. Daha fazla araştırma için SQL Server hata günlüğünü ve döküm dosyası içeriğini sağlamak için Microsoft SQL Server desteğine başvurmayı göz önünde bulundurun.

2. Yüksek CPU kullanımı veya diğer sistem performansı sorunu

Kiralama zaman aşımı, SQL Server dahil olmak üzere tüm sistemi etkileyen bir performans sorununu gösterir. Sistem sorununu tanılamak için Always On sistem durumu tanılama, küme günlüğündeki performans izleyici verilerini raporlar ve kira zaman aşımı olayını içerir. Performans verileri, kira zaman aşımı olayına kadar yaklaşık 50 saniye sürer ve CPU kullanımı, boş bellek ve disk gecikme süresini bildirir.

İşte, küme günlüğünde bir kiralama zaman aşımını gösteren raporlanan performans verilerine ilişkin bir örnek. Bu örnek çıktıda, yüksek genel CPU kullanımı kira zaman aşımıyla ilgili olabilir.

00000f90.000015c0::2020/08/07-14:16:41.378 WARN [RES] SQL Server Availability Group: [hadrag] Lease timeout detected, logging perf counter data collected so far
00000f90.000015c0::2020/08/07-14:16:41.382 WARN [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:20.0, 83.266073, 31700828160.000000, 0.018094, 0.015752
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:30.0, 93.653224, 31697063936.000000, 0.038590, 0.026897
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:40.0, 94.270691, 31696265216.000000, 0.166000, 0.038962
00000f90.000015c0::2020/08/07-14:16:41.434 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:50.0, 90.272016, 31695409152.000000, 0.215141, 0.106084
00000f90.000015c0::2020/08/07-14:16:41.434 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:16:1.0, 99.991336, 31695892480.000000, 0.046983, 0.035440

Performans verileri, lease zaman aşımı sırasında yüksek CPU kullanımı, bellek yetersizliği durumu veya yüksek disk gecikmesi gösteriyorsa, bu belirtileri araştırmak için birincil replika üzerinde tam bir gün boyunca Performans İzleyicisi verilerini toplamaya başlayın. Performans izleyicisi verilerini daha uzun bir süre boyunca yakalayarak, bu kaynaklar için temel ve en yüksek değerleri daha iyi tanımlayabilir ve kiralama zaman aşımı oluştuğunda bu kaynaklardaki değişiklikleri izleyebilirsiniz. Bu verileri toplarken, SQL Server'da bu kaynak sorunlarının ve sistem durumu olaylarının zamanıyla ilişkili belirli zamanlanmış veya geçici iş yükleri olup olmadığını göz önünde bulundurun.

Aşağıdakiler de dahil olmak üzere aynı sistem kaynağı kullanımını bildiren sayaçları da yakalamanız gerekir:

• Processor Information::% Processor Time
• Memory::Available MBytes
• Logical Disk::Avg. Disk sec/Read
• Logical Disk::Avg. Disk sec/Write
• Logical Disk::Avg. Disk Read Queue Length
• Logical Disk::Avg. Disk Write Queue Length
• MSSQLServer:SQL Statistics::Batch Requests/sec

Sağlık denetimi zaman aşımı: Bir Always On sağlık olayı

Always On, SQL Server'ın durumunu ve istemci uygulamalarının bağlanabilmesini izlemek için bir sistem durumu denetimi mekanizması kullanır.

Belirtiler

Bir kullanılabilirlik grubu çoğaltması birincil role geçtiğinde, Always On sistem durumu izleme SQL Server örneğine yerel bir ODBC bağlantısı kurar. Always On bağlı ve izlemedeyken, SQL Server kullanılabilirlik grubunun sistem durumu denetim zaman aşımı için ayarladığınız süre içinde ODBC bağlantısı üzerinden yanıt vermezse (varsayılan değer 30 saniyedir), Always On bir sistem durumu denetim zaman aşımı olayını tetikler. Bu durumda, kullanılabilirlik grubu birincil rolden Çözümleme rolüne geçiş yapar ve bunu yapacak şekilde yapılandırılmışsa yük devretmeyi başlatır.

Sistem durumu denetimi zaman aşımları hakkında daha fazla bilgi için, Always On kullanılabilirlik grupları için kiralama, küme ve sistem durumu denetimi zaman aşımlarının işleyişi ve yönergeleri başlıklı bölümdeki "Sistem durumu denetimi zaman aşımı işlemi" bölümüne bakın.

Küme günlüğünde bildirildiği gibi AlwaysOn sistem durumu denetim zaman aşımı aşağıdadır:

0000211c.00002d70::2021/02/24-02:50:01.890 WARN [RES] SQL Server Availability Group: [hadrag] Failed to retrieve data column. Return code -1
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <AG>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <AG>: [hadrag] Resource Alive result 0.
0000211c.00002594::2021/02/24-02:50:02.453 WARN [RHS] Resource AG IsAlive has indicated failure.
00001278.00002ed8::2021/02/24-02:50:02.453 INFO [RCM] HandleMonitorReply: FAILURENOTIFICATION for 'AG', gen(0) result 1/0.

Always On sistem durumu denetim zaman aşımı olaylarını tanılama ve düzeltme

Aşağıdaki bölüm, karşılaşabileceğiniz ve tespit edilip bildirilen Always On sistem durumu denetimi zaman aşımlarıyla ilişkili olan "breadcrumb" olayları için SQL Server günlüklerini incelemenize yardımcı olur. Burada gözden geçireceğiniz günlükler küme günlüğünü (sistem durumu denetim zaman aşımının onaylandığı yer), system_health genişletilmiş olay günlüklerini ve SQL Server hata günlüklerini (her ikisi de SQL Server \LOG klasöründe bulunur) ve Windows sistem olay günlüğünü içerir. Sistem durumu denetimi zaman aşımının nedeninin kapsamını belirlemenize yardımcı olabilecek ilişkili olayları aramak için bunları ve diğer günlükleri kullanın.

1. Verimsiz zamanlayıcı olaylarını denetleyin

Always On sistem durumu denetim zaman aşımı genellikle SQL Server "verimsiz" olaylardan kaynaklanır. SQL Server bir iş parçacığının zamanlayıcıda verim almadığını algıladığında, verimsiz bir zamanlayıcı olayının oluştuğu bildirilir. Aynı zamanlayıcıda CPU süresi almayan başka görevler görürseniz, bu koşul verimsiz bir zamanlayıcının birincil işaretidir. Bu davranış, bu görevlerin gecikmeli yürütülmesine ve belirli bir CPU zamanlayıcısına atanan iş yüklerinin "açlıktan ölmesine" neden olabilir.

Verimsiz zamanlayıcı olaylarını denetlemek için şu adımları izleyin:

1. system_health SQL Server genişletilmiş olay günlüklerini gözden geçirin ve Her Zaman Açık durum denetimi zaman aşımı olayının etrafında bir tür verimsiz zamanlayıcı olayının bildirilip bildirmediğini belirleyin. Karşılaşabileceğiniz sonuç üretmeyen olaylar şunlardır:

   • scheduler_monitor_non_yielding_ring_buffer_recorded
   • scheduler_monitor_non_yielding_iocp_ring_buffer_recorded
   • scheduler_monitor_stalled_dispatcher_ring_buffer_recorded
   • scheduler_monitor_non_yielding_rm_ring_buffer_recorded

2. Birincil çoğaltmadaki SQL Server sistem durumu genişletilmiş olay günlüklerini şüpheli sistem durumu denetim zaman aşımı süresine kadar açın.

3. SQL Server Management Studio(SSMS) bölümünde Dosya>Aç'a gidin ve Genişletilmiş Olay Dosyalarını Birleştir'i seçin.

4. Ekle düğmesini seçin.

5. Dosya Aç iletişim kutusunda, SQL Server \LOG dizinindeki dosyalara gidin.

6. Control tuşunu basılı tutun ve adları ile system_health_xxx.xelbaşlayan dosyaları seçin.

7. Aç>Tamam seçin.

8. Sonuçları filtreleyin. Ad sütununun altında bir olaya sağ tıklayın ve Bu Değere Göre Filtrele'yi seçin.

   

9. Aşağıdaki ekran görüntüsünde gösterildiği gibi ad sütunundaki değerlerin içerdiği yieldsatırları sıralamak için bir filtre tanımlayın. Bu filtre, system_health günlüklerine kaydedilmiş olabilecek her türlü sonuç vermeyen olayı döndürür.

   

10. Sağlık denetimi zaman aşımı sırasında yanıt vermeyen olaylar olup olmadığını görmek için zaman damgalarını karşılaştırın. Küme günlüğünde belirtildiği üzere sağlık denetimi zaman aşımı aşağıdadır:

    0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost 0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group < SQL19AGN1>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel 0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group < SQL19AGN1: [hadrag] Resource Alive result 0.
    

    Yanıt vermeyen olayların sistem durumu denetimi zaman aşımı sırasında oluştuğunu görebilirsiniz.

    

Verimsiz olaylar algılanırsa, verimsiz olayın nedenini denetleyin. Verimsiz olayları araştırmak için SQL Server destek ekibine başvurmayı göz önünde bulundurun.

2. SQL Server hata günlüğünü denetleyin

Sistem durumu denetim zaman aşımı sırasındaki olayları ilişkilendirmek için SQL Server hata günlüğünü denetleyin. Bu olaylar, sağlık denetimi zaman aşımlarının kök nedenini belirlemeye yönelik sonraki adımlara işaret eden "iz niteliğinde" ipuçları sağlayabilir.

Örneğin, aşağıdaki günlük girdisi küme günlüğünde bir sistem durumu denetiminin zaman aşımına uğradığını gösterir:

0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost 
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <SQL19AGN1>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel 
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <SQL19AGN1>: [hadrag] Resource Alive result 0.

SQL Server hata günlüğünde, sağlık denetimi zaman aşımından sonraki saniyeler içinde SQL Server, ciddi G/Ç gecikmesi algıladığını bildirir:

2021-02-23 20:49:54.64 spid12s SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\agdb_log.ldf] in database id 12. The OS file handle is 0x0000000000001594. The offset of the latest long I/O is: 0x000030435b0000. The duration of the long I/O is: 26728 ms.

Sistem durumu denetimi zaman aşımı olayıyla ilişkili olabilecek olası sistem ipuçları için sistem olay günlüğünü gözden geçirin. Windows sistem olay günlüğünü gözden geçirirken, aynı sistem durumu denetim zaman aşımı için aynı anda bildirilen bir G/Ç sorunu bulabilirsiniz:

02/23/2021,08:50:16 PM,Warning,SQL19AGN1.CSSSQL.local.local,<...>,"Reset to device, \Device\<device ID>, was issued."
02/23/2021,08:50:16 PM,Warning,SQL19AGN1.CSSSQL.local.local,<...>,"The IO operation at logical block address <block address> for Disk 6 (PDO name: \Device\<device ID>) was retried."

SQL Server sistem durumu: bir Always On sistem durumu olayı

Always On, farklı türde SQL Server sistem durumu olaylarını izler. SQL Server, kullanılabilirlik grubunun birincil çoğaltmasını barındırırken, farklı bileşenleri kullanarak SQL Server’ın durumunu raporlayan sp_server_diagnostics yordamını sürekli olarak çalıştırır. Herhangi bir sistem durumu sorunu algılandığında, sp_server_diagnostics söz konusu bileşen için bir hata bildirir ve sonuçları Always On sistem durumu algılama işlemine geri gönderir. Bir hata bildirildiğinde, kullanılabilirlik grubu bunu yapacak şekilde yapılandırılmışsa Kullanılabilirlik Grubu rolü başarısız durumu ve olası yük devretmeyi gösterir.

Belirtiler

sp_server_diagnostics tarafından küme günlüğünde bildirilen bir SQL Server sağlık sorunu örneği aşağıda verilmiştir. SQL Server, sistem bileşenindeki "hata" durumunu Always On sistem durumu izlemesine bildirir ve "contoso-ag" kullanılabilirlik grubu başarısız duruma geçirilir.

Not

SQL Server’daki bir sistem durumu sorunu, sistem durumu denetimi zaman aşımı olayınınkine benzer bir rapor oluşturur. Her iki sistem durumu olayı da Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel değerini bildirir. SQL Server sistem durumu olayının ayırt edici özelliği, SQL Server bileşeninin "uyarı" durumundan "hata" durumuna geçtiğini bildirmesidir.

INFO [RES] SQL Server Availability Group: [hadrag] SQL Server component 'system' health state has been changed from 'warning' to 'error' at 2019-06-20 15:05:52.330
ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, the state of system component is error
ERR [RES] SQL Server Availability Group <contoso-ag>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel
ERR [RES] SQL Server Availability Group <contoso-ag>: [hadrag] Resource Alive result 0.
ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, the state of system component is error
WARN [RHS] Resource contoso-ag IsAlive has indicated failure.
INFO [RCM] HandleMonitorReply: FAILURENOTIFICATION for 'contoso-ag', gen(0) result 1/0.

SQL Server sistem durumu olaylarını tanılama

SQL Server sistem durumu tarafından bildirilen sistem durumu sorunu türü, kök neden analizinin yönünü belirlemelidir.

Varsayılan olarak, bir kullanılabilirlik grubu dağıttığınızda, FAILURE_CONDITION_LEVEL değeri üç olarak ayarlanır. Bu, bazı SQL Server sistem durumu profillerinin izlenmesini etkinleştirir, ancak tüm SQL Server sistem durumu profillerini etkinleştirmez. Varsayılan düzeyde Always On, SQL Server çok fazla döküm dosyası oluşturduğunda, bir yazma erişimi ihlali veya sahipsiz kalmış bir spinlock meydana geldiğinde bir sağlık olayı tetikler. Kullanılabilirlik grubunun dört veya beş düzeyine ayarlanması, izlenen SQL Server sistem durumu sorunlarının türlerini genişletir. SQL Server sağlık Always On monitörleri hakkında daha fazla bilgi için bkz. Bir kullanılabilirlik grubu için esnek bir otomatik yük devretme ilkesi yapılandırma - SQL Server Always On.

Always On’a özgü sistem durumu sorununu belirlemek için şu adımları izleyin:

1. Birincil çoğaltmadaki SQL Server kümesi tanılama genişletilmiş olay günlüklerini, şüpheli SQL Server sistem durumu olayının gerçekleştiği zaman noktasında açın.

2. SSMS'de Dosya>Aç seçeneğine gidin ve ardından Genişletilmiş Olay Dosyalarını Birleştir seçeneğini belirleyin.

3. Ekle'yi seçin.

4. Dosya Aç iletişim kutusunda, SQL Server \LOG dizinindeki dosyalara gidin.

5. Control tuşuna basın, adları <servername>_<instance>_SQLDIAG_xxx.xel ile eşleşen dosyaları seçin ve ardından Aç>Tamam seçeneğini belirleyin.

   

   Aşağıdaki ekran görüntüsünde gösterildiği gibi, SSMS'de genişletilmiş olayları içeren yeni bir sekmeli pencere görürsünüz.

6. Bir SQL Server sistem durumu sorununu araştırmak için, component_health_result değeri state_desc olan error bulun. Aşağıda Always On sistem durumu izlemesine hata bildiren bir sistem bileşeni olayı örneği verilmişti:

   

7. Alt bölmedeki veri sütununa çift tıklayın. Bu eylem, ayrıntılı bileşen verilerini inceleme için yeni bir SSMS pencere bölmesinde açar. Sistem bileşeni verileri şöyle görünür:

   

   totalDumprequests=186 Veri, bu SQL Server’da çok fazla döküm dosyası tanılama olayı oluşturulduğunu gösteriyor. Bu koşul, sistem bileşeninin hata durumunu bildirmesine neden olur. Always On sistem durumu izlemesi bu hata durumunu aldığında bir kullanılabilirlik grubu sistem durumu olayını tetikler. Ayrıca, sistem bileşeni verilerinde sağlanan bilgilerden hiçbir yazma erişimi ihlali veya sahipsiz spinlock tespit edilmediğini de kontrol edebilirsiniz.

Çözüm

Bulduğunuz sorunun türüne bağlı olarak sorunu uygun şekilde ele alın. Kullanılabilirlik grubu için esnek otomatik yük devretme ilkesi yapılandırma - Always On SQL Server makalesinde açıklandığı gibi, farklı sorunlar bu koşula yol açabilir. Örnekler şunları içerir:

• SQL Server hizmeti çalışmıyor.
• Kira zaman aşımı.
• Kullanılabilirlik çoğaltması başarısız durumdadır.
• Sahipsiz kalan spinlock'lar, erişim ihlalleri veya kısa süre içinde çok sayıda bellek dökümü oluşturulması nedeniyle oluşturulan bellek dökümleri.
• SQL Server iç kaynak havuzundaki kalıcı yetersiz bellek koşulu.
• Zamanlayıcı kilitlenmesinin algılanması.
• Çözülemeyen bir kilitlenme algılanması.

Gerekirse, SQL Server’daki bu iç sistem durumu sorunlarının kök nedenini belirleme konusunda daha fazla yardım almak için bir destek talebi açmak üzere SQL Server desteğiyle iletişime geçin.