SQL Plus против жабы IDE - Запуск вставки в SQL Plus занимает значительно больше

Question

Я бегу запрос, как это:

INSERT INTO TableA (colA, colB) 
Select ColA, ColB 
from TableB 

Это огромная вставка, как она запрашивая более 2 миллионов строк затем вставлять их в таблицу. Мой вопрос касается производительности. Когда я запускаю запрос в toad, запрос занимает около 4-5 минут для запуска.

Когда я запускаю запрос через sqlplus, он занимает больше времени. Он уже работает 40 минут +, и он еще не закончен. Я даже сделал небольшую настройку, установив выход сервера на случай, если это повлияло на производительность.

Есть ли какая-либо настройка, которую я должен знать о выполнении запроса через sqlplus? Есть ли способ узнать разницу в том, как выполняется или обрабатывается запрос разными клиентами?

Примечание: Это единственный способ передать данные из таблицы A в таблицу B. Я изучил imp/exp и impdp/expdp, и это невозможно в моей ситуации.

жаба. - v 9.6.1.1 Sqlplus - 9.2.0.1.0 Oracle DB - 10г

Answer 1

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

Answer 2

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

Вот некоторые идеи:

• Различные настройки сеанса - параллельный 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%'; Затем запустите это посмотреть на детали каждого шага: (. В 11g, вы можете использовать V $ sql_monitor, или даже лучше, dbms_sqltune.report_sql_monitor) select * from v$sql_plan_statistics_all where sql_id = '<sql_id from above>';

Answer 3

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

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

Answer 4

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

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

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