Veritabanı Recovery Pending Durumu ve Düzeltme Seçenekleri

Veritabanı Recovery Pending Durumu Nedir? SQL Server’da veritabanları bazı nedenlere bağlı olarak “Recovery Pending” (Kurtarma Bekleme)  moduna geçebilir. Veritabanın düzgün bir şekilde kapatılmaması, eksik veya bozuk log dosyaları, disk depolama sorunları, sistemde yaşanan anormal şekilde çökmeler veya MS SQL Server’daki hatalar bu duruma sebep olabilir. Recovery durumu, aslında veritabanını tekrar kullanılabilir hale getirmek için bir kurtarma işlemi yürüttüğünü ifade eder ve üç aşamadan oluşur; Analysis (Analiz): Transaction log incelemesi yapılması ve işlemlerin tamamlanma (Commit) durumunun kontrol edilmesi, Redo (Yeniden İşleme): Tamamlanmış (Commit) ancak henüz diske yazılamamış olan işlemlerin yeniden işlenmesi, Undo (Geri Alma): Başlamış (Begin) ancak tamamlanmamış (Commit) işlemlerin  geri alınmasıdır.   Veritabanı Neden Recover Pending Duruma Düşer? SQL Server Restart Süreci SQL Server servisi restart edildiğinde üzerinde bulunan tüm veritabanları tutarlılığın sağlanması için otomatik olarak recovery moduna girer ve redo/undo işlemleri sürecince devam eder. Ani Sistem Kapanışları Elektrik kesintisi, donanım arızası vb. gibi nedenlerle SQL Server beklenmedik şekilde aniden […]

Veritabanı Recovery Pending Durumu ve Düzeltme Seçenekleri

Veritabanı Recovery Pending Durumu Nedir?

SQL Server’da veritabanları bazı nedenlere bağlı olarak “Recovery Pending” (Kurtarma Bekleme)  moduna geçebilir. Veritabanın düzgün bir şekilde kapatılmaması, eksik veya bozuk log dosyaları, disk depolama sorunları, sistemde yaşanan anormal şekilde çökmeler veya MS SQL Server’daki hatalar bu duruma sebep olabilir. Recovery durumu, aslında veritabanını tekrar kullanılabilir hale getirmek için bir kurtarma işlemi yürüttüğünü ifade eder ve üç aşamadan oluşur;

Analysis (Analiz): Transaction log incelemesi yapılması ve işlemlerin tamamlanma (Commit) durumunun kontrol edilmesi,

Redo (Yeniden İşleme): Tamamlanmış (Commit) ancak henüz diske yazılamamış olan işlemlerin yeniden işlenmesi,

Undo (Geri Alma): Başlamış (Begin) ancak tamamlanmamış (Commit) işlemlerin  geri alınmasıdır.

 

Veritabanı Neden Recover Pending Duruma Düşer?

  1. SQL Server Restart Süreci

SQL Server servisi restart edildiğinde üzerinde bulunan tüm veritabanları tutarlılığın sağlanması için otomatik olarak recovery moduna girer ve redo/undo işlemleri sürecince devam eder.

  1. Ani Sistem Kapanışları

Elektrik kesintisi, donanım arızası vb. gibi nedenlerle SQL Server beklenmedik şekilde aniden kapanması durumunda, işlemler yarıda kalabilir. Bu durumda kalan işlemlerin düzeltilmesi esnasında Recovery durumda kalabilir.

  1. Transaction Log Sorunu

Log dosyalarının dolması veya bozulması durumunda işlemlerin başarılı bir şekilde tamamlanıp tamamlanmadığının belirlenmesi esnasında yaşanabilir

  1. Veritabanı Bozulması

SQL Serverin kurulu olduğu ortamda yaşan donanım sorunları, disk hataları veya yanlış yapılandırma gibi nedenlerle veritabanı dosyaları (MDF veya LDF) bozulabilir. Buna bağlı olarak veritabanı recovery durumda kalabilir.

  1. Veritabanı Restore İşlemi

Bir veritabanı yedeği (backup) geri yüklendiğinde (restore işlemi), işlem tamamlanana kadar veritabanı recovery durumunda kalabilir.

  1. Hatalı Veritabanı Durumu

İşlem sırasında anormal bir durumun oluşmasına veya tutarsız bir durumun ortaya çıkması recovery moduna girmesine neden olabilir.

  1. Veritabanı Dosyalarına Erişim Sorunu

Transaction log’un kazara silinmesi veya veritabanı dosyalarına erişimin kesilmesi durumunda recovery durumu yaşanır.

  1. Disk Doluluk Durumu

Veritabanına ait MDF veya LDF dosyalarının bulunduğu disklerde yeterli boş alan kalmaması  ve dosyaların büyüyememesi durumunda recovery duruma geçebilir.

  1. Folder Yetki Eksikliği

SQL Service kullanıcısının  veritabanı dosyalarının bulunduğu dosya dizinine yazma yetkisi bulunmadığı durumlarda da yaşanabilir.

  1. Auto Close Options

Auto Close özelliği; Veritabanı üzerindeki son kullanıcı bağlantısını kapattığında, veritabanının kapatılarak sunucu üzerindeki (veritabanının kullandığı) kaynakların kullanılabilir olmasını sağlamaktadır. Veritabanı kapatıldığında, bir sonraki kullanıcının erişimi daha uzun sürer.

 

Recovery Pending Durumu Nasıl Çözülür?

Recovery durumu, genellikle veritabanı tutarlılığını sağlamak için gerekli bir işlemdir. Ancak sürekli recovery durumunda kalan bir veritabanı, bir altyapı sorunu olduğunu gösterebilir. Bu duruma bağlı olarak öncelikle temel kontroller yapılmalıdır. Sorunun düzelmediği durumlarda müdahale edilir.

Temel kontrol ve müdahale seçenekleri aşağıdaki şekildedir;

  1. Sürecin Tamamlaması

Recovery işlemi genellikle SQL Server tarafından otomatik olarak tamamlanır. Recovery durumu uzun sürmesi log dosyasının büyümesi  veya disk performansına bağlı olarak değişikli gösterir.

  1. Disk Doluluk Durumu

Disk dolmasından kaynaklı durum yaşandığında; disk üzerinden boş alan açıldıktan sonra SQL Servis restartı ile durum toparlanır. 

  1. Yetki Düzenleme

SQL Service kullanıcısının veritabanı filelarının bulunduğu dosyaya yazma yetkisi kontrol edilmelidir.  

  1. Transaction Log’u Temizliği

Transaction log  dosyası dolmuş ve recovery durumu devam ediyorsa, log dosyasını küçültmek veya yeniden boyutlandırmak gerekebilir:

DBCC SHRINKFILE (LogFileName, Size);

BACKUP LOG [DatabaseName] WITH TRUNCATE_ONLY;

Uyarı: TRUNCATE_ONLY işlemi, transaction log içeriğini kaybedebileceğinden buna göre işelem yapılmalıdır. kullanılmalıdır. 

  1. Auto Close Özelliği Düzenleme

Bu özelliğin açık olduğu databaseler  de benzer durum yaşanabileceğinden bu özellik kontrol edilmelidir. Best practicede kapalı kalması uygundur.

  • Management Studio (SSMS) ile

Database > (Sağ Tık) Properties > Options > Automatic > Auto Close False

  • T-SQL ile
--Ayarı aktif etmek için
ALTER DATABASE [DatabaseName] SET AUTO_CLOSE ON WITH NO_WAIT
GO

--Ayarı pasif etmek için
ALTER DATABASE [DatabaseName] SET AUTO_CLOSE OFF WITH NO_WAIT
GO
  1. Veritabanı Onarımı:

Log file’a erişimin sağlanmadığı durumlar veritabanını normale döndürebilmek için yeni bir log file oluşturularak veritabanı ayağa kaldırılabilir. Bu duruma daha önce log da kalmış işlem kayıtlarını kaybetmeyi göze almış olarak devam edilebilir. Dikkat edilmelidir.

1.Yöntem 

Veritabanı loglarını göz ardı ederek bozulma kontrolü yaparak düzeltme

-- Acil durum moduna alınır. Bu mod veritabanını yalnızca okuma/yazma ve sistem yöneticisi kullanıcıları için erişilebilir hale getirir.
ALTER DATABASE [DatabaseName] SET EMERGENCY;
GO

-- Veritabanı üzerinde yapılacak işlemler sırasında yalnızca bir kullanıcının bağlanmasına izin verilir.
ALTER DATABASE [DatabaseName] set single_user
GO

--Veritabanının kontrol edilerek bozuklukların onarılması sağlanır. Veri kaybı riski kabul edilir. Hata mesajlarını gösterir.
DBCC CHECKDB ([DatabaseName], REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS;
GO 

---- Veritabanı üzerinde yapılacak işlemler için çoklu kullanıcı bağlanmasına izin verilir. 
ALTER DATABASE [DatabaseName] set multi_user 
GO

İşlem sonrasında uyarı olarak; mevcut log dosyasına erişemediği için yeni bir log file oluşturulacağı ve veri tutarlılığı kaybedildiği ifade edilir.

2.Yöntem

Yeni bir log file oluşturarak kurtarma

-- Acil durum moduna alınır. Bu mod veritabanını yalnızca okuma/yazma ve sistem yöneticisi kullanıcıları için erişilebilir hale getirir.
ALTER DATABASE [DatabaseName] SET EMERGENCY;

--Log dosyası sorun olduğunda öncelikle veritabanı detach edilir.
EXEC sp_detach_db [DatabaseName]

--MDF dosyasının bulunduğu path belirtilerek tekrar attach edilir. Bu esnada SQL Server yeni bir log dosyası oluşturur.
EXEC sp_attach_single_file_db @DBName = [DatabaseName], @physname =N'E:\MSSQL\DataFileName.mdf'

3.YÖNTEM

MDF dosyasının fiziksel pathini göstererek veri tabanını yeniden oluşturma

USE master;
CREATE DATABASE [DatabaseName]
ON (FILENAME = N'E:\MSSQL\DataFileName.mdf')

FOR ATTACH_FORCE_REBUILD_LOG;
--Or
FOR ATTACH_REBUILD_LOG;

File path erişimlerinde yetki sorunu ile karşılaşabilirsiniz. SSMS’i yönetici modunda açarak işlem yapabilirsini.

Bu işlemde yer alan attach işleminde Force özelliğinin kullanımlarına da dikkat edilmelidir.

FOR ATTACH_REBUILD_LOG:

Log dosyası kaybolmuş, ancak veritabanı düzgün bir şekilde kapatılmış.

Tutarsızlık veya veri kaybı riski olmadan yeni bir log dosyası oluşturabilirsiniz.

FOR ATTACH_FORCE_REBUILD_LOG:

Veritabanı düzgün kapatılmamış veya bozulmuş.

Kurtarma için başka bir seçenek yoksa, bu yöntemi kullanabilirsiniz.

Önemli Not: Bu işlem sonrasında veritabanını kontrol etmek için mutlaka DBCC CHECKDB çalıştırılmalıdır.

 

  1. Yedekten Geri Yükleyin:

Eğer veritabanı onarılamayacak kadar bozulmuşsa, son alınan yedek dosyasını geri yüklenmelidir.

Sonuç

Recovery Pending duruma düşen veritabanı bir süre zarfı içerisinde normale dönmemiş işe data veya log dosyalarının bozulmasına bağlı olarak kayıtlarının kritikliği değerlendirilerek gerekli kurtarma yöntemleri uygulanmaktadır.

Kaynaklar

https://red9.com/blog/how-to-fix-recovery-pending-state-in-sql-server/

Benzer Yazılar

SQL SERVER RIGHT-LEFT PARTITION

SQL Server 5 gün önce

SQL Server’da partitioning, büyük veritabanı tablolarını daha yönetilebilir ve performanslı hale getirmek amacıyla kullanılan bir tekniktir. Bu teknik, tablonun verilerini fiziksel olarak değil, mantıksal olarak parçalara ayırır. Veriler, belirli bir partition function ve partition scheme kullanılarak farklı bölümlere yönlendirilir. Partitioning, özellikle büyük veri kümeleriyle çalışan veri tabanlarında sorgu performansını artırır ve veri yönetimini kolaylaştırır. Partition Function ve Partition Scheme nedir? Partition Function: Verilerin hangi kriterlere göre bölüneceğini belirler. Örneğin, bir tarih aralığına göre verileri ayırmak. Partition Scheme: Verilerin hangi filegroup’larda depolanacağını belirler.   Örnek olarak Range LEFT ve Range RIGHT olmak üzere iki ayrı tabloda partition nasıl yapılır sizlere göstereceğim. İlk olarak Range LEFT olan partition yapısından başlayacağım. Öncelikle Veri tabanıma yeni filegroup ve file ekliyorum Şimdi sıra FUNCTION ve SCHEME oluşturmakta ben tablomu yıllık olarak partition yaptım sizler ihtiyaçlarınız doğrultusunda aylık,günlük vs yapabilirsiniz. LEFT partition dediğimiz olay vermiş olduğunuz tarih aralığına eşit bir veri geldiğinde bu veriyi solundaki partition […]

SQL Server DMV ve DMF – 6

SQL Server 2 hafta önce

Bu yazımızda DMV ve DMF Serimizin 6.sına devam edeceğiz. Bir önceki seride Memory’ye ilişkin DMV ve DMF’leri ele almıştık. Bu yazıda Memory konusunda devam edeceğiz. SQL server’da Memory kavramı en önemli kavramlardan biridir. Özellikle tüm transaction işlemlerinin önce Buffer sonra disk üzerinden devam ettiğini düşünürsek buffer’ın oynadığı kritik rolü daha iyi anlayabiliriz. Bu yazıda Memory’nin durumunu ve monitör edilmesine bakacağız. Özellikle Performans sorunlarında memory konusunda sorun yaşandığı durumda nasıl okumak gerektiği önemli rol oynamaktadır. Hangi database’de, hangi tablo’da sorun yaşandığına ilişkin bilgilere bu paylaşım sonrasında görebileceğiz. SQL Server’ın Memory kullanım durumunu incelediğimde; select physical_memory_in_use_kb/1048576.0 AS ‘physical_memory_in_use (GB)’, locked_page_allocations_kb/1048576.0 AS ‘locked_page_allocations (GB)’, virtual_address_space_committed_kb/1048576.0 AS ‘virtual_address_space_committed (GB)’, available_commit_limit_kb/1048576.0 AS ‘available_commit_limit (GB)’, page_fault_count as ‘page_fault_count’ from  sys.dm_os_process_memory; Görsel – 1   Physical_memory_in_use: Kullanımda olan Fiziksel Memory miktarını gösterir. locked_page_allocations: Memory’de lock’lanmış olan Page’lerin miktarını belirtir. virtual_address_space_contained: SQL Server VAS(Virtual Adress Space) için ayrılan miktarı belirtir. available_commit_limit: SQL Server tarafından kullanılabilecek Memory Miktarını gösterir. […]

File Share Witness Çalışma Mantığı Ekleme ve Kaldırma İşlemleri

SQL Server 4 hafta önce

İçindekilerFile Share Witness Çalışma Mantığı Ekleme ve Kaldırma İşlemleriCluster Mimarisinin ÇalışmasıQuorum Witness Amacı:Oy Hakkı nedir?Örnekler ve Durumlar1 Node Çevrimdışı (Node C Düşüyor) File Share Witness Kaldırma ve yeniden ekleme işlemleriFile Share Witness Kaldırma ve Ekleme İşlemleriFile Share Witness KaldırmaFile Share Witness EklemeFile Share Witness Çalışma Mantığı Ekleme ve Kaldırma İşlemleri Merhaba arkadaşlar Bu yazımızda Windows Failover Cluster (WFC) mimarisinde bulunan File Share Witness hakkında çalışma mantığı ekleme ve kaldırma işlemlerini sizler ile  paylaşacağım. Öncelikle WFC veri tabanı sunucularının(Node) birbiri ile iletişimi sağlayan genel çerçeve denilebilir. SQL Server Always On Hight Availability Mimarisi kullanılan sistemler yedek sunucular ile kesintisiz hizmet vermeyi amaçlar. Bu sunucular birbiri ile eşlenik ve anlık olarak aynı verilere sahip olmayı sağlar (Senkron). Yoğunluklara göre Asenkron olduğu yerlerde vardır. Bu sayede olası bir durum (Elektrik kesintisi, Donanımsal Arıza, Doğal Afetler ) olduğu zamanlarda SQL Server Always On Hight Availability Mimarisinde WFC içerisinde Senkron olan Node ‘muza Failover (Yük Devretme) […]

0 Yorum

Yorum Yaz

Rastgele