Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Oracle |
![]() ![]() |
Landgraf Member Откуда: Сообщений: 274 |
Ребята всем привет! Нужен ваш совет. Есть таблица размером в 800 Гб. Она партицирована по полю dDate (тип дата). Нужно удалить все записи у которых dDate < 01.01.17. Учитывая размер таблицы, оператор delete будет работать очень долго. Думал над таким вариантом: Create table MyTable_tmp as select * from MyTable where dDate >= 01.01.17; Truncate table MyTable; Insert into mytable Select * from mytable_p Но при таком варианте пропадает партицирование. Как бы сделать так, чтобы партицирование не слетели по оставшимся записям? |
7 фев 19, 20:07 [21803836] Ответить | Цитировать Сообщить модератору |
-2- Member Откуда: Сообщений: 14350 |
|
||
7 фев 19, 20:10 [21803838] Ответить | Цитировать Сообщить модератору |
Landgraf Member Откуда: Сообщений: 274 |
На сколько мне известно, на основании этого поля строятся отчёты. Поле хранит дату загрузки данных. Т.е. за каждый день присутствует N записей. Таблица была сделана до меня, поэтому почему ее партиционировали.... Для скорости наверное :) |
||||
7 фев 19, 20:17 [21803842] Ответить | Цитировать Сообщить модератору |
jan2ary Member Откуда: Киев Сообщений: 1715 |
Landgraf, Транкейтить партиции? |
7 фев 19, 21:23 [21803881] Ответить | Цитировать Сообщить модератору |
andrey_anonymous Member Откуда: Москва Сообщений: 17095 |
Помолясь и запасясь бэкапом...
|
|
8 фев 19, 00:32 [21803935] Ответить | Цитировать Сообщить модератору |
Landgraf Member Откуда: Сообщений: 274 |
Ребята всем спасибо за ответы. В итоге сделал так: Отобрал все необходимые партиций, сделал altet table truncate partition, а потом alter table drop partition. После того, как удалил данные, теперь нужно уменьшить таблицу, скорректировать уровень HWM. Я так понимаю можно сделать либо: alter table shrink space Либо alter table move Во втором варианте нужно будет ещё индексы перестроить и пересобрать статистику. Какой вариант предпочтительней? Таблица весит около 400Гб, партицирована. В оракловой доке написано, что shrink ужимает неиспользуемое пространство с низу и с верху HWM. |
11 фев 19, 16:33 [21806622] Ответить | Цитировать Сообщить модератору |
Elic Member Откуда: 1984. Выбраковка финно-угром продолжается. КЯЗ Сообщений: 28679 |
|
||
11 фев 19, 16:48 [21806639] Ответить | Цитировать Сообщить модератору |
Landgraf Member Откуда: Сообщений: 274 |
Да, есть такое. |
||||
11 фев 19, 16:53 [21806648] Ответить | Цитировать Сообщить модератору |
SY Member Откуда: Middlebury, CT USA Сообщений: 9340 |
andrey_anonymous, drop partition update indexes не уменьшит число листьев индекса да и увеличит время выборки по глобальным индексам. UPDATE != REBUILD. SY. |
11 фев 19, 17:15 [21806677] Ответить | Цитировать Сообщить модератору |
кит северных морей Member Откуда: Красноярск Сообщений: 533 |
|
||
11 фев 19, 17:38 [21806711] Ответить | Цитировать Сообщить модератору |
andrey_anonymous Member Откуда: Москва Сообщений: 17095 |
Не уменьшит - в сравнении с ЧЕМ? |
||
11 фев 19, 18:14 [21806764] Ответить | Цитировать Сообщить модератору |
SY Member Откуда: Middlebury, CT USA Сообщений: 9340 |
C rebuild. SY. |
||
11 фев 19, 18:16 [21806768] Ответить | Цитировать Сообщить модератору |
andrey_anonymous Member Откуда: Москва Сообщений: 17095 |
В сравнении с rebuild глобального индекса по крупной таблице некоторое падение производительности и последующая подчистка orphanned ночным джобиком - сущая ерунда с точки зрения доступности системы. |
||
11 фев 19, 19:05 [21806812] Ответить | Цитировать Сообщить модератору |
SY Member Откуда: Middlebury, CT USA Сообщений: 9340 |
В смысле ночным index rebuild? Хорошо когда не 24x7 - у меня удаление soft deleted index keys получаетя только когда release. Проверить насколько дополнительный предикат проверки на orphaned влияет на производительность все руки не доходят. SY. |
||
11 фев 19, 20:08 [21806836] Ответить | Цитировать Сообщить модератору |
andrey_anonymous Member Откуда: Москва Сообщений: 17095 |
DBMS_PART.CLEANUP_GIDX |
||||
12 фев 19, 14:35 [21807430] Ответить | Цитировать Сообщить модератору |
Fogel Member Откуда: Сообщений: 334 |
Коллеги, вы сильно усложняете всё.
Будьте проще. 1. смОтрите скрипт создания вашей оригинальной таблицы (со всеми индексами, констрэйнтами и т.д.). Копируете его целиком. (заменяете названия индексов и констрэйнтов, дописывая 1 в конце) 2. Вместо create table MyTable (col1, col2, ... colN) tablespace <какое-то tb> PARTITION BY RANGE (dDate) ... и там потом индексы и прочие констрэйнты с комментариями -- пишете create table MyTable_NEW -- выкидываете весь блок столбцов здесь tablespace <какое-то tb> PARTITION BY RANGE (dDate) INTERVAL(NUMTOYMINTERVAL(1, 'DAY')) ( PARTITION p0 VALUES LESS THAN (TO_DATE('01-01-2017', 'DD-MM-YYYY')), PARTITION p1 VALUES LESS THAN (TO_DATE('01-02-2017', 'DD-MM-YYYY')) ) ENABLE ROW MOVEMENT as select перечисление всех колонок, а не звёздочка from MyTable where dDate >= date '2017-01-01'; ... и там потом индексы и прочие констрэйнты с комментариями 3. собираете статистику begin dbms_stats.gather_table_stats(ownname => <схема где таблица>, tabname => 'MYTABLE_NEW', granularity => 'ALL', force => TRUE); end; 4. Переименовываете таблички alter table MYTABLE rename to MYTABLE_OLD; alter table MYTABLE_NEW rename to MYTABLE; 4.1 можете сверить данные в табличках всякими интерсектами и минусами для спокойствия души. 5.Дропаете старую таблицу с высвобождением места drop table MYTABLE_OLD purge; 6. переименовываете все те индексы и констрэйнты, которым добавили 1 в пункте 1, обратно в оригинальные названия. ALTER INDEX index1 RENAME TO oldnameindex; как-то так. без лишней головной боли, с сохранением партиций и прочей структуры таблицы, корректным высвобождением места (без "хвостов" от шринкования ) и т. д., и т. п. ... |
||
13 фев 19, 01:01 [21807931] Ответить | Цитировать Сообщить модератору |
кит северных морей Member Откуда: Красноярск Сообщений: 533 |
как говорила моя не по годам мудрая соседка по парте классе в шестом, "просто даже мухи не еб-ся". ![]() 2e12 |
||
13 фев 19, 06:56 [21807968] Ответить | Цитировать Сообщить модератору |
flexgen Member Откуда: Город на песке Сообщений: 676 |
Ты не упомянул о следующих шагах: 1. Не забыть дать все необходимые права на созданные заново таблицы поскольку при переименовании объекта теряются и права на него. 2. Проверить не стали ли объекты, каким-либо образом использующие пересоздаваемые таблицы, инвалидными и, соответственно, перекомпилировать эти объекты. 3. Не забыть про foreign key constraints в других таблицах, завязанные на пересоздаваемые таблицы. 4. И главное - без downtime, пусть даже минимального, все равно не обойтись. |
||
13 фев 19, 21:50 [21808962] Ответить | Цитировать Сообщить модератору |
Все форумы / Oracle | ![]() |