Geri alma durumundaki Kullanılabilirlik Grubu veritabanı sorunlarını giderme

Bu makale, geri alma durumundaki kullanılabilirlik grubu veritabanının sorunlarını gidermenize yardımcı olur.

Geri alma durumu nedir?

İkincil sunucunun birincil sunucuyla eşitlenmiş olarak geri dönebilmesi için zaten uyguladığı değişiklikleri geri alması gerektiğinde geri alma durumu oluşur.

Birincil çoğaltmadaki değişikliklerin ikincil çoğaltmalarla etkin bir şekilde eşitlenmesi için kullanılabilirlik grubu birincil ve ikincil çoğaltmalar normal işlem sırasında bağlı durumda kalır.

Yük devretme sırasında bu bağlı durum kesilir. Yeni birincil çoğaltma çevrimiçi olduktan sonra, birincil çoğaltma ile ikincil çoğaltmalar arasında bağlantı yeniden başlatılır. Bu ilk bağlı durum sırasında, yeni ikincilin birincil ile eşitlenmiş olması için kurtarmayı başlatması gereken ortak bir kurtarma noktası belirlenir.

Yük devretme sırasında büyük bir işlem çalışıyorsa, yeni ikincil veritabanı günlüğü birincil çoğaltma veritabanının önündedir. Anlaşmaya varılan yeni ortak kurtarma noktası, eşitlemenin sürdürülebileceği bir durumda olması için ikincil çoğaltmanın birincil çoğaltmadan sayfalar almasını gerektirir. Geri alma işlemi "Yinelemeyi Geri Alma" olarak da adlandırılır.

Geri döndürme işlemi doğal olarak yavaştır, sık sık gerçekleşir ve genellikle geri alma durumunu tetikleyen küçük işlemler pek fark edilir. Yük devretme büyük bir işlemi kesintiye uğrattığında geri alma durumu genellikle fark edilir ve ikincil çoğaltma veritabanını kurtarılabilir duruma döndürmek için birincilden ikincile birçok sayfa gönderilmesine neden olur.

Kullanılabilirlik grubu veritabanının geri alma durumundaki belirtileri ve etkisi

Veritabanı ikincil çoğaltmada geri döndürülüyor durumundayken, veritabanı eşitlenmez ve bu nedenle birincil çoğaltmadan değişiklik almaz. Birincil çoğaltmadaki veritabanının aniden kaybolması veri kaybına neden olabilir.

Her Zaman Açık pano raporları birincilde Eşitlenmiyor

Bir kullanılabilirlik grubunun yükünü devrettikten sonra, yük devretme başarılı olurken ikincil grubun eşitlenmediğinin bildirildiğini görebilirsiniz. AlwaysOn panosu, birincilde Eşitlenmiyor ve ikincil panoda Geri Döndürülüyor raporlarını bildirir.

Her Zaman Açık pano raporları birincilde Eşitlenmiyor	Always On pano raporları İkincilde geri dönüyor

Always On DMV'leri birincil sunucuda EŞITLENMİP EŞITLENMIYOR

Birincilde aşağıdaki Always On kullanılabilirlik gruplarını (AG) Dinamik Yönetim Görünümleri'ni (DMV) sorguladığınızda, veritabanı EŞITLENMİP EŞITLENMIYOR durumunda olur.

SELECT DISTINCT ar.replica_server_name, drcs.database_name, drs.database_id, drs.synchronization_state_desc, drs.database_state_desc
FROM sys.availability_replicas ar 
JOIN sys.dm_hadr_database_replica_states drs 
ON ar.replica_id=drs.replica_id 
JOIN sys.dm_hadr_database_replica_cluster_states drcs
ON drs.group_database_id=drcs.group_database_id

İkincilde DMV'leri sorguladığınızda, kullanılabilirlik grubu veritabanı GERI DÖNDÜRÜLÜYOR durumundadır.

Salt okunur ve raporlama iş yükleri ikincil veritabanına erişelamıyor

İkincil veritabanı geri dönerken, veritabanına erişilemiyor veya sorgulanamıyor. Bu salt okunur iş yükleri çevrimdışıdır ve kesintiye uğrar. Veritabanının ne kadar süre geri döndürülme durumunda olduğuna bağlı olarak, bu iş yüklerinin iş açısından kritik olduğu durumlarda bu iş yüklerini başka bir ikincil çoğaltmaya veya birincil çoğaltmaya yeniden yönlendirmek gerekebilir.

İkincil çoğaltmaya yönlendirilen raporlama iş yükü gibi salt okunur bir iş yükünüz varsa, bu toplu işlemler 922 iletisiyle başarısız olabilir:

Msg 922, Düzey 14, Durum 1, Satır 2 Veritabanı 'agdb' kurtarılıyor. Kurtarma tamamlanana kadar beklemede.

İkincil çoğaltma veritabanında geri alma durumunda oturum açmaya çalışan bir uygulama bağlanamıyor ve 18456 hatasını yükseltiyor:

2023-01-26 13:01:13.100 Oturum Açma Hatası: 18456, Önem Derecesi: 14, Durum: 38. 2023-01-26 13:01:13.100 Oturum< Açma 'UserName>' kullanıcısı için başarısız oldu. Neden: Açıkça belirtilen 'agdb' veritabanı açılamadı. [İsteMCİ: <yerel makine>]

Başarısız oturum açma işlemleri denetleniyorsa bu hata SQL Server hata günlüğünde de bildirilebilir.

Geri alma durumunda kalan süreyi tahmin etme

Geri alma durumunda kalan süreyi tahmin etmek için aşağıdaki yöntemlerden birini kullanın:

AlwaysOn_health XEvent oturumunu kullanma

AlwaysOn_health genişletilmiş olay tanılama günlüğünde, beş dakikada bir durum ilerleme durumunun geri döndürüldüğünü bildiren hadr_trace_message bir olay bulunur.

SQL Server Management Studio (SSMS) Nesne Gezgini kullanarak ikincil çoğaltmaya bağlanın ve Yönetim, Genişletilmiş Olaylar ve ardından Oturumlar'da detaya gidin. AlwaysOn_health etkinliğine sağ tıklayın ve Canlı Veri İzle'yi seçin. Geri alma işleminin geçerli durumunu bildiren yeni bir sekmeli pencere almanız gerekir. Durum, olay aracılığıyla hadr_trace_message beş dakikada bir bildirilir ve geri döndürme işleminin tamamlanan yüzdesi bildirilir.

Not

Genişletilmiş olay hadr_trace_message , SQL Server 2019 ve sonraki sürümlerdeki en son toplu güncelleştirmelere eklendi. Genişletilmiş olay oturumunda bu genişletilmiş olayı AlwaysOn_health gözlemlemek için en son toplu güncelleştirmeleri çalıştırıyor olmanız gerekir.

İkincil çoğaltmadaki SQL Server hata günlüğü, tamamlanmanın geri döndürülüyor olduğunu tahmin ederken pek yardımcı olmaz. Aşağıdaki görüntüde, geri alma durumundayken 10:08 ile 11:03 arasını gözlemleyebilirsiniz. İkincil, birincil çoğaltmadaki tüm sayfaları aldıktan sonra, geri alma durumunu tetikleyen özgün birincilde çalışan işlemi geri alabiliyor. Kurtarma işlemi 11:03 ile 11:05 saatleri kadar çalışır. Kurtarma tamamlandıktan kısa bir süre sonra, veritabanı birincil çoğaltmayla eşitlemeye başlamalı ve ikincil veritabanı geri alma durumundayken birincilde yapılan tüm değişiklikleri yakalamalıdır.

Performans İzleyicisi kullanarak tamamlanma süresini geri döndürmeyi izleme

Sql Server:Database Replica:Total Log Requiring Undo ve SQL Server:Database Replica:Log Remaining for Undo performans sayaçlarını kullanarak durum ilerleme durumunun geri döndürülme durumunu izleyin ve Örnek için kullanılabilirlik grubu veritabanını seçin. Aşağıdaki ekran görüntüsündeki örnekte, Geri Almayı Gerektiren Toplam Günlük 56,3 mb olarak bildirilmiştir ve Geri Alma için Kalan Günlük yavaş yavaş 0'a düşerek geri alma işleminin ilerleme durumunu bildiriyor.

Beklemekten başka seçenekleriniz nelerdir?

Microsoft, geri alma durumunun tamamlanması için gereken süreyi tahmin etmenizi önerir.

Kullanılabilirlik grubuna ikincil çoğaltma ekleme

Kullanılabilirlik grubunda yalnızca iki çoğaltma varsa, mümkünse, yüksek kullanılabilirlik ve yedeklilik sağlayabilen ve diğer ikincil çoğaltma geri döndürmeyi tamamlarken birincil çoğaltmayla etkin olarak eşitleyebilen başka bir ikincil çoğaltma ekleyin.

Önemli

Veritabanları geri alma durumunda olan bir çoğaltmaya yük devretmeyin. Bu, yedekten geri yükleme gerektiren kullanılamayan bir veritabanına neden olabilir. İkincil çoğaltma örneğini yeniden başlatmayın, bu işlemi hızlandırmaz ve geri alma durumundaki ikincil çoğaltma veritabanının durumunu tehlikeye atabilir.

Başarısız olan salt okunur iş yüklerini giderme

Geri döndürmedeki ikincil çoğaltma veritabanlarına erişilemediğinden, salt okunur iş yükleri başarısız oluyor. Etkilenen ikincil çoğaltma veritabanı geri alma işlemini tamamlayana kadar, trafiği birincil çoğaltmaya veya başka bir ikincil çoğaltmaya yönlendirmek için okuma amacı yönlendirme tablosunu güncelleştirin.

Durumu geri almaktan kaçının - büyük işlemleri izleyin

Planlı yük devretmeler sırasında bu durumu sık sık gözlemliyorsanız, yük devretme öncesinde büyük işlemleri denetleyen bir yordam uygulayın. Aşağıdaki sorgu, sistemdeki açık işlemlerin işlem başlangıç saatini ve geçerli saatini bildirir ve işlemlerin giriş arabelleği sağlar.

SELECT tat.transaction_begin_time, getdate() AS 'current time', es.program_name, es.login_time, es.session_id, tst.open_transaction_count, eib.event_info
FROM sys.dm_tran_active_transactions tat
JOIN sys.dm_tran_session_transactions tst ON tat.transaction_id=tst.transaction_id
JOIN sys.dm_exec_sessions es ON tst.session_id=es.session_id 
CROSS APPLY sys.dm_exec_input_buffer(es.session_id, NULL) eib WHERE es.is_user_process = 1
ORDER BY tat.transaction_begin_time ASC