|
Тема
|
Зор с Oracle9 и големи таблици
|
|
Автор |
c1ick (once) |
Публикувано | 25.09.03 15:26 |
|
Зор -> Как да кажа на Oracle да не ползва някакъв secondary index в таблица, в която не мога да използвам никой от primary index-ите?
Проблемът е там, че ако това поле, което в момента е вторичен индекс, не е индексно, куерито върви около 6-7 минути. Ако това поле стане вторичен индекс (което е необходимо за други заявки), куерито ми върви над час.
Таблицата е с около 7-8 млн записа.
има един hint, в който се казва /*+NO_INDEX(table_name field_name) */, но очевидно не работи.
Благодарен съм за всякакви идеи за оптимизиране на бързината на пустия Oracle9
c1ick once here to get A5 - а шес хиляди марки
| |
Тема
|
Re: Зор с Oracle9 и големи таблици
[re: c1ick]
|
|
Автор | sbd (Нерегистриран) |
Публикувано | 25.09.03 17:16 |
|
Схемата ти анализирана ли е? Ако не е, анализирай я, на първо време например с DMBS_UTILITY.ANALYZE_SCHEMA и опитай пак да пуснеш заявката, но без никакви hint_ове.
Ако не стане, кажи да пробваме нещо друго.
| |
Тема
|
Re: Зор с Oracle9 и големи таблици
[re: c1ick]
|
|
Автор |
timmyyy (sp addicted) |
Публикувано | 26.09.03 13:01 |
|
Може да пробваш и нещо от сорта select .... from (select нещо from таблицата), .....
Ако облечеш таблицата във view оптимизатора най-вероятно няма да се усети да използва индекса. Ако пък го сортираш това view може ти да му намекнеш какъв индекс да използва.
Използвай explain plan - полезна работа върши и за да добиеш представа какво мисли оракала за изпълнението на заявката и къде можеш да я оптимизираш.
| |
|
Събери системна статистика, така позволяваш на оракала да хитрее и бърза още повече :-) Виж тия далавери:
begin
dbms_stats.delete_table_stats(login_user, 'TABLICA');
dbms_stats.gather_table_stats(login_user, 'TABLICA', method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => true);
end;
| |
Тема
|
Re: Зор с Oracle9 и големи таблици
[re: c1ick]
|
|
Автор | AcidMemory (Нерегистриран) |
Публикувано | 26.09.03 17:44 |
|
попрочети още малко, иначе си на прав път ...
RTFM му е майката
Значи в 9i е малко по-различно, тъй като са сменени начините и случаите, в които действат optimizer-ите (RBO - Rule Based Optimizer и CBO - Cost Based Optimizer). Това е така, поради факта, че с всяка версия Oracle ще налагат CBO, а с течение на времето RBO ще стане deprecated.
Много се набляга на факта всички приложения и бази да ползват CBO, а RBO се поддържа само за backward compatibility. Трябва да видиш как е настроена базата (специално optimizer променливите като OPTIMIZER_MODE). "Кофтито" на CBO е, че се нуждае от статистики за да може да действа (примерно ако нямаш статистики и OPTIMIZER_MODE ти е CHOOSE, тогава бачка RBO)
Както другите споменават отчасти, един прост начин да ползваш CBO, а оттам и hints, е collecting statistics. След това лесно можеш с един EXPLAIN PLAN да видиш как ще се промени плана на заявката, като добавиш
SELECT /*+NO_INDEX(<table> <index>)*/ <field>
FROM <table>
WHERE <field> <relation> ...
btw бъркаш в NO_INDEX синтаксиса, правилният е (няма field):
/*+ NO_INDEX ( table [index [index]...] ) */
аде дерзай ...
| |
|
|
|
|