SQL Server’ı Ne Zaman Yeniden Başlatmalısınız? Öğrenin!

Yazar :  Çağlar Özenç

SQL Server’ı restart etmek her zaman doğru bir çözüm müdür? Teoride, Microsoft SQL Server asla yeniden başlatılmaya ihtiyaç duymaz ve iyi bakım yapılan sağlıklı bir SQL Server sonsuza kadar çalışabilir.

Ancak gerçek dünyada, bazen SQL Server servisini yeniden başlatmak zorunda kalabiliriz. Örneğin, bir Activate kurulumu veya güncellemesi sonrasında SQL Server’ı restart etmeniz istenebilir. Bu gibi durumlarda, öncelikle SQL Server’a olan tüm bağlantıların kapatıldığından emin olmalıyız. Fakat unutmayın, restart işlemi bellek ve plan cache’i tamamen temizler, tempdb’yi yeniden oluşturur ve tüm sorgu planlarının yeniden derlenmesine neden olur.

Dahası, SQL Server’ın durumu, sorunların teşhisi ve performans ayarlamaları için kullanılan Dinamik Yönetim Görünümleri (DMV’ler) tarafından toplanan tüm bilgiler restart sonrası kaybolur. Bu nedenle, SQL Server servisini ne zaman ve neden yeniden başlatmanız gerektiğini bilmek çok önemlidir.

Bu makalede, SQL Server’ı restart etmenin gerekli olduğu durumları, performansa etkilerini ve restart sonrası karşılaşabileceğiniz riskleri ele alacağız. Ayrıca, restart işleminden önce yapmanız gereken kontrolleri ve SQL Server servisini güvenli bir şekilde yeniden başlatma yöntemlerini de detaylı olarak inceleyeceğiz.

SQL Server Neden ve Ne Zaman Restart Edilir?

SQL Server servisini yeniden başlatmak, veri tabanı yöneticilerinin belirli durumlarda başvurduğu önemli bir işlemdir. Ancak her sorun için “restart” düğmesine basmak doğru bir yaklaşım değildir. Bu bölümde, SQL Server’ın neden ve hangi durumlarda yeniden başlatılması gerektiğini inceleyeceğiz.

Gerçek senaryo: Planlı bakım sırasında restart ihtiyacı

İstanbul’daki büyük bir e-ticaret şirketinde, hafta sonu planlı bakım sırasında sistem yöneticisi, sistem veritabanlarının fiziksel konumunu daha hızlı bir depolama birimine taşımak zorunda kaldı. Bu tür bir değişiklik, SQL Server’ın yeniden başlatılmasını gerektiren nadir durumlardan biridir.

Veritabanı yöneticisi, öncelikle tüm kullanıcıların sistemden çıktığından emin oldu. Sistem veritabanlarının (master, msdb, tempdb) fiziksel konumunu değiştirdiğinde, bu değişikliklerin etkili olabilmesi için SQL Server servisini yeniden başlatmak zorunda kaldı. Bu tür planlı bakımlar, genellikle kullanıcı trafiğinin en düşük olduğu zamanlarda gerçekleştirilir.

Planlı bakım sırasında restart gerektiren başka bir senaryo da, SQL Server güncellemelerinin veya güvenlik yamalarının uygulanmasıdır. Güncellemeler yüklendikten sonra, SQL Server’ı yeniden başlatmak, değişikliklerin etkili olmasını ve sistemin en son yapılandırmalarla çalışmaya devam etmesini sağlar.

Yaygın restart nedenleri: Güncellemeler, yapılandırma değişiklikleri

SQL Server’ı yeniden başlatmanın en yaygın nedenleri şunlardır:

• Güvenlik güncellemeleri ve yamalar: Veritabanı sunucuları, güvenlik açıklarını gidermek, hataları düzeltmek ve genel performansı iyileştirmek için düzenli güncellemelere ihtiyaç duyar.
• Yapılandırma değişiklikleri: Bazı yapılandırma değişiklikleri SQL Server’ın yeniden başlatılmasını gerektirir. Bunlar arasında:
  • Veritabanı varsayılan konumlarının değiştirilmesi
  • Anlık dosya başlatma ayarları
  • Sistem veritabanlarının fiziksel konumunun taşınması
  • Kalıcı iz bayrakları (persisted trace flags)
• Donanım değişiklikleri ve bakımı: RAM veya depolama sürücüleri gibi bileşenleri yükseltirken, yeni donanımın algılanması ve sunucu kurulumunda düzgün yapılandırılması için genellikle yeniden başlatma gerekir.
• Kaynak yönetimi: SQL Server, CPU, bellek ve disk alanı gibi önemli miktarda kaynak tüketebilir. Bazı durumlarda, bu kaynakları geri kazanmak ve kaynak tükenmesinden kaynaklanan potansiyel sorunları önlemek için sunucuyu yeniden başlatmak gerekebilir.

Özellikle belirtmek gerekir ki, bazı yapılandırma değişiklikleri için SQL Server’ı yeniden başlatmak gerekmez. Örneğin, veritabanı dosyası eklemek veya kaldırmak için servis yeniden başlatılmasına gerek yoktur.

Restart gerektiren özel durumlar

SQL Server’ı yeniden başlatmanızı gerektirebilecek bazı özel durumlar şunlardır:

Bozuk veritabanları, SQL Server hizmetinin başlatılamamasına neden olabilir. SQL hizmetlerinin başlatılması için gereken üç sistem veritabanı vardır: master veritabanı, model veritabanı ve tempdb. Bu veritabanlarından birinde bozulma sorunu varsa, SQL Server hizmeti başlatılamayabilir.

Master veritabanındaki bozulma sorunu varsa, önerilen çözüm veritabanını bir yedekten geri yüklemektir. Model veritabanındaki bozulma durumunda ise, SQL Server Model Veritabanı Onarımı prosedürü uygulanabilir.

Sorun giderme ve performans ayarlama faaliyetleri sırasında da SQL Server yeniden başlatılabilir. Yavaş performans veya açıklanamayan hatalar gibi belirli sorunlar ortaya çıktığında, sunucuyu yeniden başlatmak genellikle geçici sorunlar için hızlı bir çözüm olabilir.

Bununla birlikte, SQL Server üzerinde yapılacak her işlem için restart gerekmediğini de unutmamak gerekir. Windows’ta SQL Server, hizmeti durdurmanıza gerek kalmadan duraklatılabilir ve devam ettirilebilir. Duraklatma özelliği, kullanıcıların işlemlerini tamamlamasını bekleyip hizmeti durdurmak istediğinizde kullanışlıdır.

Veritabanı Motorunu durdurmak için Transact-SQL ‘SHUTDOWN’ komutunu kullanabilirsiniz. Bu komutu kullanmak için sysadmin veya serveradmin sabit sunucu rollerine üye olmanız gerekir. Ayrıca, çalışan Transact-SQL ifadelerinin ve saklı yordamların bitmesini beklemek için SHUTDOWN; komutunu, veya Veritabanı Motorunu hemen durdurmak için SHUTDOWN WITH NOWAIT; komutunu kullanabilirsiniz.

Sonuç olarak, SQL Server’ı yeniden başlatmak, belirli durumlarda gerekli olan bir işlemdir. Ancak her sorun için hemen restart çözümüne başvurmak yerine, sorunun kaynağını anlamak ve gerçekten restart gerektirip gerektirmediğini değerlendirmek daha doğru bir yaklaşımdır.

Restart Etmenin Performansa Etkisi

SQL Server servisini yeniden başlatmak, performans üzerinde önemli etkilere sahiptir. Çoğu veritabanı yöneticisi performans sorunlarını çözmek için hızlı bir çözüm olarak restart düğmesine basar, ancak bu yaklaşım kısa vadede fayda sağlasa da uzun vadede performansı olumsuz etkileyebilir. Bu bölümde, restart işleminin SQL Server performansına nasıl etki ettiğini detaylı olarak inceleyeceğiz.

Gerçek senaryo: Restart sonrası yavaşlayan sistem

Ankara’daki bir finans şirketinde veritabanı yöneticisi, kullanıcılardan gelen yavaşlık şikayetleri üzerine SQL Server’ı yeniden başlattı. Restart sonrası sistem hızlandı, ancak yarım saat içinde performans tekrar düştü ve kullanıcılar daha önce olmadığı kadar yavaşlık yaşamaya başladı. Yönetici, restart sonrası tüm sorgu planlarının yeniden derlendiğini ve plan önbelleğinin (plan cache) tamamen temizlendiğini fark etti. Bu durum, sistemin tekrar optimize olana kadar yavaşlamasına neden olmuştu.

Gerçekte, SQL Server yeniden başlatıldığında, sorgu planları önbelleğini tamamen kaybeder ve her sorgunun ilk çalıştırılmasında yeni bir plan oluşturması gerekir. Bu, restart sonrası ilk dakikaların beklenenden daha yavaş olmasına yol açar.

Bellek ve plan cache’in sıfırlanması

SQL Server’ı yeniden başlattığınızda aşağıdaki önemli performans etkileri ortaya çıkar:

• Bellek Kullanımı: Restart işlemi, SQL Server’ın kullandığı tüm belleği işletim sistemine geri verir. Yeniden başlatma sonrası, SQL Server belleği Windows işletim sisteminden geri almak zorundadır ve bu süreç zaman alır. Bu dönemde, SQL Server diskten çok sayıda veri okur ve verileri belleğe geri yükler.
• Plan Cache Kaybı: SQL Server’ın Plan Önbelleği, sık çalıştırılan sorguların önceden derlenmiş yürütme planlarını saklar. Bu, sorgu performansını, yürütme planlarının oluşturulması ve tekrar tekrar derlenmesi maliyetini azaltarak iyileştirir. Restart sonrası tüm önbelleğe alınmış sorgu planları kaybolur ve SQL Server bunları yeniden derlemek zorunda kalır.
• Sorgu Performansı: Önbellekteki tüm plan bilgileri kaybolduğundan, restart sonrası her sorgu ilk kez çalıştırılıyormuş gibi davranır ve yeni bir plan oluşturulur. Bu, sorgu süreleri üzerinde önemli bir etki yaratabilir, özellikle karmaşık sorgular için.

Önemli bir nokta şu ki, plan cache’i temizlemek için SQL Server’ı restart etmenize gerek yoktur. Bunun yerine,  DBCC FREEPROCCACHE  komutunu kullanabilirsiniz. Bu komut, plan cache’i temizler ve SQL Server servisini tamamen durdurmadan önbelleği yenilemenizi sağlar.

Ayrıca, restart sonrası oluşturulan sorgu planları her zaman en iyi olanlar olmayabilir. SQL Server, plan oluşturma aşamasında mevcut indeks ve istatistikleri dikkate alır, ancak zaman içinde yapılan ince ayarlar ve “akıllı geri bildirim” teknikleriyle optimize edilen planlar restart sonrası kaybolur.

TempDB’nin yeniden oluşturulması

SQL Server servisini yeniden başlattığınızda, tempdb veritabanı tamamen yeniden oluşturulur. Bu işlem, tempdb performansını doğrudan etkileyen önemli bir faktördür:

• TempDB Boyutu: SQL Server başladığında, tempdb veritabanı model veritabanının bir kopyası kullanılarak yeniden oluşturulur ve tempdb son yapılandırılmış boyutuna sıfırlanır. Yapılandırılmış boyut, ALTER DATABASE komutu veya DBCC SHRINKFILE gibi bir dosya boyutu değiştirme işlemiyle ayarlanan son açık boyuttur.
• Otomatik Büyüme: Varsayılan olarak, tempdb veritabanı gerektiğinde otomatik olarak büyüyecek şekilde yapılandırılmıştır. Bu nedenle, bu veritabanı zamanla beklenenden daha büyük bir boyuta ulaşabilir. İlginç bir nokta, daha büyük tempdb veritabanı boyutlarının SQL Server’ın performansını olumsuz etkilemediğidir.
• İşlem Günlüğü Davranışı: SQL Server, tempdb işlem günlüğünde sadece bir işlemi geri almak için yeterli bilgiyi kaydeder, ancak veritabanı kurtarması sırasında işlemleri yeniden yapmak için bilgi kaydetmez. Bu özellik, tempdb’deki INSERT ifadelerinin performansını artırır. Ayrıca, tempdb her SQL Server yeniden başlatıldığında yeniden oluşturulduğundan, ileriye doğru veya geriye doğru sürdürülecek işlemleri olmaz.

Sonuç olarak, SQL Server’ı restart etmek performans üzerinde çeşitli etkilere sahiptir. Özellikle plan cache’in temizlenmesi ve tempdb’nin yeniden oluşturulması, sistem performansını doğrudan etkiler. Restart gereken durumlarda, bu etkileri göz önünde bulundurarak planlama yapmak ve kullanıcıları bilgilendirmek, olası sorunları en aza indirmenize yardımcı olacaktır. Yeniden başlatma sonrası ilk dakikalarda yavaşlık beklenmeli, sistemin normal performansa dönmesi için zaman tanınmalıdır.

SQL Server Restart Sonrası Karşılaşılan Riskler

SQL Server’ı yeniden başlattığınızda çeşitli risklerle karşılaşabilirsiniz. Hızlı çözüm gibi görünse de, restart işlemi beklenmeyen sonuçlara yol açabilir. Bu bölümde, SQL Server’ı restart etmenin potansiyel riskleri üzerinde duracağız.

Gerçek senaryo: Uzun süren transaction rollback

İzmir’deki bir finans şirketinde, veritabanı yöneticisi 2 TB boyutundaki bir işlem günlüğüne sahip veritabanında sorun yaşadı. Yönetici, sorunu çözmek için SQL Server’ı yeniden başlattı. Ancak, restart sırasında tamamlanmamış işlemlerin geri alınması (rollback) beklenmedik şekilde uzun sürdü. İşlem geri alma süreci ilk iki hafta için günde sadece %2 ilerledi ve sonunda %22’de tamamen durdu. Toplam süreç yaklaşık 60 gün sürdü ve bu süre boyunca veritabanı kullanılamaz durumdaydı.

SQL Server’ı yeniden başlattığınızda, Çöküş Kurtarma (Crash Recovery) süreci başlar. Bu süreçte, SQL Server henüz commit edilmemiş tüm işlemleri geri alır. Geri alma işlemi, işlemin büyüklüğüne bağlı olarak uzun sürebilir ve bu süre zarfında veritabanı tam olarak erişilebilir durumda olmayabilir.

Önemli bir nokta şudur: Tamamlanmamış bir işlemi durdurmak için SQL Server’ı restart etmek çoğunlukla hatalı bir yaklaşımdır. Çünkü restart sonrası, SQL Server zaten kurtarma işlemi tamamlanana kadar veritabanını erişilebilir hale getirmeyecektir. Dahası, işlem günlüğü dolduğunda, SQL Server’ı yeniden başlatmak sorunu çözmek yerine durumu daha da kötüleştirebilir.

Büyük bir veritabanında uzun süren işlemler varsa, bu işlemlerin geri alınması saatler hatta günler sürebilir. Bu nedenle, özellikle üretim ortamında, SQL Server’ı yeniden başlatma kararı verilirken bu risk göz önünde bulundurulmalıdır.

DMV verilerinin kaybı

Dinamik Yönetim Görünümleri (DMV’ler), SQL Server’ın iç yapılarından toplanan değerli performans ve durum bilgilerini sağlar. Ancak, bu görünümler kalıcı veri içermez ve her SQL Server yeniden başlatıldığında sıfırlanır. Örneğin:

• Sorgu istatistikleri (sys.dm_exec_query_stats)
• Sunucu performans metrikleri
• Bağlantı ve oturum bilgileri
• Bellek kullanım istatistikleri
• Disk I/O metrikleri

Bir performans sorunu yaşadığınızda ve sorun giderme amacıyla DMV’leri kullanırken, SQL Server’ı restart etmek bütün tanılama verilerinizi kaybetmenize neden olur. Bu durum, sorunun kaynağını belirlemenizi imkansız hale getirebilir.

En önemli DMV’lerden biri olan sys.dm_exec_query_stats, tüm güncel yürütme planları hakkında ayrıntılı bilgi tutar. Bu görünüm, derleme girişimlerinin sayısı, kullanılan toplam CPU kaynakları, yürütme sayısı gibi verileri kaydeder ve sunucunun CPU kullanımını optimize etmek için mükemmel bir araç olabilir. Restart sonrası bu değerli bilgiler kaybolur.

SQL Server restart sonrası son yeniden başlatma zamanını kontrol etmek için aşağıdaki sorgulardan birini kullanabilirsiniz:

Bu komutlar, SQL Server’ın en son ne zaman yeniden başlatıldığını ve dolayısıyla DMV istatistiklerinin ne zaman sıfırlandığını belirlemenize yardımcı olur.

Kötü execution plan oluşma riski

SQL Server restart edildiğinde, önbellekteki tüm sorgu planları kaybolur ve SQL Server sunucusunun tüm yürütme planlarını yeniden derlemesi gerekir. Bununla birlikte, yeni derlenen planlar her zaman öncekiler kadar verimli olmayabilir.

Bir finansal hizmet şirketinde, SQL Server restart sonrası, daha önce sorunsuz çalışan bir rapor sorgusu, farklı bir yürütme planı üretildiği için 10 kat daha yavaş çalışmaya başladı. Plan kararsızlığı (Plan Instability) nedeniyle, SQL Server yeniden başlatıldıktan sonra farklı ve daha az verimli bir yürütme planı oluşturdu ve bu plan önbelleğe alınarak tekrar tekrar kullanıldı.

Özellikle karmaşık sorgular için, farklı parametre değerleriyle oluşturulan planlar (parametre koklama/parameter sniffing) performans sorunlarına yol açabilir. Restart sonrası, sistem parametrelere dayalı olarak yeni planlar oluşturduğunda, önceden optimize edilmiş planlar yerine daha kötü performans gösteren planlar üretilebilir.

Önemli bir not: Plan önbelleğini temizlemek için SQL Server’ı restart etmeniz gerekmez. Bunun yerine,  DBCC FREEPROCCACHE  komutunu kullanabilirsiniz. Ancak, bu komut da yüksek izin gerektirir ve yoğun sistemlerde istenmeyen bloklamalara neden olabilir.

Ayrıca,  OPTION(RECOMPILE)  ipucunu kullanarak belirli sorguların yeniden derlenmesini sağlayabilirsiniz. Bu yaklaşım, tüm plan önbelleğini temizlemeden, yalnızca sorunlu sorguların planlarını yenilemenize olanak tanır.

Sonuç olarak, SQL Server’ı restart etmek hızlı bir çözüm gibi görünse de, uzun süren işlem geri almaları, değerli DMV verilerinin kaybı ve kötü sorgu planları gibi önemli riskler taşır. Bu riskler, restart kararı verirken dikkate alınmalı ve mümkünse daha az riskli alternatif çözümler değerlendirilmelidir.

SQL Server’ı Ne Zaman Restart Etmemelisiniz?

Her performans sorunu için SQL Server’ı yeniden başlatmak, genellikle gereksiz ve tehlikeli bir çözüm yoludur. Birçok durumda, restart etmeden çözülebilecek sorunlar için SQL Server’ı yeniden başlatmak, zaman kaybına ve ek sorunlara yol açabilir. Bu bölümde, SQL Server’ı ne zaman restart etmemeniz gerektiğini ve alternatif çözümleri inceleyeceğiz.

Gerçek senaryo: Sorun restart ile çözülmeyen bir sistem

Bir e-ticaret şirketinin veritabanı yöneticisi, sistemdeki yavaşlıkları çözmek için SQL Server’ı düzenli olarak yeniden başlatıyordu. Ancak her restart sonrası, sistem birkaç saat iyi çalışıyor, sonra tekrar yavaşlıyordu. Sorunu araştırdığında, asıl problemin plan önbelleğinde biriken çok sayıda ad-hoc SQL sorgusu olduğunu keşfetti. Restart işlemi geçici olarak belleği temizlese de, kök sorunu çözmediği için problem tekrar ortaya çıkıyordu.

Bu tür durumlarda, SQL Server’ı yeniden başlatmak sorunu çözmek yerine sadece semptomları geçici olarak gizler. Plan önbelleği şişmesi gibi sorunlar için restart yerine, parametrelendirme ayarlarını değiştirmek veya sorgu planlarını optimize etmek daha kalıcı çözümler sunar.

Ayrıca, birçok yapılandırma değişikliği için SQL Server’ı yeniden başlatmanız gerekmez. Örneğin, minimum sunucu belleği (min server memory) ve maksimum sunucu belleği (max server memory) gibi seçenekler, Veritabanı Motoru’nda dinamik olarak güncellenir. Bu nedenle, sunucuyu yeniden başlatmadan değiştirebilirsiniz.

Alternatif çözümler: Konfigürasyon değişiklikleri, sorgu optimizasyonu

SQL Server’ı yeniden başlatmak yerine aşağıdaki durumlarda alternatif çözümleri değerlendirebilirsiniz:

• Bellek sorunları için: Bellek ayarlarını düzenlemek genellikle restart gerektirmez. Minimum ve maksimum sunucu belleği, sorgu başına minimum bellek, bellekte indeks oluşturma gibi ayarlar dinamik olarak değiştirilebilir.
• Plan önbelleği temizliği için: Plan önbelleğini temizlemek için SQL Server’ı restart etmenize gerek yoktur. Bunun yerine, DBCC FREEPROCCACHE komutunu kullanabilirsiniz.
• Yapılandırma değişiklikleri için: Birçok yapılandırma seçeneği sp_configure kullanılarak dinamik olarak değiştirilebilir. Değişikliğin dinamik olarak güncellenip güncellenmediğini görmek için sp_configure '<configname>' komutunu çalıştırabilirsiniz. run_value ve config_value sütunlarındaki değerler dinamik olarak güncellenen bir seçenek için eşleşmelidir.

Veritabanı düzeyindeki aşağıdaki ayarlar da restart gerektirmez:

• Sorgu Deposu’nu (Query Store) etkinleştirme veya devre dışı bırakma
• Veritabanı dosyalarını ve dosya gruplarını değiştirme
• Otomatik kapanma veritabanı
• Otomatik küçültme veritabanı
• İstatistikleri otomatik oluşturma ve güncelleme
• Anlık görüntü izolasyonu ve Okuma-taahhütlü anlık görüntü izolasyonu (RCSI)

Özellikle uzun süren veya bitmeyen sorgularla ilgili sorunlarda, SQL Server’ı yeniden başlatmak yerine sorgu optimizasyonu yapabilirsiniz. Tahmini sorgu yürütme planı XML’sini yakalayarak, eksik bir dizin önerisi bulabilir ve uygulayabilirsiniz. Daha iyi bir plan oluşturmak için  HASH JOIN ,  MERGE JOIN ,  FORCE ORDER ,  FORCESEEK  veya  RECOMPILE  gibi sorgu ipuçlarını kullanmayı deneyebilirsiniz.

Sık restart’ın uzun vadeli zararları

SQL Server’ı sık sık yeniden başlatmanın uzun vadede ciddi zararları vardır:

• Artan I/O yükü: Her restart sonrası SQL Server, verileri diskten okuyup belleğe geri yüklemek için çok sayıda fiziksel I/O gerçekleştirir. Bu durum, özellikle büyük veritabanlarında önemli bir yük oluşturur.
• Performans düşüşü: Tüm sorgu planları kaybolduğundan, SQL Server her sorgu için yeni bir yürütme planı oluşturmak zorunda kalır. Bu, restart sonrası performansın düşmesine neden olur.
• Tanılama verilerinin kaybı: DMV’ler (Dinamik Yönetim Görünümleri) tarafından toplanan tüm bilgiler kaybolur, bu da performans sorunlarını teşhis etmeyi zorlaştırır.
• Plan kararsızlığı riski: Restart sonrası, SQL Server farklı ve muhtemelen daha az verimli yürütme planları oluşturabilir. Bu, önceden iyi performans gösteren sorguların restart sonrası yavaşlamasına neden olabilir.
• İşlem geri alma süreçleri: Restart sırasında, tamamlanmamış işlemler geri alınır ve büyük işlemler söz konusu olduğunda bu süreç çok uzun sürebilir.

Bunlara ek olarak, SQL Server’ı sık sık yeniden başlatmak, sunucunun genel kararlılığını ve güvenilirliğini olumsuz etkileyebilir. Paul Randal’ın belirttiği gibi: “SQL Server’ı düzenli olarak yeniden başlatıyorsanız, bunun iyi bir nedeni olduğundan emin olun ve sadece birisi bunun iyi bir şey olduğunu düşündüğü için veya başka bir şekilde çözülmesi gereken bir sorunu çözmenin seçilen yolu olduğu için yapmayın”.

Sonuç olarak, SQL Server performans sorunlarını çözmek için her zaman ilk seçenek olarak restart işlemini düşünmek yerine, sorunu analiz etmek ve alternatif çözümleri değerlendirmek daha doğru bir yaklaşımdır. Birçok durumda, yapılandırma değişiklikleri veya sorgu optimizasyonu gibi yöntemler, SQL Server’ı yeniden başlatmadan sorunları çözebilir ve uzun vadeli sistem kararlılığını sağlayabilir.

SQL Server Restart Etmeden Önce Kontrol Listesi

SQL Server servisini yeniden başlatma kararı aldığınızda, öncesinde mutlaka bir kontrol listesi uygulamalısınız. Doğru hazırlık yapılmadan gerçekleştirilen restart işlemleri, veri kaybına, uzun kesintilere ve hatta sistem bütünlüğünün bozulmasına yol açabilir. Bu bölümde, SQL Server’ı restart etmeden önce neleri kontrol etmeniz gerektiğini ve nasıl hazırlanmanız gerektiğini ele alacağız.

Gerçek senaryo: Kullanıcılar sistemde aktifken yapılan restart

Bursa’daki bir üretim şirketinde, sistem yöneticisi performans sorunlarını çözmek için SQL Server’ı mesai saatleri içinde restart etti. Kullanıcı bağlantılarını kontrol etmeden yapılan bu işlem sonucunda, aktif işlemler yarıda kesildi ve bazı veri tutarsızlıkları oluştu. Finansal raporlama döneminde gerçekleşen bu olay, şirkete önemli zaman ve veri kaybına mal oldu.

Bu tür senaryolardan kaçınmak için, restart işleminden önce mevcut kullanıcı bağlantılarını ve çalışan işlemleri kontrol etmek şarttır. Özellikle mesai saatleri içinde yapılacak restart işlemlerinde, kullanıcıları önceden bilgilendirmek ve çalışmalarını tamamlamalarına fırsat vermek gerekir.

Bağlantıların kapatılması

Restart işleminden önce mevcut kullanıcı bağlantılarını düzgün şekilde kapatmak, veri bütünlüğünü korumak için kritik öneme sahiptir. Bunu yaparken izleyebileceğiniz adımlar:

1. Bağlantı durumunu kontrol edin: Aktif kullanıcıları görmek için sp_who veya sp_who2 komutlarını kullanabilirsiniz.
2. Duraklat fonksiyonunu kullanın: Veritabanı Altyapısı hizmetini durdurmadan önce, “Duraklat” özelliğini kullanabilirsiniz. Bu sayede, mevcut kullanıcılar çalışmalarını tamamlayabilir ancak yeni bağlantılar kurulmaz. Hizmeti durdurmadan önce kullanıcıların işlerini bitirmelerini beklemek istediğinizde bu özellik idealdir.
3. Kullanıcıları bilgilendirin: Planlı bir restart öncesinde, kullanıcılara bildirim göndererek işlemlerini tamamlamalarını ve sistemden çıkmalarını sağlayın.
4. Bloke edilmiş işlemleri kontrol edin: Uzun süren işlemler, restart sırasında geri alınırken gecikmelere neden olabilir. Bu tür işlemleri önceden tespit edip sonlandırmak, restart sürecini hızlandırır.

Unutmayın ki, varsayılan olarak, SQL Server hizmetlerini sadece yerel yönetici grubunun üyeleri başlatabilir, durdurabilir, duraklatabilir, sürdürebilir veya yeniden başlatabilir.

Dış servislerin durdurulması

SQL Server ile etkileşim halinde olan dış servisleri düzgün şekilde durdurmak, restart sürecinin sorunsuz ilerlemesi için önemlidir:

1. Bağımlı uygulamaları belirleyin: SQL Server’a bağlanan ETL süreçleri, raporlama hizmetleri veya arka uç hizmetleri gibi uygulamaları tespit edin.
2. Servisleri kontrol edin: SQL Server Agent, SQL Server Browser gibi ilişkili servisleri durdurun. Bu servisleri SQL Server Configuration Manager üzerinden veya komut isteminde şu komutlarla durdurabilirsiniz.

3. Bağımlılık stratejisi oluşturun: Restart sırasında bu servislerin nasıl yönetileceğine dair bir plan yapın.

Dikkat edilmesi gereken nokta, SQL Server Agent hizmetinin SQL Server’dan farklı olarak duraklatılamadığı veya sürdürülemediğidir. Bu nedenle, SQL Server Agent’ı tamamen durdurmak ve yeniden başlatmak gerekir.

Yedekleme kontrolü

Restart işlemi öncesinde güncel yedeklemeye sahip olmak, olası veri kayıplarına karşı en önemli güvenlik önlemidir:

1. Son yedekleme durumunu kontrol edin: Yedeklemelerin güncel ve eksiksiz olduğundan emin olun. Bu, restart sırasında sorun çıkması durumunda veri kaybını önler.
2. Hızlı yedekleme alın: Mümkünse, restart öncesinde hızlı bir yedekleme yapın. Bu, en güncel verilerin korunmasını sağlar.
3. Kurtarma planınızı gözden geçirin: Restart sonrası bir sorunla karşılaşırsanız nasıl ilerleyeceğinizi önceden planlayın.

Transact-SQL SHUTDOWN komutunu kullanarak Veritabanı Altyapısı’nı durdurmak için sysadmin veya serveradmin sabit sunucu rollerine üye olmanız gerektiğini ve bu yetkinin aktarılamaz olduğunu unutmayın.

Sonuç olarak, SQL Server’ı restart etmeden önce bu kontrol listesini uygulamak, işlemin sorunsuz gerçekleşmesini ve olası risklerin en aza indirilmesini sağlayacaktır. Ayrıca, plan önbelleğini temizlemek için SQL Server’ı restart etmek yerine  DBCC FREEPROCCACHE  komutunu kullanabileceğinizi hatırlatmak isteriz.

SQL Server Servisini Güvenli Şekilde Yeniden Başlatma

Güvenli bir SQL Server restart işlemi, doğru araçlar ve komutlar kullanıldığında oldukça basit bir süreçtir. Yanlış uygulandığında ise veri tutarsızlıklarına ve uzun kesintilere yol açabilir. Restart işlemini güvenle gerçekleştirmek için birkaç farklı yöntem bulunmaktadır.

SQL Server Configuration Manager ile restart

Finans sektöründe çalışan bir veritabanı yöneticisi, planlı bakım sırasında SQL Server’ı güvenli şekilde yeniden başlatmak için her zaman SQL Server Configuration Manager’ı tercih ediyordu. Bu araç, restart işlemini en güvenli şekilde gerçekleştiren resmi Microsoft aracıdır.

SQL Server Configuration Manager’ı açmak için şu adımları izleyebilirsiniz:

1. Başlat menüsünden Tüm Programlar > Microsoft SQL Server > Yapılandırma Araçları > SQL Server Configuration Manager‘ı seçin.
2. Sol bölmede SQL Server Hizmetleri‘ni seçin.
3. Sonuçlar bölmesinde, yeniden başlatmak istediğiniz SQL Server örneğine (varsayılan için SQL Server (MSSQLSERVER) veya adlandırılmış bir örnek) sağ tıklayın.
4. Açılan menüden Yeniden Başlat‘ı seçin.
5. Tamam‘ı seçerek SQL Server Configuration Manager’ı kapatın.

Ayrıca TCP/IP protokolünü etkinleştirdikten sonra değişikliklerin etkili olabilmesi için SQL Server servisini yeniden başlatmanız gerekebilir.

restart sql service komutu kullanımı

Bir e-ticaret şirketinin otomatik bakım süreçlerinde, komut satırı üzerinden SQL Server servisini yeniden başlatma ihtiyacı doğdu. Sistem yöneticisi, bu işlemi komut istemi veya PowerShell kullanarak gerçekleştirmeyi tercih etti.

Komut isteminden SQL Server servisini yeniden başlatmak için:

1. Yönetici haklarıyla komut istemini açın.
2. Varsayılan SQL Server örneğini durdurmak için aşağıdaki komutu yazın:

Ardından başlatmak için:

Adlandırılmış bir örnek için, yukarıdaki komutlarda  MSSQLSERVER  yerine  MSSQL$instancename  şeklinde örnek adını belirtmelisiniz.

PowerShell kullanarak restart işlemi ise şu şekilde yapılabilir:

restart sql server service sonrası kontrol adımları

Ankara’daki bir kamu kurumunda, sistemin durduğu düşünülerek SQL Server restart edildi, ancak bağımlı servislerin kontrolü yapılmadı. Restart sonrası sistemde hatalar oluştu.

Restart işlemi sonrası şunları kontrol etmelisiniz:

1. SQL Server servisinin başarıyla çalıştığını doğrulayın.
2. SQL Server Agent gibi bağımlı servisleri de başlatın:

Son restart zamanını görmek için aşağıdaki sorguyu çalıştırabilirsiniz.

Restart sonrası oluşan plan önbelleği durumunu izleyin.

Unutmayın ki plan önbelleğini temizlemek için SQL Server’ı restart etmenize gerek yoktur. Bunun yerine  DBCC FREEPROCCACHE  komutunu kullanabilirsiniz.