Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Универсальное решение по партицированию таблицы  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
RA\/EN
У человека REDO проблемы вызывает, где ты там углядел "пустой maxvalue-раздел"? Или ты предполагаешь, что есть желание нарезать данные на две группы: один кусок "то что было но", и второй "светлое будущее"?

Да, именно так.
Делаем таблицу из трех секций - "старые данные", "актуальные данные", "maxvalue".
Существующая таблица обменивается с секцией "старые данные".
DML начинает жить в секции "актуальные данные", постепенно уходя все дальше от "старых", новые секции режутся из maxvalue.
В один прекрасный момент раздел "старые данные" дропается по причине полной потери актуальности.
Почему это работает: потому что сегодня система как-то живет, следовательно размер существующей таблицы не перевалил за грань добра и зла.
Именно так переводятся на partitioned некоторые решения известных производителей ;)
13 июл 10, 22:54    [9098750]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
RA\/EN
Member

Откуда:
Сообщений: 3658
andrey_anonymous
RA\/EN
У человека REDO проблемы вызывает, где ты там углядел "пустой maxvalue-раздел"? Или ты предполагаешь, что есть желание нарезать данные на две группы: один кусок "то что было но", и второй "светлое будущее"?

Да, именно так.
Делаем таблицу из трех секций - "старые данные", "актуальные данные", "maxvalue".
Существующая таблица обменивается с секцией "старые данные".
DML начинает жить в секции "актуальные данные", постепенно уходя все дальше от "старых", новые секции режутся из maxvalue.
В один прекрасный момент раздел "старые данные" дропается по причине полной потери актуальности.
Почему это работает: потому что сегодня система как-то живет, следовательно размер существующей таблицы не перевалил за грань добра и зла.
Именно так переводятся на partitioned некоторые решения известных производителей ;)

Твое предположение несколько консервативно: решение по рефакторингу приниматеся не только для случая "что-то кажется. через полгода совсем ляжем", но и для случая "повысить время отклика сейчас". Второе больше похоже на исходящие от заказчика. Можно найти некий баланс, но все же тащить на хребте гигантскую партицию, которая проэкспайрится тогда, когда проэкспайрится самая свежая в ней запись.... Это, например, узнать, что механизм удаления мусора "не работает" не сейчас, а через несколько лет
Я, все же, за получение видимого профита.
Можно, конечно, нарезать старые данные в сторонке потихоньку, а потом всю нарезку заэксченжить, и, вполне возможно, это доступно делать в течении нескольких дней, если гарантируется неизменность нарезаемого.
13 июл 10, 23:12    [9098815]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
RA\/EN
Member

Откуда:
Сообщений: 3658
andrey_anonymous
Почему это работает: потому что сегодня система как-то живет, следовательно размер существующей таблицы не перевалил за грань добра и зла.

Кстати о добре и зле - тебе не кажется, что с случае появления в планах вместо имени партиции трех буковок "K","E" и "Y" могут начаться чудеса, и грань добра и зла внезапно окажется перейденной очень сильно? Я бы ожидал западла, аналогичного разбалансированным индексам без гистограмм (а он не панацея в случае разбаланса колонки со ссылкой на суррогатный ID, например).
13 июл 10, 23:18    [9098838]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
RA\/EN
могут начаться чудеса

:)
Либо приложение готово к partitioning либо не готово.
Во втором случае разговор ни о чем, в первом - все будет ОК.
13 июл 10, 23:45    [9098930]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
RA\/EN
Member

Откуда:
Сообщений: 3658
andrey_anonymous
RA\/EN
могут начаться чудеса

:)
Либо приложение готово к partitioning либо не готово.
Во втором случае разговор ни о чем, в первом - все будет ОК.

К сожалению, нет Oracle под руками, и 2 недели не будет - фокусы показать не смогу. В общем, в методике "частично партиционированной таблицы" вижу технологические риски. Представляется внедорожник, которому только на заднюю ось колеса поставили от трактора (задние же). Вроде, и плюсы есть, и на трактор теперь похоже, и задним ходом проходимость лучше стала, но чего-то не хвататет
Но всегда есть компромиссное решение - долгими зимними вечерами грызть толстый партишен сплитами, по сплиту за вечер...
14 июл 10, 00:37    [9099110]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
ahtolllka
Member

Откуда:
Сообщений: 95
andrey_anonymous
RA\/EN
У человека REDO проблемы вызывает, где ты там углядел "пустой maxvalue-раздел"? Или ты предполагаешь, что есть желание нарезать данные на две группы: один кусок "то что было но", и второй "светлое будущее"?

Да, именно так.
Делаем таблицу из трех секций - "старые данные", "актуальные данные", "maxvalue".
Существующая таблица обменивается с секцией "старые данные".
DML начинает жить в секции "актуальные данные", постепенно уходя все дальше от "старых", новые секции режутся из maxvalue.
В один прекрасный момент раздел "старые данные" дропается по причине полной потери актуальности.
Почему это работает: потому что сегодня система как-то живет, следовательно размер существующей таблицы не перевалил за грань добра и зла.
Именно так переводятся на partitioned некоторые решения известных производителей ;)

Прошу прощения, что вмешиваюсь в ваш увлекательный спор, но я нигде не говорил, что у меня partition by range. =)
Несмотря на то, что вопрос общий, задача над которой я работаю подразумевает list partitioning без такого понятия как "устаревающие данные" (скажем, иерархически организованная БД бюро кредитных историй).
14 июл 10, 09:28    [9099752]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
ahtolllka
задача над которой я работаю подразумевает list partitioning без такого понятия как "устаревающие данные"

Тогда просто создать целевую таблицу и заполнить в append nologgind, после чего сделать backup.
14 июл 10, 10:14    [9100063]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
ahtolllka
Member

Откуда:
Сообщений: 95
andrey_anonymous,

... и это сожрёт места еще больше, чем эта таблица уже занимает в данный момент...

Не знаю, я, возможно, не вижу весь спектр проблем, но в моём видении они таковы:
1. Нехватка места. Грубо говоря, табличка весит 2 килограмма, а в распоряжении есть лишних 0.5 килограмма.
2. Много внешних ссылок на партицируемый объект, что исключает какие либо ручные действия.
3. Маленькое окно (даже на выходных) для наката изменений.

Не думал, что выбор схемы секционирования в данном случае должен кардинально менять подход...
14 июл 10, 10:43    [9100309]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
ahtolllka

... и это сожрёт места еще больше, чем эта таблица уже занимает в данный момент...

Совсем не факт, скорее наоборот - капельку поменьше.
Но в любом случае - сравнимо с исходным объектом.

ahtolllka
Не знаю, я, возможно, не вижу весь спектр проблем, но в моём видении они таковы:
1. Нехватка места. Грубо говоря, табличка весит 2 килограмма, а в распоряжении есть лишних 0.5 килограмма.

В Вашем сценарии место придется изыскать.

ahtolllka

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

Однако должен.
14 июл 10, 10:52    [9100414]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
ahtolllka
Member

Откуда:
Сообщений: 95
andrey_anonymous
ahtolllka

... и это сожрёт места еще больше, чем эта таблица уже занимает в данный момент...

Совсем не факт, скорее наоборот - капельку поменьше.
Но в любом случае - сравнимо с исходным объектом.

ahtolllka
Не знаю, я, возможно, не вижу весь спектр проблем, но в моём видении они таковы:
1. Нехватка места. Грубо говоря, табличка весит 2 килограмма, а в распоряжении есть лишних 0.5 килограмма.

В Вашем сценарии место придется изыскать.

ahtolllka

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

Однако должен.

Возможно мои сведения не соответствуют действительности, но я предполагал, что append ускоряет вставку именно за счёт неоптимального использования дискового пространства.

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

Я так понимаю, что в общем случае:

exchange + split будет есть redo/undo,
dbms_redefinition будет есть как рабочее место, так и redo/undo, зато избавит от геморроя с констрейнтами
insert --+append nologging будет жрать только рабочее место
?
14 июл 10, 11:02    [9100547]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
RA\/EN
Member

Откуда:
Сообщений: 3658
ahtolllka
Я так понимаю, что в общем случае:

exchange + split будет есть redo/undo,
dbms_redefinition будет есть как рабочее место, так и redo/undo, зато избавит от геморроя с констрейнтами
insert --+append nologging будет жрать только рабочее место
?

Что-то мне подсказывает, что при exchange + split скушается ровно столько места, сколько пи insert+append, потому как оригинальный кусок данных нельзя будет уменьшить до тех пор, пока из него не будет вынесены ВСЕ данные. Поищите что такое HWM у таблицы.
Кстати, в качестве эксперимента, сделайте таблицу с двумя записями в одной партиции, а потом сделайте ей сплит, и посмотрите, как изменились ROWID у записей. Уж не изменятся ли оба ROWID?
14 июл 10, 11:22    [9100741]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
sapzvezda
Member

Откуда:
Сообщений: 291
Если по дате партицировать, то может Oracle ILM?
14 июл 10, 11:23    [9100757]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
Splain
Member

Откуда: Череповец
Сообщений: 924
RA\/EN

Что-то мне подсказывает, что при exchange + split скушается ровно столько места, сколько пи insert+append, потому как оригинальный кусок данных нельзя будет уменьшить до тех пор, пока из него не будет вынесены ВСЕ данные. Поищите что такое HWM у таблицы.
Кстати, в качестве эксперимента, сделайте таблицу с двумя записями в одной партиции, а потом сделайте ей сплит, и посмотрите, как изменились ROWID у записей. Уж не изменятся ли оба ROWID?


При split оба куска изменяются совместно с локальными индексами.
14 июл 10, 11:41    [9100948]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
ahtolllka
Member

Откуда:
Сообщений: 95
RA\/EN
ahtolllka
Я так понимаю, что в общем случае:

exchange + split будет есть redo/undo,
dbms_redefinition будет есть как рабочее место, так и redo/undo, зато избавит от геморроя с констрейнтами
insert --+append nologging будет жрать только рабочее место
?

Что-то мне подсказывает, что при exchange + split скушается ровно столько места, сколько пи insert+append, потому как оригинальный кусок данных нельзя будет уменьшить до тех пор, пока из него не будет вынесены ВСЕ данные. Поищите что такое HWM у таблицы.
Кстати, в качестве эксперимента, сделайте таблицу с двумя записями в одной партиции, а потом сделайте ей сплит, и посмотрите, как изменились ROWID у записей. Уж не изменятся ли оба ROWID?


Признаюсь, не знаю как точно работает exchange partition, но судя по тому, что написано в хелпе, сами данные не двигаются вообще:

Oracle manual
You can convert a partition (or subpartition) into a nonpartitioned table, and a nonpartitioned table into a partition (or subpartition) of a partitioned table by exchanging their data segments.
When you specify WITHOUT VALIDATION for the exchange partition operation, this is normally a fast operation because it involves only data dictionary updates.


Таким образом рабочее место не должно есться в принципе, а последующий сплит, так как партиций будет много, не будет есть много редо. Ну а ребилды и валидация не должны съедать много места, только время. Я не прав?
14 июл 10, 11:42    [9100954]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
Splain
Member

Откуда: Череповец
Сообщений: 924
andrey_anonymous

Либо приложение готово к partitioning либо не готово.
Во втором случае разговор ни о чем, в первом - все будет ОК.


Готово - это одно. Другое - появляется глобальная статистика, изменяется способ расчета стоимости. Соответственно планы могут меняться, в некоторых случаях в худшую сторону. Это тоже нужно учитывать.
14 июл 10, 11:45    [9100995]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
Splain
появляется глобальная статистика

Глобальная - это хорошо. Хуже когда при rolling window на свежей секции собирается локальная.
Но вместо того чтобы подобно Косте понапрасну пугать ТС плодами болезненной фантазии - лучше бы показали "что по чем".
14 июл 10, 11:50    [9101055]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
RA\/EN
Member

Откуда:
Сообщений: 3658
andrey_anonymous
Splain
появляется глобальная статистика
.
Но вместо того чтобы подобно Косте понапрасну пугать ТС плодами болезненной фантазии - лучше бы показали "что по чем".
По безоружным стреляешь? ;)
14 июл 10, 12:05    [9101181]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
RA\/EN
andrey_anonymous
Splain
появляется глобальная статистика
.
Но вместо того чтобы подобно Косте понапрасну пугать ТС плодами болезненной фантазии - лучше бы показали "что по чем".
По безоружным стреляешь? ;)

Что бы делаешь без оружия на поле брани?
...apex.oracle.com или как там его - вроде никто не отменял?
14 июл 10, 12:10    [9101203]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
Splain
Member

Откуда: Череповец
Сообщений: 924
ahtolllka

Таким образом рабочее место не должно есться в принципе, а последующий сплит, так как партиций будет много, не будет есть много редо. Ну а ребилды и валидация не должны съедать много места, только время. Я не прав?


Только что делал split. Около 2 Гб данных, столько же локальных индексов, скушало 10,5 Гб redo. Там правда rebuild новых секций индексов был дополнительный, но все равно - нагрузка весьма существенна.
14 июл 10, 12:15    [9101218]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
Splain
Member

Откуда: Череповец
Сообщений: 924
andrey_anonymous
Splain
появляется глобальная статистика

Глобальная - это хорошо. Хуже когда при rolling window на свежей секции собирается локальная.
Но вместо того чтобы подобно Косте понапрасну пугать ТС плодами болезненной фантазии - лучше бы показали "что по чем".


Тут уже Льюис успел отметиться :)

Если серьезно, то нужен пример, на котором показать можно было бы. Что за система у ТС непонятно совершенно, а свою примеры еще придумать нужно.
14 июл 10, 12:36    [9101361]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
ahtolllka
Member

Откуда:
Сообщений: 95
Splain
ahtolllka

Таким образом рабочее место не должно есться в принципе, а последующий сплит, так как партиций будет много, не будет есть много редо. Ну а ребилды и валидация не должны съедать много места, только время. Я не прав?


Только что делал split. Около 2 Гб данных, столько же локальных индексов, скушало 10,5 Гб redo. Там правда rebuild новых секций индексов был дополнительный, но все равно - нагрузка весьма существенна.

Ну так загвоздка-то не в сплите. Split совершенно разный может быть. В моём случае я собираюсь сплитовать таблицу на партиции по 0.17% (+ 2% максимальная партиция) от общего объёма таблицы, и большой redo не планируется.
14 июл 10, 14:48    [9102749]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
ahtolllka
Member

Откуда:
Сообщений: 95
Столкнулся с проблемой на самом последнем этапе, когда накатываю записанные в clob'ы DDL-ки:

Для начала, триггер в clob посредством функции dbms_metadata.get_ddl пишется вместе с увловием инициализации:

  CREATE OR REPLACE TRIGGER "my_schema"."TRG_my_table" 

    before delete or insert or update on my_table
    for each row
    begin
      dbms_output.put_line('test');
    end;

ALTER TRIGGER "my_schema"."TRG_my_table" ENABLE

В результате, при попытке выполнить эти две команды вместе, вторая пишется в тело триггера и он становится инвалидным.

Во-вторых при выполнении DDL комментов, выдранных в clob к таблице запросом:
 select dbms_metadata.get_dependent_ddl('COMMENT','my_table', 'my_schema') from dual;
не проставляется ";", из-за чего экзекут падает, если на таблице больше одного коммента.

С этим есть какие-нибудь стандартные способы борьбы, без тупого парсинга?
14 июл 10, 17:42    [9104906]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
ahtolllka
С этим есть какие-нибудь стандартные способы борьбы, без тупого парсинга?

Нет.
Зато есть стандартные парсеры - sql*plus, например.
14 июл 10, 19:17    [9105466]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
ahtolllka
Member

Откуда:
Сообщений: 95
ahtolllka
Splain
ahtolllka

Таким образом рабочее место не должно есться в принципе, а последующий сплит, так как партиций будет много, не будет есть много редо. Ну а ребилды и валидация не должны съедать много места, только время. Я не прав?


Только что делал split. Около 2 Гб данных, столько же локальных индексов, скушало 10,5 Гб redo. Там правда rebuild новых секций индексов был дополнительный, но все равно - нагрузка весьма существенна.

Ну так загвоздка-то не в сплите. Split совершенно разный может быть. В моём случае я собираюсь сплитовать таблицу на партиции по 0.17% (+ 2% максимальная партиция) от общего объёма таблицы, и большой redo не планируется.


Я здесь написал фактически неправду. При split'е вместо старой партиции создаётся две новые и данные исходной перегоняются в них, таким образом, если в таблице одна партиция, то первый сплит в любом случае съест редо = объёму всей таблицы, и чем больше первый сплит - тем, в результате, выгодна.

Опыт - сын ошибок трудных.
22 июл 10, 17:48    [9146126]     Ответить | Цитировать Сообщить модератору
 Re: Универсальное решение по партицированию таблицы  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 8127
ahtolllka
чем больше первый сплит - тем, в результате, выгодна.
Об этом подробнее, пожалуйста - мысль уловить не удалось...
22 июл 10, 18:01    [9146257]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Oracle Ответить