Схема Oracle: отдельная схема с вводом-выводом?

Question

Мы разрабатываем схему базы данных для новой системы на базе Oracle 11gR1.Мы определили основную схему, которая будет иметь около 100 таблиц, к ним будет обращаться из внешнего Java-приложения.

У нас есть требование проверять значения, которые были изменены в почти 50 таблицах, это имеетбыть сделано в каждом ряду.

Это означает, что, возможно, для одной строки в MYSYS.T1 может быть 50 (или больше или даже меньше, но минимум 1) строк в таблице MYSYS_AUDIT.T1_AUD.У нас могут быть старые значения каждой записи в столбце и новые значения, доступные из T1.

. Администратор базы данных дал наблюдение, советуя против этого метода, потому что он сказал, что отдельная схема означает дополнительный ввод-выводза каждую операцию .В основном схема AUDIT будет использоваться только для некоторого анализа и ввода значений (таким образом, SELECT и INSERT).

Правда ли, что "отдельная схема означает дополнительный ввод-вывод"?Я не смог найти оправдания.

Мне кажется логичным, что данные AUDIT не должны быть подделаны, поэтому отдельная схема.

Кроме того, мы разработали отдельную схему для архивирования некоторых таблиц.от MYSYS.Начиная с MYSYS_ARC таблица может быть скопирована на ленты или удалена через достаточное время.

Немного статистики: Несколько таблиц (около 20, 30) в схеме MYSYS могут вырасти примерно до 50 миллионов строк.Мы попросили общее дисковое пространство 4 ТБ.MYSYS_AUDIT схема может иметь в 10 раз больше, чем MYSYS, но мы не будем хранить их более 3 месяцев.Несколько таблиц в MYSYS будут иметь следующие транзакции / мин.

• 100 INSERT в MYSYS, что означает одинаковое количество вставок в MYSYS_AUDIT таблиц.
• 1000 UPDATE в MYSYS таблицах, означающих одинаковое количество вставок в MYSYS_ADIT таблицах.

Вопросы: Учитывая все это, вы можете предложить мне какие-либо улучшения?

1. Отдельная схема влияет на дисковый ввод-вывод?(один дополнительный ввод / вывод для каждой схемы?)
2. Какие-либо общие предложения?

Рисунок:

+-------------------+          +-------------------+
|       MYSYS       |          |     MYSYS_AUDIT   |
|                   |          |                   |
|    1. T1          |          |     1. T1_AUD     |
|    2. T2          |          |     2. T2_AUD     |
|    3. T3          |--------->|     3. T3_AUD     |
|    4. T4          |(SELECT,  |     4. T4_AUD     |
|     .             | INSERT)  |      .            |
|     .             |          |      .            |
|     .             |          |      .            |
|  100. T100        |          |    50. T50_AUD    |
+-------------------+          +-------------------+
        |
        |
        |
        |
        |(INSERT)
        |
        |
        |
        *
+-------------------+
|   MYSYS_ARC       |
|                   |
|    1. T1_ARC      |
|    2. T2_ARC      |
|    3. T3_ARC      |
|    4. T4_ARC      |
|     .             |
|     .             |
|     .             |
|  100. T100_ARC    |
+-------------------+

Кроме этогоУ нас есть еще две схемы с правами только на чтение, но в основном они предназначены для специальных целей, и мы не возражаем против их производительности.

Предложения: Есть несколько предложений.Мы договорились о следующем.

1. Схема для логического разделения.
2. TRIGGER для вставки данных в таблицы AUDIT.
3. Имена таблиц не будут иметь _AUD суффикс.:)
4. Процедура заполнения ARCHIVE таблиц схемы.
5. Разделы на основе интервалов.

Мы анализируем ...

1. Опция диспетчера рабочей области.

Вопрос по-прежнему открыт для дальнейших предложений, прежде чем принимать решение APC или dpbradely.

Answer 1

Наличие отдельной схемы - определенно путь. Помимо всего прочего это означает, что вы можете использовать те же имена таблиц - MYSYS.T1 и MYSYS_AUDIT.T1 - что полезно, если у вас есть таблицы с длинными именами (> 25 символов).

Но главное достоинство отдельной схемы заключается в том, что таблицы аудита могут быть защищены от случайного или вредного вмешательства.

Влияние вставки строк аудита, e, g, из триггера остается независимо от того, кому принадлежат таблицы.

общие рекомендации по оформлению стола

Хорошей идеей будет присвоить контрольным таблицам ту же структуру, что и основной таблице. Поэтому, если у вас есть столбцы метаданных, которые вам нужны для аудита, например номер редакции, включите их в основную таблицу. Кроме того, заполните таблицы аудита новыми значениями, а не старыми. То есть, когда новая запись вставляется в MYSYS.T1, вставьте соответствующую запись в MYSYS_AUDIT.T1; когда существующая запись обновляется до MYSYS.T1, вставьте новую запись в MYSYS_AUDIT.T1. Гораздо проще проверять и составлять отчеты по таблицам аудита, если их последние записи совпадают с текущими в основных таблицах.

использование триггеров

Аудит не должен быть сложным. Все, что нам нужно, это оператор вставки в before insert or update or delete trigger. Они легко генерируются из представления словаря данных USER_TAB_COLUMNS.

Answer 2

Наличие объектов в отдельной схеме не приведет к дополнительному вводу / выводу - возможно, возникло недоразумение, и ваш администратор базы данных хотел сказать, что наличие аудита приведет к дополнительному вводу / выводу, что, конечно, будет верно независимо от того, как вы это реализуете.

Answer 3

Также, если у вас есть деньги, посмотрите на Oracle Total Recall

Answer 4

В дополнение к ответу APC.

Может взглянуть на Workspace Manager , может быть лучше, чем триггеры, так как они могут выйти из строя или отключиться и т. Д.

Answer 5

Посмотрите на разделение диапазона для данных аудита. Возможно, вы захотите отправить данные аудита в менее дорогое хранилище. Разбиение позволяет легко пересылать, например, данные за месяц, на другой сервер. Или удалить записи аутентификации старше месяца.

http://www.orafaq.com/wiki/Interval_partitioning