partition table размером 150 гиг

Antipich
Дата: 14.11.2008 15:58:17
В базе будет таблица, размер которой будет в районе 120 гигов(точнее это предположительный максимум). Данные будут чиститься в ней каждый месяц, т.е. это размер с данными за месяц.

Встал вопрос об организации такой таблицы.
Как я думаю, это должна быть partition таблица. Пока я думаю сделать в ней 4 части-бить по дате записей, соответственно 4 части-4 недели в месяце.
Отсюда первый вопрос: может следует селать 31 часть-по дням?

Далее. Если вся эта таблица будет лежать в одном файлен, то забэкапить 150 гигов почти нереально(кассеты с лентой по 40 гигов).
Поэтому tablespace для неё будет состоять из нескольких файлов.
Пока я думаю так: сделать 4 части по 30 гигов. Это нормально или лучше больше?

И ещё. Я вот подумал, может следует сделать 4 tablespace для каждой партиции таблицы?
Но тогда ещё такой вопрос: при создании таблицы указывается для неё tablespace и tablespace для каждой части. Что тогда будет храниться в tablespace самой таблицы?

И ещё момент: получилось так, что место на серваке очень ограниченно. И это размер самой таблицы без индексов по ней :( А ещё будут индексы полям по 4(всего в таблице на данный момент 12 полей). Я так понимаю, что физический размер этих индексов будет тоже не малый(два bitmap индекса и два обычных). Поэтому я думаю, может сделать эту таблицу индекс-организованной для экономии места или лучше не стоит?

И, думаю, последний момент: по таблице периодически(предположительно раз в день) создаются отчеты. Время создания у них не малое(пока нет индексов). Но заливка данных в таблицу осуществляется постоянно(время между двумя разными insert может быть довольно мало)-отсюда и такой размер за месяц. Поэтому не будут ли индексы сильно тормозить процесс заливки в таблицу?

Вообще, я раньше никогда не имел дела с такими здоровыми таблицами, поэтому прошу помощи и наставления на путь истинный, как тут всё организовать :)

Заранее благодарю.
SQL*Plus
Дата: 14.11.2008 16:03:43
Antipich
Вообще, я раньше никогда не имел дела с такими здоровыми таблицами, поэтому прошу помощи и наставления на путь истинный, как тут всё организовать :)
Вообще, если проект серьезный, то лучше всего нанять квалифицированных консультантов,
которые все обследуют, опишут, настроют, дадут рекомендации на будущее и т.п.
Antipich
Дата: 14.11.2008 16:38:04
Проект пока пилотный, поэтому есть шанс учиться на своих ошибках. Просто хочу их совершать всё же поменьше, а не переделывать потом всё полностью :)
sqlplus
Дата: 14.11.2008 16:54:35
Количество секций нужно делать в зависимости от того как типичные запросы будут запрашивать данные. Если в базе будет много запросов по суткам- значит и секционировать посуточно итп.
TS на месяц достаточно одного из нескольких файлов, по 30Gb не больше.

Bitmap-индексы не рекомендуют для таблиц с интенсивным DML, особенно по столбцам, которые часто меняются.

Если объём выбираемых данных запросами больше 3-4% - использовнаие индексов вообще сомнительно.
gotozero
Дата: 14.11.2008 17:06:26
Версия бд?
gotozero
Дата: 14.11.2008 17:11:49
Отталкиваться нужно из соображений :
• Доступность данных
• Упрощение администрирования
• Повышение производительности SELECT и DML

Если данные надо бэкапить не рекомендую делать партицию больше 10Гб!
Типы секционирования:
• по диапазонам ключей (range),
• списку значений ключа (list),
• хеш-секционирование (hash),
• диапазонное секционирование со списочным подсекционированием (range/list) и
• диапазонное секционирование с хеш-подсекционированием (range/hash).
С 11g:
• Ссылочное секционирование
• Интервальное секционирование
• Расширенное составное секционирование
• Секционирование по виртуальным столбцам

Если база не OLTP, преимущественно используется range секционирование с локально-управляемыми индексами!
Antipich
Дата: 14.11.2008 17:12:03
Объём выбираемых данных-это инфа по времени ото дня, до пары недель.

А почему не рекомендуется битмап индексы, из-за тормозов?
Просто ещё есть такой момент, про который я забыл упамянуть:
Периодически в эту таблиу будут пытаться попасть полностью одинаковые записи. В отчёт они попадать не должны.
Поэтому два варианта: делать поверх таблицы вьюху с SELECT DISTINCT-сейчас сделано так и имеем большие тормоза просто при полной выборке из вьюхи, либо пресекать попадание записей в таблицу при вставке. Проверять уникальность можно по 8 полям из 12...
Думаю, что если просто при вставке прошаривать всю таблицу без индексов в поиске совпадающей записи, то это даст неслабые тормоза. При этом и индексы тоже, думаю, тормозить будут...
Поэтому как тут поступить, оставить вьюху и не мучиться?
Antipich
Дата: 14.11.2008 17:16:35
Прошу пращения.
Сейчас уточнил, данные выбираются в основном за час или несколько часов в сутках.
Поэтому как тут секционировать лучше?

База 11i, но, признаться, с её новыми возможнеостями я знаком слабо. В основном работал всегда с 10g.
orawish
Дата: 14.11.2008 18:39:54
Antipich
Прошу пращения.
Сейчас уточнил, данные выбираются в основном за час или несколько часов в сутках.
Поэтому как тут секционировать лучше?

База 11i, но, признаться, с её новыми возможнеостями я знаком слабо. В основном работал всегда с 10g.

на самом деле - ответ на вопрос как бить зависит (в том числе) и от того, на чём вы храните данные. Если это массив - один компот, если несколько отдельных дисков - совсем другой..
Antipich
Дата: 15.11.2008 15:56:40
Данная таблица будет лежать на одном винте(весь винт под неё). Этот винт зеркалируется.