Исходное сообщение
"Проект CentOS снова в строю" Отправлено Еще один аноним, 04-Авг-09 10:58
Ну, если вы работали с СУБД, то наверное пояснения вам не должны были понадобиться. Жесткий разбор - это когда каждый раз SQL-машине приходится заново полностью разбирать SQL-выражение и строить план выполнения запроса, что оказывается таки забирает сравнительно много времени и ресурсов, особенно когда запросов много. Чаще всего такое происходит когда массировано используется склеивание строки запроса и значений ( " ... where t.id=12345 ") и не используются переменные биндинга в которые и должны передаваться значения запроса (" ... where t.id=:aId "). В Оракле каждый новый поступивший запрос хэшируется и по коду хэша в кэше ищется среди уже синтаксически разобранных и спланированных запросов. Если нашли - то пользуемся готовыми результатами разбора. А вот насчет дата-брокера с последовательным доступом могу только предполагать. Вероятнее всего там ошибки в архитектуре приложения, например, этот дата брокер, который должен обслуживать множество клиентов, желательно одновременно, для запроса использует конструкцию SELECT ... FOR UPDATE и когда обращения от разных пользователей происходят к одной таблице то первый счастливчик лочит нужные записи (или все записи таблицы, зависит от условия отбора строк), а второй висит на ожидании блокировки этих же строк (или всех строк в самом неудачном случае), т.е. ждет пока первый завершит транзакцию. Получается последовательная работа множества клиентов.