Фрагмент для ознакомления
2
Логическая резервная копия содержит логические данные, которые извлекаются из базы данных. Это включает в себя резервное копирование логических данных, таких как представления, процедуры, функции, таблицы и т.д. Во многих случаях это полезное дополнение к физическим резервным копиям, но недостаточное защита от потери данных без физического резервного копирования, поскольку логическое резервное копирование предоставляет только структурную информацию.
Планирование и тестирование резервного копирования помогает предотвратить сбой носителя, операционной системы, программного обеспечения и любые другие сбои, которые приводят к серьезному сбою данных. Это определяет скорость и успех восстановления.
Физическое резервное копирование извлекает данные из физического хранилища (обычно с диска на магнитную ленту). Примером физического резервного копирования является операционная система.
Логическая резервная копия извлекает данные с помощью SQL из базы данных и сохраняет их в двоичном файле.[1]
Логическая резервная копия используется для восстановления объектов базы данных в базу данных. Таким образом, логическая утилиты резервного копирования позволяют администратору базы данных создавать резервные копии и восстанавливать выбранные объекты в базе данных.
Существуют различные методы резервного копирования в базе данных:
• Полное резервное копирование - Этот метод занимает много времени, поскольку создается полная копия базы данных, включая данные и записи транзакций.
• Журнал транзакций - В этом методе в качестве резервной копии сохраняются только журналы транзакций. Чтобы размер файла резервной копии был как можно меньше, предыдущие сведения журнала транзакций удаляются при создании новой резервной записи.
• Дифференциальное резервное копирование - Это похоже на полное резервное копирование в том смысле, что в нем хранятся как данные, так и записи транзакций. Однако в резервной копии сохраняется только та информация, которая изменилась с момента последнего полного резервного копирования.
Из-за этого дифференциальное резервное копирование приводит к уменьшению размера файлов.
Может быть несколько причин сбоя в базе данных, из-за которых требуется план резервного копирования и восстановления базы данных. Вот некоторые из этих причин:
• База данных включает в себя огромное количество данных и транзакций.
• Если система выходит из строя или происходит сбой, восстановить базу данных очень сложно.
Для восстановления базы данных в основном используются два метода:
• Восстановление на основе журналов - В режиме восстановления на основе журналов журналы всех транзакций базы данных хранятся в защищенной области, чтобы в случае сбоя системы база данных могла восстановить данные. Вся информация журнала, такая как время транзакции, ее данные и т.д., должна быть сохранена до выполнения транзакции.
• Теневой пейджинг - При теневом пейджинге после завершения транзакции ее данные автоматически сохраняются для сохранности. Таким образом, если система выйдет из строя в середине транзакции, внесенные ею изменения не будут отражены в базе данных.
Журналы - это последовательность записей, которые поддерживают записи действий, выполняемых транзакцией.
При восстановлении на основе журналов журнал каждой транзакции сохраняется в некотором стабильном хранилище. Если произойдет какой-либо сбой, его можно будет восстановить оттуда, чтобы восстановить базу данных.[2]
Журнал содержит информацию о выполняемой транзакции, значениях, которые были изменены, и состоянии транзакции. Вся эта информация будет храниться в порядке выполнения. Пример:
Предположим, транзакция для изменения адреса сотрудника. Для этой транзакции записываются следующие журналы,
Журнал 1: транзакция инициирована, записывается в журнал 'START'.
Журнал: <Tn НАЧАЛО>
Журнал 2: транзакция изменяет адрес с "Пуна" на "мумбаи".
Журнал регистрации: <Tn Адрес, 'Пуна', 'Мумбаи'>
Журнал 3: транзакция завершена. В журнале указано завершение транзакции.
Журнал: <Tn ФИКСАЦИИ>
Существует два метода создания файлов журналов и обновления базы данных,
При отложенной модификации базы данных, все журналы транзакций создаются и сохраняются в стабильной системе хранения. В приведенном выше примере создаются три записи журнала и сохраняются в некоторой системе хранения, база данных будет обновлена с помощью этих шагов.
При немедленной модификации базы данных, после создания каждой записи журнала, база данных немедленно изменяется для каждого шага записи журнала. В приведенном выше примере база данных изменяется на каждом этапе ввода журнала, что означает, что после первой записи в журнале транзакция попадет в базу данных для извлечения записи, затем будет введен второй журнал с последующим обновлением адреса сотрудника, затем в третьем журнале с последующим внесением изменений в базу данных.
Ограничения целостности - это набор правил. Он используется для поддержания качества информации. Ограничения целостности гарантируют, что вставка, обновление и другие процессы имеют должно выполняться таким образом, чтобы не нарушалась целостность данных.[3]
Таким образом, ограничение целостности используется для защиты от случайного повреждения базы данных.
Фрагмент для ознакомления
3
1. Бирн Microsoft SQL Server 6.5. Руководство администратора / Бирн, Джеффри. - М.: ЛОРИ, 1998. - 211 c.
2. Б. Ларсон Microsoft SQL Server 2005 Reporting Services. Профессиональная работа с отчетами / Б. Ларсон. - М.: НТ Пресс, 2008. - 608 c.
3. SQL Server 2005 шаг за шагом. Практическое руководство. - М.: Эком, 2007. - 463 c.
4. И. Горбач Microsoft SQL Server 2005 Analysis Services. OLAP и многомерный анализ данных / И. Горбач, А. Бергер. - М.: БХВ-Петербург, 2007. - 928 c.
5. Ларсон Microsoft SQL Server 2005 Reporting Services. Традиционные и интерактивные отчеты. Создание, редактирование, управление / Ларсон, Брайан. - М.: НТ Пресс, 2008. - 608 c.
6. Р.Дж. Яргер MySQL и mSQL: Базы данных для небольших предприятий и Интернета / Р.Дж. Яргер, Дж. Риз, Т. Кинг. - М.: СПб: Символ-Плюс, 2000. - 560 c.
7. Шнайдер Microsoft SQL Server 6.5. Проектирование высокопроизводительных баз данных / Шнайдер, Роберт. - М.: ЛОРИ, 1998. - 361 c.