Комментарии по теме

«Ре­ко­ме­нда­ции по обе­спе­че­нию бе­зо­па­сно­сти и контроля SAP HANA»
Дмитрий Буслов:
(1) Автор начинает с того, что HANA — это СУБД, позволяющая хранить записи в колонках и работающая в оперативной памяти. Я бы, хотел сделать акцент на том, что HANA — не просто СУБД,...
«Различие между двумя текущими версиями HANA»
Олег Точенюк:
Спасибо конечно... я вот не понимаю как консалт выживает в этом мире, когда есть такой чудесный традиционный сайт help.sap.com/ :-)
«Ма­сте­р-кла­сс по архи­те­кту­ре SAP HANA 2.0. День 1»
Вячеслав Шиболов:
Добрый день, Влад.   У меня опыта разворачивания SAP HANA достаточного для ответа в данной ситуации нет. Но вариант с акселератором, конечно, в плане реализации гораздо проще, чем полная...

База знаний

Резервное копирование в SAP HANA

561

Оглавление

Введение

Реализация изменений в базе данных SAP HANA

Операция Savepoint

Моментальные снимки (Snapshots)

Резервное копирование

Заключение

Введение

Проведение регулярного резервного копирования является важнейшей частью работы администратора любой базы данных, и SAP HANA тут не исключение. Однако подходы к формированию стратегии резервного копирования могут различаться, и причиной тому не только внутренние регламенты компании, но концепции резервного копирования, которые закладывают разработчики той или иной СУБД.

В этой статье я не буду рассказывать про типы операций резервного копирования, возможности планирования, настройки параметров и наличие инструментов для создания резервных копий, про это уже очень много сказано в различных статьях, руководствах по администрированию и т.д. В статье я бы хотел подробнее остановиться на тех процессах, которые происходят внутри базы данных при вызове операции резервного копирования.  

Реализация изменений в базе данных SAP HANA

Несмотря на то, что в базе данных SAP HANA воплощена концепция in-memory, она использует жесткие диски для сохранения информации. В процессе эксплуатации базы данных измененные данные автоматически сохраняются из оперативной памяти на диск с помощью регулярной операции savepoint. Помимо самих измененных данных на диск записывается информация о транзакциях, которые произвели те или иные изменения. Информация о них хранится в redo log buffer (специальная область памяти), запись изменений на диск инициируется вызовом команды commit или при заполнении пространства в буфере redo лога, администраторам СУБД Oracle все это покажется очень знакомым. Процедура записи изменений на диск изображена на рис. 1.

Рис. 1 – Схема сохранения измененных данных и логов операций на диск

Информация из redo логов необходима для восстановления базы данных на определенный момент времени. Теперь, давайте немного подробнее остановимся на операции savepoint.

Операция Savepoint

Savepoint – асинхронный фоновый процесс. Каждый сервис SAP HANA имеет свой собственный процесс savepoint. Операция savepoint синхронизирует изменения в памяти с дисками на т.н. persistence уровне. SAP HANA persistence отвечает за мэппинг данных между памятью и дисками.

 Все измененные страницы из областей памяти ROW и COLUMN store, записываются на диск в процессе операции savepoint. Операция savepoint вызывается следующими событиями:

  • По умолчанию вызывается каждые 300 секунд (значение может быть изменено параметром global.ini -> [persistence] -> savepoint_interval_s.
  • Вызывается каждый раз при остановке базы данных. Это существенно сокращает время запуска БД.
  • В процессе запуска, после того как БД перейдет в консистентное состояние.
  • Вызывается перед запуском процедуры резервного копирования.
  • Может быть вызвана администратором (ALTER SYSTEM SAVEPOINT).

Информацию о операциях savepoint можно получить из представлений M_SAVEPOINTS и M_SAVEPOINT_STATISTICS.

Операция Savepoint делится на 3 фазы:

Фаза 1

В процессе выполнения фазы 1 база данных записывает все измененные страницы на диск. При этом база данных остается открытой на изменение. Все изменения страниц, произошедшие в течении выполнения этой фазы, попадут в текущую операцию savepoint.

Фаза 2 (CRITICAL_PHASE)

Вторая фаза гарантирует, что точка сохранения относится к уникальному состоянию базы данных. Это состояние определятся одной, конкретной позицией в журнале, таким образом, во время перезапуска базы данных обработка журналов транзакций начнется с правильной позиции в журнале. В процессе выполнения этой фазы, устанавливается блокировка на изменения. Блокировка гарантирует, что в процессе выполнения фазы 2 никаких изменений в базе данных не произойдет, транзакции не смогут быть запущены или завершены. После этого, база данных записывает текущую позицию лога, как позицию лога savepoint в файл данных, вместе со списком открытых транзакций. В процессе удержания блокировки, база данных определяет список страниц, которые были изменены в процессе выполнения фазы 1. Запись этих измененных страниц выполняется асинхронным процессом ввода/вывода. Как только асинхронный процесс запустится, блокировка на изменение будет снята и база данных возобновит обработку транзакции на изменение. Информацию по работе фазы 2 можно получить из представления M_SAVEPOINTS и M_SAVEPOINT_STATISTICS.

Фаза 3.                

    В процессе выполнения этой фазы все страницы, изменённые в фазе 1, будут записаны на диск. Транзакции, выполняющие изменение данных, снова доступны, но вновь измененные данные уже не будут являться частью этой операции savepoint.

Моментальные снимки (Snapshots)

Перед тем, как приступить к описанию непосредственно процедуры резервного копирования, немного поговорим об основе, а именно, о моментальных снимках, как важнейшей части любой операции резервного копирования.

Моментальный

Ограниченный доступ

Для прочтения полной версии статьи необходимо зайти как зарегистрированный пользователь.


Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП»