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

Ситуация такова : Есть таблица, которая интенсивно обновляется
(в основном insert ). И в то же самое время из нее могут делать всевозможные select-ы. С целью ускорения выборки данных сделали ее секционированной по одному из столбцов - дате вставки в таблицу.
Сделали также несколько индексов, в том числе и по ключу секционирования. Но желаемого ускорения не достигли - select цепляет нужную партицию только в том случае, если ее название явно прописывать в селекте.

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

(предвижу советы сделать WH, перегнать данные туда и селектить уже оттуда, но пока WH не планируется, надо обходиться OLTP.)
16 мар 06, 10:47    [2454420]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
kosour
Member

Откуда:
Сообщений: 236
Всё как обычно -

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


---
Косоурихин Сергей
BI Partner
DWH & OLAP
16 мар 06, 12:18    [2455104]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Sqaimes
Member

Откуда: Украина, Мариуполь
Сообщений: 443
ответ скорей всего одназначный :
сделай : analyze table ....
16 мар 06, 13:53    [2455771]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Sqaimes
Member

Откуда: Украина, Мариуполь
Сообщений: 443
и еще одно замечание по поводу получения ожидаемой производительности:

однозначное повышение производительности от распараллеливания операторов DML можно достичь только в среде больших хранилищ данных при изменении больших объемов данных.
В OLTP это можно получить посредствам "игнорирования" в запросе, некоторых фрагментов, которые в alter index можно пометить как unusable!
16 мар 06, 14:09    [2455878]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Анонимщик
Guest
вот таблица и индексы.
Oracle Database 10g Enterprise Edition Release 10.1.0.4.0

Интересно еще - как можно эту таблицу безболезненно
переделать в обычную несекционированную.


-- Create table
create table PP_CALL
(
PPCAL_ID INTEGER not null,
PPCAL_START_DATE DATE not null,
PPCAL_ANSWER_DATE DATE,
PPCAL_FINISH_DATE DATE not null,
PPCAL_CALLER VARCHAR2(30),
PPCAL_CALLED VARCHAR2(30),
PPCAL_NOTE VARCHAR2(800),
PPEXT_IN_ID INTEGER,
PPEXT_OUT_ID INTEGER,
PPCAL_IN_PREFIX VARCHAR2(30),
PPCAL_OUT_PREFIX VARCHAR2(30),
PPCAL_RESULT INTEGER,
PPCAL_REF_NUM INTEGER,
PPCAL_TIME_IN INTEGER,
PPCAL_TIME_OUT INTEGER,
PPCAL_DURATION INTEGER,
PPIDX_ID NUMBER,
PPEXT_ID INTEGER,
PPCAL_SESSION INTEGER
)
partition by range (PPCAL_START_DATE)
(
partition Y2004 values less than (TO_DATE(' 2005-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')
tablespace DATA
pctfree 10
initrans 1
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
),
partition Y2005Q1 values less than (TO_DATE(' 2005-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')
tablespace DATA
pctfree 10
initrans 1
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
),
partition Y2005Q2 values less than (TO_DATE(' 2005-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')
tablespace DATA
pctfree 10
initrans 1
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
),
partition Y2005Q3 values less than (TO_DATE(' 2005-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')
tablespace DATA
pctfree 10
initrans 1
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
),
partition Y2005Q4 values less than (TO_DATE(' 2006-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')
tablespace DATA
pctfree 10
initrans 1
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
),
partition Y2006Q1 values less than (TO_DATE(' 2006-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')
tablespace DATA
pctfree 10
initrans 1
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
),
partition Y2006Q2 values less than (TO_DATE(' 2006-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')
tablespace DATA
pctfree 10
initrans 1
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
),
partition Y2006Q3 values less than (TO_DATE(' 2006-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')
tablespace DATA
pctfree 10
initrans 1
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
),
partition Y2006Q4 values less than (TO_DATE(' 2007-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')
tablespace DATA
pctfree 10
initrans 1
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
)
)
;
-- Create/Recreate primary, unique and foreign key constraints
alter table PP_CALL
add constraint PP_CALL_PK primary key (PPCAL_ID)
using index
tablespace IDX
pctfree 10
initrans 2
maxtrans 255
storage
(
initial 400K
minextents 1
maxextents unlimited
);
alter table PP_CALL
add constraint CALL_EXTENSION_FK foreign key (PPEXT_ID)
references PP_EXTENSION (PPEXT_ID);
alter table PP_CALL
add constraint CALL_INDEX_FK foreign key (PPIDX_ID)
references PP_INDEX (PPIDX_ID);
alter table PP_CALL
add constraint REF_53318_FK foreign key (PPEXT_IN_ID)
references PP_EXTENSION (PPEXT_ID);
alter table PP_CALL
add constraint REF_53322_FK foreign key (PPEXT_OUT_ID)
references PP_EXTENSION (PPEXT_ID);
-- Create/Recreate indexes
create index PPCAL_EXT_ID_IDX on PP_CALL (PPEXT_ID)
tablespace IDX
pctfree 10
initrans 2
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
);
create index PPCAL_EXT_IN_ID_IDX on PP_CALL (PPEXT_IN_ID)
tablespace IDX
pctfree 10
initrans 2
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
);
create index PPCAL_EXT_OUT_ID_IDX on PP_CALL (PPEXT_OUT_ID)
tablespace IDX
pctfree 10
initrans 2
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
);
create index PPCAL_IDX_ID_IDX on PP_CALL (PPIDX_ID)
tablespace IDX
pctfree 10
initrans 2
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
);
create index PPCAL_START_DATE_IDX on PP_CALL (PPCAL_START_DATE)
tablespace IDX
pctfree 10
initrans 2
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
);
16 мар 06, 15:25    [2456327]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Sqaimes
Member

Откуда: Украина, Мариуполь
Сообщений: 443
что касается таблицы и созданных для нее индексов, то...... как насчет GLOBAL и LOCAL? хотя эта надо хоть какое либо представление иметь о том какие запросы вы делаете, может у вас неправильно индексы созданы..
А что касается переделки...могу написать но позже...скорее только завтра :)
16 мар 06, 16:07    [2456532]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
А что, правда твои tablespaces dictionary managed или это глюк?

--
Антон
Per rectum ad astrum
16 мар 06, 22:04    [2457909]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
и пример запроса с планом в студию!

--
Антон
Per rectum ad astrum
16 мар 06, 22:05    [2457913]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Анонимщик
Guest
Anton Demidov
А что, правда твои tablespaces dictionary managed или это глюк?

--
Антон
Per rectum ad astrum



А где видно что они dictionary managed ? вообще что это такое ?
Запросы в основном по дате, то есть ключу секционирования.



to Sqaimes:
Вот я и парюсь с этими GLOBAL LOCAL. непонятно, какие индексы нужны в данном случае.
17 мар 06, 13:19    [2459882]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Sqaimes
Member

Откуда: Украина, Мариуполь
Сообщений: 443
Анонимщик
(предвижу советы сделать WH, перегнать данные туда и селектить уже оттуда, но пока WH не планируется, надо обходиться OLTP.)

поскольку у тебя OLTP, то использовать надо глобальные индексы, т.к. локальные больше для WH, тоесть о локальных даже и недумай... :)
17 мар 06, 14:00    [2460196]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Sqaimes
Member

Откуда: Украина, Мариуполь
Сообщений: 443
и еще... я немогу сказать как повысить производительность твоего запроса, поскольку я его досих пор невижу :)
17 мар 06, 14:05    [2460228]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Анонимщик
Guest
Sqaimes
и еще... я немогу сказать как повысить производительность твоего запроса, поскольку я его досих пор невижу :)


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

select * from PP_CALL where ppcal_start_date between sysdate-10 and sysdate
17 мар 06, 17:57    [2461768]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Анонимщик
А где видно что они dictionary managed ?
storage
(
minextents 1
maxextents unlimited
);
Анонимщик
вообще что это такое ?
По вашему запросу найдено 67 тем.
Ну и на самом оракле много было написано.
17 мар 06, 19:25    [2462105]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
RA\/EN
Member

Откуда:
Сообщений: 3658
Sqaimes
и еще одно замечание по поводу получения ожидаемой производительности:

однозначное повышение производительности от распараллеливания операторов DML можно достичь только в среде больших хранилищ данных при изменении больших объемов данных.
В OLTP это можно получить посредствам "игнорирования" в запросе, некоторых фрагментов, которые в alter index можно пометить как unusable!


А поподробнее о таком вандальском методе можно?
18 мар 06, 15:21    [2463184]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
nata1111
Member

Откуда:
Сообщений: 1800
Anton Demidov
Анонимщик
А где видно что они dictionary managed ?
[src oracle]storage
(
minextents 1
maxextents unlimited
);

обычный глюк какого-нить софта, пытающегося самостоятельно генерить определение объектов.
19 мар 06, 13:44    [2464233]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Sqaimes
Member

Откуда: Украина, Мариуполь
Сообщений: 443
:)
RAVEN
А поподробнее о таком вандальском методе можно?

есть таблица:
CREATE TABLE Т1
 (col11 int,
 col2 varchar2(2))
 PARTITION BY...
(partition p_l tablespace tspace1,
 partition p_2 tablespace tspace2
 
Create index...
.....игнорируем фрагменты:
alter index l_index modify partition p_1 unusable;
можем и отключать табличные пространства, правда после этого в запросах придется использовать связываемые переменные:
alter tablespace tspace1 offline;
и то по большому щету есть это имеет смысл только в запросах, условия которых позволяют использовать игнорирование фрагментов индекса.
и еще...
Анонимщик
Но желаемого ускорения не достигли - select цепляет нужную партицию только в том случае, если ее название явно прописывать в селекте.


какраз в глобально фрагментированом идексе использование префикса и дает возможность игнорировать фрагменты индекса....
20 мар 06, 00:44    [2465326]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
Sqaimes
поскольку у тебя OLTP, то использовать надо глобальные индексы, т.к. локальные больше для WH, тоесть о локальных даже и недумай... :)
Интересная точка зрения. Аргументы в студию, плзз...

Всего
20 мар 06, 01:40    [2465382]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Sqaimes
Member

Откуда: Украина, Мариуполь
Сообщений: 443
локальные индексы, прежде всего подходят для ХД, потому что как известно, в отличие от глобальных, обеспечивают большую доступность данных...,сокращая время простоя, да и полный просмотр больших таблиц характерен как раз больше для ХД!!! А в OLTP так нужно?, нужно полностью смотреть огромные таблицы? нужно переносить данные из одного табличного пространства в другое?....и т.д....все преимущества которые дает локальный индекс играют роль в основном только для ХД, даже тот факт что при вставке/удалении фрагментов глобальный индекс надо пересоздавать не дает выиграшь поскольку в OLTP вставка или удаление в виде "фрагмента" , я думаю происходит редко....

Ааз
Интересная точка зрения. Аргументы в студию, плзз...


В OLTP для скоростного доступа к данным локальные индексы неособо приемлемы поскольку нам бы пришлось ,как и в ХД выполнить параллельный просмотр диапазонов по индексам..., а распаралеливание в OLTP не лучший способ повышения производительности :) (не путать с увелечением степени паралелилизма, что какраз достигается при использовании глобальных индексов!)...
Более весомые аргументы ищите в литературе...... :)
20 мар 06, 14:16    [2467291]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
тихо ржу...
Guest
Sqaimes
локальные индексы, прежде всего подходят для ХД, потому что как известно, в отличие от глобальных, обеспечивают большую доступность данных...,сокращая время простоя, да и полный просмотр больших таблиц характерен как раз больше для ХД!!! А в OLTP так нужно?, нужно полностью смотреть огромные таблицы? нужно переносить данные из одного табличного пространства в другое?....и т.д....все преимущества которые дает локальный индекс играют роль в основном только для ХД, даже тот факт что при вставке/удалении фрагментов глобальный индекс надо пересоздавать не дает выиграшь поскольку в OLTP вставка или удаление в виде "фрагмента" , я думаю происходит редко....

Ааз
Интересная точка зрения. Аргументы в студию, плзз...


В OLTP для скоростного доступа к данным локальные индексы неособо приемлемы поскольку нам бы пришлось ,как и в ХД выполнить параллельный просмотр диапазонов по индексам..., а распаралеливание в OLTP не лучший способ повышения производительности :) (не путать с увелечением степени паралелилизма, что какраз достигается при использовании глобальных индексов!)...
Более весомые аргументы ищите в литературе...... :)

тихо ржу...
20 мар 06, 18:09    [2468794]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
Sqaimes
локальные индексы, {skipped} обеспечивают большую доступность данных..., сокращая время простоя
Хороший аргумент... Но почему не в пользу OLTP? Особенно когда 24x7?

Sqaimes
даже тот факт что при вставке/удалении фрагментов глобальный индекс надо пересоздавать не дает выиграшь поскольку в OLTP вставка или удаление в виде "фрагмента" , я думаю происходит редко....
Только не говорите этого админам МТС, Beeline и Мегафон. Не поймут ;-).

Всего
20 мар 06, 20:13    [2469241]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Sqaimes
Member

Откуда: Украина, Мариуполь
Сообщений: 443
автор
тихо ржу...

ну, ну.... с чего же?

Ааз

Sqaimes

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

Только не говорите этого админам МТС, Beeline и Мегафон. Не поймут ;-).

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

что касается:
Только не говорите этого админам МТС, Beeline и Мегафон. Не поймут ;-)

и другие... Вы все не хуже меня знаете что у каждой системы своя специфика...
...а что касется аргументов буду рад неменьше остальных узнать приумущества в использовании того или иного индекса как в DWH так и в OLTP и в какой ситуации...

to:
тихо ржу
тихо ржу

особенно, интересно ваше мнение....
21 мар 06, 09:44    [2470108]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
тихо ржущий
Guest
Sqaimes

to:
тихо ржу
тихо ржу

особенно, интересно ваше мнение....

Да какое мое мнениЁ? Глупости ты говоришь, вот и все. Локальные индексы используются и в OLTP и в DWH.
21 мар 06, 09:57    [2470148]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Анонимщик
Guest
Ребята, мне кажется, вы слегка отклонились от сути вопроса.
Как насчет конкретных рекомендаций, ради которых, собственно, и была создана эта тема ?
21 мар 06, 10:11    [2470203]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
scela
Member

Откуда: Москва
Сообщений: 565
Анонимщик

Ситуация такова : Есть таблица, которая интенсивно обновляется
(в основном insert ). И в то же самое время из нее могут делать всевозможные select-ы.

В самом деле всевозможные или всетаки их можно перечислить?

Анонимщик

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

Если запросы используют в условии where ключ секции , очень хорошо.

Анонимщик

Сделали также несколько индексов, в том числе и по ключу секционирования. Но желаемого ускорения не достигли - select цепляет нужную партицию только в том случае, если ее название явно прописывать в селекте.

Если запрос использует ключ партиции , то оптимизатор будет искать только в нужных секциях.
Вообще, если ты явно указаываешь название партиции , значит, ты каким-то образом знаешь, где именно искать. так расскажи это оптимизатору :)
21 мар 06, 10:41    [2470395]     Ответить | Цитировать Сообщить модератору
 Re: Выбор между обычной таблицей и секционированной  [new]
Анонимщик
Guest

Анонимщик

Сделали также несколько индексов, в том числе и по ключу секционирования. Но желаемого ускорения не достигли - select цепляет нужную партицию только в том случае, если ее название явно прописывать в селекте.

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


ну, скажем так, нафига каждый раз запрос дописывать нужной партицией, если она должна определяться и без этого ?
(В условии where, как правило, содержится условие отбора по ключу секционирования, и я догадываюсь, что это хорошо :-)
Так все-таки - как улучшить ситуацию ? И нужны ли партиции в данном случае вообще ? Может, переделать ее на хрен в обычную таблицу с обычными индесами, и не морочиться ?
21 мар 06, 11:41    [2470772]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить