Номери LSN та планування відновлення, Microsoft Docs
Цей розділ стосується лише баз даних SQL Server, які використовують модель повного відновлення.
При плануванні відновлення найважливішими номерами LSN є перший і останній номери LSN. Ці номери LSN можна отримати з таких місць.
Таблицяbackupset уmsdb. Назвами стовпців єfirst_lsn таlast_lsn.
Інструкція RESTORE HEADERONLY. Стовпці називаютьсяFirstLSN іLastLSN.
Наведені нижче таблиці визначають ці дані для різних резервних копій.
first_lsn абоFirstLSN
Реєстраційний номер транзакції в журналі першого або раннього запису журналу в резервному наборі даних.
Для даних або різницевих резервних копій перший номер LSN визначає ранній запис журналу, необхідний для відновлення з даної резервної копії.
Для резервних копій журналів перший номер LSN визначає перший запис журналу, включений до цієї резервної копії.
last_lsn абоLastLSN
Реєстраційний номер транзакції у журналі запису, що настає за резервним набором даних.
Останній номер LSN означає запис журналу, який слідує за кінцем резервної копії. Для даних та різницевих резервних копій (і резервних копій журналів, що містять операції з неповним протоколюванням), накат повинен проводитися як мінімум до цього номера LSN. В іншому випадку дані, що копіюються під час відновлення, не будуть узгодженими.
Для резервних копій журналів відповідна резервна копія включає записи журналів до LSN, але не включаючи його самого.
LSN номери та резервні копії даних або різницеві резервні копії
Для повних та різницевихрезервних копій дані журналів міжfirst_lsn таlast_lsn включаються до резервної копії. Це дозволяє використовувати цю резервну копію без резервних копій журналів для відновлення доlast_lsn.
Для повних та різницевих резервних копій номерlast_lsn — це сама рання точка відновлення під час використання цієї резервної копії у послідовності відновлення. Якщо потрібна більш рання точка відновлення, потрібно використати більш ранню резервну копію.
При плануванні того, яку резервну копію журналів використовувати для накату після відновлення з резервної копії даних чи резервної копії, зазвичай починають з першої після відповідної резервної копії даних або резервної копії резервної копії журналів. При перевірці властивостей цієї резервної копії виявляється резервна копія журналів, в якій номерfirst_lsn менший або дорівнює номеруlast_lsn з резервної копії даних або різницевої резервної копії, номерlast_lsn якої більше номераlast_lsn із резервної копії даних або різницевої резервної копії журналів.
LSN номери та резервні копії журналів у ланцюжку журналів
Новий ланцюжок журналів починається або з першої повної резервної копії бази даних після її створення або після перемикання з простої моделі відновлення на модель повного відновлення або модель відновлення з неповним протоколюванням. У першій резервній копії журналів у ланцюжку параметрbackupset.begins_log_chain= 1.
Номериfirst_lsn таlast_lsn використовуються для з'єднання резервних копій журналів у послідовність (ланцюжок журналів). Послідовність резервних копій журналів дозволяє накачувати базу даних із останньої резервної копіїданих з різницевою резервною копією або з більш ранньої резервної копії, минаючи відсутні або пошкоджені резервні копії.
У резервних копіях журналів номерfirst_lsn — це номер LSN першого запису журналу в даній резервній копії, і, починаючи з цього запису, резервна копія журналу включає записи журналів до запису з номером LSN, що дорівнюєlast_lsn, але не вмикаючи її. Дві резервні копії журналу є послідовними тоді і тільки тоді, коли номер LSN останнього запису журналу в ранній копії (Backup_A) більше або дорівнює номеру LSN першого запису журналу в наступній резервній копії (Backup_B); тобто Backup_A.last_lsn>= Backup_B.first_lsn. Якщо це не так, то між цими резервними копіями є перепустка.
Сенс зв'язку між цими номерами LSN наступний.
A.last_lsn= B.first_lsn
Якщо A.last_lsn= B.first_lsn, B зазвичай є резервною копією журналів, знятою відразу після A.
Цей зв'язок показано на наступному малюнку. Зверніть увагу, що запис журналу n, що є у резервній копії журналів B, був записаний під номеромlast_lsn у резервній копії журналів A та під номеромfirst_lsn у резервній копії журналів B.
A.last_lsn> B.first_lsn
Якщо A.last_lsn> B.first_lsn, має місце перекриття. Перекриття зазвичай виникає через створення резервної копії журналів лише для копіювання або створення першої резервної копії журналів після відновлення на даний момент. Перекриття може призвести до різних вилок відновлення. Щоб отримати додаткові відомості, див. Шляхи відновлення.
Причини розірваних ланцюжків журналів
У загальному випадку компонент SQL Server Database Engine запобігаєпоява перепусток у послідовності резервних копій журналів, зберігаючи цілісність ланцюжка журналів. Однак адміністратор бази даних може розірвати ланцюжок журналів, змінивши модель відновлення на просту та назад на повну або з неповним протоколюванням.
Накат через зміни моделей відновлення із застосуванням простої моделі відновлення неможливий через розрив ланцюжка журналів. Після перемикання на модель повного відновлення або модель відновлення з неповним протоколюванням необхідно зняти нову основу для резервної копії різниці або набір таких основ. Крім того, можна використовувати різницеві резервні копії для переходу через цю перепустку.