ДОСТУПНОСТЬ ДАННЫХ В СЛУЧАЕ СБОЯ ОБОРУДОВАНИЯ. Защита данных от сбоев оборудования достигается через комбинацию журналирования транзакций и периодическое обновление дисковой версии базы данных «в памяти». Журнальные записи сбрасываются на диск в асинхронном или синхронном режиме по окончании транзакции и контролируются приложением на транзакционном уровне.
Для систем, в которых главную роль играет максимальная производительность, таких как оперативная обработка транзакций, асинхронное журналирование позволяет достигать высоких скоростей обработки данных при минимальной незащищённости. В случаях, когда первостепенной задачей является защищённость данных, резидентные в оперативной памяти базы данных могут обеспечить полную сохранность данных, хотя это сильно влияет на производительность и требует дополнительной настройки.
Транзакционное журналирование используется в следующих случаях:  восстановление завершённых транзакций в случае сбоя приложения или базы данных;  откат транзакций;  репликация изменений в другую базу данных;  репликация изменений в резидентной в оперативной памяти базе данных в таблицу дисковой базы (в случае её использования в качестве кэша СУБД);  позволяет приложению определять изменения в таблице.
Так же есть операция, называемая контрольной точкой. Этот процесс является фоновым и имеет слабое воздействие на операции в базе данных (в случае асинхронных контрольных точек). Контрольные точки выполняются автоматически, их периодичность зависит от предварительно установленных атрибутов используемых хранилищ данных. Для сохранности файлов данных на диске в случае сбоя, произошедшего во время выполнения контрольной точки, их создаётся несколько (обычно 2). Эти файлы обновляются по очереди и должны быть расположены на отдельных дисках от тех, на которых хранятся журнальные файлы с целью уменьшения конкуренции ввода/вывода. Ещё одним способом обеспечить целостность данных в случае сбоя оборудования является репликация.
Репликация – это процесс копирования данных между базами данных. Её главной задачей является обеспечить высокую доступность данных в критических к потерям приложениях с минимальным ухудшением производительности.
Кроме того, репликация также полезна для распределения нагрузки по нескольким экземплярам базы данных для увеличения производительности общей системы, а также для облегчения модернизации и сопровождения баз данных. Рис. 4. Репликация встроенной базы данных. Для достижения наилучшей производительности используется схема репликации, основанная на транзакционных записях. Репликация на основном и дополнительном экземпляре контролируется репликационным агентом, который оперирует по протоколу TCP/IP. Репликационный агент на основном сервере читает записи из транзакционного журнала. Он направляет эти изменения своему второму элементу на дополнительном сервере.
Далее репликационный агент на дополнительном сервере делает обновление в дополнительной базе данных. Если агент подписчика не готов принять записи, направленные ему с основного сервера, агент мастера сохраняет не переданные записи в своём журнале до тех пор, пока они не будут применены на дополнительном сервере.
В описанном ранее сценарии использования встроенных баз данных используется репликация в конфигурации “зеркальная копия”. Основная база данных повторяется дополнительной с соответствующим механизмом доступности, встроенном в приложение. Рис. 5. Репликация в конфигурации «зеркальная копия».