| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
dumpino
Участник со стажем
Вступление в Клуб: 13.12.2011
|
 Вт Янв 31, 2012 07:20 Partition больших таблиц |
 |
Полезность: Нет оценки
|
опыта работы с ЦФТ системами не много и некоторые вещи по части БД меня малость смущают, хотелось бы пообщаться с гуру.
немного истории.
есть Тип - !Платежные документы[MAIN_DOCUM], таблица соответственно - Z#MAIN_DOCUM. Почти все представления с участием этой таблицы жутко тормозят, медленно работают. А при фильтре масок счетов по Кр и Дб одновременно показ представления вообще дождаться не возможно.
| Код: | SELECT A1.Id ID,
a1.CLASS_ID Class_Id,
a1.STATE_ID State_Id,
a1.C_DOCUMENT_NUM C_1,
a1.C_DATE_PROV C_2,
a2.C_MAIN_V_ID C_3,
a3.C_MAIN_V_ID C_4
from Z#MAIN_DOCUM a1, Z#AC_FIN a3, Z#AC_FIN a2
where a1.C_ACC_DT = a2.id
and a1.C_ACC_KT = a3.id
and (a1.C_DATE_PROV) >= TO_DATE('24.01.2012', 'dd.mm.yyyy')
and (a1.C_DATE_PROV) <= TO_DATE('24.01.2012', 'dd.mm.yyyy')
and a2.C_MAIN_V_ID like '423%'
and a3.C_MAIN_V_ID like '202%' |
Смотрю план, там всё красиво, хотя не всё что он использует могу объяснить)). Смотрю, есть ли партиции по данной таблице - их нет. Отсюда мысли.
Кто-нить может поделиться опытом партицирования таблиц и стоит ли это делать? Сейчас таблица с документами довольно большая (121 млн. записей) и разбивание на партиции процесс не очень быстрый и довольно ответственный, поэтому если есть, кто с этим уже сталкивался, хотелось бы посоветоваться. |
|
 |
prog
Эксперт
Вступление в Клуб: 03.03.2008
|
| Вт Янв 31, 2012 09:22 |
|
Полезность: Нет оценки
|
| Я понимаю вопрос не про это. Но может опубликуете план. |
|
|
Random
Эксперт
Вступление в Клуб: 27.06.2011
|
| Вт Янв 31, 2012 10:14 Re: Partition больших таблиц |
|
Полезность: Нет оценки
|
| dumpino пишет: | ...А при фильтре масок счетов по Кр и Дб одновременно показ представления вообще дождаться невозможно.
| Код: | SELECT A1.Id ID,
a1.CLASS_ID Class_Id,
a1.STATE_ID State_Id,
a1.C_DOCUMENT_NUM C_1,
a1.C_DATE_PROV C_2,
a2.C_MAIN_V_ID C_3,
a3.C_MAIN_V_ID C_4
from Z#MAIN_DOCUM a1, Z#AC_FIN a3, Z#AC_FIN a2
where a1.C_ACC_DT = a2.id
and a1.C_ACC_KT = a3.id
and (a1.C_DATE_PROV) >= TO_DATE('24.01.2012', 'dd.mm.yyyy')
and (a1.C_DATE_PROV) <= TO_DATE('24.01.2012', 'dd.mm.yyyy')
and a2.C_MAIN_V_ID like '423%'
and a3.C_MAIN_V_ID like '202%' |
Смотрю план, там всё красиво, хотя не всё что он использует могу объяснить))... |
А подумать?
1) and (a1.C_DATE_PROV) >= TO_DATE('24.01.2012', 'dd.mm.yyyy')
and (a1.C_DATE_PROV) <= TO_DATE('24.01.2012', 'dd.mm.yyyy')
не проще написать a1.C_DATE_PROV = TO_DATE('24.01.2012', 'dd.mm.yyyy') ?
2) Если уж >= и <=, то хотя бы разные даты пиши
3) Сравни объем документов по счетам 423% или 202% за весь период существования MAIN_DOCUM и количество документов за 1 день, который ты хочешь вытащить (примерно 400-500 тыс., навскидку, так?)
Вот и выходит у меня, что нужен несколько другой запрос (точнее, план, но по представленному мной запросу план будет такой, какой я тебе хочу показать - 100%):
| Код: |
SELECT A1.Id ID,
a1.CLASS_ID Class_Id,
a1.STATE_ID State_Id,
a1.C_DOCUMENT_NUM C_1,
a1.C_DATE_PROV C_2,
a2.C_MAIN_V_ID C_3,
a3.C_MAIN_V_ID C_4
from Z#MAIN_DOCUM a1, Z#AC_FIN a3, Z#AC_FIN a2
where a1.C_ACC_DT+0 = a2.id -- сбиваем с индекса по счету
and a1.C_ACC_KT+0 = a3.id -- сбиваем с индекса по счету
-- Вот по этому условию и должны индексироваться документы
and a1.C_DATE_PROV >= TO_DATE('24.01.2012', 'dd.mm.yyyy')
and a1.C_DATE_PROV <= TO_DATE('24.01.2012', 'dd.mm.yyyy')+1
and ''||a2.C_MAIN_V_ID like '423%' -- Сбиваем с индекса по C_MAIN_V_ID - счета должны подсоединяться по pk
and ''||a3.C_MAIN_V_ID like '202%' -- Сбиваем с индекса по C_MAIN_V_ID
|
Последний раз редактировалось: Random (Вт Янв 31, 2012 10:32), всего редактировалось 1 раз |
|
|
dumpino
Участник со стажем
Вступление в Клуб: 13.12.2011
|
| Вт Янв 31, 2012 10:22 Re: Partition больших таблиц |
|
Полезность: Нет оценки
|
| Random пишет: |
А подумать?
1) and (a1.C_DATE_PROV) >= TO_DATE('24.01.2012', 'dd.mm.yyyy')
and (a1.C_DATE_PROV) <= TO_DATE('24.01.2012', 'dd.mm.yyyy')
не проще написать a1.C_DATE_PROV = TO_DATE('24.01.2012', 'dd.mm.yyyy') ?
2) Если уж >= и <=, то хотя бы разные даты пиши
3) Сравни объем документов по счетам 423% или 202% за весь период существования MAIN_DOCUM и количество документов за 1 день, который ты хочешь вытащить (примерно 400-500 тыс., навскидку, так?)
Вот и выходит у меня, что нужен несколько другой запрос (точнее, план, но по представленному МНОЙ запросу план будет такой, какой я тебе хочу показать - 100%):
| Код: |
SELECT A1.Id ID,
a1.CLASS_ID Class_Id,
a1.STATE_ID State_Id,
a1.C_DOCUMENT_NUM C_1,
a1.C_DATE_PROV C_2,
a2.C_MAIN_V_ID C_3,
a3.C_MAIN_V_ID C_4
from Z#MAIN_DOCUM a1, Z#AC_FIN a3, Z#AC_FIN a2
where a1.C_ACC_DT+0 = a2.id -- сбиваем с индекса по счету
and a1.C_ACC_KT+0 = a3.id -- сбиваем с индекса по счету
-- Вот по этому условию и должны индексироваться документы
and a1.C_DATE_PROV >= TO_DATE('24.01.2012', 'dd.mm.yyyy')
and a1.C_DATE_PROV <= TO_DATE('24.01.2012', 'dd.mm.yyyy')+1
and ''||a2.C_MAIN_V_ID like '423%' -- Сбиваем с индекса по C_MAIN_V_ID - счета должны подсоединяться по pk
and ''||a3.C_MAIN_V_ID like '202%' -- Сбиваем с индекса по C_MAIN_V_ID
|
|
дело в том, что я этот запрос не сам пишу, его так интерпретирует компилятор ЦФТ  поэтому я отталкиваюсь от того, что есть. Ну и пользователь может указать период, как в моем случае.
и что значит "сбиваем с индекса"?, извините
Последний раз редактировалось: dumpino (Вт Янв 31, 2012 10:28), всего редактировалось 1 раз |
|
|
dumpino
Участник со стажем
Вступление в Клуб: 13.12.2011
|
| Вт Янв 31, 2012 10:27 |
|
Полезность: Нет оценки
|
| prog пишет: | | Я понимаю вопрос не про это. Но может опубликуете план. |
SELECT STATEMENT 3
| NESTED LOOPS 3 115
| | NESTED LOOPS 2 85
| | | TABLE ACCESS BY INDEX ROWID Z#AC_FIN 1 30
| | | | INDEX RANGE SCAN IDX_Z#AC_FIN_MNUM 1
| | | TABLE ACCESS BY INDEX ROWID Z#MAIN_DOCUM 1 55
| | | | INDEX RANGE SCAN IDX_Z#MAIN_DOCUM_ACCKT_DP_ST 1
| | TABLE ACCESS BY INDEX ROWID Z#AC_FIN 1 30
| | | INDEX UNIQUE SCAN PK_Z#AC_FIN_ID 1
как его сюда в лучшем виде запостить, что-то не нашёл) последние стобцы Cost и Byte |
|
|
Random
Эксперт
Вступление в Клуб: 27.06.2011
|
| Вт Янв 31, 2012 10:41 Re: Partition больших таблиц |
|
Полезность: Нет оценки
|
| dumpino пишет: | дело в том, что я этот запрос не сам пишу, его так интерпретирует компилятор ЦФТ поэтому я отталкиваюсь от того, что есть. Ну и пользователь может указать период, как в моем случае.
и что значит "сбиваем с индекса"?, извините |
Мм...
Если ты просишь совета по поводу представления, которое ты не сам пишешь, то просто сравни план выполнения твоего варианта и моего.
к документам надо обращаться (в твоём случае) по индексу IDX_Z#MAIN_DOCUM_DATE_PROV, ко счетам - по индексу PK_Z#AC_FIN_ID.
В противном случае Oracle придётся лопатить очень большой объём данных (навскидку - примерно 10-30% всей таблицы Z#MAIN_DOCUM)
Поскольку для разных случаев нужны разные индексы, на типе MAIN_DOCUM построено дофига представлений.
Ищите то, которое вас бы устроило.
Если ты просишь совета по поводу того, как написать представление самостоятельно, так, чтобы оно побыстрее отрабатывало, то пожалуйста
1) делаем представление pl/plus;
2) | Код: | type main is
select a(
a.[DOCUMENT_NUM]
, a.[DATE_PROV]
, dt.[MAIN_V_ID]
, kt.[MAIN_V_ID]
) in ::[MAIN_DOCUM], (::[AC_FIN] all:dt), (::[AC_FIN] all:kt) all
where a.[ACC_DT]+0 = dt
and a.[ACC_KT]+0 = kt
and a.[DATE_PROV] >= :date:
and a.[DATE_PROV] < :date:+1
|
Сбить с индекса - это построить запрос так, чтобы оптимизатор Oracle ни в коем случае не использовал бы "вредный" индекс (в данном случае, использование конкатенации для номер счета говорит оптимизатору, что индексы, начинающиеся с поля C_MAIN_V_ID будет неэффективно использовать. А +0 к полям-ссылкам на счет говорит о том, что при анализе индексов Z#MAIN_DOCUM не нужно брать индесы типа IDX_Z#MAIN_DOCUM_ACCKT_DP_ST)
Простого решения нет.
Дело в том, что если по маске счета у тебя получится два-три счета, по которым документов не очень много (то есть не счета переоценки), и при этом анализируемый период документов - месяц (а то и год!) то тот план, который получается у тебя, будет гораааздо эффективнее моего. |
|
|
dumpino
Участник со стажем
Вступление в Клуб: 13.12.2011
|
| Вт Янв 31, 2012 10:57 |
|
Полезность: Нет оценки
|
| Random, спасибо. Сделаю для себя выводы |
|
|
Random
Эксперт
Вступление в Клуб: 27.06.2011
|
| Вт Янв 31, 2012 10:59 Re: Partition больших таблиц |
|
Полезность: Нет оценки
|
| dumpino пишет: | ...Смотрю, есть ли партиции по данной таблице - их нет. Отсюда мысли.
Кто-нить может поделиться опытом партицирования таблиц и стоит ли это делать? Сейчас таблица с документами довольно большая (121 млн. записей) и разбивание на партиции процесс не очень быстрый и довольно ответственный, поэтому если есть, кто с этим уже сталкивался, хотелось бы посоветоваться. |
Насчёт партиций не подскажу, хотя имею своё мнение, что в данном случае в эту сторону смотреть не стоит. |
|
|
dumpino
Участник со стажем
Вступление в Клуб: 13.12.2011
|
| Вт Янв 31, 2012 11:03 Re: Partition больших таблиц |
|
Полезность: Нет оценки
|
| Random пишет: |
Насчёт партиций не подскажу, хотя имею своё мнение, что в данном случае в эту сторону смотреть не стоит. |
я конечно этот вариант тоже рассматриваю как "сверх-запасной", есть надежда вытащить представление индексами.
но вопрос, почему изначально разработчикам не предусмотреть партиционность таких значимых таблиц?
у них во всей базе нет партиций, неужели Oracle придумал какую-то ерунду, которая и не нужна вовсе, а Том Кайт нам всем по ушам ездит? |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
О проекте
Поиск
Отзывы
Регистрация
Вход
