Просто аврал! Очень нужна помощь!

На работающем проекте на одном сервере находятся маленькие веб-проекты - десятка 4 страничек с формами. На другом сервере (в локальной сети) находится база. Все как бы работало нормально.
Но сейчас что-то случилось и коннект к базе происходит секунд 30-60 (был мгновенный). Раньше могло возникнуть иногда исключение типа такого:
java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Но это было достаточно редко и допускаю, что из-за огромного количества параллельных запросов (коннекшн к базе происходит с каждой странички - jsp-шки, а также из сервлетов) - иногда до 20-30 в секунду.
Я их уговарию на переделку проекта - сделать одно соединение с кешем, чтобы через него шли запросы. Но пока ломаются, да и решить проблему надо срочно.

Например, на первой же странице код такой:



В чем может быть дело, подскажите. Ну очень нужно - висим!

Да знаю, что нормально. И все проверено - все как раньше.
Но вот каждое соединение до минуты делается - никуда не годится.
Там, правда, дата-сервер голимый - старый и в последний раз переставлялся в 2006-ом году. Но ведь еще пару недель назад все работало нормально. Правда, меня смущает, что в панели задач SQL Server кушает почти 2 гига памяти.
В чем дело - ума не приложу.

P.S. Да, архитектурка криворукая - делалась под одну страничку, а за 2 года их уже 40. Если бы платили за то, что надо - все было бы пучком. Но экономят на этом. Вот и проблемы рисуются.

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

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

Таким образом, вопрос о пуле открытый - я поддерживаю и вижу выигрыш, да и правильно это. Их планы - до 400 таких подпроектов на сервере. Если на 40 такие лажи, то больше не потянет точно. В пиковые моменты в секунду заходит около 30 человек, а в каждом подпроектике 4 страницы, на каждой из которых есть коннект к базе, а также 3 сервлета, где также присутствуют коннекты. То есть если человек зашел и находится на сайтике, то он может осуществить до 7 коннектов к базе. Ужасно бестолково - это я и сам понимаю, но надо знать как это начиналось, как делалось и какие вопросы решались. Сделать я хочу, но бесплатно - "нафига козе баян"?

А вот проблема присутствует.
Думали, что они подключили какие-то views на базу ... нету. Изменения не вносились. Правда, пару недель база сама перешла в монопольный режим ... почему, непонятно. Исправили, перегрузили.

Вчера откатили базу на начало декабря. Вроде лучше, но тормоза присутствуют все равно.
Место на компе есть точно, беки почистили. Локалка работает нормально - никаких нюансов не замечено, firewall ничего не блокирует.
На страницах присутствовали скрипты для гугловской статистики. Но из-за длительности работы скрипта по коннекту к базе не грузятся. Пока повыкидывал их. Та же фигня.
Брал первую страничку и комментировал коннект к базе. При обращении к страничке срабатывает мгновенно. Убираю коннект - тормоза. То есть проблема точно локализована - это база.
На БД-сервере баз дофига и больше, комп старый, WinServer 2000 и SQL Server 2000 - тоже древний. Но все работало достаточно стабильно и нормально, а тут вдруг такой облом. Главное, что неизвестно что происходит, как решить и как застраховаться на будущее (точнее, понятно - новый сервак и грамотная архитектура).
Загрузка памяти высокая, но процы как на веб-сервере, так и на дата-сервере, не загружены - тут все нормально.

vimbaЧито? Вы предлагаете одну одновременно выполняющаяся транзакция или один одновременный запрос к базе на выборку?
Я бы не то что ломался, а просто пристрелил бы вас на месте или выслал бы за вами киллера в Россию, тут достаточно как вам выше уже указали ввести пул соединений, чтобы коннекшн не открывался при каждом запросе, а брался готовый из пула, ну и когда база слишком уж удалена от сервера приложений это тоже не гуд, нужно с этим что-то в дальнейшем делать, например вводить WEB сервисы, потому как JDBC некошерно себя ведёт когда СУБД далеко от сервера приложений.
Читай внимательнее. Речь идет о переделке архитектуры под пул запросов.

P.S. Россия? - Упаси боже!

Petro123vimba, :)
когда будет флейм про ОРМ, ты скажешь что: "без ОРМ пишут ламеры". Нужен ОРМ.
ЗЫ.
Аффтар - надоест - дай знать.
Даю знать!
Воспользовался советами, пооптимизировал базы, поубирал логи в соответствующих таблицах, поработал с сервером - вроде значительно лучше.
Всем огромное спасибо, вроде проблема отошла ... пока.