Най-важното нещо, което трябва да разберете за паралелизма на Oracle, е, че той е сложен. Оптимизирането на паралелизъм изисква много познания на Oracle, четене на ръководствата, проверка на много параметри, тестване на продължителни заявки и много скептицизъм.
Задайте правилните въпроси
Паралелните проблеми наистина включват три различни въпроса:
- Колко паралелни сървъра бяха заявени?
- Колко паралелни сървъра бяха разпределени?
- Колко паралелни сървъра са били смислено използвани?
Използвайте най-добрите инструменти
Отидете направо до най-добрия инструмент - SQL мониторинг с активни отчети. Намерете своя SQL_ID и генерирайте HTML отчета:select dbms_sqltune.report_sql_monitor(sql_id => 'your_sql_id', type => 'active') from dual; . Това е единственият начин да разберете колко време е изразходвано за всяка стъпка от плана за изпълнение. И ще ви каже колко паралелизъм е бил ефективно използван и къде. Например:
Друга добра опция е type => 'text' . Не съдържа толкова много информация, но е по-бърза за разглеждане и по-лесна за споделяне.
Мониторингът на SQL също включва исканата DOP и разпределената DOP:
100-редов паралел select може да работи прекрасно, но тогава всичко спира на една стъпка поради некеширана последователност. Можете да гледате план за обяснение, следа или отчет за AWR с часове и да не видите проблема. Активният отчет прави бавните стъпки почти тривиални за намиране. Не губете време да гадаете къде е проблемът.
Въпреки това, все още са необходими други инструменти. План за обяснение, генериран с explain plan for ... и select * from table(dbms_xplan.display); ще предостави няколко ключова информация. По-конкретно Notes раздел може да включва много причини, поради които заявката не е поискала паралелизъм.
Но ЗАЩО получих този брой паралелни сървъри?
Съответната информация е разпределена в няколко различни ръководства, които са много полезни, но понякога са неточни или подвеждащи. Има много митове и много лоши съвети относно паралелизма. И технологията се променя значително с всяка версия.
Когато съберете всички реномирани източници, списъкът с фактори, влияещи върху броя на паралелните сървъри, е удивително голям. Списъкът по-долу е подреден приблизително според това, което според мен са най-важните фактори:
- Паралелизъм на операциите Всяка заявка, използваща сортиране или групиране, ще разпредели два пъти повече паралелни сървъри от DOP. Това вероятно е отговорно за мита „Oracle разпределя възможно най-много паралелни сървъри!
- Подсказка за заявка За предпочитане е намек на ниво израз като
/*+ parallel */, или евентуално намек на ниво обект като/*+ noparallel(table1) */. Ако конкретна стъпка от план се изпълнява последователно, това обикновено се дължи на подсказки на ниво обект само върху част от заявката. - Рекурсивен SQL Някои операции могат да се изпълняват паралелно, но могат да бъдат ефективно сериализирани чрез рекурсивен SQL. Например, некеширана последователност върху голяма вложка. Рекурсивният SQL, генериран за анализиране на израза, също ще бъде сериен; например заявки за динамични извадки.
- Промяна на сесията
alter session [force|enable] parallel [query|dml|ddl];Имайте предвид, че паралелният DML е деактивиран по подразбиране. - Таблица степен
- Индекс на степен
- Индексът беше по-евтин Паралелните намеци само казват на оптимизатора да обмисли пълно сканиране на таблица с определен DOP. Те всъщност не налагат паралелизъм. Оптимизаторът все още е свободен да използва сериен индексен достъп, ако смята, че е по-евтин. (
FULLнамек може да помогне за решаването на този проблем.) - Управление на планове Базови линии на SQL план, очертания, профили, разширено пренаписване и SQL преводачи могат да променят степента на паралелизъм зад гърба ви. Проверете секцията Забележка на плана.
- Издание Само Enterprise и Personal Edition позволяват паралелни операции. С изключение на пакета DBMS_PARALLEL_EXECUTE.
- PARALLEL_ADAPTIVE_MULTI_USER
- PARALLEL_AUTOMATIC_TUNING
- PARALLEL_DEGREE_LIMIT
- PARALLEL_DEGREE_POLICY
- PARALLEL_FORCE_LOCAL
- PARALLEL_INSTANCE_GROUP
- PARALLEL_IO_CAP_ENABLED
- PARALLEL_MAX_SERVERS Това е горната граница за цялата система. Тук има компромис. Пускането на твърде много паралелни сървъри наведнъж е лошо за системата. Но понижаването на заявка до серийно може да бъде катастрофално за някои заявки.
- PARALLEL_MIN_PERCENT
- PARALLEL_MIN_SERVERS
- PARALLEL_MIN_TIME_THRESHOLD
- PARALLEL_SERVERS_TARGET
- PARALLEL_THREADS_PER_CPU
- Брой RAC възли Друг множител за DOP по подразбиране.
- CPU_COUNT Ако се използва DOP по подразбиране.
- RECOVERY_PARALLELISM
- FAST_START_PARALLEL_ROLLBACK
- Профил
SESSIONS_PER_USERсъщо така ограничава паралелните сървъри. - Мениджър на ресурси
- Зареждане на системата Ако parallel_adaptive_multi_user е true. Вероятно е невъзможно да се отгатне кога Oracle ще започне да дроселира.
- ПРОЦЕСИ
- Ограничения за паралелни DML Паралелният DML няма да работи, ако някой от тези случаи:
- СЪВМЕСТИМ <9.2 за вътрешноразделен дял
- INSERT VALUES, таблици със задействания
- репликация
- целост на самореференция или изтриване на каскадни или отложени ограничения за целостта
- достъп до колона с обект
- неразделена таблица с LOB
- паралелизъм в рамките на дяла с LOB
- разпределена транзакция
- клъстерирани таблици
- временни таблици
- Скаларните подзаявки не се изпълняват паралелно? Това е в ръководството и ми се иска да беше вярно, но моите тестове показват, че паралелизмът работи тук в 11g.
- ENQUEUE_RESOURCES Скрит параметър в 10g, това актуално ли е вече?
- Индексно организирани таблици Не можете да вмъкнете паралелно директен път към IOT? (Вярно ли е това?)
- Изисквания за паралелни конвейерни функции Трябва да използвате
CURSOR(?). ЗАДАЧИ. - Функциите трябва да са PARALLEL_ENABLE
- Тип изявление По-старите версии ограничаваха паралелизма на DML в зависимост от разделянето. Някои от текущите ръководства все още включват това, но със сигурност вече не е вярно.
- Брой дялове Само за присъединяване на дялове в по-стари версии.(?)
- Бъгове По-конкретно, видях много грешки при анализа. Oracle ще разпредели точния брой паралелни сървъри, но нищо няма да се случи, тъй като всички те чакат събития като
cursor: pin s wait on x.
Този списък със сигурност не е пълен и не включва функции 12c. И не разглежда проблеми с операционната система и хардуера. И не отговаря на ужасно трудния въпрос "коя е най-добрата степен на паралелизъм?" (Кратък отговор:повече обикновено е по-добре, но за сметка на други процеси.) Надяваме се, че поне ви дава представа колко трудни могат да бъдат тези проблеми и е добро място да започнете да търсите.
