SQL Server AlwaysON “Not Synchronizing / Suspect”

“Not Synchronizing / Suspect” SQL Serer AlwaysOn mimarisinde bulunan sunucuların veri tabanlarında bu sorunun meydana gelmesinde birçok neden vardır. Bunlar; Ağ Sorunları: AlwaysOn mimarisinde, ana sunucu ve ikincil sunucular arasında veri senkronizasyonu için gerekli olan ağ bağlantısı sorunları. Disk Sorunları: Veri tabanı dosyalarının tutulduğu disklerde disk doluluğu, disk arızası gibi disk sorunlarının meydana gelebilir. Log Dosyası Sorunları: Veri tabanlarının log dosyalarının bozulması veya dolması durumu. Bekleyen İşlemler: Veri tabanında bekleyen bir işlem (örneğin, büyük bir sorgu veya bir yedekleme işlemi) diğer işlemleri engellemesi durumunda. Veri tabanı Bozulması: Veri tabanı dosyalarında veya yapılarında bozulma meydana gelmesi. Bakım Yetersizliği: Düzenli yedekleme, veri tabanı kurtarma işlemleri vb. gibi veri tabanı yönetimi için gerekli düzenli bakımların yapılmaması. Bu gibi durumlarda, genellikle SQL Server hata günlüklerine bakarak daha spesifik bir sorun tespit edilebilir ve ardından uygun çözüm yolları belirlenebilir. Biz bu makalede disk sorunu ile karşılaşacağımız için disk sorununun tespiti ve çözümü üzerine gideceğiz. Karşılaşabileceğimiz […]

SQL Server AlwaysON “Not Synchronizing / Suspect”

“Not Synchronizing / Suspect” SQL Serer AlwaysOn mimarisinde bulunan sunucuların veri tabanlarında bu sorunun meydana gelmesinde birçok neden vardır. Bunlar;

  • Ağ Sorunları: AlwaysOn mimarisinde, ana sunucu ve ikincil sunucular arasında veri senkronizasyonu için gerekli olan ağ bağlantısı sorunları.
  • Disk Sorunları: Veri tabanı dosyalarının tutulduğu disklerde disk doluluğu, disk arızası gibi disk sorunlarının meydana gelebilir.
  • Log Dosyası Sorunları: Veri tabanlarının log dosyalarının bozulması veya dolması durumu.
  • Bekleyen İşlemler: Veri tabanında bekleyen bir işlem (örneğin, büyük bir sorgu veya bir yedekleme işlemi) diğer işlemleri engellemesi durumunda.
  • Veri tabanı Bozulması: Veri tabanı dosyalarında veya yapılarında bozulma meydana gelmesi.
  • Bakım Yetersizliği: Düzenli yedekleme, veri tabanı kurtarma işlemleri vb. gibi veri tabanı yönetimi için gerekli düzenli bakımların yapılmaması.

Bu gibi durumlarda, genellikle SQL Server hata günlüklerine bakarak daha spesifik bir sorun tespit edilebilir ve ardından uygun çözüm yolları belirlenebilir.

Biz bu makalede disk sorunu ile karşılaşacağımız için disk sorununun tespiti ve çözümü üzerine gideceğiz.

Karşılaşabileceğimiz bazı disk arızaları arasında Disk dolulukları, Disk bozulmaları, Disk yavaşlamaları bulunur. Bu gibi sorunların çözümünde aşağıdaki birkaç çözüm yöntemi uygulanabilir.

  1. Performans İzleme ve Analiz:  Anormal disk kullanımı veya gecikmelerini belirleyerek bunların nedenlerini analiz edebiliriz.
  2. Düzgün Kapasite Yönetimi: Disk doluluklarını düzenli olarak izleyerek gerektiğinde disk alanını artırabiliriz.
  3. Yedekleme ve Kurtarma Stratejisi: Düzenli yedekleme işlemleriyle veri kaybını önleyebiliriz.
  4. Disk Yapılandırması ve Optimizasyonu: Veri tabanı ve log dosyalarını farklı disk sürücülerine veya disk gruplarına dağıtarak disk performansını optimize edebiliriz.
  5. Otomasyon ve Uyarılar: SQL Server tarafından sağlanan veya üçüncü taraf araçlarla yapılandırılabilen otomasyon ve uyarılar kullanarak disk sorunlarını tespit ederek hızlı bir şekilde müdahalede bulunabiliriz.

Bu genel bilgilerden sonra bizim yaşadığımız soruna ve çözümüne geçebiliriz.

AlwaysOn mimarisi içerisinde bulunan secondary sunucu içerisinde “U” isimli veritabanına baktığımızda “Not Synchronizing / Suspect” moda geçtiğini görüyoruz.

 

Öncelikle veri tabanının ayağa kaldırmak için “Resume Data Movement” seçeneğine tıklıyoruz ve veri tabanı “Not Synchronizing / In Recovery” moda geçiyor.

 

Ancak veri tabanı ayağa kalkmıyor ve tekrardan “Not Synchronizing / Suspect” moda geçiyor.

Yukarıda belirttiğim üzere SQL Server hata günlüklerine bakarak sorunu tespit ederek uygun çözüm yolları belirlemeliyiz.

 

SQL Server Logs kısmından hata loglarına bakıyoruz. İşte veri tabanının neden “Not Synchronizing / Suspect” moda geçtiğinin nedeni tam da burada yazıyor. Disk dolmuş!

Neyse ki primary sunucuda bulunan DATA08 ismindeki disk alanı secondary sunucuda bulunan DATA08 isimli diskten daha fazla olduğu için veri tabanı hizmet vermeye devam etti.

Diskimizin bulunduğu yola bakarak verilen hata logunun doğruluğundan emin oluyoruz.

Gerekli disk artırımlarını yaptırıyoruz ve ardından data dosyasının görünümü aşağıdaki gibi oluyor.

AlwaysOn mimarisinde secondary sunucumuzda “U_AG” de meydana gelen sorunun çözümünün son kısmına geldik artık.

“U_AG” nin üzerinde  “Resume Data Movement” seçeneğine tıklıyoruz ve veri tabanı disk artırımını yaptığımız için veri tabanının büyüklüğüne bağlı olarak bir süre sonra “Synchronizing” moda geçiyor.

Neyse ki primary sunucuda bulunan DATA08 ismindeki disk alanı secondary sunucuda bulunan DATA08 isimli diskten daha fazla olduğu için veri tabanı hizmet vermeye devam etti.

Benzer Yazılar

SQL SERVER RESOURCE GOVERNOR

SQL Server 5 gün önce

Bu makalede Sql Server ’da kaynak kullanımımız için farklı seçenekler ve değerlendirme fırsatları sunan Resource Governor yakından kullanım örneklerini göreceğiz. Günümüzde sistemlerimizin verimli kaynak kullanımı ve buna yönelik olarak çalışmalar oldukça önemli bir durumdadır. Bu kapsamda Veri tabanı sistemlerimizin kurulu olduğu sunucu kaynaklarımızdan maksimum faydayı ve verimi almaya çalışmaktayız. Bu kapsamda SQL Server veri tabanlarımızda kaynak (CPU, bellek, disk ve I/O) kullanımını yönetmek ve optimize etmek için kullanılan güçlü bir araç olan Resource Governor bizlere 2008 ve sonraki sürümlerde sunmaktadır. Bu sayede kritik iş yüklerinizin ihtiyaç duyduğu kaynaklara erişmesini sağlayabilir ve performansınızı optimize ederek veri tabanlarına gelebilecek aşırı yükü önlemiş olabilirsiniz. Biraz çalışma prensibinden bahsedelim, Resource Governor veri tabanı nesne ve sorgularında bir öncelik atayarak çalışır. Bunu şu şekilde örneklendirebiliriz sunucuya gelen uygulama sorguları var bunu servis kullanıcısı ile, raporlama sorguları var bunu raporlama kullanıcısı ile ve ilgili uygulamanın loglarının sorgulamasını yapan log kullanıcısı bulunmaktadır bu yapıda en öncelikli sorgularımız […]

SQL Server Trace Flag(Startup Parameters) Nedir? Ne için kullanılır ? Yaygın olarak kullanılan Trace Flaglar Nelerdir?

SQL Server 1 hafta önce

Bu makalede, SQL Server Trace Flag ne olduğunu, nasıl kullanıldığını ve bazı yaygın senaryolarda nasıl faydalı olabileceğini inceleyeceğiz. Trace Flag Nedir ? SQL Server’ın davranışını değiştiren ve çeşitli senaryolarda performansı artıran veya hata ayıklama sürecini kolaylaştıran özel ayarlar olarak tanımlanabilir. Kullanım amaçları genel anlamda kriz anında ihtiyaçlara göre Trace Flags’ler eklenip problemi çözmeye yönelik işlemler yapılabilir. SQL Server Trace Flag seçerken dikkatli olmak önemlidir. Yanlış bir Trace flag etkinleştirilmesi, beklenmedik davranış değişikliklerine veya performans sorunlarına neden olabilir. Bu nedenle, her Trace Flag etkilerini ve kullanım senaryolarını bilmek önemlidir. Trace Flag etkinleştirildikten sonra sistem üzerindeki etkilerini izlemek ve değerlendirmek de önemlidir. Trace Flag nasıl aktif edebiliriz. Bağzı Trace Flag’ ler Service Restart edildikten sonra devreye girecektir. Aktif etmek için; SQL Server Configuration Manager/ SQL Server Services/ SQL Server (InstanceName)   Instance’a sağ tıklayıp Properties diyoruz ve Startup Parameters kısmına geliyoruz burada 3 tane System tarafından Default olarak gelen Trace Flag’ler bulunmaktadır. […]

Database’yi AG eklerken Status “Password Required”

SQL Server 2 hafta önce

Bir veri tabanını Always On Availability Group’a eklerken karşılaşmış olduğum “Password Required” durumunda yapabileceğiniz bir kaç adımdan bahsedeceğim. Öncelikle bu durumla şifrelenmiş veri tabanını  Always On Availability Group’a eklerken karşılaşırsınız. Hangi veri tabanlarında şifreleme olduğunu aşağıda script yardımıyla görebilirsiniz. USE MASTER SELECT * FROM sys.symmetric_keys Şimdi gelelim veri tabanımızı Always On Availability Group’a eklemeye Yukarıda gördüğünüz yere veri tabanını uygulamış olduğunuz şifreyi girmeniz daha sonrasında refresh dediğinizde ilerlemenize izin verecektir. Peki şifremizi unuttuysak neler yapabiliriz 🙂 1- Master key’i drop edebiliriz. USE [DENEMEDB] GO DROP MASTER KEY 2- Master key şifresini değiştirebiliriz. ALTER MASTER KEY REGENERATE WITH ENCRYPTION BY PASSWORD=’YENİ_ŞİFRENİZ’ Her adımı denediniz fakat aşağıdaki gibi bir hata alıyorsanız ne yapmanız gerek? Msg 15329, Level 16, State 2, Line 1 The current master key cannot be decrypted. If this is a database master key, you should attempt to open it in the session before performing this operation. The FORCE option […]

0 Yorum

Yorum Yaz

Rastgele