Это связано с цепочкой журналов, зеркалирование напоминает восстановление резервных копий журналов транзакций на другой сервер, но автоматически, для его работы вам нужна непрерывная цепочка журналов из полной резервной копии в последнюю резервную копию t-журнала, поэтому цепочка журналов будет выглядеть так (с хорошими последовательными LSN):
Full-1-> LogA-> LogB-> LogC-> Full-2-> LogD-> LogE-> LogF и т. д.
В приведенном выше примере, если вы восстановили резервную копию Full-1, вы можете восстановить резервные копии журналов A, B, C, но не D, E, F. Вы можете восстановить их только при восстановлении Full-2.
В зеркалировании вы берете полную резервную копию БД, а затем восстанавливаете ее, затем SQL-сервер просматривает номера порядковых номеров (LSN) и передает транзакции, отсутствующие в восстановленной зеркальной базе данных, если вы берете другую полная резервная копия, вы разрываете цепочку последовательных LSN.
В вашем случае это похоже на то, что вы восстановили Full-1, а затем попытались применить к нему журналы D, E, F, есть пробел в порядковых номерах. Это должно было сработать для вас, если бы вы только что восстановили вторую случайную резервную копию, которую вы взяли на зеркальный сервер, а затем начали зеркалировать. Изменяя модель восстановления, вы полностью сбрасываете цепочку журналов и начинаете заново.
спасибо. не могли бы вы объяснить мне, почему зеркалирование требует дополнительных резервных копий журнала? не может ли сервер sql использовать оригинальную резервную копию и восстановить недостающую информацию из основной базы данных? – user2542655
Это потому, что он работает, переигрывая транзакции в зеркальную базу данных, а не просто беря данные, как сейчас, из основной БД. – steoleary