Конфигурирование сервера Oracle для сверхбольших баз данных
Планирование табличных пространств
При преобразовании логической модели данных в физическую, Вам требуется сделать долгосрочные решения о том, как Вы поделите сегменты базы данных между табличными пространствами. Следующие ограничения определяют то, как Вы должны распределить сегменты по табличным пространствам:
- Производительность операций ввода/вывода
— каждое табличное пространство должно включать сегменты, имеющие схожие характеристики ввода/вывода (уровень параллелизма, объем) — такое разбиение упростит выбор размера сегмента чередования и емкости дискового массива. Объединение сегментов, используемых только для чтения, в табличное пространство только для чтения, снижает объем передаваемых данных при резервном копировании и восстановлении, а также снижает издержки на PCMблокировки. Разделение сегментов, в которые часто осуществляется запись, от сегментов с низкой интенсивностью записи придает больше гибкости при конструировании процедуры «горячего» резервного копирования.
- Устойчивость к отказам — малые табличные пространства позволяют минимизировать простой приложения во время работ, требующих перевода этих табличных пространств в автономный режим (offline). Табличное пространство system не может быть переведено в автономный режим, также как не может быть удалено и пересоздано, поэтому храните минимально необходимое число сегментов в этом табличном пространстве. Изоляция сегментов отката в минимально необходимом числе табличных пространств снижает частоту возникновения простоев, поскольку табличное пространство с активным (online) сегментом отката невозможно перевести в автономный режим. Хранение связанных, с помощью ссылочной целостности, сегментов в небольшой группе табличных пространств даст Вам возможность использовать процедуру восстановления на заданный момент времени («point-in-time), введенную в Oracle8.
- Управление пространством — изоляция сегментов с коротким временным жизненным циклом минимизирует влияние фрагментации свободного табличного пространства, которая может блокировать выделение новых экстентов сервером Oracle. Администраторам VLDB принесет пользу возможность использования умалчиваемых параметров хранения, определенных на уровне табличного пространства, вместо явного указания этих параметров в описании сегментов.
- Управление квотами — управление квотами пространства в сервере Oracle выполняется на уровне пользователей и табличных пространств. Поэтому размещайте сегменты одной схемы в небольшом числе табличных пространств.
Рис. 3. Ожидания занятого процесса архивирования. Рисунок демонстрирует, каким образом быстрый LGWR-процесс может обогнать медленный ARCH-процесс, что приведет к возникновению «узкого места» и к снижению производительности. Эпизод (a) демонстрирует состояние инстанции сразу после старта — процесс LGWR пишет в файл A, процесс ARCH ничего не делает. В эпизоде (b) LGWR переключился на запись в файл B, позволяя ARCH открыть A и начать его архивирование. В (c) LGWR переключился на файл C, в то время как ARCH еще не обработал A. В эпизоде (d) ARCH переключился на обработку файла B, в (e) LGWR пишет в файл A. В эпизоде (f) LGWR пытается переключиться на файл B, но не может выполнить этого, поскольку ARCH еще не сделал его архивную копию. Начиная с этого момента, из-за ARCH, системой будут блокироваться попытки фиксации транзакции до тех пор, пока ARCH не переключиться на файл C.
