Firebird Dataguard - это инструмент, созданный компанией Ibsurgeon для мониторинга и обслуживания баз данных Firebird, который помогает администраторам предотвращать и решать проблемы с производительностью и целостностью данных. Он предлагает такие функции, как автоматизированное наблюдение за состоянием сервера, предупреждения о потенциальных проблемах и возможность восстановления данных в случае серьезных сбоев оборудования. Firebird Dataguard включает в себя множество функций, таких как валидация метаданных, управление резервным копированием и защита от поломок, что делает его важным инструментом для администраторов баз данных.

1. FIREBIRD
DATAGUARD
Еще раз об уверенности в завтрашнем дне

2. О чем пойдёт речь
 Почему IBSurgeon создал FBDataGuard?
 Что делает FBDataGuard (примеры сценариев)
 Основные функции FBDataGuard
 Контакты и как попробовать FBDataGuard

3. Почему IBSurgeon
создал
FBDataGuard?

4. Неважно, какого цвета Ваш сервер
В любом случае – это
«черный ящик».
Вы не знаете, что же в действительности
происходит с Вашими данными – это факт.
Сомневаетесь?

5. Давайте об этом поговорим?

6. Итак, утро Вашего админа может начинаться так:

7. Или так:

8. Но в любом случае
администратору
надо кое-что проверить.

9. Хватает ли
База вообще Индексы не
места для
работает? поломались?
базы?
Ошибки в Хватает ли
Бэкап
firebird.log места для
прошел?
есть? бэкапа?
А Статистика
Не застряли
проверочный индексов
транзакции?
рестор? пересчитана?

10. Без сомнения, Ваш администратор
именно так и делает…

11. …особенно если у Вас
много серверов, …

12. …расположенных в
удаленных офисах.

13. Вы, наверное, не поверите…
но в некоторых
компаниях всё
действительно так и есть.

14. Но этого недостаточно
Во-первых, админы спят. Во-вторых, все ошибаются.
И в-третьих, базовых проверок недостаточно.

15. Откуда мы все это знаем?
Самые умные,
да?

16. 8 лет мы чиним поломанные базы данных
…и хорошо
знаем, ЧТО и КАК
ломается.

17. Вот почему мы создали Firebird DataGuard
 Наблюдение за базой
 Предупреждения и советы
 Автоматизация обслуживания баз данных
 Гарантия восстановления в сложных случаях
РАНЬШЕ БОРОЛИСЬ С ПОСЛЕДСТВИЯМИ,
ПОРА ВЗЯТЬСЯ ЗА ПРИЧИНЫ.

18. Что делает
FBDataGuard
(примеры)

19. Типичная рабочая среда Firebird
Это рабочий сервер
Это база данных
Firebird Здесь хранится
еще одна
копия бэкапов
Это бэкапы

20. Рассмотрим сервер в деталях
Сервер доступен?
Рабочие
параметры Сколько RAM?
Временные
# Mb
файлы?
Логи Записи в логах? 6 уровней
проблем
Размер логов?
Версия Рекомендуемая Баги,
сервера версия? проблемы

21. Сервер Firebird
7 параметров, 1. Доступность сервера
2. Размер RAM сервера
которые могут 3. Количество временных
сообщать о файлов
проблемах с базой 4. Размер временных
файлов
данных и 5. Записи в логе
сервером 6. Размер логов
7. Версия сервера

22. Пример разрешения проблемы с
сервером
FBDataGuard
определил, что
размер файлов
Места
сортировки = N
может не
хватить!
Размер
M – N<X
свободного места
на диске с TEMP-
файлами = M

23. Ретроспективный анализ
 Все логи хранятся на
сервере и позволяют
анализировать
события,
происшедшие в
прошлом
 Инструментарий для
удобного просмотра
логов

24. Рассмотрим базу данных Firebird
Обычно базу данных изображают так:
База данных
как будто это что-то совсем простое.

25. Профессионалы видят «много
деревьев», а не «лес».

26. Файловая организация БД
delta
- Основной файл БД
0-level
- Файлы томов БД
- Файлы delta
(nbackup) и incremental
Файл база
данных backups
Том 1
- Внешние таблицы
Том N

27. Внутренняя организация БД
Задачи:
Метаданные  Проверить физическую
целостность данных,
индексов и метаданных
Данные таблиц
 Проверить логическую
целостность
Индексы  Проверить активность
метаданных (статус
триггеров, check,
Блобы
хранимых процедур)

28. FBDataGuard бдит за базой данных:
 Наблюдает за файлами, томами, дельта-
файлами и инкрементальными backups
 Верифицирует метаданные, данные и индексы
 Следит за ограничениями
 ВЫДАЕТ ПРЕДУПРЕЖДЕНИЯ и РЕКОМЕНДАЦИИ

29. Пример разрешения проблемы с
базой данных Firebird
FBDataGuard non-activated
определил, что индексы могут
после restore указывать на
индекс не повреждения БД,
активирован SQL запросы могут
«тормозить» Предотвращена
потеря
производитель
ности!

30. Катастрофические поломки
Серверы (как любые
сложные устройства) –
ЛОМАЮТСЯ.

31. Что может сломаться в железе?
Наиболее  Жесткий диск (HDD)
 Flash-накопители
опасны для базы  Память (RAM)
данных  Контроллеры
следующие SCSCI/SATA и другие
подобные устройства
поломки:

32. Типичные проявления поломок
«железа»:
 Жесткий диск:
 Потерянные и смешанные страницы (wrong page type)
 Ошибки в цепочках записей (Cannot find record fragment)
 Память:
 Ошибки на уровне записей (Wrong record length)
 Flash-накопители и Контроллеры
 Сдвиги страниц (база не открывается в isql)
 Ошибки страниц и ошибки в записей

33. Как FBDataGuard защищает от
поломок железа?
 Во-первых, верификация данных и индексов
(выборка данных, пересчет статистики индексов)
 Позволяет предупредить о появлении ошибки
 Во-вторых – ЗАЩИТНЫЙ РЕПОЗИТОРИЙ
МЕТАДАННЫХ
 Позволяет спасти данные даже в случае очень тяжелых
повреждений

34. Защитный репозиторий метаданных
Метаданные
Копия в репозитории
Данные таблиц
FBDataGuard сохраняет
Индексы копию актуальных
метаданных в отдельном
Блобы от БД репозитории

35. В случае поломки железа:
Метаданные в FBDataGuard
репозитории Extractor
извлекает все
доступные
данные из БД и Новая БД
Данные таблиц
вставляет в
новую БД
Блобы

36. Последний рубеж защиты
 FBDataGuard спасет оставшиеся данные
в случае потери метаданных
 Данные из поврежденного delta-файла
 В случае поломки жесткого диска, контроллера или
flash-накопителя
 Вытащит данные даже из «обрывка» БД
Но лучше не доводить ситуацию до крайности, не так ли?

37. Резервное копирование
 Мало кто осознает насколько верен простой
факт:
Резервное копирование –
наиболее надежный способ
защиты данных

38. Формально у Firebird два способа
резервного копирования…
 Gbak  Nbackup
 последовательное  Сохранение«слепка»
чтение данных с базы данных с
сохранением в перенесением
линейном формате изменений через
delta-файл

39. …но на самом деле есть только один.
 Резервное копирование – не вызов gbak –b и
nbackup, это ПЛАН ДЕЙСТВИЙ
 Онможет включать в себя вызовы gbak, nbackup, а
также другие технические и организационные
процедуры

40. Правильный gbak
 Правильный набор опций при бэкапе ускоряет
резервное копирование в несколько раз
 Бэкапы должны проверяться на корректность путем
тестового восстановления
 Существование файлов бэкапов должно
контролироваться (резервное копирование в /dev/null
– не шутка, а горькая правда жизни)
 Должна сохраняться история бэкапов с револьверной
заменой резервных копий

41. Правильный nbackup
 Контроль за delta-файлом
 Размер delta-файла
 Время жизни delta-файла
 Контроль целостности копии базы данных
 Последовательный gbak с проверкой
 Слежение за окружением копии (второй
компьютер?)

42. План резервного копирования
(простой вариант)
База данных Копия Тестовый
Firebird nbackup Gbak -b рестор
И на каждом этапе – контроль результатов выполнения.

43. Пример разрешения аварийной
ситуации с бэкапами
FBDataGuard
вычислил (или взял
последнее значение)
размера бэкапа M Места
может не
хватить!
FBDataGuard M>=N
обнаружил, что
Предотвращена
свободное место на поломка backup
диске для бэкапов = N и потеря данных!

44. Firebird DataGuard
 Наблюдение за 26 важными параметрами базы данных
и сервера
 Предупреждения о потенциальных и реальных
проблемах по email
 Правильная автоматизация обслуживания баз данных
 Возможность встраиваться в существующие
приложения
 Windows, Linux, MacOS, Firebird 1.5-2.1
 FBDataGuard включает сервисы ремонта и
оптимизации базы данных (в зависимости от лицензии)

45. Основные
функции
FBDataGuard

46. 3 группы функций FBDataGuard
Мониторинг Обслуживание
Защита

47. Мониторинг-1
 Ошибки сервера и базы данных
 Доступность сервера и базы данных
 Анализ firebird.log (изменения)
 Периодический опрос метаданных
 Транзакции
 Отслеживание разницы между 4 маркерами
 Лимит транзакций (2млрд. транзакций до бэкап-рестора)
 Пользователи
 Минимальное/максимальное количество пользователей

48. Мониторинг-2
 Файлы базы данных
 Однофайловые и многофайловые
 Расположение – предупреждения о путях и пересечении с
местом хранения бэкапов
 Размеры и отслеживаемые пределы роста (задаются
пользователем)
 Файлы delta (nbackup)
 Время жизни и размер delta-файлов
 Файлы бэкапов
 Наличие, размер и прогноз роста

49. Мониторинг-3
 Временные файлы Firebird
 Общий размер и количество
 Количество форматов на таблицу
 Не более 255 (лимит реализации)
 В production-базе данных нежелательно
 Наличие неактивных и неактивированных индексов в
базе данных
 Неактивные – явно отключены
 Неактивированные – не включились в результате сбоя рестора

50. Мониторинг-4
 Автоматизированный сбор статистики gstat
 Задается cron-выражением
 Версия сервера Firebird, размер папки сервера
 Размер логов сервера
 Размер логов FBDataGuard
 Логи изменений всех параметров хранятся для анализа
 Автоудаление логов – по умолчанию хранятся 60 дней
 Автообноовление
 – предупреждение о выходе новых версий

51. Обслуживание-1
 Бэкапы
 Револьверные (сдвигающиеся по времени) бэкапы
 Настраиваемая глубина хранения бэкапов
 Тестовый рестор с анализом результатов
 Прогноз роста (при недостатке места бэкап не
происходит, статус БД ->критический)
 Контроль времени операции бэкапа (по умолчанию
Max time =120 min)
 Опциональное сжатие небольших бэкапов (до 4Гб)

52. Обслуживание-2
 Индексы
 Пересчет статистики индексов
 Всех (не рекомендуется для баз более 1Гб)
 Выбранных (список индексов)
 Всех, кроме исключенных
 Проверка статусов индексов
 Проверка «здоровья»
 - алерт в случае обнаружения поврежденных индексов
 По умолчанию джоб отключен

53. Обслуживание-3
 Валидация БД с помощью стандартных средств (Gfix)
 Перевод базы в shutdown – работа в выделенном режиме
 Анализ результатов (в т.ч. вывода в firebird.log)
 Валидация метаданных
 Проверка ключевых системных таблиц
 Лог Firebird
 Перенос частей лога в отдельные файлы по достижению
установленного размера

54. Обслуживание-4
 Для серьёзных конфигураций баз данных необходимы:
 Регламент обслуживания
 План аварийного восстановления
 FBDataGuard помогает решить много технических
проблем, значительно расширяя возможности
администратора
 Алерты и рекомендации
 FBDataGuard сообщает о найденных или ожидающихся
проблемах, выдает рекомендации
 Устанавливает статус базе данных и серверу в целом

55. Защита
 Защитный репозиторий метаданных
 Сохранение копии «сырых» метаданных, необходимых для
расшифровки
 Дополнительная проверка метаданных
 Расшифровка критически поврежденных файлов БД (в
т.ч. при сбоях HDD и другого железа)
 Экспорта данных из поврежденных delta-файлов
 Восстановление удаленных данных (в том числе DROP
TABLE) (только версия Enterprise)

56. Попробуйте FBDataGuard прямо
сейчас:
 Онлайн-форум по FBDataGuard
 http://groups.google.ru/group/ibsurgeon2?hl=ru
 Скачать FBDataGuard
 http://groups.google.ru/group/ibsurgeon2/browse_thread/thread/56962586ffd33aa4?hl=ru
 Мы будем рады ответить на все Ваши вопросы.
 dataguard@ib-aid.com, +7 495 953 13 34