Доступ к базе данных в параллельных потоках, жизнеспособный вариант?

Question

У меня следующая ситуация

main()
{

   hnd = CreateTHread( func1 );

   // Call fun2()

   wait(hnd);

   return ;

}


fun2()
{
  //Access database to perform some read operation on TAble A
}


func1()
{

//Access database to perform some read operation on TAble A
// Recursive operations
}

То, что я заметил, это то, что fun2() занимает больше времени, если я использую многопоточность. Может быть, так как THread func и fuc2 работают на одном столе. Обратите внимание, что в обеих функциях есть только операция чтения. Предполагается, что в отчете AWR количество обработок запросов увеличилось при использовании подхода с многопоточностью

Answer 1

Попробуйте изменить уровень изоляции на READ COMMITTED и выполнить запросы с READ ONLY «предложением». Он должен быть менее строгим и позволять читать одни и те же таблицы одновременно.

Answer 2

Попробуйте использовать два разных соединения.Многопоточность одного и того же подключения к одной и той же таблице всегда будет ухудшать производительность, вы делаете ударение на самом соединении.Вы не сказали, к какому драйверу вы обращаетесь, но я протестировал аналогичный подход с драйвером JDBC в Oracle 10 и имел снижение производительности. Я предполагаю, что команды SQL несколько конвейеризуются одна за другой, если вы используете одно и то же соединение.

Answer 3

Аналогичный вопрос - Многопоточный доступ на чтение базы данных

Интерфейсы Oracle JDBC, а также собственные драйверы Oracle (я полагаю) способны обрабатывать многопоточные запросы (* 1006)*)

Однако, когда дело доходит до реализации в ядре базы данных - это не ясно.Из текущей документации я понимаю, что до тех пор, пока ваш запрос ЧИТАЕТСЯ ТОЛЬКО без намерения обновить, блокировка не произойдет, и вы должны увидеть повышение производительности (по крайней мере, незначительное).

Однако существует много других факторов, которые определяют, будет ли двигатель использовать параллелизм.Аппаратная конфигурация сервера (многоядерная) и т. Д. Также может определять, прибегает ли механизм запросов к параллельному или очереди.

Кстати, сколько различий во времени вы наблюдаете в обоих подходах, которые вы пробовали.Какова была величина ваших данных?

Answer 4

Параллельность всегда заставляет вас терять производительность. Если вам нужен параллелизм, вам придется жить с этим; Если вам это не нужно, вы не должны его использовать!

Некоторые операции в SQL, такие как «count», выполняют LOCKs в таблицах. Можете ли вы поделиться своим SQL?