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

Откуда:
Сообщений: 4
Привет, эксперты!
Я в Оракле делаю только первые шаги, поэтому очень нуждаюсь в вашем мудром совете. Хочу задать вам вопрос про “партиционирование”, а точнее – про его разумное использование и имеющиеся ограничения.

Преамбула.
Есть некая БД, большая, размером в несколько Тб. Часть таблиц (15 штук) секционирована по операционному дню. Политика хранения данных такова, что данные в таблицах хранятся строго 3 месяца, и где-то раз в 7 дней 7 партиций за наиболее старые даты архивируется и выводится из эксплуатации.

Фабула.
Такой сложившийся порядок долгое время всех устраивал. И все бы ничего, но однажды задумал разработчик изменить схему партиционирования “по опер.дню” на партиционирование по другому атрибуту: у всех записей всех таблиц имеется атрибут, позволяющий в рамках одного опер.дня дополнительно разделять данные на ~3.000 независимых фрагментов. Т.е. если раньше для каждой из 15 вышеуказанных таблиц создавалось по 1 новой партиции в день, то теперь планируется создавать по ~3.000 новых партиций в день. Эти изменения в схеме партиционирования стали следствием изменений в “политике хранения и архивации данных”. Теперь нельзя стало выводить из эксплуатации старые опер.дни тупо целиком. Часть данных этих опер.дней может оставаться в схеме еще какое-то (неопределенное) время. Теперь планируется архивировать данные “кусочками”, опираясь на новый ключ секционирования (создающий теперь в рамках одного опер.дня по 3000 партиций на таблицу).
Таким образом, не считая остальных таблиц схемы (коих итак немало) только эти 15 дадут за 3 месяца:

15 таблиц * 90 дней * 3.000 партиций в день  =  4.050.000 партиций

Вопрос:
Я тут пообщался с коллегами с параллельного проекта (поимевшими на своем проекте проблемы из-за большого количества партиций) и выяснил для себя такую вещь, цитирую их слова: "При достижении рубежа примерно в миллион партиций на схему Оракл начал... медленно умирать". Перевожу: запросы, пэкаджи и пр. стали выполняться значительно дольше по времени. Коллеги объяснили это так:
  • сильно возрасли накладные расходы на поддержку словаря данных;
  • сбор статистики стал выполняться значительно дольше; иногда статистика по каким-то причинам вообще не собиралась;
  • большое количество запросов постоянно перекомпилировалось (т.е. планы запросов постоянно вытеснялись из кэша)
    Так вот возникают у меня вопросы:
  • Согласны ли вы, уважаемые Гуры, с тем, что очень большое количество партиций способно негативно отразиться на производительности Оракла?
  • Если да, то есть ли какие-либо рекомендации по снижению негативных последствий такого экстремального партиционирования?
  • Если же по-вашему мнению надежных средств борьбы с отрицательными последствиями нет, то какое разумное ограничение (по количеству партиций на схему) вы можете порекомендовать?

    P.S.
    Если по неопытности я тут что-то не то понаписал, сильно не пинайте – все когда-то начинали.
  • 29 мар 10, 19:38    [8550254]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    suPPLer
    Member

    Откуда: Харків, Україна
    Сообщений: 7794
    Блог
    йош
    15 таблиц * 90 дней * 3.000 партиций в день  =  4.050.000 партиций

    http://download.oracle.com/docs/cd/E11882_01/server.112/e10820/limits003.htm
    Oracle® Database Reference
    11g Release 2 (11.2)
    ...
    ItemType of LimitLimit Value
    .........
    PartitionsMaximum number of partitions allowed per table or index1024K - 1
    .........


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


  • RTFM Oracle 11g Database New Features.
    29 мар 10, 20:07    [8550309]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    Двоюшник
    Member

    Откуда: Киев
    Сообщений: 1135
    Субпартиции Вам не помогут?

    ---
    Ну ты заходи ежели чё...
    29 мар 10, 20:09    [8550318]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    stdio
    Member

    Откуда:
    Сообщений: 4524


    Сделайте и посмотрите, что Вам мешает.

    Но можно сказать, что жопа вам гарантирована. Не сейчас, так чуть позже.

    А зачем 3000 секций в день? КАКУЮ ЗАДАЧУ ЭТО РЕШАЕТ? Чем заведение 10 секций в день хуже чем заведение 3000 секций в день?
    29 мар 10, 20:15    [8550335]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    SQL*Plus
    Member

    Откуда: Россия, Москва
    Сообщений: 8131
    suPPLer
    11g Release 2 (11.2)
    ...
    ItemType of LimitLimit Value
    .........
    PartitionsMaximum number of partitions allowed per table or index1024K - 1
    .........

    Oracle9i R2 (9.2), Oracle 10g R2 (10.2)
    Maximum number of partitions allowed per table or index - 64 KB - 1 partitions

    64 KB - 1 = 65536 - 1 = 65535 partitions

    То есть если у вас не Oracle11g, то этот подход просто не будет работать.
    29 мар 10, 20:35    [8550389]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    andrey_anonymous
    Member

    Откуда: Москва
    Сообщений: 18351
    SQL*Plus
    То есть если у вас не Oracle11g, то этот подход просто не будет работать.

    1) лям партиций - уже c 10g
    2) как отметил stdio, в миллион автор не помещается.
    29 мар 10, 20:42    [8550407]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    suPPLer
    Member

    Откуда: Харків, Україна
    Сообщений: 7794
    Блог
    andrey_anonymous
    1) лям партиций - уже c 10g

    С 10gR2. :)
    29 мар 10, 20:47    [8550420]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    -2-
    Member

    Откуда:
    Сообщений: 15330
    andrey_anonymous
    2) как отметил stdio, в миллион автор не помещается.
    270K < 1M per table.
    29 мар 10, 21:03    [8550445]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    suPPLer
    Member

    Откуда: Харків, Україна
    Сообщений: 7794
    Блог
    -2-
    andrey_anonymous
    2) как отметил stdio, в миллион автор не помещается.
    270K < 1M per table.


    Да, это я дал маху, забыв убрать "15 таблиц" из формулы. Но меня ещё вот это смущает:

    йош
    Теперь нельзя стало выводить из эксплуатации старые опер.дни тупо целиком. Часть данных этих опер.дней может оставаться в схеме еще какое-то (неопределенное) время.


    Достаточно накапливать неудаляемые партиции недельки две-три (в зависимости от остающейся части), чтобы прыгнуть за 1М-1.
    29 мар 10, 21:11    [8550462]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    SQL*Plus
    Member

    Откуда: Россия, Москва
    Сообщений: 8131
    suPPLer
    andrey_anonymous
    1) лям партиций - уже c 10g

    С 10gR2. :)

    Oracle® Database
    Reference
    10g Release 2 (10.2)
    B14237-01
    June 2005

    Maximum number of partitions allowed per table or index - 64 KB - 1 partitions
    Documentation bug?
    В данный момент ссылка http://www.oracle.com/technology/documentation/database10gR2.html не работает, проверить по онлайн варианту не могу
    (An error occurred while processing the request. Try refreshing your browser. If the problem persists contact the site administrator)
    29 мар 10, 21:28    [8550492]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    suPPLer
    Member

    Откуда: Харків, Україна
    Сообщений: 7794
    Блог
    SQL*Plus
    Oracle® Database
    Reference
    10g Release 2 (10.2)
    B14237-01
    June 2005

    Maximum number of partitions allowed per table or index - 64 KB - 1 partitions
    Documentation bug?


    Ага. Я так понимаю, цитата с оффлайновой доки, в онлайне уже исправили давно.
    29 мар 10, 21:41    [8550520]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    suPPLer
    Member

    Откуда: Харків, Україна
    Сообщений: 7794
    Блог
    SQL*Plus
    Oracle® Database
    Reference
    10g Release 2 (10.2)
    B14237-01
    June 2005


    Текущая онлайновая версия:
    Oracle® Database Reference
    10g Release 2 (10.2)
    Part Number B14237-04
    29 мар 10, 21:43    [8550525]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    --Попрошайка--
    Member

    Откуда: АО "Попрошайка".
    Сообщений: 13709
    Блог
    автор

    Если же по-вашему мнению надежных средств борьбы с отрицательными последствиями нет, то какое разумное ограничение (по количеству партиций на схему) вы можете порекомендовать?


    Я бы автору дал такой ответ: глубина/детализация партиционирования зависит от технических характеристик аппаратной части.
    29 мар 10, 21:55    [8550542]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    andrey_anonymous
    Member

    Откуда: Москва
    Сообщений: 18351
    --Попрошайка--
    Я бы автору дал такой ответ: глубина/детализация партиционирования зависит от технических характеристик аппаратной части.

    Вы, должно быть, математик...
    29 мар 10, 22:11    [8550560]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    --Попрошайка--
    Member

    Откуда: АО "Попрошайка".
    Сообщений: 13709
    Блог
    andrey_anonymous
    --Попрошайка--
    Я бы автору дал такой ответ: глубина/детализация партиционирования зависит от технических характеристик аппаратной части.

    Вы, должно быть, математик...


    В качестве примера.

    Партиционирование - количество работы. Пропускная способность - ресурсы. Таким образом, еще надо сто раз подумать, что лучше лишняя партиция или лишний параллельный процесс на простаивающий, например, ЦПУ.

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

    Примечание: мой взгляд может быть и ошибочным.
    29 мар 10, 22:50    [8550654]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    -2-
    Member

    Откуда:
    Сообщений: 15330
    suPPLer
    Но меня ещё вот это смущает:

    йош
    Теперь нельзя стало выводить из эксплуатации старые опер.дни тупо целиком. Часть данных этих опер.дней может оставаться в схеме еще какое-то (неопределенное) время.


    Достаточно накапливать неудаляемые партиции недельки две-три (в зависимости от остающейся части), чтобы прыгнуть за 1М-1.
    Предположу, что "нельзя" - это невозможность оттранкейтить по партициям из-за недневного разбиения. Тут был совет - партиция=день*90, субпартиция=х*3000.

    Вопрос наверное в другом, поведение словаря данных и влияние на работу системы при миллионных количествах объектов в нем, пусть даже это партиции таблиц (а еще локальные индексы?).
    30 мар 10, 00:28    [8550828]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    Вячеслав Любомудров
    Member

    Откуда: Владивосток
    Сообщений: 18484
    Еще как-то проскакивала темка, что чрезмерное увлечение секционированием резко замедляет parse запросов

    Мне вот интересно, а сколько записей ежедневно вносится в эти таблицы. А то, если меньше 3000 строк, некоторые секции останутся пустыми , или много больше, но все лягут в 1-2 секции (делится по аттрибуту, а не по хешу, насколько я понял). Каков вообще глубинный смысл такого действа? Добиться быстродействия, распараллеливания запросов, удобства очистки/удаления...? Сомнительно все это...
    30 мар 10, 02:09    [8550988]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    wurdu
    Member

    Откуда: Владивосток
    Сообщений: 4441
    Замедление парсинга происходит из-за загрузки в shared pool информации по всем партициям из словаря, неважно сколько партиций участвует в запросе. Скорее всего это связано с тем, что HAGH_VALUE это LONG. Последующие hard parses уже идут быстро, но это до тех пор пока инфа не будет вытеснена из shared pool. Пример в 10.2.0.4 на таблице с 30000 партиций:
    select * from v$sgastat where name = 'partitioning d';
    
    POOL         NAME                            BYTES
    ------------ -------------------------- ----------
    shared pool  partitioning d                   5672
    
    set timing on
    set autotrace traceonly explain
    select * from part_tst where num = 1;
    Elapsed: 00:00:17.87
    
    Execution Plan
    ----------------------------------------------------------
    Plan hash value: 3531436128
    
    --------------------------------------------------------------------------------------------------
    | Id  | Operation             | Name     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    --------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT      |          |     1 |    65 |     2   (0)| 00:00:01 |       |       |
    |   1 |  PARTITION LIST SINGLE|          |     1 |    65 |     2   (0)| 00:00:01 |     1 |     1 |
    |   2 |   TABLE ACCESS FULL   | PART_TST |     1 |    65 |     2   (0)| 00:00:01 |     1 |     1 |
    --------------------------------------------------------------------------------------------------
    
    set autotrace off
    select * from v$sgastat where name = 'partitioning d';
    
    POOL         NAME                            BYTES
    ------------ -------------------------- ----------
    shared pool  partitioning d               16470800
    
    Elapsed: 00:00:00.00
    select * from part_tst where num = 2;
    
    no rows selected
    
    Elapsed: 00:00:00.01
    
    Соответственно, возможны проблемы с вытеснением из shared pool тех или иных структур с разными последствиями.
    30 мар 10, 06:59    [8551077]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    Вячеслав Любомудров
    Member

    Откуда: Владивосток
    Сообщений: 18484
    wurdu
    Замедление парсинга происходит из-за загрузки в shared pool информации по всем партициям из словаря, неважно сколько партиций участвует в запросе.
    Да я, собственно, об этом и говорил
    30 мар 10, 07:17    [8551090]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    d.nemolchev
    Member

    Откуда: Кустанай
    Сообщений: 310
    Жуткая задача описана...

    автор
    Есть некая БД, большая, размером в несколько Тб. Часть таблиц (15 штук) секционирована по операционному дню. Политика хранения данных такова, что данные в таблицах хранятся строго 3 месяца, и где-то раз в 7 дней 7 партиций за наиболее старые даты архивируется и выводится из эксплуатации.

    М.б. стоило изначально создавать одну партицию на неделю?

    автор
    Такой сложившийся порядок долгое время всех устраивал. И все бы ничего, но однажды задумал разработчик изменить схему партиционирования “по опер.дню” на партиционирование по другому атрибуту: у всех записей всех таблиц имеется атрибут, позволяющий в рамках одного опер.дня дополнительно разделять данные на ~3.000 независимых фрагментов. Т.е. если раньше для каждой из 15 вышеуказанных таблиц создавалось по 1 новой партиции в день, то теперь планируется создавать по ~3.000 новых партиций в день. Эти изменения в схеме партиционирования стали следствием изменений в “политике хранения и архивации данных”. Теперь нельзя стало выводить из эксплуатации старые опер.дни тупо целиком. Часть данных этих опер.дней может оставаться в схеме еще какое-то (неопределенное) время. Теперь планируется архивировать данные “кусочками”, опираясь на новый ключ секционирования (создающий теперь в рамках одного опер.дня по 3000 партиций на таблицу).

    изменить - я так понимаю - "заменить", т.е. вместо партиций по дням будут партиции по некому другому ключу секционирования. Т.о. Вам предлагается схема секционирования не "каждый день 3000 партиций", а "в работе находятся примерно 3000 партиций", которые при необходимости создаются в оперативной части БД и выводятся из нее когда их можно заархивировать. И здесь уже номинально нет однозначной зависимости партиции от опердня - в 3000 партиций льются данные всех опердней.
    Поэтому не стоит так пугать про 4 млн партиций - одновременно в БД у вас их будет около 3 тыс, что уже не так страшно.
    У вас в итоге получится такая же OLTP со скользящим окном, но только окно будет не по датам опердней, а по списку 3 тыс генерируемых вами ключей.
    Однако надо заметить что замена схемы секционирования породит вам геморрой с уже заархивированными партициями прошлых времен: по-хорошему их надо поднять в базу, перепартиционировать по новой схеме (например применяя эквивалент "бывший опердень=уникальное значение нового атрибута партиционирования") и заархивировать вновь.
    30 мар 10, 08:20    [8551175]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    d.nemolchev
    Member

    Откуда: Кустанай
    Сообщений: 310
    --Попрошайка--
    На мой взгляд, при разработке DWH необходимо постоянно быть внимательным при соблюдении здорового баланса, чтобы не получилось, что в одном месте густо, а в другом пусто.

    Примечание: мой взгляд может быть и ошибочным.


    Тут речи о DWH не идет, у ТС OLTP и партиционирование есть средство выноса из БД прошлогоднего снега...
    30 мар 10, 08:22    [8551180]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    debosh
    Member

    Откуда:
    Сообщений: 326
    d.nemolchev,

    если
    автор
    вместо партиций по дням будут партиции по некому другому ключу секционирования.
    , то по какому критерию снег-то будет выноситься?
    30 мар 10, 08:51    [8551249]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    d.nemolchev
    Member

    Откуда: Кустанай
    Сообщений: 310
    debosh
    d.nemolchev,

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


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

    ТС можно еще посоветовать "универсальное" - задуматься о подходе к проектированию системы...
    30 мар 10, 09:17    [8551336]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    SQL*Plus
    Member

    Откуда: Россия, Москва
    Сообщений: 8131
    suPPLer
    SQL*Plus
    Oracle® Database
    Reference
    10g Release 2 (10.2)
    B14237-01
    June 2005

    Maximum number of partitions allowed per table or index - 64 KB - 1 partitions
    Documentation bug?
    Ага. Я так понимаю, цитата с оффлайновой доки, в онлайне уже исправили давно.
    Да, действительно исправили. В 10gR2 1024K-1 partitions.
    30 мар 10, 10:45    [8551853]     Ответить | Цитировать Сообщить модератору
     Re: Поддержка Ораклом огромного количества партиций  [new]
    йош
    Member

    Откуда:
    Сообщений: 4
    1.
    Oracle 11g Database New Features
    suPPLer
    RTFM Oracle 11g Database New Features.
    1.10.8.2 Enhanced Statistics Collection for Partitioned Objects
    An improved statistics collection process for partitioned objects avoids having to regather statistics on partitions that have not been touched by using a summary instead.

    Partitioned objects tend to become larger and larger, and statistics collection, and particularly global statistics collection, can become increasingly time and resource intensive. This feature significantly improves the speed and accuracy of statistics collection for partitioned objects.
    Звучит прям как то, что нужно! Но увы, у нас Оракл версии 10.2.0.4.0

    2.
    Двоюшник
    Субпартиции Вам не помогут?
    Это вы меня спрашиваете?
    Если субпартиции успешно борются с описанными проблемами, я с радостью рассмотрю вариант с субпартициями! Напомню, опасения связаны с:
    йош
  • сильно возрасли накладные расходы на поддержку словаря данных;
  • сбор статистики стал выполняться значительно дольше; иногда статистика по каким-то причинам вообще не собиралась;
  • большое количество запросов постоянно перекомпилировалось (т.е. планы запросов постоянно вытеснялись из кэша)

  • 3.
    stdio
    1) Сделайте и посмотрите, что Вам мешает.
    ...
    2) А зачем 3000 секций в день? КАКУЮ ЗАДАЧУ ЭТО РЕШАЕТ? Чем заведение 10 секций в день хуже чем заведение 3000 секций в день?
    1) Сделаю обязательно, мешает недостаток опыта, думал что с помощью форума быстрее ответ получу.

    2) Такая схема партиционирования призвана решать 2 задачи:
  • минимизация row-level операций при вытеснении устаревших данных;
  • использование функциональности “исключения секций” из плана исполнения запросов

    Изменения в схеме секционирования вызваны применением новой “политики сохранения данных” и новой хитромудрой отчетностью, которой требуются выборочные данные из базы. Раньше опер.день можно было архивировать целиком (т.е. все 3.000 теперешних партиции одним махом). Сейчас, например, спустя 3 месяца можно архивировать данные только 2.900 партиций/”кусков”, еще через полгодика – еще 50 из оставшихся 100, а последние 50 должны присутствовать в схеме вечно (ну или по крайней мере несколько лет)!
    Purge-ить старые данные запросами на DELETE не реально – очень долго по времени, в отведенное для этого окно уложиться невозможно.
    И еще:
    в значительном количестве запросов к БД имеется “предикат” – ключ секционирования новой схемы секционирования, что при умелом использовании теоретически способно повысить уровень исключаемости ненужных секций из плана запросов.

    4.
    --Попрошайка--
    Я бы автору дал такой ответ: глубина/детализация партиционирования зависит от технических характеристик аппаратной части.
    Вы не могли быть чуть более подробнее рассказать?

    5.
    -2-
    Вопрос наверное в другом, поведение словаря данных и влияние на работу системы при миллионных количествах объектов в нем, пусть даже это партиции таблиц (а еще локальные индексы?).
    Именно! Самое большое опасение – а выдержит ли словарь данных, не треснет ли по швам?

    6.
    Вячеслав Любомудров
    Мне вот интересно, а сколько записей ежедневно вносится в эти таблицы. А то, если меньше 3000 строк, некоторые секции останутся пустыми , или много больше, но все лягут в 1-2 секции (делится по аттрибуту, а не по хешу, насколько я понял). Каков вообще глубинный смысл такого действа? Добиться быстродействия, распараллеливания запросов, удобства очистки/удаления...? Сомнительно все это...
    Распределение по секциям не очень равномерное, но не такое, конечно, как вы привели в примере. В общем случае – от нескольких сотен до нескольких тысяч записей на партицию. За день в каждую из 15 таблиц добавляется около 5.000.000 новых записей, иногда больше.

    7.
    wurdu
    Замедление парсинга происходит из-за загрузки в shared pool информации по всем партициям из словаря, неважно сколько партиций участвует в запросе. Скорее всего это связано с тем, что HAGH_VALUE это LONG. Последующие hard parses уже идут быстро, но это до тех пор пока инфа не будет вытеснена из shared pool. Пример в 10.2.0.4 на таблице с 30000 партиций:
    ...
    Соответственно, возможны проблемы с вытеснением из shared pool тех или иных структур с разными последствиями.
    Пошел осмыслять и копать доку (правда пока не знаю где ).
    Если не сложно, поделитесь пожалуйста ссылочкой, где про эту красоту написано.

    8.
    d.nemolchev
    Жуткая задача описана...
    ...
    М.б. стоило изначально создавать одну партицию на неделю?
    Вовсе нет, бОльшая часть запросов к БД имеет предикат “опер.день”, т.е. в значительной части запросов данные отбираются за один конкретный день, таким образом с успехом применяется исключение “лишних” секций из запроса.

    d.nemolchev
    изменить - я так понимаю - "заменить", т.е. вместо партиций по дням будут партиции по некому другому ключу секционирования. Т.о. Вам предлагается схема секционирования не "каждый день 3000 партиций", а "в работе находятся примерно 3000 партиций", которые при необходимости создаются в оперативной части БД и выводятся из нее когда их можно заархивировать. И здесь уже номинально нет однозначной зависимости партиции от опердня - в 3000 партиций льются данные всех опердней.
    Новый атрибут партиционирования – это ID пакета, в котором данные поступили в систему. Этот ID пакета – счетчик, автоинкремент, суррогатный ключ. Так что каждый день создается по 3.000 именно новых партиций.

    d.nemolchev
    Поэтому не стоит так пугать про 4 млн партиций - одновременно в БД у вас их будет около 3 тыс, что уже не так страшно.
    Поверьте, их будет именно 4 М :)


    На самом деле мне просто хотелось услышать мнение человека, который уже наталкивался на подобные грабли в прошлом. Господа, неужели никто и никогда так яростно не партиционировал?
  • 30 мар 10, 15:49    [8554494]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
    Все форумы / Oracle Ответить