Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Bir kullanılabilirlik grubunda, otomatik bir devretmeden veya veri kaybı olmadan gerçekleştirilen planlı bir manuel devretmeden sonra, devretme süresinin kurtarma süresi hedefinizi (RTO) aştığını görebilirsiniz. Ya da, Always On Kullanılabilirlik Grupları için performansı izleme bölümündeki yöntemi kullanarak eşzamanlı işleme kullanan bir ikincil replikasının (örneğin otomatik yük devretme ortağının) yük devretme süresini tahmin ettiğinizde, bunun RTO'nuzu aştığını görürsünüz.
Otomatik failover hâlâ tamamlanmadıysa, SQL Server 2012 Always On ortamlarında otomatik failover sorunlarının giderilme bölümüne bakabilirsiniz.
Aşağıdaki bölümler, RTO'yu aşan bir devralma süresinin yaygın nedenlerini açıklar.
İş yükü raporlaması, redo iş parçacığının çalışmasını engeller
İkincil replikadaki redo iş parçacığının veri tanımlama dili (DDL) değişiklikleri yapması, uzun süre çalışan bir salt okunur sorgu tarafından engellenmektedir.
Explanation
İkincil replikada, yalnızca okunan sorgular şema kararlılığı (Sch-S) kilitleri elde eder. Bu Sch-S kilitler, redo iş parçacığının herhangi bir DDL değişikliği yapabilmek için şema değiştirme (Sch-M) kilitlerini edinmesini engelleyebilir. Bloklanmış bir redo iş parçacığı, blokajı kaldırılana kadar log kayıtlarını uygulayamaz. Blokaj kaldırıldığında, günlüğün sonuna kadar ilerlemeyi sürdürebilir ve sonraki geri alma ile failover sürecinin ilerlemesine olanak tanıyabilir.
Tanı ve çözüm
Redo iş parçacığı engellendiğinde, sqlserver.lock_redo_blocked adlı genişletilmiş bir olay oluşturulur. Ayrıca, ikincil replikada DMV sys.dm_exec_request'yi sorgulayarak hangi oturumun REDO iş parçacılığını engellediğini öğrenebilir ve ardından düzeltme işlemi yapabilirsiniz. Aşağıdaki sorgu, redo iş parçacığını engelleyen salt okunur sorgunun oturum kimliğini döndürür.
select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource
from sys.dm_exec_requests where command = 'DB STARTUP'
Raporlama iş yükünün tamamlanmasına izin verebilirsiniz; bu durumda redo iş parçacığının engeli kalkar. Ya da engelleyen oturum kimliği için KILL (Transact-SQL) komutunu çalıştırarak redo iş parçacığının engelini hemen kaldırabilirsiniz.
Yeniden yap konusu, kaynak çatışması nedeniyle geride kalıyor
İkincil replikada büyük bir raporlama iş yükü, ikincil replikanın performansını yavaşlatmış ve yeniden yapma iş akışı geride kaldı.
Explanation
İkincil replikada günlük kayıtları uygulanırken, redo iş parçacığı günlük kayıtlarını günlük diskinden okur ve ardından her bir günlük kaydı için, günlük kaydını uygulamak üzere veri sayfalarına erişir. Sayfa zaten tampon havuzunda değilse, sayfa erişimi G/Ç ile sınırlı olabilir (fiziksel diske erişme). Eğer I/O’ya bağımlı bir raporlama iş yükü varsa, raporlama iş yükü I/O kaynakları açısından redo iş parçacığıyla rekabet eder ve redo iş parçacığını yavaşlatabilir.
Tanı ve çözüm
Aşağıdaki DMV sorgusunu kullanarak, last_received_lsn ile last_redone_lsn arasındaki farkı ölçüp redo iş parçacığının ne kadar geride kaldığını görebilirsiniz.
select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,
last_redone_lsn, last_redone_time
from sys.dm_hadr_database_replica_states
Eğer redo iş parçacığı gerçekten geri kalıyorsa, ikincil replikadaki performans düşüşünün temel nedenini araştırmanız gerekir. Raporlama iş yüküyle bir G/Ç çekişmesi varsa, raporlama iş yükü tarafından kullanılan CPU döngülerini denetlemek ve böylece kullanılan G/Ç döngülerini de bir ölçüde dolaylı olarak denetlemek için Resource Governor kullanabilirsiniz. Örneğin, raporlama iş yükünüz CPU'nun %10'unu tüketiyorsa ancak iş yükü I/O bağımlıysa, Resource Governor'ı kullanarak CPU kaynak kullanımını %5 ile sınırlayarak okuma iş yükünü azaltabilirsiniz, böylece I/O üzerindeki etkiyi en aza indirebilirsiniz.