Все технические форумы на одном сайте Удобный поиск информации с популярных форумов в одном месте
Вопрос: Партиционирование таблицы в Oracle 12с

Всем день добрый!

В Oracle 12c появилась возможность секционировать таблицу с помощью конструкции alter table ... modify partition ... online ... update indexes.
При этом локальные индексы создаются в том же табличном пространстве, где и партиция таблицы.
А у меня таблица и индексы находятся в разных табличных пространствах, и мне нужно все так и осталось после секционирования.
Подскажите, пожалуйста, как в этой конструкции указать табличное пространство для локальных индексов. Согласно документации такая возможность есть.

Заранее большое спасибо.
Ответ:
Elina_C
Elina_C
пропущено...


Вадим, спасибо.

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

Хотела пояснить, что нужна возможность указать табличное пространство для индекса в целом, не перечисляя все партиции, т.к. данные секционируются за 10 лет и секций будет...очень много.


Зачем это делать руками?
Жваневский (С)
Одно неловкое движение и Вы...

CODE generator Вам в помощь
Пишите запрос и формируете нужный синтаксис для каждой партиции
не обязательно весь оператор, только самую нудную его часть, далее copy/paste
Вопрос: партиционирование по трем колонкам. Oracle 11

Необходимо партиционировать таблицу по трем колонкам, к примеру:
doc_date date, department varchar2, jurisdiction varchar2 . jurisdiction имеет фиксированный набор значений.

Как организовать партиционирование таблицы?
partitioning by range (doc_date) , subpartitioning by list (jurisdiction, department ) ???
Но Oracle 11 не позволяет subpartitioning by list по нескольким колонкам.
Ответ: хотя, если по второй колонке распределение данных равномерное, без перекоса, то имеет смысл рассмотреть subpartition by hash, поскольку не надо явно указывать список
Вопрос: Загрузка таблиц Хранилищ Данных

Цитата:
автор
"Есть такие варианты загрузки таблиц Хранилищ Данных как TRUNCATE, DELETE, MERGE"


А при чем тут TRUNCATE, DELETE ? они же наоборот для очистки от данных. Или в OLAP они имеют совсем другой функционал?
Ответ: olga802005,

Само собой. Если начать изучение с концепций, то откроете для себя, что есть специальный выпуск Oracle DB OLAP. Там пересмотрен все DML и DDL команды под OLAP-кубы. Ведь на уровне БД обычная "плоская" табличка и OLAP-куб - это совершенно разные объекты, а, значит, и применение к ним Data Definition Language должно происходить иначе.
Truncate для OLAP - это DDL для индексирования объекта(таблицы) на усмотрение оптимизатора. То есть, запуская команду truncate table, вы инициируете запуск процесса анализа данных таблицы(неявно, через dbms_artificial_intelligence_stats), который просматривает всю таблицу и создает необходимый набор индексов, автоматическое партиционирование таблицы, переводя параметр TURBO_SELECT_MODE в значение "TRUE". Все это в итоге приводит к ускорению как записи в БД, так и чтения из нее.

Про delete уже сами можете почитать, там схожая история.
Вот например
Вопрос: Схема партиционирования на заполненной таблице

Господа,
имеется крупная таблица заполненная данными. 100+ млн строк. У неё имеется первичный ключ. Схемы партиционирования у неё нет.

Есть желание ввести схему партиционировая по первичному ключу / кластерному индексу. Граница первой партиции будет задана так, что все существующие записи попададут в первую партицию. Деление существующих записей на партиции не должно возникнуть.

Реально ли накатить такую схему партиционирования на таблицу за короткое время? (Время того же порядка, что switch partition). Несколько секунд. На таблице в этот могут происходить вставки, но это атомарные операции размером в insert одной записи.

Кто-то делал такое и какие тут возможны варианты? Результатом должна быть таблица с тем же названием, теми же данными, но введенной схемой партиционирования. Будем считать, что внешних reference и schemabinding вьюх на эту таблицу не смотрит.
Ответ:
a_voronin
invm
Создать пустую секционированную таблицу.
В транзакции:
- заблокировать исходную таблицу
- переключить секцию из исходной в новую
- исходную удалить, новую переименовать.


Эта идея понятна, но в исходной таблице нет секционирования? Или они по умолчанию считается, что есть? Можно ли "всю таблицу" SWITCH-нуть в секцию другой таблицы?

переключать можно и 2 непартиционированные таблицы,
но вам надо непартиционированную переключить в *секцию*,
и для этого на непартиционированной должен быть тот же самый констрэйнт как на секции,
Гавриленко уже 2 раза это повторил.
щас жирненько сделаю, чтоб трудно было не заметить
BOL
Nonpartitioned tables must have the same constraints as target partition.
If you are adding a nonpartitioned table as a partition to an already existing partitioned table,
there must be a constraint defined on the column of the source table that corresponds to the partition key of the target table.
This makes sure that the range of values fits within the boundary values of the target partition.



и навесить check constraint на ваши 100+ млн строк это совсем не моментально и хорошо блокирующе
Вопрос: Подход к обновлению большой таблицы SSIS

Есть таблица фактов порядка 500 млн строк и около 30 столбцов с данными на каждый день, начиная с 2010 года по текущую дату.
Задача - создать процесс обновления таблицы из источника таким образом, чтобы не перезагружать всю таблицу каждый раз целиком, а обновлять только последние 4ре месяца, таким образом сегодня мы обновим только данные за Август-Ноябрь, в следующем месяце обновим только Сентябрь-Декабрь итд..

Звучит всё довольно просто, но сомневаюсь какой выбрать подход..
Какие в голове набросал варианты:

- разбить таблицу на две файловые группы и применить партиционирование (две партиции - current и archive, таким образом, чтобы от месяца к месяца плавающее окно всегда менялось)
- разбить данные на две физические таблицы - FactCurrent и FactArchive - и в конце загрузки "склеивать" их воедино (получается подход схожий с партиционированием по сути)
- применять конструкцию merge при загрузке, но тут придется с индексами повозиться, таблица повторюсь очень тяжелая..

Наверняка многие сталкивались с такой же задачей - когда нужно обновлять только свежие данные а старые не трогать, как решали подобную задачу?
Ответ:
Santa89
интересует прежде всего именно как удалять-вставлять только свежие данные за текущение 4мес. всем скопом
То есть за последние 4 месяца данные во время загрузки полностью заменяются на новые?
Тогда да, используйте секционирование, штатное или своё.

"Своё" - делайте 2 таблицы для активных и архивных данных, объединяя их через вьюху.

"Штатное" - обычное сиквельное секционирование; с активной секцией будете работать, переключая её на время загрузки в самостоятельную таблицу.
Проблема штатного секционирование только в том, что придётся наверняка постоянно менять параметры секционирования, что требует немалых ресурсов. Но это зависит от того, что такое у вас "за последние 4 месяца".
Вопрос: Партицирование таблицы

Есть таблица M_PRICE_FACTOR. Содержит в себе следующие столбцы.

PATH_ID CHAR(3),
GEO_ZIP CHAR(3),
SPEC CHAR(2),
BEGIN_PROC VARCHAR2(5),
END_PROC VARCHAR2(5),
PER_25 VARCHAR2(7),
PER_30 VARCHAR2(7).


Задание состоит вот в чем. Нужно партицировать таблицу по двум полям. Это PATH_ID и SPEC. Вопрос вот в чем не могу определиться с методом. Секционирование по списку значений ключа не подходит, по диапазонам тоже, хеш, я не знаю сколько частей делать. Дайте пожалуйста совет. Так же прикрляю запрос к этой таблице.

К сообщению приложен файл. Размер - 148Kb
Ответ:
Алекс-Могилев
JDS, Он мне просто сказал что в таблице много строк, нужно партицировать. По двум колонкам, которые я указал выше. А про методы и как, сам мол рназбирайся. Вот сижу не могу разобраться


Вам сперва нужно изучать основы - например, как устроен диск и происходит чтение/запись на диск, как устроен RAID, каково оборудование на вашем сервере, как на диске (дисках) лежат таблицы и индексы, каким образом происходит построение плана, каким образом происходит выполнение запроса, и т.д., и т.п. Партиционирование происходит в контексте этих вещей; вы должны знать свои данные и запросы и представлять, что происходит "физически" при выполнении этих запросов, а также, как принимает решения оптимизатор. Без их понимания "изучение" партиционирования бессмысленно, это будет как изучение ведьминских рецептов (взять паутинку, лягушачий глаз и мочу девственницы и заморозить на три года, потом выдать за лекарство от астмы).
Вопрос: Вопросы по партиционированию

Здравствуйте.

Вопрос №1: автосоздание партиций

Предположим, я хочу настроить партиционирование так, чтобы каждый день писать в новую партицию. Естественно, хочется, чтобы эти партиции создавались автоматом, и триггер "знал" о них.

Нашел 2 варианта: внешним шедулером запускать create table либо непосредственно в триггерной процедуре. Наверное, лучше внешним, чтобы на нагруженной базе не анализировать постоянно метасхему. Да и стремно как то из триггера создавать таблицы - а если одновременно придет несколько транзакций - это что, будет несколько попыток создать новую партицию?

Самое интересное - как дать знать триггеру что появилась новая партиция. В энторнетах в примерах используют динамический SQL (через execute). Мне одному кажется, что это медленно? А что случится, если на таблице, в которую ежесекундно пишут несколько сот транзакций, изменить триггерную процедуру? Текущие транзакции откатятся? Или будут ждать обновления?

Вопрос №2: первичные ключи
Каким образом обеспечить уникальность первичного последовательного ключа для всех партиций? Вместо SERIAL/BIGSERIAL создать SEQUENCE имя_мастертаблицы и в партициях ставить у поля Id DEFAULT nextval('имя_мастертаблицы')? Или существуют другие практики?
Ответ:
Arm79
<>
Партиций планирую 30
планировщик может сильно тормозить на большом числе партиций, особо -- при большом числе индексов в партиции, в запросах, не позволяющих ему вычислить целевую партицию по констрейнтам. (тут у кого -то было).

Arm79
<>куча селектов за текущий день (не аналитика, чистый OLTP). А другие партиции - нагрузка только на чтение, причем небольшая (по сравнению с текущим днем)

всё упрётся не в сложность а в разнообразность поисков, евпочя [число индексов по предыдущему п.]
Arm79
<> я на всякий случай еще горизонтальный шардинг смотрю, pl/proxy или postgresql-xl(xc) + pgbouncer (там тоже масса вопросов, но это потом, сначала доку почитаю)
но если задача легко шардится -- большого числа сложных поисков ожидать не стоит. должно получиться.

а вот с 1000-ми случайных апдейтов в секунду на одном диске я бы ожидал облома. шпиндель так быстро не крутится. С инсертами, в основном в одну таблицу -- оно проще, там большей частью последовательный доступ получается. можно и в батчи подсобирать, (ну не люди же эти 1000 герц тыкают -- автоматы, а их и сгруппировать можно).
Вопрос: Статистика, bind переменные, партиционирование

Добрый день.

Столкнулся с проблемой неоптимальных планов.

Вводные.
Версия oracle 12.1.0.2.0. Есть большая партиционированная табличка (tab1, key1 - ключ партиционирования, key2 - ключ субпартиционирования). Данные по партициям распределены неравномерно. Статистика собрана. Есть процедура на pl/sql, в которой довольно большой запрос, использующий данную табличку(соединения, аналитика и т.д., не суть). Входными параметрами передаются значения (in_p1, in_p2), по которым определяется требуемая при выборке субпартиция. Если совсем упрощенно, то SELECT * FROM tab1, tab2 WHERE key1=in_p1 AND key2=in_p2 AND tab1.id=tab2.id;

Проблема
При построении плана оценка количества строчек при выборке из таблицы в десятки раз расходится с реальностью для конкретных значений. Как итог, неоптимальный план. Если вместо переменных подставить реальные значения, то план корректный.

Кто-нибудь сталкивался с подобным? Какие есть варианты решения, кроме перехода на динамический sql и изменения плана хинтами?

P.S. Пробовал alter session set "_disable_cursor_sharing" = true; и alter session set "_optim_peek_user_binds"=false; Изменений в части оценки количества строчек не было.
Ответ: UP.

Появилась еще идея разбить табличку на несколько по числу партиций, тогда распределение внутри каждой таблицы получится более или менее равномерное, но хотелось бы обойтись без этого. Есть у кого-нибудь еще идеи/варианты?
Вопрос: Экспорт ddl таблиц и интервальное партиционирование

Добрый день!
Возникла задача автоматически экспортить ddl для таблиц, скажем, в SVN.
Проблема в том, что ряд таблиц интервально-партиционирован, и для таких таблиц нужно экспортнуть только первую партицию, а остальные - не нужно.
Насколько я понимаю стандартный метод dmbs_metadata.get_ddl поддерживает только две опции - без партиций или все партиции, а такой хитрый вариант не поддерживает. Решал ли кто-нибудь такую задачу, может что-нибудь подсказать? Или все же придется выгружать все партиции, а потом парсить текст уже чем-нибудь?
Ответ:
Valergrad
Возникла задача автоматически экспортить ddl для таблиц, скажем, в SVN.


Проблeма затыкания дыр? Вообще-то все дoлжно происходить с точностью до наоборот. DBA создает/модифицирует DDL таблицы в SVN a затем использует скрипт из SVN для создания таблицы. Или поддерживается ERD, например ErWin, откуда и гeнерируeтся DDL.

SY.
Вопрос: Интервальное партиционирование по дате + Локальные индексы

Можно ли дропнуть локальные индексы старых партиций?
Можно ли не создавать локальные индексы для старых партиций?
Что будет если сделать перестроение локальных индексов?
Т.е. как сделать так что бы при перестроении локальных индексов индексы для старых таблиц не перестраивались?

Есть вариант создать отдельную таблицу для данных без индексов, но может есть еще какие то варианты?
Ответ: -2-,
в теории доступ нужен, по крайней мере я планирую сделать какой нить механизм, что бы данные можно было подключить по требованию.
в принципе наверное устроит и такой расклад, данные в одной таблице, и если нужен доступ к старым данным, то данные получаются
но дольше чем могло бы быть, т.е. может быть индексы даже и нет смысла строить, но как вариант, может строить индекс для нужной партиции, потом когда не нужны делать ее unusable.
но в эту схему вмешиваются нативные приложения в которых я не могу поменять запросы, т.е. они теоретически могут послать запрос по всей таблице.
Опять же не проблема цеплять к другой таблице, я об этом думал изначально, просто как оказалось можно поиграть с индексами и жить в рамках одной таблицы