Veritabanı SQL Server 2012 yansıtılamıyor

Aşağıdaki komutu kullanarak bir veritabanını yansıtmaya çalışırken

ALTER AVAILABILITY GROUP SQLAlwaysonGroup ADD DATABASE test0916aj8CJ

Aşağıdaki hatayı alıyorum

Msg 1475, düzey 16, durum 105, satır 1
veritabanı "test0916aj8cj" yedeklenmemiş toplu günlüğe kaydedilmiş değişiklikler içerebilir. Ana veritabanında veya birincil veritabanında bir günlük yedeği alın. Daha sonra, veritabanı yedeklemeyi etkinleştirmek için ayna veritabanına veya kullanılabilirlik grubuna katılmanızı sağlamak için her ikincil veritabanına bu yedeklemeyi geri yükleyin.

Bu veritabanını desteklemeden yapılabilir mi? Yoksa yedeklemeli ve sonra yedeklemeliyim. Bu yeni oluşturulan bir db içindir, bu yüzden yine de bu noktada yedeklemeye gerek yok.

Aşağıdaki denedim ...

BACKUP
DATABASE [test0916aj8CJ] TO DISK = N’NUL’
WITH COPY_ONLY, NOFORMAT, INIT,
NAME = N’test-Full Database Backup’,
SKIP, NOREWIND, NOUNLOAD
GO

ancak yukarıdaki yöntem de işe yaramadı.

Teşekkürler

Aldığınız hatayı yeniden kopyalamak kolaydır

• Birincil üzerinde tam kurtarma modunda veritabanı oluşturun.
• İkincil'de tam kurtarma modunda veritabanı oluşturun.
• GUI'yi başlatın ve Birincil ve İkincil arasındaki yansıtmayı yapılandırmayı deneyin.

Alacağınız hata aşağıdadır:

"Test_mirroring_kin" veritabanı yedeklenmemiş toplu günlük değişiklikleri içerebilir. Ana veritabanında veya birincil veritabanında bir günlük yedeği alın. Daha sonra, veritabanı yedeklemeyi etkinleştirmek için ayna veritabanına veya kullanılabilirlik grubuna katılmanızı sağlamak için her ikincil veritabanına bu yedeklemeyi geri yükleyin. (Microsoft SQL Server, Hata: 1475)

Bu hatanın ne olduğunu anlayalım:

Veritabanınızı TAM kurtarma modunda yapılandırdınız ve veritabanının gerçekten TAM kurtarma modunda olduğunu düşünüyorsunuz.

Yukarıdakiler doğru değil. Veritabanını oluşturduktan sonra, veritabanı TAM kurtarma modunda olsa bile, TAM yedekleme yapmazsanız, sözde SIMPLE kurtarma işlemindedir.

Sen kolaylıkla kullanarak doğrulayabilirsiniz dbcc dbinfo> - dbi_dbbackupLSNdeğerini haiz 0:0:0(0x00000000:00000000:0000)veya Paul Randal'ın script kullanarak

dbcc traceon (3604)
go
dbcc dbinfo('test_mirroring_kin') with tableresults
go
dbcc traceoff (3604)

Edit:COPY_ONLY Seçeneği ile ilk tam yedekleme almak bile bir yedekleme zinciri oluşturmaz

backup database test_mirroring_kin
to disk = 'D:\test_mirroring_kin_FULL.bak'
with init, stats=10, COPY_ONLY

dbcc dbinfo-> dbi_dbbackupLSNhala değerine sahip 0:0:0(0x00000000:00000000:0000). Bu, veritabanının hala sahte basit kurtarma modunda olduğu anlamına gelir.

Yukarıdaki hatayı çözmek için ne yapmanız gerekir?

Birincil olarak tam yedekleme + bir işlem günlüğü yedeği almanız ve daha sonra ikincil veritabanına geri yüklemeniz with norecoveryve daha sonra AG grubu veya Yansıtma'da veritabanına katılmanız gerekir.

Bir yan not olarak, bütünlüğü ve senaryonuz anlatımında backup to NUL, Gail Shaw tarafından bu blog yazısı okundu.

Neden TO DISK = N’NUL’?

Neden kullandığınızı anlamıyorum TO DISK = N’NUL’:

BACKUP
DATABASE [test0916aj8CJ] TO DISK = N’NUL’

Bunu yaparsanız, yedekleme NUL, (yani. = Hiçbir yere / hiçbir yere) olarak kaydedilir ve dosyası olmadığı için kullanılamaz.

İken NULde LOG Yedekler için bir hedef olarak kullanılabilir, bu günlüklerine kaybolacak çünkü özellikle Prod sunucularında ya kullanılmamalıdır ve Yedek zincir kırılacak. (~ a benzer SHRINKFILE)

LOG Yedekleme

Gruba bir DB eklemeden önce onu hazırlamanız gerekir. İkincil bir DB hazırlamak istediğinizde, en az 1 İşlem Günlüğü yedeği alınmalı ve geri yüklenmelidir. Ayna, ikincil DB'de hangi işlemlerin önceden senkronize edildiğini ve hangi işlemlerin henüz birincil DB ile senkronize olmadığını anlamak için kullanır.

Bu nedenle, birincil DB'deki İşlem Günlüklerini Yedeklemelisiniz:

BACKUP LOG [test0916aj8CJ] TO  DISK = N'....bak' 
WITH  COPY_ONLY, FORMAT, INIT,  NAME = N'test0916aj8CJ-Transaction Log  Backup', STATS = 10

COPY_ONLYSeçenek kullanılmalıdır. Günlüklerin LOG yedeklemesinin sonunda kesilmemesini sağlar.

Birincil DB yedekleme zinciri

Ancak, bir günlük yedeklemesini tek başına geri yükleyemezsiniz, yani yedekleme zinciri olmadan (bkz. Kin yanıtı). Bu, İşlem Günlüğü yedeklemesinin bir TAM Veritabanı Yedeklemesi (+ gerekirse isteğe bağlı bir Diferansiyel) alındıktan sonra alınması gerektiği anlamına gelir.

Yana COPY_ONLYseçenek yedekleme zincirini kırmak değil, aynı zamanda bir yedek zincirini oluşturmaz. Bu COPY_ONLYseçenek Veritabanı Yedekleme için kullanılamaz.

Yedeklemeler sırayla:

• COPY_ONLYSeçenek olmadan TAM Veritabanı yedekleme
• İsteğe bağlı Diferansiyel yedekleme
• 1 LOG Yedekleme COPY_ONLYseçeneği
• gerekirse başka bir (veya daha fazla) LOG yedeklemesi ...

İkincil DB'yi geri yükleme

Ardından, Veritabanı Yedeklemesi ikincilde geri yüklenmelidir (+ Diferansiyel).

Bu ile restore edilmelidir NORECOVERYaynı zamanda TAM Yedekleme restore edildikten sonra LOG yedekleme (ler) geri yüklemek istediğiniz çünkü seçenek.

Son olarak LOG Yedeklemesini geri yükleyeceksiniz. Bu NORECOVERYseçeneği kullanmaya devam etmeniz gerekir, çünkü ayna işlemi bir kez geri yüklemeye devam edecektir.

• TAM yedeklemeyi NORECOVERYseçenekle geri yükle
• NORECOVERYSeçenekle DIFF yedeklemesini geri yükleme
• Tüm LOG yedeklemelerini NORECOVERYisteğe bağlı olarak geri yükleme

Hepsini bir araya getirelim (env'nize uyarlayın)

• Birincil sunucuda:

  USE master
  Go
  BACKUP DATABASE [test0916aj8CJ] TO DISK = N'....bak'
  WITH FORMAT, INIT, NAME = N'test0916aj8CJ-Full Database Backup', STATS = 10
  GO
  BACKUP LOG [test0916aj8CJ] TO DISK = N'....bak' 
  WITH COPY_ONLY, FORMAT, INIT, NAME = N'test0916aj8CJ-Transaction Log Backup', STATS = 10
  GO

• İkincil sunucuda:

  USE master
  Go
  RESTORE DATABASE [test0916aj8CJ] FROM DISK = N'....bak' 
  WITH FILE = 1, NORECOVERY, NOUNLOAD, REPLACE, STATS = 10
  GO
  RESTORE LOG [test0916aj8CJ] FROM DISK = N'....bak' 
  WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10

• Daha sonra, kullanılabilirlik grubuna yeni ikincil DB eklemeye devam edebilirsiniz ...

İsteğe bağlı eylemler

• DISK seçeneğini, Birincil ve İkincil sunuculardan kullanılabilen paylaşılan bir klasöre ayarlamak daha iyidir.
• DB dosyalarını hem Birincil hem de İkincil sunucularda benzer diskte ve konumda depolamak daha iyidir.