Microsoft SQL Server Veritabanlarını Kurtarma. Veritabanı kurtarma

Bir VTYS için temel gereksinimlerden biri, harici bellekte veri depolamanın güvenilirliğidir. Depolama güvenilirliği, herhangi bir donanım veya yazılım arızasından sonra DBMS'nin DB'nin son tutarlı durumunu geri yükleyebilmesi gerektiği anlamına gelir. Genellikle iki olası donanım arızası türü göz önünde bulundurulur: bilgisayarın aniden durması (örneğin, bir acil durum kapanması) olarak yorumlanabilen sözde yumuşak arızalar ve bilgisayardaki bilgi kaybı ile karakterize edilen donanım arızaları. medya. harici bellek... Yazılım hatalarına örnek olarak şunlar verilebilir: DBMS'nin anormal şekilde sonlandırılması (programdaki bir hatadan dolayı veya bazı donanım arızalarının bir sonucu olarak) veya bir kullanıcı programının anormal şekilde sonlandırılması, bunun sonucunda bazı işlemler eksik kalır. İlk durum, özel bir tür yumuşak donanım arızası olarak görülebilir; ikincisi gerçekleştiğinde, yalnızca bir işlemin sonuçlarını ortadan kaldırmak gerekir.

Her durumda, veritabanını geri yüklemek için bazı ek bilgilere sahip olmanız gerekir. Başka bir deyişle, bir veritabanında veri depolamanın güvenilirliğini sürdürmek, yedek veri depolaması gerektirir ve verilerin kurtarma için kullanılan bölümünün özellikle güvenilir bir şekilde saklanması gerekir. Bu tür gereksiz bilgileri korumanın en yaygın yöntemi, bir veritabanı değişiklik günlüğü tutmaktır.

Dergi, veritabanının VTYS kullanıcıları tarafından erişilemeyen ve özel bir özenle korunan özel bir parçasıdır (bazen derginin iki kopyası desteklenir, farklı adreslerde bulunur). fiziksel diskler), veritabanının ana bölümündeki tüm değişikliklerin kayıtlarını alır. Günlüğe kaydederken, "ileri" yazma stratejisine bağlı kalınır; bu, herhangi bir veritabanı nesnesindeki bir değişiklikle ilgili bir kaydın, değiştirilen nesne ana bölümünün harici belleğine girmeden önce günlüğün harici belleğine girmesi gerektiği anlamına gelir. veri tabanı. DBMS'nin bu koşulu doğru bir şekilde gözlemlemesi durumunda, günlüğü kullanarak herhangi bir arızadan sonra veritabanını geri yükleme ile ilgili tüm sorunları çözmenin mümkün olduğu bilinmektedir.

Yazılım hatası durumunda, veritabanının ana bölümünün harici belleği, hata anında tamamlanmayan işlemler tarafından değiştirilmiş nesneleri içerebilir ve o sırada başarıyla tamamlanmış işlemler tarafından değiştirilen nesneler olmayabilir. hatanın nedeni ancak harici belleğe yazılmamıştır. Yumuşak bir hatadan sonraki kurtarma işleminin amacı, veritabanının ana bölümünün harici belleğinin durumudur, tamamlanan tüm işlemlerdeki değişiklikler harici belleğe kaydedildiğinde ortaya çıkacak ve bitmemiş işlemlerin hiçbir izini içermeyecektir. . Bunu başarmak için, önce taahhüt edilmemiş işlemleri geri alırlar ve ardından tamamlanmış işlemlerin, sonuçları harici bellekte görüntülenmeyen işlemlerini yeniden yürütürler. Sabit bir arızadan sonra veritabanını geri yüklemek için bir günlük ve veritabanının bir arşiv kopyası kullanılır. Arşiv kopyası, dergi dolmaya başladığında veritabanının tam bir kopyasıdır. Sabit bir hatadan sonra normal veritabanı kurtarma için, günlüğün kaybolmaması gerekir. Ardından, veritabanının kurtarılması, arşiv kopyasına dayanarak, arıza anında sona eren tüm işlemlerin çalışmasının günlükte yeniden üretilmesinden oluşur.

Güvenilirlik açısından günlüğe kaydetme için özel gereksinimler olmasına rağmen, prensipte kaybolabilir. O zaman veritabanını geri yüklemenin tek yolu bir arşiv kopyasına geri dönmektir. Elbette bu durumda, veritabanının son tutarlı durumunu elde edemezsiniz, ancak bu hiç yoktan iyidir.

Bir veritabanını arşivlemenin en kolay yolu, bir günlük taşması meydana geldiğinde gerçekleşir. Sözde "sarı bölge", yeni işlemlerin oluşumunun geçici olarak engellendiği günlüğe girilir. Tüm işlemler tamamlandığında ve dolayısıyla veritabanı tutarlı bir durumda olduğunda, onu arşivleyebilir ve ardından günlüğü yeniden doldurmaya başlayabilirsiniz.

Veritabanını, günlük dolduğundan daha az sıklıkta yedekleyebilirsiniz. Günlük doluysa ve başlatılan tüm işlemler sona erdiyse, günlüğün kendisini arşivleyebilirsiniz. Böyle bir arşivlenmiş günlük, esasen yalnızca veritabanının arşivlenmiş bir kopyasını yeniden oluşturmak için gerekli olduğundan, arşivlenmiş günlük bilgileri önemli ölçüde sıkıştırılabilir.

Bir yedekten verileri nasıl kurtaracağınızı öğrenmeniz gerekir. Bir donanım arızası durumunda veya başka bir sunucuda mevcut veritabanının tamamen aynı bir kopyasının oluşturulması gerektiğinde kurtarma gerekebilir.

Basit Kurtarma Modelini kullanarak bir veritabanını geri yüklerseniz, yalnızca son tam kopyayı geri yüklemeniz gerektiğini unutmayın. Tam veya Toplu Kurtarma Modelini kullanıyorsanız, tam kopyayı, ardından son farklı kopyayı ve işlem günlüklerinin tüm kopyalarını geri yüklemelisiniz. İyileşme süreçlerine daha yakından bakalım.

Veritabanını tam kopyadan geri yükleme.

Kurtarma modeli ne olursa olsun, ilk adım her zaman en son tam yedeği geri yüklemektir. Veritabanını Enterprise Manager'da geri yüklemek için veritabanını seçin, üzerine çift tıklayın sağ tık fare ve seçin bağlam menüsü“Tüm Görevler> Veritabanını Geri Yükle”, bu Şekil A'da gösterilen iletişim kutusunu açacaktır.

Şekil A.

Veritabanını Geri Yükle iletişim kutusu, tüm son bilgileri görüntülemenizi sağlar. yedekler kronolojik sırayla. Orada, geri yüklemek istediğiniz veritabanını da seçebilirsiniz. Şekil B'de gösterilen Seçenekler sekmesinde, yapma seçeneklerini seçebilirsiniz:

Her yedeklemeyi geri yükledikten sonra bantları çıkarın
Her yedeği geri yüklemeden önce sor (her yedeği geri yüklemeden önce ek bir uyarı yayınlayın)
Varolan veritabanı üzerinden geri yüklemeyi zorla, bu seçenek T-SQL'de Taşı ile eşdeğerdir.

Şekil B.

Pencerenin altında, bir kopyayı geri yükledikten sonra veritabanının durumunu belirlemenizi sağlayan üç anahtar vardır:

Veritabanını Operasyonel Bırakın. Hiçbir Ek İşlem Günlüğü Geri Yüklenemez.
- Bu değeri seçerseniz, yedeklemeyi yükledikten sonra, bekleyen tüm işlemlerin geri alınmasıyla sonuçlanacak olan geri yükleme işlemi başlatılacaktır. İşlem günlüğünün ek kopyalarını indirmek imkansız hale gelecektir. Kullanıcılar veritabanı ile normal şekilde çalışabilecektir.
Veritabanını Çalışmaz Bırakır Ama Ek İşlem Günlüklerini Geri Yükleyebilir.
- Kopyanın indirilmesi tamamlandıktan sonra, veritabanı geçici olarak kullanılamayacak durumda kalacaktır. Ek kopyalar indirmeniz ve ardından geri yükleme işlemini başlatmanız gerekecektir.
Veritabanını Salt Okunur Bırakın ve Ek İşlem Günlüklerini Geri Yükleyebilir.
- Veritabanı salt okunur hale gelir. Ek işlem günlüğü yedeklerini indirebilirsiniz. Bu seçenek, bir bekleme sunucusu oluşturmak için kullanılır

Tek yapmanız gereken, veritabanını ve işlem günlüklerini geri yüklemek için Tamam'ı tıklamaktır.

T-SQL kullanarak veritabanı kurtarma.

Veritabanı kurtarma, Enterprise Manager'dan daha fazla seçenek sunan T-SQL kullanılarak da yapılabilir. Kullanım sözdizimi T-SQL komutları sonraki:

VERİTABANI GERİ YÜKLE ( veri tabanı ismi | @ database_name_var }
[İTİBAREN< backup_device > [ , ...n ] ]
[İLE BİRLİKTE
[RESTRICTED_USER]
[ [ , ] DOSYA = { dosya numarası | @ dosya numarası } ]
[ [ , ] PAROLA = { parola | @ şifre_değişkeni } ]
[ [ , ] MEDYANAME = { medya_adı | @ media_name_variable } ]
[ [ , ] MEDYA ŞİFRESİ = { medya şifresi | @ mediapassword_variable } ]
[ [ , ] HAREKET " mantıksal_dosya_adı" İLE " işletim_sistemi_dosya_adı" ]
[ , ...n ]
[ [ , ] KEEP_REPLICATION]
[ [ , ] (NORECOVERY | KURTARMA | BEKLEMEDE = geri alma_dosya_adı } ]
[ [ , ] (NOREWIND | GERİ SATIR)]
[ [ , ] (YÜKLEME | YÜKLEME)]
[ [ , ] YER DEĞİŞTİRMEK]
[ [ , ] TEKRAR BAŞLAT]
[ [ , ] İSTATİSTİKLER [ = yüzde ] ]

Her seçeneğin ayrıntılı bir tartışması için SQL Server 2000 Books Online'daki açıklamaları okuyun.

Şekil C, Pubs veritabanının tam bir kopyasının bir yedekleme cihazından geri yüklenmesini göstermektedir.

Şekil C.

Bir diferansiyel kopyadan bir veritabanını geri yükleme.

Tam veya Toplu Kurtarma Modelini kullanıyorsanız, önce tam yedeği, ardından son diferansiyel yedeği ve tüm işlem günlüklerini geri yüklemelisiniz. Diferansiyel kopya kullanarak bir veritabanını geri yüklemek için Enterprise Manager'da veritabanını seçin, üzerine çift tıklayın ve içerik menüsünden “Tüm Görevler> Veritabanını Geri Yükle” öğesini seçin, veritabanının tam ve farklı kopyalarını geri yükle öğesini seçin ve ardından Tamam öğesine tıklayın. . (Şekil D)

Şekil D.

Diferansiyel yedekleme geri yüklemesi gerçekleştirmek için Geri Yükle komut sözdizimi Şekil E'de gösterilmektedir.

Şekil E.

İşlem günlüğü geri yükleniyor.

İşlem günlüğünü geri yüklemeye başlamadan önce, veritabanının tam ve en son diferansiyel kopyasını geri yüklemelisiniz. Ardından işlem günlüklerini uygun sırayla geri yükleyebilirsiniz. Enterprise Manager kullanıyorsanız, veritabanını seçmeniz, üzerine farenin sağ tuşuyla çift tıklamanız ve içerik menüsünden “Tüm Görevler> Veritabanını Geri Yükle” seçeneğini seçmeniz, gerekli tüm kopyaları ve gerekirse Noktayı seçmeniz gerekir. Zaman Geri Yükleme seçeneğinde zaman noktası) (Şekil F).

Şekil F.

İşlem günlüğünü geri yüklemek için Geri Yükle komut sözdizimi Şekil G'de gösterilmektedir.

Şekil G.

Özetleyelim. Destek olmak ve veritabanını geri yüklemek, bir veritabanı yöneticisinin temel, en önemli görevlerinden biridir. Herhangi bir zamanda, veritabanını geri yükleme yeteneğinizden emin olmalısınız. SQL Server 2000, felaket kurtarma planınıza göre. Bir felaket kurtarma planınız yoksa, bir tanesi üzerinde çalışmaya başlamanızı tavsiye ederim. Bir şey olursa ve veriler kaybolursa, sizin için bir sonraki kayıp işinizi kaybetmek olabilir.

Bugünün dersi: MySQL.(MySQL ücretsiz bir veritabanı yönetim sistemidir). Bir veritabanını kurtarmak basittir, ancak veritabanınızın yedeğini almanız gerekir. Veritabanında sorun yaşadığımda siteye giremedim ve tüm yazılarım kayboldu. Wordprerss veritabanını nasıl geri yükleyeceğime acilen karar vermem gerekiyordu.

Bu durum birkaç gün önce Ders 59'u yazarken başıma geldi. Kelimenin tam anlamıyla birkaç dakika sonra Yandex-Metrica'dan sitemin müsait olmadığına dair bir SMS aldım. Daha önce böyle bir sorunla karşılaştıysanız, her şeyi nasıl çalışır duruma getireceğinizi biliyorsunuz ve değilse okumaya devam edin.

WordPress Veritabanı Nasıl Kurtarılır (Yöntem 1)

İnternette, çoğunlukla bir veritabanının nasıl yedekleneceğini yazarlar, ancak çok az kişi yazar, WordPress veritabanı nasıl geri yüklenir ... ile gerekli değildir veri tabanı sizin hatanızdan dolayı sorunlar çıkabilir. Veritabanında başka nedenlerle hatalar oluşabilir.

Blogunuz henüz bir eklenti veya benzerini yüklemediyse, blogsuz kalma riskiniz vardır. Uzun bir süre blog yazdığınızı ve sonra bir kez, işte bu kadar! Amba! Bu eklenti bunun olmasına izin vermeyecek. Blog veritabanınızı kalıcı olarak içeride tutar otomatik mod ve katılımınız olmadan.

İnternette veritabanını geri yükleme hakkında pek çok bilgi var, ancak bazen insanların da teşekkür ettiği saçma sapan şeyler yazıyorlar. Makalenin yazarı, bunun ve bunun nasıl doğru bir şekilde yapılacağı konusunda tavsiyelerde bulunur, ancak kendisi ne hakkında yazdığını bile anlamıyor. Her şey, işe koyulma zamanı 🙂

Bir blogu önceki durumuna geri yüklemek için veritabanının yeni bir yedeğine sahip olmanız gerekir. Temel dosyayı paketinden çıkarın ve paketlenmemiş dosyayı Windows Not Defteri'nde açın. Dosyanın içeriğini şuraya kopyalayın. PhpMyAdmin'de hostinginizin kontrol paneline gidin.

Geri yüklemek istediğiniz veritabanının adına tıklayın.

O zaman tıklamanız gerekiyor "SQL"ve veritabanı dosyasından kopyaladığınızı tıklayarak pencereye yapıştırın" CTRL " + "V". Sonra tıklayın" Tamam ".

Veritabanı kurtarma tamamlanana kadar bekleyin. Başarı mesajı görünmelidir.

Blogunuz artık tamamen geri yüklendi.

Bir WordPress veritabanı nasıl hızlı bir şekilde geri yüklenir (yöntem 2)

Yani gereksiz girişler olmadan. Barındırma kontrol panelinize (cPanel) gidin. Bağlantıyı bulun” MySQL" veya " PhpMyAdmin ».

Şimdi veritabanı yönetim panelinde, yani PhpMyAdmin'de oturum açmanız gerekiyor. Tıklamak " İçeri gel»

PhpMyAdmin'e yönlendirileceksiniz. Sol tarafta, geri yükleyeceğiniz veritabanına tıklayın. Benim durumumda, bu dvpress veritabanıdır.

Bir veritabanı seçtikten sonra, o veritabanı için tüm tablolar görünecektir. Kurtarma sırasında herhangi bir hatadan kaçınmak için bu veritabanı tamamen silinmelidir. En alta iniyoruz ve “ Tümünü kontrol et / Tümünün seçimini kaldır ". Tıklamak " Hepsini seç "Böylece veritabanındaki tüm tablolar onay kutusunda işaretlenir. Sağdaki pencerede seçiyoruz “ Silmek"Ve sonra onayla" Evet". Veritabanı tüm tablolardan tamamen temizlenmiş olmalıdır.

Şimdi göreviniz bu veritabanını bir yedekten geri yüklemek. üstte tıklayın" İçe aktarmak", Ardından düğmesine tıklayın" Bir dosya seçin ". Bilgisayarınızdaki veritabanının yedek bir kopyasını bulun ve “ Açık". Şimdi PhpMyAdmin'de altta " Tamam". İşlem başarılı olmalı ve yazıt “ SQL sorgusu başarıyla tamamlandı ».

Geçen hafta yayınladığım, belli bir ilgi uyandırmış gibiydi, ama ne yazık ki, "pratik" içermiyordu. Evet, verilerin nasıl kaydedileceği yazıyor ama örnek yok.
İlk başta aynı yazardan bir çeviri daha yapmak istedim ama biraz düşündükten sonra sanki “esaslı” gibi “kendi başıma” bir yazı yazmaya karar verdim. Beni bunu yapmaya iten sebepleri yazının sonunda, notlarda anlatacağım.

SQL Server'da Veritabanlarını Geri Yükleme

Bir önceki makalede bahsedildiği gibi, kümelenmiş dizin veya yığın sayfaları zarar görürse, bu sayfalarda bulunan veriler kaybolur ve bunları kurtarmak için tek seçenek doğrudan veritabanını geri yüklemektir.

SQL Server, veritabanı kurtarma için birçok seçenek sunar. İlk olarak, bu tüm veritabanını geri yüklemektir - oldukça uzun zaman alabilir (veritabanının boyutuna ve hızına bağlı olarak). sabit sürücüler). İkinci olarak, veritabanınız birkaç dosya grubundan (veya buna göre dosyalardan) oluşuyorsa, tek tek dosya gruplarının veya dosyaların kurtarılması. Bu durumda, geri kalanını etkilemeden veritabanının yalnızca hasarlı kısımlarını geri yüklemek mümkündür. Bu iki tür veritabanı kurtarma oldukça sık kullanılmaktadır ve gelecekte bunlara değinilmeyecektir.
Üçüncüsü, SQL Server 2005'te, tek tek veritabanı sayfalarını geri yüklemek mümkün hale geldi - bu durumda, yedekten yalnızca belirtilen sayfalar geri yüklenecektir. Bu tür bir kurtarma, özellikle DBCC CHECKDB ağır bir dosyada "yatan" bazı büyük tablolarda birkaç hasarlı sayfa bulursa önemli olacaktır. Tüm dosyanın ve hatta tüm tablonun değil, yalnızca birkaç sayfanın geri yüklenmeyeceği gerçeği nedeniyle, kesinti süresi önemli ölçüde azaltılabilir.

Gereksinimler ve Sınırlamalar

Kurtarma modeli ve işlem günlüğü yedeklerinin kullanılabilirliği

Hatırlanması gereken en önemli şey, tek tek sayfaları kurtarmak için veritabanının tam kurtarma modelini veya toplu olarak günlüğe kaydedilen kurtarma modelini kullanması gerektiğidir. Veritabanlarınız basit (basit) bir kurtarma modelindeyse, daha fazlasını okuyamayabilirsiniz.
İkinci gereksinim, tam ve işlem günlüğü yedeklemelerinizin kırılmaz bir günlük zinciri oluşturmasıdır. TRUNCATE_ONLY (NO_LOG) İLE YEDEKLEME GÜNLÜĞÜ'nü hiçbir zaman çalıştırmazsanız ve basit model kurtarma işlemi günlüğünü küçültmek için ve son tam sayfasız yedeklemeden bu yana TÜM işlem günlüğü yedeklemeleriniz var (bu en eksiksiz yedekleme dahil) - günlük zinciri hakkında endişelenmenize gerek yok.
Toplu olarak günlüğe kaydedilen bir kurtarma modelinde, teorik olarak, yukarıda açıklanan koşullar karşılanıyorsa ve geri yüklenen sayfalar minimum günlük kaydıyla gerçekleştirilen işlemlerle değiştirilmediyse, tek tek sayfa kurtarma düzgün çalışmalıdır.

SQL Server Sürümleri

SQL Server'ın herhangi bir sürümünde sayfa kurtarma mümkündür, ancak Enterprise ve Developer sürümleri için hasarlı sayfaları on-line kurtarmak mümkündür, yani. kurtarma sırasında veritabanına erişebilirsiniz (ve ayrıca, bu sayfaların kendileri "etkilenmeyecekse", o anda geri yüklenen sayfaların ait olduğu tabloya bile başvurabilirsiniz - aksi takdirde istek başarısız olur). Enterprise Edition'ın "altındaki" sürümler için sayfa kurtarma çevrimdışı gerçekleşir ve kurtarma sırasında veritabanı kullanılamaz hale gelir.

Hasarlı sayfa türü

Dizin sayfalarının veya veri sayfalarının zarar görmesi durumunda, Enterprise Edition'da çevrimiçi olarak kurtarılmaları mümkündür.
Kritik sistem tablolarını içeren sayfalar geri yüklenebilir, ancak veritabanı geri yüklendiğinde SQL Server'ın herhangi bir sürümünde mevcut olmayacaktır.
"Yerleştirme kartları" "ayrı" olarak geri yüklenemez. GAM, SGAM, PFS, ML, DIFF sayfaları hasar görmüşse, tüm veritabanını geri yüklemeniz gerekir. Tek istisna IAM sayfalarıdır. "Yerleşim haritaları" olarak adlandırılsalar da, tüm veritabanını değil, yalnızca bir tabloyu tanımlarlar ve geri yüklenebilirler.
Veritabanı önyükleme sayfası (1. veritabanı dosyasında sayfa 9) ve dosya başlık sayfası (her dosyada sayfa 0) "ayrı olarak" geri yüklenemez; bunlar hasar görürse, tüm veritabanını geri yüklemeniz gerekir.

Aslında, kurtarma

Şimdi, son olarak, teoriden pratiğe geçelim.
Her şeyden önce, eğitim için bozuk bir veritabanına ihtiyacınız var.

Veritabanını bozuyoruz

Deneme için SQL Server ile birlikte gelen AdventureWorks veritabanını kullanacağım. Eğer yüklemediyseniz, isterseniz indirebilirsiniz. Bunu tam kurtarma modeline çeviriyorum:
ALTER DATABASE AdventureWorks SET RECOVERY FULL İçinde henüz hata olmadığından emin oluyorum:
NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY İLE DBCC CHECKDB ("AdventureWorks") ve tam bir yedekleme oluşturun:
YEDEK VERİTABANI AdventureWorks TO DİSK = "D: \ tmp \ aw_backups \ aw_full_ok1.bak"

Bu veritabanında bir kilitlenme tablosu oluşturuyorum.
CREATE TABLE crash (txt varchar (1000)) SQL Server aniden orada kendi yazdığı verileri bulursa ne olacağını kontrol etmek için varchar alanını bozacağız.
Bir şeyi mahvetmeden önce, onu bir şeyle doldurmanız gerekir. Sol verileri oluşturulan tabloya yüklüyorum.
DECLARE @i ÜZERİNDE NOCOUNT SET INT SET @i = 1 WHILE @i<100000 BEGIN INSERT INTO crash SELECT REPLICATE("a", 1000) SET @i = @i + 1 END SET NOCOUNT OFF Теперь делаю резервную копию журнала транзакций:
YEDEKLEME GÜNLÜĞÜ AdventureWorks TO DISK = "D: \ tmp \ aw_backups \ aw_log_ok1.trn"

Şimdi verileri biraz değiştirelim:

Yani her şey hazır. Veritabanını ayırın ve FAR mdf dosyasını açın (veya sizin için daha uygun olanı), içindeki "zzzzzzz" dizesini arayın ve birkaç "z"yi rastgele karakterlerle değiştirin:

Şimdi veritabanı bozulduğuna göre, onu bağlarız. Ve evet, bir önceki makalede veritabanını ayırmanın / eklemenin buna değmeyeceğinin açıkça belirtildiğini hatırlıyorum. Ancak bizim durumumuzda kesinlikle "güvenli" - "şüpheli" veritabanı düşmeyecek.

Hataları aramak

Böylece, hasarlı veritabanı başarıyla hizmete geri döndü. Bütünlük kontrolünü tekrar çalıştıralım:
NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY İLE DBCC CHECKDB ("AdventureWorks") Sonuç olarak, beklediğimiz şey ( hasarlı sayfaların numaralarını hatırladığınızdan emin olun!):

Mesaj 8928, Seviye 16, Durum 1, Satır 1
Nesne Kimliği 1883153754, dizin kimliği 0, bölüm kimliği 72057594054246400, ayırma birimi kimliği 72057594061651968 (satır içi veri türü): Sayfa (1: 20455) işlenemedi. Detaylar için diğer hatalara bakın.
Mesaj 8939, Seviye 16, Durum 98, Satır 1
Tablo hatası: Nesne Kimliği 1883153754, dizin kimliği 0, bölüm kimliği 72057594054246400, ayırma birimi kimliği 72057594061651968 (sıra içi veri türü), sayfa (1: 20455). Test (IS_OFF (BUF_IOERR, pBUF-> bstat)) başarısız oldu. Değerler 29493257 ve -4'tür.
CHECKDB, "çökme" tablosunda 0 ayırma hatası ve 2 tutarlılık hatası buldu (nesne kimliği 1883153754).
CHECKDB, "AdventureWorks" veritabanında 0 ayırma hatası ve 2 tutarlılık hatası buldu.
Repair_allow_data_loss, DBCC CHECKDB (AdventureWorks) tarafından bulunan hatalar için minimum onarım düzeyidir.
V bu durumdaöbekteki veriler zarar görür (index id = 0), bu nedenle SQL Server bu verileri kurtaramaz.
Şimdi üç seçeneğimiz var:

Veri kaybını kabul edin ve DBCC CHECKDB'yi çalıştırın ("AdventureWorks", REPAIR_ALLOW_DATA_LOSS)
İşlem günlüğünün aktif kısmının yedeğini alın ve tüm veritabanını geri yükleyin - sonuç olarak veri kaybı olmayacak, ancak uzun zaman alacak
İşlem günlüğünün aktif bölümünün yedeğini alın ve yalnızca bir (!) Hasarlı sayfayı geri yükleyin

İkinci seçenekle, her şey açık olmalıdır, ancak DBCC CHECKDB çalıştırırsanız ne olur veya tek tek sayfaların nasıl geri yüklendiğini - daha fazla göstereceğim.

Hasarlı bir sayfayı kurtarma

Her şeyden önce, işlem günlüğünün son parçasının bir yedeğini almamız gerekiyor (kuyruk yedeği). Aynı zamanda, Enterprise Edition'ınız varsa, bu sürüm çevrimiçi sayfa kurtarmayı desteklediğinden, veritabanını "geri yükleme" durumuna aktaracak NORECOVERY parametresini ekleyemezsiniz. Ayrıca işlem log yedeklemeleriniz log zincirini bozmamak için düzenli olarak yapılıyorsa Enterprise Edition'da COPY_ONLY yedeklemesi yapabilirsiniz.
Çevrimdışı kurtarma yolunu takip ediyorum ve şunu yürütüyorum:
AdventureWorks'ün DİSK'E YEDEKLEME GÜNLÜĞÜ = "D: \ tmp \ aw_backups \ aw_log_fail3.trn" NORECOVERY İLE

Artık hasarlı sayfayı kurtarabilirsiniz. Öncelikle tam bir yedek kullanıyoruz (aw_full_ok1.bak):

VERİTABANI GERİ YÜKLE AdventureWorks SAYFASI = "1: 20455" DİSK'TEN = "D: \ tmp \ aw_backups \ aw_full_ok1.bak" NORECOVERY İLE
Sonuç olarak, elimizde:

İşlem günlüğü yedeklerini henüz üzerine almadığımız için NORECOVERY seçeneğini kullanmanız gerektiğini unutmayın.
DİSK'TEN GÜNLÜĞÜ GERİ YÜKLE AdventureWorks = "D: \ tmp \ aw_backups \ aw_log_ok1.trn" NORECOVERY İLE ve
DİSK'TEN GÜNLÜĞÜ GERİ YÜKLE AdventureWorks = "D: \ tmp \ aw_backups \ aw_log_fail3.trn" KURTARMA İLE

Her şey başarılı görünüyor, DBCC CHECKDB'yi çalıştırın ve ...

Kurtarma başarılı oldu.
Lütfen tüm veritabanını tam bir yedekten geri yüklemediğimiz, yalnızca hasarlı sayfaları geri yüklediğimiz için kesinti süresinin azaldığını unutmayın (tüm yedeği geri yükleseydim, yedekleme 8,5 saniyede geri yüklenirdi, ancak daha büyük boy DB - zaman farkı ne kadar büyükse). SQL Server Enterprise Edition'a sahip ve çevrimiçi kurtarma kullanan şanslı kişiler, günlük yedeklerinden kurtarma konusunda da zaman kazanacak ve çevrimdışı kurtarma ile ne yazık ki, tüm günlükler işlenecek.
Ayrıca şunu da eklemek gerekir ki SQL Server 2005, 2008, 2008 R2'de tek bir sayfanın geri yüklenmesi sadece T-SQL kullanılarak mümkün iken, Denali'de bunu GUI üzerinden yapmak mümkün hale geldi.

Ya sonuçta DBCC CHECKDB ise?

Her ihtimale karşı, REPAIR_ALLOW_DATA_LOSS parametresiyle DBCC CHECKDB çalıştırırsam SQL Server'ın ne yapacağını kontrol etmeye karar verdim. Aynı hata:

İlk olarak veritabanını SINGLE_USER moduna aktarıyoruz:
ALTER DATABASE AdventureWorks SET SINGLE_USER Ardından kurtarma işlemini başlatın:
NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY İLE DBCC CHECKDB ("AdventureWorks", REPAIR_ALLOW_DATA_LOSS) Sonuç olarak:
Onarım: Sayfa (1: 20455) nesne kimliği 1883153754, dizin kimliği 0, bölüm kimliği 72057594054246400, ayırma birimi kimliği 72057594061651968'den (satır içi veri türü) ayrılmış.
Evet, SQL Server "kusurlu" sayfayı sildi. Veritabanını MULTI_USER moduna aktarıyoruz, böylece herkes tarafından kullanılabilir hale geliyor ve neyin eksik olduğunu kontrol ediyoruz:

SQL Server'daki sayfa boyutunun 8KB olduğu ve kullanıcı verileri için biraz daha az mevcut olduğu göz önüne alındığında, her şey doğaldır, tablo 7 kayıtla "ağırlık kaybetti" (başlangıçta 99999 idi). Bu tablonun kümelenmiş bir indeksi olmadığından, veriler rastgele bir sırada saklanabilir, yani. hangi verilerin kaybolacağını bile bulamadık.

Öyleyse neden bir çeviri değil?

Öyleyse neden hala bir çeviri değil de "dayanan" bir yazı. Gerçek şu ki, kamuya açık alanda Gail Shaw'ın "Sayfa Geri Yükleme" adlı bir makalesi yok. SQL Server MVP Deep Dives vol.2 kitabında oldukça yüksek bir paraya satılan (ama elbette internette kolayca bulunan) böyle bir bölüm var ve bir çeviri yayınlamanın doğru olduğundan emin değilim. , um ... doğru ya da başka bir şey.
Genel olarak makaleyi okudum, ana noktaları not ettim ve sonra metni kendim yazdım ve bu arada restorasyon üzerine bir deney yaptım. Umarım birisi bu deneyimi faydalı bulmuştur.
Ve beyler, içtenlikle umuyorum ki, bu deneyi tekrarlamaya karar verirseniz, son derece dikkatli olursunuz (örneğin, üretim sunucusundaki ana veritabanıyla deney yapmayacaksınız). Yaptıklarından sorumlu olmadığımı unutma.

SQL Server'da Veritabanlarını Geri Yükleme

Bir önceki makalede bahsedildiği gibi, kümelenmiş dizin veya yığın sayfaları zarar görürse, bu sayfalarda bulunan veriler kaybolur ve bunları kurtarmak için tek seçenek doğrudan veritabanını geri yüklemektir.

SQL Server, veritabanı kurtarma için birçok seçenek sunar. İlk olarak, bu tüm veritabanını geri yüklemektir - oldukça uzun zaman alabilir (veritabanının boyutuna ve sabit sürücülerin hızına bağlı olarak). İkinci olarak, veritabanınız birkaç dosya grubundan (veya buna göre dosyalardan) oluşuyorsa, tek tek dosya gruplarının veya dosyaların kurtarılması. Bu durumda, geri kalanını etkilemeden veritabanının yalnızca hasarlı kısımlarını geri yüklemek mümkündür. Bu iki tür veritabanı kurtarma oldukça sık kullanılmaktadır ve gelecekte bunlara değinilmeyecektir.
Üçüncüsü, SQL Server 2005'te, tek tek veritabanı sayfalarını geri yüklemek mümkün hale geldi - bu durumda, yedekten yalnızca belirtilen sayfalar geri yüklenecektir. Bu tür bir kurtarma, özellikle DBCC CHECKDB ağır bir dosyada "yatan" bazı büyük tablolarda birkaç hasarlı sayfa bulursa önemli olacaktır. Tüm dosyanın ve hatta tüm tablonun değil, yalnızca birkaç sayfanın geri yüklenmeyeceği gerçeği nedeniyle, kesinti süresi önemli ölçüde azaltılabilir.

Gereksinimler ve Sınırlamalar

Kurtarma modeli ve işlem günlüğü yedeklerinin kullanılabilirliği

Hatırlanması gereken en önemli şey, tek tek sayfaları kurtarmak için veritabanının tam kurtarma modelini veya toplu olarak günlüğe kaydedilen kurtarma modelini kullanması gerektiğidir. Veritabanlarınız basit (basit) bir kurtarma modelindeyse, daha fazlasını okuyamayabilirsiniz.
İkinci gereksinim, tam ve işlem günlüğü yedeklemelerinizin kırılmaz bir günlük zinciri oluşturmasıdır. YEDEKLEME LOG İLE TRUNCATE_ONLY (NO_LOG) komutunu hiç çalıştırmazsanız ve işlem günlüğünü küçültmek için basit kurtarma modeline geçmezseniz ve son tam sayfa ücretsiz yedeklemeden bu yana TÜM işlem günlüğü yedeklemeleriniz varsa (bu en eksiksiz yedekleme dahil). yedekleme) - günlük zinciri hakkında endişelenmenize gerek yok.
Toplu olarak günlüğe kaydedilen bir kurtarma modelinde, teorik olarak, yukarıda açıklanan koşullar karşılanıyorsa ve geri yüklenen sayfalar minimum günlük kaydıyla gerçekleştirilen işlemlerle değiştirilmediyse, tek tek sayfa kurtarma düzgün çalışmalıdır.

SQL Server Sürümleri

Hasarlı sayfa türü

Aslında, kurtarma

Şimdi, son olarak, teoriden pratiğe geçelim.
Her şeyden önce, eğitim için bozuk bir veritabanına ihtiyacınız var.

Veritabanını bozuyoruz

Hataları aramak

Mesaj 8928, Seviye 16, Durum 1, Satır 1
Nesne Kimliği 1883153754, dizin kimliği 0, bölüm kimliği 72057594054246400, ayırma birimi kimliği 72057594061651968 (satır içi veri türü): Sayfa (1: 20455) işlenemedi. Detaylar için diğer hatalara bakın.
Mesaj 8939, Seviye 16, Durum 98, Satır 1
Tablo hatası: Nesne Kimliği 1883153754, dizin kimliği 0, bölüm kimliği 72057594054246400, ayırma birimi kimliği 72057594061651968 (sıra içi veri türü), sayfa (1: 20455). Test (IS_OFF (BUF_IOERR, pBUF-> bstat)) başarısız oldu. Değerler 29493257 ve -4'tür.
CHECKDB, "çökme" tablosunda 0 ayırma hatası ve 2 tutarlılık hatası buldu (nesne kimliği 1883153754).
CHECKDB, "AdventureWorks" veritabanında 0 ayırma hatası ve 2 tutarlılık hatası buldu.
Repair_allow_data_loss, DBCC CHECKDB (AdventureWorks) tarafından bulunan hatalar için minimum onarım düzeyidir.
Bu durumda, verilerin kendisi öbekte zarar görür (index id = 0), bu nedenle SQL Server bu verileri kurtaramaz.
Şimdi üç seçeneğimiz var:

Veri kaybını kabul edin ve DBCC CHECKDB'yi çalıştırın ("AdventureWorks", REPAIR_ALLOW_DATA_LOSS)
İşlem günlüğünün aktif kısmının yedeğini alın ve tüm veritabanını geri yükleyin - sonuç olarak veri kaybı olmayacak, ancak uzun zaman alacak
İşlem günlüğünün aktif bölümünün yedeğini alın ve yalnızca bir (!) Hasarlı sayfayı geri yükleyin

İkinci seçenekle, her şey açık olmalıdır, ancak DBCC CHECKDB çalıştırırsanız ne olur veya tek tek sayfaların nasıl geri yüklendiğini - daha fazla göstereceğim.

Hasarlı bir sayfayı kurtarma

Artık hasarlı sayfayı kurtarabilirsiniz. Öncelikle tam bir yedek kullanıyoruz (aw_full_ok1.bak):

VERİTABANI GERİ YÜKLE AdventureWorks SAYFASI = "1: 20455" DİSK'TEN = "D: \ tmp \ aw_backups \ aw_full_ok1.bak" NORECOVERY İLE
Sonuç olarak, elimizde:

İşlem günlüğü yedeklerini henüz üzerine almadığımız için NORECOVERY seçeneğini kullanmanız gerektiğini unutmayın.
DİSK'TEN GÜNLÜĞÜ GERİ YÜKLE AdventureWorks = "D: \ tmp \ aw_backups \ aw_log_ok1.trn" NORECOVERY İLE ve
DİSK'TEN GÜNLÜĞÜ GERİ YÜKLE AdventureWorks = "D: \ tmp \ aw_backups \ aw_log_fail3.trn" KURTARMA İLE

Her şey başarılı görünüyor, DBCC CHECKDB'yi çalıştırın ve ...

Kurtarma başarılı oldu.
Lütfen tüm veritabanını tam bir yedekten değil, yalnızca hasarlı sayfaları geri yüklediğimiz için kesinti süresinin azaldığını unutmayın (tüm yedeği geri yüklersem, yedekleme 8,5 saniyede geri yüklenir, ancak veritabanı boyutu ne kadar büyük olursa) , daha fazla zaman farkı olacak). SQL Server Enterprise Edition'a sahip ve çevrimiçi kurtarma kullanan şanslı kişiler, günlük yedeklerinden kurtarma konusunda da zaman kazanacak ve çevrimdışı kurtarma ile ne yazık ki, tüm günlükler işlenecek.
Ayrıca şunu da eklemek gerekir ki SQL Server 2005, 2008, 2008 R2'de tek bir sayfanın geri yüklenmesi sadece T-SQL kullanılarak mümkün iken, Denali'de bunu GUI üzerinden yapmak mümkün hale geldi.

Ya sonuçta DBCC CHECKDB ise?

Her ihtimale karşı, REPAIR_ALLOW_DATA_LOSS parametresiyle DBCC CHECKDB çalıştırırsam SQL Server'ın ne yapacağını kontrol etmeye karar verdim. Aynı hata: