Как нужно распределять данные?
Для выяснения, что лучше: создать меньше томов с тонкими и широкими
или больше томов с относительно толстыми и узкими полосами страйпинга, не-
обходимо провести почти научное исследование. Этот выбор зависит от таких
вопросов, как секционированы ли таблицы и/или индексы, нужна ли для основ-
ных операций поддержка параллелизма и наличие либо отсутствие сервисных
соглашений об обеспечении высокой или частичной готовности. В то время как
широкие и узкие страйпинга могут быть интересными с точки зрения
или больше томов с относительно толстыми и узкими полосами страйпинга, не-
обходимо провести почти научное исследование. Этот выбор зависит от таких
вопросов, как секционированы ли таблицы и/или индексы, нужна ли для основ-
ных операций поддержка параллелизма и наличие либо отсутствие сервисных
соглашений об обеспечении высокой или частичной готовности. В то время как
широкие и узкие страйпинга могут быть интересными с точки зрения
простоты администрирования, факторы типа включения ограниченного параллелизма, ограниченной готовности и менее чем идеальной поддержки секционирования данных/индексов делают их не столь привлекательным. Наша цель лежит где-го посередине между тонкими и широкими и толстыми и узкими полосами страйпинга.
Многие администраторы баз данных выяснили, что они заблуждались отно-
сительно своих онлайновых и архивированных журналов обновлений. Если ба-
за данных работает в режиме NOARCHIVELOG, может быть, для хранения
журналов обновлений достаточно одного тома RAID 1. Однако для баз данных,
находящихся в режиме ARCHIVELOG, необходимо дальнейшее отделение
групп журналов обновлений друг от друга и от архивированных журналов. Для
эффективного размещения используется три тома RAID На этих томах не дол-
жно размещаться никаких других наборов данных. Именно в этом месте некото-
рые администраторы начинают ощущать дискомфорт. Если система похожа на
большинство остальных, она использует диски емкостью 9 или 18 Гбайт. Итак,
два из них применяются для хранения одного тома, но так как они являются зер-
кальными по отношению друг к другу, мы все еще имеем емкость одного тома.
Поэтому для того чтобы получить три тома по 9 Гбайт, придется использовать
шесть дисков по 9 Гбайт. Один из томов задействуется для хранения архивиро-
ванных журналов, чтобы можно было иметь хотя бы несколько из них в онлай-
новом режиме. Остаются два тома и на каждом из них хранится всего по
нескольку онлайновых журналов. И так как онлайновые журналы могут быть до-
статочно малы, скажем, от 250 Мбайт до 1 Гбайта, на диске остается большое ко-
личество неиспользуемого пространства.
томах другие активные компоненты базы данных Oracle способен только моги-
льщик производительности. Можно, однако, использовать это пространство
для хранения экспортируемых файлов других административных эле-
сительно своих онлайновых и архивированных журналов обновлений. Если ба-
за данных работает в режиме NOARCHIVELOG, может быть, для хранения
журналов обновлений достаточно одного тома RAID 1. Однако для баз данных,
находящихся в режиме ARCHIVELOG, необходимо дальнейшее отделение
групп журналов обновлений друг от друга и от архивированных журналов. Для
эффективного размещения используется три тома RAID На этих томах не дол-
жно размещаться никаких других наборов данных. Именно в этом месте некото-
рые администраторы начинают ощущать дискомфорт. Если система похожа на
большинство остальных, она использует диски емкостью 9 или 18 Гбайт. Итак,
два из них применяются для хранения одного тома, но так как они являются зер-
кальными по отношению друг к другу, мы все еще имеем емкость одного тома.
Поэтому для того чтобы получить три тома по 9 Гбайт, придется использовать
шесть дисков по 9 Гбайт. Один из томов задействуется для хранения архивиро-
ванных журналов, чтобы можно было иметь хотя бы несколько из них в онлай-
новом режиме. Остаются два тома и на каждом из них хранится всего по
нескольку онлайновых журналов. И так как онлайновые журналы могут быть до-
статочно малы, скажем, от 250 Мбайт до 1 Гбайта, на диске остается большое ко-
личество неиспользуемого пространства.
Забудьпи о нем.
Размещать на этихтомах другие активные компоненты базы данных Oracle способен только моги-
льщик производительности. Можно, однако, использовать это пространство
для хранения экспортируемых файлов других административных эле-
ментов, которые не взаимодействуют с базой данных Oracle.
Табличное пространство SYSTEM физически разместимо на любом томе и в
большинстве случаев разделяет физический том с табличными пространствами
TEMP и RBS. Дело в том, что конкуренция между этими компонентами базы данных обычно сведена к минимуму. Для уменьшения ввода/вывода в табличном
пространстве SYSTEM крайне важно оптимально настроить параметры инициализации SHARED_POOL_SIZEh DB BLOCK BUFFERS.
| < Предыдущая | Следующая > |
|---|
