SQL SERVER SERViS RESTART HATASI

Bu haftaki yazımızda karşılan bir hata üzerindeki; logları ve çözümünü anlatacağım. Aşağıdaki GÖRSEL-1’de görüldüğü üzere SQL servisini restart ettiğimiz sırada bir hata ile karşılaşıyoruz. Servis running state’e geçemiyor. “The request failed or the service did not respond in a timely fashion. Consult the event log or other applicable error logs for details” şeklinde bir uyarı veriyor. Hatanın çözümüne doğru ilerlerken farklı servis hesaplarıyla veya “Local System” hesabı ile restart etmeye çalıştığınızda servis ilginç bir şekilde ayağa kalkıyor. Ancak Always on sistem çalışıyorsanız farklı servis hesaplarını kullandığınızda always on size haberleşme izni vermiyor. Aynı hesabın şifresi ile ilgili sorunlar olduğu düşünüp hesabın şifresini de değiştirdiğiniz de yine sonuç alamıyorsunuz. Burdan yola çıkıldığında sıkıntı servis hesabında gibi görünüyor olabilir ancak çözüme geçildiğinde regedit üzerinde yapacağımız bir işlem ile sorunu çözüyoruz. Servis hesabının kaydının olduğu regedit kaydını siliyoruz. Regedit üzerindeki servis hesap bilgisi güncellendiğinde sorun çözülmüş olmakta. GÖRSEL-1  Servis restart edildiğinde SQL’in verdiği Error […]

SQL SERVER SERViS RESTART HATASI

Bu haftaki yazımızda karşılan bir hata üzerindeki; logları ve çözümünü anlatacağım. Aşağıdaki GÖRSEL-1’de görüldüğü üzere SQL servisini restart ettiğimiz sırada bir hata ile karşılaşıyoruz. Servis running state’e geçemiyor. “The request failed or the service did not respond in a timely fashion. Consult the event log or other applicable error logs for details” şeklinde bir uyarı veriyor.

Hatanın çözümüne doğru ilerlerken farklı servis hesaplarıyla veya “Local System” hesabı ile restart etmeye çalıştığınızda servis ilginç bir şekilde ayağa kalkıyor. Ancak Always on sistem çalışıyorsanız farklı servis hesaplarını kullandığınızda always on size haberleşme izni vermiyor. Aynı hesabın şifresi ile ilgili sorunlar olduğu düşünüp hesabın şifresini de değiştirdiğiniz de yine sonuç alamıyorsunuz.

Burdan yola çıkıldığında sıkıntı servis hesabında gibi görünüyor olabilir ancak çözüme geçildiğinde regedit üzerinde yapacağımız bir işlem ile sorunu çözüyoruz. Servis hesabının kaydının olduğu regedit kaydını siliyoruz. Regedit üzerindeki servis hesap bilgisi güncellendiğinde sorun çözülmüş olmakta.

GÖRSEL-1 

  • Servis restart edildiğinde SQL’in verdiği Error logları aşağıya yazdım.

2024-01-25 22:18:00.64 spid11s     Error: 17190, Severity: 16, State: 1.

2024-01-25 22:18:00.64 spid11s     Initializing the FallBack certificate failed with error code: 1, state: 20, error number: 0.

2024-01-25 22:18:00.64 spid11s     Unable to initialize SSL encryption because a valid certificate could not be found, and it is not possible to create a self-signed certificate.

2024-01-25 22:18:00.64 spid11s     Error: 17182, Severity: 16, State: 1.

2024-01-25 22:18:00.64 spid11s     TDSSNIClient initialization failed with error 0x80092004, status code 0x80. Reason: Unable to initialize SSL support. Cannot find object or property.

2024-01-25 22:18:00.64 spid11s     Error: 17182, Severity: 16, State: 1.

2024-01-25 22:18:00.64 spid11s     TDSSNIClient initialization failed with error 0x80092004, status code 0x1. Reason: Initialization failed with an infrastructure error. Check for previous errors. Cannot find object or property.

2024-01-25 22:18:00.64 spid11s     Error: 17826, Severity: 18, State: 3.

2024-01-25 22:18:00.64 spid11s     Could not start the network library because of an internal error in the network library. To determine the cause, review the errors immediately preceding this one in the error log.

2024-01-25 22:18:00.64 spid11s     Error: 17120, Severity: 16, State: 1.

2024-01-25 22:18:00.64 spid11s     SQL Server could not spawn FRunCommunicationsManager thread. Check the SQL Server error log and the Windows event logs for information about possible related problems.

Error loglar okunduğunda SSL sertifika ile ilgili bir hata olduğu kanısına varabiliyoruz. Ancak hata aldığımız sistemde SQL servisi sertifika ile çalışmıyordu. SQL Servis hesabının sunucuda gezici profil oluşturduğunu fark ettik.

ÇÖZÜME GEÇECEK OLURSAK;

Çalıştır üzerinden regedit’e giriyoruz ve GÖRSEL-2’deki dizine kadar iniyoruz;

\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList(GÖRSEL-2)

GÖRSEL-2

Burada dikkatinizi uzantısı “.bak” olan dosyalar çekmelidir. Bir veya daha fazla sayıda olabilir. Uzantısı bak olan aynı zamanda bizim servis kullanıcımızın bilgisini içeren dosyayı sileceğiz.

Tabi silmeden önce bir yedeğini almamız gerekiyor. (GÖRSEL-3). Sileceğimiz kullanıcının dosyası üzerine gelip sağ tık->export deyip kolay ulaştığımız yere kopyalıyoruz. Aksi bir durumunda yedeği lazım olursa, yedek dosyası üzerine çift tıklayarak sildiğimiz kullanıcı regedit dosyasının tekrar yüklenmesi sağlayabiliyoruz.

GÖRSEL-3

NOT: GÖRSEL-2’de görünen ProfileList klasörüne de kısaca değinecek olursak. O server da oturum açan tüm kullanıcıları gösteriyor. Biz burada servis kullanıcısına ait olanı siliyoruz. Servis restart’ı yaparken Windows tekrar yüklüyor. Sonucunda hata çözülüyor.

Sonuca gelirsek; ProfileList klasörü içerisinde servis kullanıcı bilgisini içeren dosyayı sağ tık->delete ile siliyoruz. Sonrasında servisi restart ettiğimizde servis ayağa kalkmış oluyor. (GÖRSEL-4)

GÖRSEL-4

Benzer Yazılar

SQL Server ‘da Detach-Attach İşlemleri Nasıl Yapılır?

SQL Server 14 saat önce

SQL Server’ da  Detach – Attach İşlemleri. Merhaba, bu yazımda SQL Serverda veri tabanımızı farklı sunuculara taşımamız gerektiğinde ya da farklı sunuculardaki veri tabanlarını listemize almak istediğimizde nasıl bir yol izlememiz gerektiğini anlatacağım.İçindekilerDETACH İşlemiATTACH İşlemi Öncelikle bir veri tabanını taşımanın birden fazla yolu var. Bunlar: Detach-Attach, Restore, Backup yöntemleridir. Neden Veri Tabanını Taşırız? Sunucularımızda kaynak yetersizliğimiz olabilir. Sürüm yükseltmemiz gerekebilir. Domain değişikliği olabilir. İlk olarak “Uygulama” isimli bir veri tabanı oluşturalım. İşlemlerimizi bu veri tabanı üzerinden yürüteceğiz. CREATE DATABASE Uygulama Sorgumuz ile veri tabanımızın nerede tutulduğunu bulalım. USE Uygulama GO EXEC sp_helpfile DETACH İşlemi Detach İşlemi, ilgili veri tabanımızı listeden çıkarmak yani taşımak istediğimizde Detach bize yardımcı oluyor. Soldaki veri tabanı listemizden Uygulama isimli veri tabanımızın üzerine gelip sağ tık >Tasks >Detach yolunu izleyeceğiz.   Karşımıza gelen panelde Message alanında “Active Connections” yazıyor. Yani bir aktif bağlantı olduğunu söylüyor. Biz de DropConnections alanındaki tiki işaretleyeceğiz ki bu aktif bağlantıyı silsin. […]

SQL’DE İKİ NODE’UN RESOLVING DURUMA DÜŞMESİ VE ÇÖZÜMÜ

SQL Server 3 ay önce

Bu yazımızda failover olma işlemi esnasında karşılaşılan bir durumdan kısaca bahsedeceğim. Kısa bir yazı olacak ama önemli olduğunu düşünüyorum. Bazen failover olmak istediğinizde cluster secondary’e node’a failover olamaz, hem secondary hem de primary node’unuz resolving durumuna geçer. Bu durumla daha çok otomatik failover olma durumlarında karşılaşılır çünkü sistem failover’a aslında hazır değildir ancak cluster bunu bir şekilde bilemez. Failover olma gerçekleşemez bir anlamda sql cluster askıda kalır ve hiçbir sunucu da sql engine çalışmaya devam edemez. (GÖRSEL-1) GÖRSEL-1 GÖRSEL-1 üzerinde gördüğünüz üzere availability group resolving duruma düşer. Availability replica’lar üzerinde de gördüğünüz üzere primary ve secondary tüm node’lar resolving state’e düşer. Böyle bir durumunda iki farklı çözüm yolumuz var;   Çözüm: ikinci node’a sunucu restart’ı atmak. Bu noktada secondary sql node’a servis restart atmak işe yaramıyor. Zaten db’ler iki taraflı resolving modda. O sebeple ancak sunucu restart atıldığında cluster ayakta olan sunucuyu görüyor ve askıda kalma durumundan ilk başta primary […]

Query Store Nedir?

SQL Server 3 ay önce

Query Store ile birlikte execution planın seçimi ve bu sürecin performansa etkisini anlayabiliriz. SQL Server içerisinde bulunan Query Store özelliği, çalıştırılan sorguların execution planını ve bu sırada oluşan istatistiklerini otomatik olarak yakalar. Böylece query plan değişikliği ile oluşan problemleri de hızlı ve kolay şekilde fark edebiliriz. Elinizde bulunan bir sorguya ait query plan zamanla değişebilir. Bunun birçok sebebi vardır. Tablo yapısına yeni bir column eklenmesi Veri tipinin değiştirilmesi Sorgularda yeni parametrelerin eklenip çıkarılması Verilerde, schemalarda veya sorgu parametrelerindeki değişiklik Burada önemli olan ise bazen bu değişimler sorgunun yavaş çalışmasına neden olur. Query Store ile beraber bu yavaşlığın kök nedenine inmek daha kolay oldu. Ayrıca query store sayesinde ilgili sorguya ait read-write bilgileri ve cpu tüketimi bilgilerine de erişebilirsiniz. Query Store’u veritabanı seviyesinde aktif edebiliyoruz. Veritabanı üzerine sağ tıklayarak properties diyoruz ve Query Store sekmesine geliyoruz. Operation Mode alanından Read Write’ı seçiyoruz. Böylelikle Query Store gerekli bilgiyi toplayabilir ve size ilgili sonuçları […]

0 Yorum

Yorum Yaz

Rastgele