Создание контрольных точек (checkpointing)(2)
Контрольная точка может выполняться в двух режимах: быстрая контрольная точка и нормальная контрольная точка. В режиме нормальной контрольной точки процесс DBWR просто записывает немного больше грязных буферов в каждый момент своей активности. В этом режиме контрольная точка выполняется гораздо дольше, но затрагивает меньше системных ресурсов, чем быстрая. В режиме быстрой контрольной точки DBWR записывает сразу большое число буферов в каждый момент своей работы. Такая контрольная точка выполняется очень быстро и более эффективна в смысле работы ввода/вывода. Но, в тоже время, значительно снижает производительность системы.
Частое выполнение контрольных точек способствует снижению затрат времени, необходимого на восстановление системы в случае сбоя. Контрольная точка автоматически выполняется при смене журнала операций
Журналирование и архивирование
Журнал операций (redo log) записывает все изменения БД Oracle. Целью использования журнала операций является экстренное восстановление БД в некоторых случаях сбоев системы и потери файлов данных. Восстановив файлы данных из ранее сделанных резервных копий, файлы журнала операций (включая архивные файлы журнала) могут повторить все последние транзакции. Таким образом, файлы данных будут полностью восстановлены.
Журналирование и архивирование(2)
Когда файл журнала операций (или группа файлов) оказывается полностью заполненным, происходит смена журнала и процесс LGWR переключается на следующую группу файлов журналирования операций. В этот момент осуществляется контрольная точка, а после смены журнала процесс ARCH копирует заполненный файл в архив файлов журналирования. Как только архивирование закончилось, файл журнала операций помечается как доступный. Очень важно, чтобы архивные файлы журнала операций надежно хранились, так как они могут понадобиться для восстановления системы.
Производительность ORACLE
В первую очередь на производительность Oracle влияет архитектура аппаратных средств. Но существует также ряд других факторов. Например, дизайн пользовательского приложения может затронуть эффективность и скорость работы больше, чем все остальные факторы.
В большинстве случаев причиной небольшой производительности системы является именно приложение, в котором либо неоптимизированные SQL-запросы, либо не используются индексы. Хороший же дизайн приложения способен творить чудеса производительности. Приложение - это первое место, куда нужно обратить внимание, если у Вас возникают проблемы с производительностью.
Производительность
ORACLE(2)
Если Вы создадите таблицу, в которой некоторые столбцы проиндексированы, но эти столбцы не используются в предложении WHERE, то индексы никогда не будут использованы. Создавать правильные и красивые индексы недостаточно, Вы должны быть уверены в том, что они будут использованы.
Желательно создать спецификацию идентификации таблиц и индексов в Вашей БД. В этом случае разработчики ПО и команда, разрабатывающая таблицы, будут иметь исчерпывающее руководство. Это поможет избежать многих проблем, а также даст возможность полноценного использования индексов.
Производительность
ORACLE(3)
Задачи, связанные с обработкой большого количества транзакций в реальном времени или с доступом к большим хранилищам данных, неизменно приводят к высокой конкуренции пользователей за обладание ресурсами. Поэтому решение проблемы управления доступом пользователей к ресурсам может существенно повысить эффективность работы системы. Oracle предоставляет возможности управления выделением пользователю системных ресурсов и назначением приоритета пользователям - им может быть присвоен класс ресурсов, а затем каждому классу назначен соответствующий процент ресурсов системы.
Параллельный сервер ORACLE
Параллельный сервер Oracle позволяет разделить доступ к базе данных между разными серверными процессами (Oracle instance), причем каждый из процессов может обрабатывать конкурирующие транзакции. Различные серверные процессы, работающие с одной и той же базой данных, могут быть запущены на разных машинах, формируя тем самым
отдельный кластер. Это резко повышает надежность работы системы, поскольку параллельный сервер Oracle в состоянии отловить аварийную ситуацию, произошедшую с одной
из машин кластера, практически мгновенно, после чего база данных продолжает оставаться доступной через серверный процесс, запущенный на другой машине.
Репликация данных
Репликация - это процесс копирования и поддержания объектов БД на множестве серверов, составляющих распределенную информационную систему. Изменения, производимые на одном сервере системы, затем передаются на удаленные серверы. Репликации позволяют пользователю получить быстрый доступ к разделяемой информации и организовать синхронизацию данных.
Репликация данных(2)
Репликации в среде Oracle могут происходить по двум схемам: мастер-мастер и мастер-snapshot. В первом случае два или несколько серверов БД
функционируют как равные части единой системы. При такой конфигурации клиентские приложения могут изменять данные на любом из серверов - серверы БД Oracle автоматически синхронизируют данные во всех объектах репликаций, гарантируя при этом глобальную целостность данных и поддержку конкурирующих транзакций.
Репликация данных(3)
Схема мастер-snapshot предусматривает частичное или полное копирование объектов репликации с одного сервера БД на другой. При этом полученная копия представляет собой "мгновенный снимок" (snapshot) данных, содержащихся в объектах БД, подлежащих реплицированию. Такие "мгновенные снимки" могут иметь статус "только для чтения" или быть обновляемыми. Обновляемые snapshots позволяют клиенту возвращать изменения в реплицируемые объекты на мастер- сервере.