Mysql Veritabanı Onarma

Mysql Veritabanı Onarma, SQL Server veritabanı bozulması, özellikle durum aniden ortaya çıkarsa ve yedekleme yoksa, DBA’lar için zahmetlidir. Bu durum, uygun bir veritabanı onarım çözümünün yokluğunda uzun süreli kesintilere ve kalıcı veri kaybına neden olabilir.

SQL veritabanı bozulmasının nedenlerini bilmek, temel nedeni teşhis etmeye ve düzeltmeye yardımcı olabilir.

Bu makale, SQL veritabanı bozulma sorunlarının derinlemesine anlaşılmasını ve bozuk veritabanını onarma yöntemlerini sağlar.

Ayrıca, REPAIR_ALLOW_DATA_LOSS bağımsız değişkeni ile DBBC CHECKDB’ye alternatif olarak bir SQL Server veritabanı onarım aracının ana hatlarını verir.

SQL Server Veri Kurtarma İşlemleri için firmamızdan destek alabilirsiniz. 

Mysql Veritabani Onarma

Mysql Veritabani Onarma

 

Mysql Veritabanı Onarma

 

SQL sayfa düzeyinde bozulma: sayfa düzeyinde bozulma, bir veritabanı sayfasının başlığında, gövdesinde veya yuva dizisinde depolanan bilgi veya veriler, kullanıcının sayfaya erişemeyeceği şekilde değiştirildiğinde meydana gelir. Sayfa düzeyinde bozulma, donanım sorunları, disk/alt sistem arızası, kötü amaçlı yazılım, hatalı güncellemeler ve yamalar vb. nedenlerle meydana gelebilir.

 

Önyükleme sayfası bozulması: bu, önyükleme sayfasıyla ilgili olduğundan daha kritik bir SQL veritabanı bozulması durumudur. SQL veritabanı başına yalnızca bir önyükleme sayfası vardır ve tüm veritabanı için meta verileri depolar. Bu nedenle, bozulması tüm veritabanı dosyasını etkileyebilir. Ayrıca, DBCC CHECKDB veya sayfa düzeyinde geri yükleme, önyükleme sayfası bozulmasını düzeltemez. Bu sınırlamaya, önyükleme sayfasının geçerli sürüm, veritabanı kimliği, kontrol noktası LSN vb. gibi Meta bilgileri depolaması gerçeği verilir.

 

Kümelenmemiş dizin bozulması: bu tür bozulma, SQL Server 2008 ve sonraki sürümlerle ilişkilidir. Genellikle bir SQL DBA, bir tabloya karşı NOLOCK ipucu ile karmaşık bir UPDATE deyimi çalıştırmayı denediğinde oluşur. Kümelenmemiş dizin bozulması, SQL veritabanı sorgusunun yanlış okunmasına veya aynı değer üzerinde birden çok okuma işlemi yapılmasına neden olur.

 

SQL veritabanı şüpheli modunda: SQL veritabanı şüpheli modu, SQL Server başlatma sırasında veritabanı kurtarmayı durduran birincil dosya grubu dosyasındaki hasar nedeniyle DBA’ların sık karşılaştığı bir sorundur. Bir SQL Server, donanım arızası, disk alanı sorunu, sistem çökmesi vb. nedenlerle günlük dosyasında bir sorun tespit ettikten sonra veritabanını ŞÜPHELİ modunda işaretleyebilir. Şüpheli moddaki bir veritabanı, kesinti süresine yol açan okuma/yazma işlemlerini gerçekleştiremez. .

 

DBCC CHECKDB Komutu ile Bozuk SQL Server veritabanı nasıl onarılır

 

DBCC CHECKDB , bir SQL Server veritabanındaki veya Azure SQL veritabanındaki SQL veritabanı nesnelerinin mantıksal ve fiziksel bütünlüğünü kontrol etmeye yönelik bir dizi T-SQL komutudur. Bu komutları tüm veritabanında, veritabanındaki veya katalogdaki tek tek tablo ve görünümlerde çalıştırabilirsiniz.

 

 

DBCC CHECKDB komutunun genel sözdizimi aşağıdadır:

Mysql Veritabanı Onarma

Mysql Veritabanı Onarma, için aşağıda REPAIR_FAST, REPAIR_REBUILD ve REPAIR_ALLOW_DATA _LOSS bağımsız değişkenlerinin açıklaması yer almaktadır:

 

sql repair 2

SQL Veritabanı Onarımı için DBCC CHECKDB Kullanma

CHECKDB ile REPAIR_ALLOW_DATA_LOSS argümanı sadece acil durumda ve son seçenek olarak kullanılmalıdır. Bir satırın veya sayfaların serbest bırakılmasını içeren hataları düzeltebilir, ancak serbest bırakılan veriler kaybolduğundan ve bu kaybın boyutu belirlenemediğinden veri kaybına neden olabilir.

DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS komutunu çalıştırma adımları aşağıdadır:

1. Birincil ve ikincil veri dosyası, işlem günlüğü dosyası, tam metin katalogları, dosya akışı vb. dahil olmak üzere veritabanının fiziksel kopyalarını oluşturun.

2. Transact-SQL kullanarak veritabanını tek kullanıcı moduna ayarlayın

 

Önemli notlar:
  • Veritabanını tek kullanıcı moduna ayarlamak, uyarı yapmadan diğer kullanıcıların bağlantısını kesecektir.
  • Veritabanını tek kullanıcı moduna geçirmeden önce AUTO_UPDATE_STATISTICS_ASYNC seçeneğinin OFF olarak ayarlandığından emin olun.

 

a) T-SQL Veritabanı Motoruna bağlanın ve Yeni Sorgu’ya tıklayın

b) ALTER DATABASE komutunu aşağıdaki gibi çalıştırın:

KULLANIM ustası;

GİT

ALTER DATABASE Musteri2022

TEK_KULLANICI AYARLA

HEMEN GERİ DÖNME İLE;

GİT

ALTER DATABASE Musteri2022

SADECE OKUYUN AYARLA;

GİT

ALTER DATABASE Musteri2022

ÇOKLU_KULLANICI AYARLA;

GİT

Mysql Veritabanı Onarma için yukarıdaki komut, Musteri2022 adlı veritabanını tek kullanıcı moduna geçirir. İLE ROLLBACK IMMEDIATE argümanı, tüm eksik işlemlerin geri alınmasına izin vermek için kullanılır.

c) DBCC CHECKDB’yi REPAIR_ALLOW_DATA_LOSS argümanıyla aşağıdaki gibi çalıştırın:

DBCC CHECKDB(‘Musteri2022’, REPAIR_ALLOW_DATA_LOSS)

GİT

Komutun sonucu şuna benzer olacaktır:

‘Musteri2022’ için DBCC sonuçları.

Onarım: Sayfanın (1:166) konumu, nesne kimliği 2121058256, dizin kimliği 0, bölüm kimliği 72057594039042048, ayırma birimi kimliği 72057594043301888’den (sıra içi veri türü) kaldırıldı.

Mesaj 8928, Seviye 16, Durum 1, Satır 1

Nesne kimliği 2121058256, dizin kimliği 0, bölüm kimliği 72057594039042048, ayırma birimi kimliği 72057594043301888 (satır içi veri türü): Sayfa (1:166) işlenemedi. Detaylar için diğer hatalara bakın.

Hata düzeltildi.

“Musteri2022” nesnesi için 14 sayfada 930 satır var.