SQL Plus по сравнению с Toad IDE — запуск вставки в SQL Plus занимает значительно больше времени

Это звучит так, как будто здесь замешано что-то еще. Я бы предположил, что ваш сеанс SQL * Plus блокируется. Можете ли вы проверить v$lock, чтобы убедиться, что это так? Существует множество скриптов/инструментов, чтобы проверить, на что в данный момент тратится время вашего сеанса. Выясните это, а затем идите оттуда. Лично мне нравится сценарий Snapper Танела Подера (http://tech.e2sn.com/oracle-scripts-and-tools/session-snapper).

Это может быть тысяча вещей. (@John Gardner: Это одна из причин, почему я не большой поклонник dba.stackexchange.com — вы не узнаете, проблема ли это в программировании или в администраторе баз данных, пока не узнаете ответ. Я думаю, будет лучше, если мы все работают вместе на одном сайте.)

Вот несколько идей:

• Различные настройки сеанса — параллельный dml и параллельный запрос могут быть включены, принудительно или отключены. Посмотрите на свои сценарии входа или посмотрите информацию о сеансе с помощью select pdml_stats, pq_status, v$session.* from v$session;
• Замок, как предложил @Craig. Хотя я думаю, что проще посмотреть на select v$session.blocking_session, v$session.* from v$session; для идентификации блокировок.
• Отложенная очистка блока сделает второй запрос медленнее. Беги с set autotrace on. db block gets и redo size, вероятно, больше во второй раз (во втором операторе есть дополнительная работа, хотя этого, вероятно, недостаточно, чтобы объяснить разницу во времени).
• Буферный кеш может ускорить второй запрос. Запустите с set autotrace on, может быть большая разница в physical reads. Хотя с таким большим количеством данных вероятность того, что большая часть данных будет кэширована, невелика.
• Другие сеансы могут занимать много ресурсов. Посмотрите на select * from v$sessmetric order by physical_reads desc,logical_reads desc, cpu desc; Или, может быть, посмотрите на v$sysmetric_history.
• Возможно, вы захотите рассмотреть параллельные и добавочные подсказки. Вы, вероятно, можете заставить этот запрос выполняться в 10 раз быстрее (хотя у этого подхода есть некоторые недостатки, такие как невозможность восстановления данных изначально).
• Кроме того, для тестирования вы можете использовать меньшие размеры. Запустите вставку с чем-то вроде and rownum <= 10000. Настройка производительности очень сложна, очень помогает, если вы можете часто запускать операторы. Всегда есть некоторые случайности, и вы хотите игнорировать выбросы, но вы не можете сделать это только с двумя выборками.
• Вы можете просмотреть некоторые подробные статистические данные для каждого запуска, но вам может потребоваться выполнить запрос с помощью INSERT /*+ GATHER_PLAN_STATISTICS */.... Затем запустите это, чтобы найти sql_id: select * from v$sql where sql_text like '%INSERT%GATHER_PLAN_STATISTICS%'; Затем запустите это, чтобы просмотреть детали каждого шага: select * from v$sql_plan_statistics_all where sql_id = '<sql_id from above>'; (В 11g вы можете использовать v$sql_monitor или, что еще лучше, dbms_sqltune.report_sql_monitor.)

Действительно очевидный момент, но, как известно, люди сбиваются с толку... есть ли какие-либо индексы на tableA; если да, то являются ли они уникальными; и если да, то вы зафиксировали или откатили сеанс Toad, прежде чем снова запускать его в SQL * Plus? Не делать этого - это простой способ получить блок, как предлагает @Craig. В этом сценарии он никогда не завершится - ваше 40-минутное ожидание - это блокировка при вставке первой строки.

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

Как уже предполагали другие люди, есть много вещей, которые могут привести к тому, что оператор, который выбирает/вставляет такое количество данных, будет работать плохо (и непоследовательно). Хотя я иногда видел, как Toad делает что-то для повышения производительности, я никогда не видел, чтобы он делал что-то настолько намного быстрее, поэтому я склонен думать, что это больше связано с базой данных, а не с инструментом.

Я бы попросил администраторов баз данных проверить ваш сеанс и базу данных, пока работает медленное выражение. Они должны быть в состоянии дать вам некоторое представление о том, что происходит — они смогут проверить наличие любых проблем, таких как блокировка или чрезмерное переключение файлов журнала. Они также смогут отслеживать оба сеанса (Toad и SQL Plus), чтобы увидеть, как Oracle выполняет эти операторы, и есть ли какие-либо различия и т. д.

В зависимости от того, что вы делаете, они могут даже помочь вам запустить вставку быстрее. Например, может быть быстрее отключить индекс, выполнить вставку, а затем перестроить его; или можно временно отключить ведение журнала. Это, очевидно, будет зависеть от вашего точного сценария.