1
Недавно я заметил множество параллельных запросов (создайте таблицу как выбор ...), которые вызывают совпадение высокой синхронизации кеша библиотеки.Библиотека Блокировка кэша в параллельных операциях
В следующем вопросе Михаил заявил, чтобы остерегаться библиотеки блокировок кэша в долго выполняющиеся CTAS в виде
create table <new_table_name> parallel <partitioning_info> as select * from <old_table_name> where <filter>;
Faster way to load huge data warehouse table
Так почему же это? Соотношение жесткого разбора очень мало. Это проблема, потому что все сеансы пытаются найти план выполнения в кеше библиотеки? Я думал, что при мягком разборе есть только булавка на объекте кеша библиотеки?
Единственный раз, когда я помню, что CTAS вызывал проблему блокировки, были некоторые ошибки с чрезвычайно высокими параллельными градусами. Возможно, вы захотите проверить свои параметры и посмотреть, как будет выглядеть «PARALLEL». Вероятно, это комбинация узлов RAC * cpu_count (параметр) * parallel_threads_per_cpu (параметр). Или, возможно, предложение partitioning создает огромное количество разделов. Не могли бы вы добавить дополнительную информацию о заявлениях? –
Кроме того, это помогло бы иметь реальные цифры для ожиданий. Повторно запустите инструкцию, найдите SQL_ID и сгенерируйте отчет о мониторинге SQL, запустив 'select dbms_sqltune.report_sql_monitor (sql_id => '$ ADD_SQL_ID_HERE') из dual;'. Добавьте к этому вопросу все содержимое этого отчета. –