![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
Друзья! У нас с чего-то вдруг начал сдыхать Оракл. Буквально доходит до того, что простейший запрос (да, схема простейшая трехзвенная клиент-JBoss-оракл девятка) загружает процессор на 100% и все замирает в предвкушении его завершения.
Ткните пальцем либо в сообщество, либо в книжку (да, есть Manual'ы по Ораклу, но там вообще всё плохо. Не понятно куда можно посмотреть, чтобы понять хотя бы, где узкое место и что именно тормозит). Либо, что было бы идеально — нет ли тут человека, который за адекватное вознаграждение придет, покажет и расскажет вкратце что и как нужно делать, чтобы оно заработало.
Всем спасибо. :) Прошу прощения, что не совсем по теме сообщества, но более адекватного места сходу не знаю.
Update:
Всем огромное спасибо, доковырялись, нашли нужный отсутствующий индекс, вставили, заработало.
(комментировать)
(комментировать)
Ну, технически есть ![[info]](http://l-stat.livejournal.com/img/community.gif)
ru_oracle. :)
ru_oracle. :)Да, спасибо. Но фиг знает, может в контексте JBoss'а и всего остального есть спец-мысли?
Может попробовать смигрировать а Oracle 10-ку? Какой смысл 9-ку гонять?
Ох, я бы с удовольствием. Но тут условие такое. Так что паримся вот так как есть.
1. Сначала разебритесь кто тормозит: JBoss или Oracle
(подымите Оракл на другой машине или просто в top посмотрите - кто CPU жрет)
потому как JBoss умеет глючить и сам по себе (впрочем как и Оракл)
А потом уже действительно можно будет что-то думать. (делать следующие выводы)
2. Если Oracle, то действительно постарайтесь мигрировать на 10: там в enterprise manager-е можно посмотреть на источники загрузки процессора ничего не зная.
(подымите Оракл на другой машине или просто в top посмотрите - кто CPU жрет)
потому как JBoss умеет глючить и сам по себе (впрочем как и Оракл)
А потом уже действительно можно будет что-то думать. (делать следующие выводы)
2. Если Oracle, то действительно постарайтесь мигрировать на 10: там в enterprise manager-е можно посмотреть на источники загрузки процессора ничего не зная.
Они на разных машинах, тормозит оракл.
Десятка пока невозможна, к сожалению.
Десятка пока невозможна, к сожалению.
Поставьте себе какое-нибудь средство типа PL/SQL Developer. Посмотрите список сессий и выделите из них активные и работающие через JBoss (по имени пользователя например). Потом посмотрите текущий запрос активной сессии. Если будет висеть один и тот же запрос долгое время, то скорее всего проблема в его оптимизации. Еще посмотрите статистику по сессии - там будет видно чем она в основном занимается.
Общий план действий при поиске проблем с РСУБД всегда начинается с просмотра плана выполнения проблемного запроса. Имея на руках план можно увидеть причины и искать пути их устранения. конкретно для оракла попробовать получить план выполнения запроса можно с помощью этой ссылки http://www.idevelopment.info/data/Oracl
Тут проблема в том, что, например, 100 инсертов занимают 20 секунд. Таблица — 3 поля, инсерт — само понятно, элементарный.
Так что с планом выполнения тут всё уже ясно.
Так что с планом выполнения тут всё уже ясно.
0. купить валидол
1. проверить имеющиеся блокировки, повисшие сессии, свободное место в табличных пространствах и прочую хню
2. пересобрать статистику
3. думать, думать и думать
1. проверить имеющиеся блокировки, повисшие сессии, свободное место в табличных пространствах и прочую хню
2. пересобрать статистику
3. думать, думать и думать
Валидол это правильно.
Посмотрели, закончилось место в Tablespace TEMP. Что бы это значило, не понятно, но попробуем. Возможно это именно то, что нужно. Спасибо.
Посмотрели, закончилось место в Tablespace TEMP. Что бы это значило, не понятно, но попробуем. Возможно это именно то, что нужно. Спасибо.
Неа, либо мы до конца не пересоздали этот темп, либо ему все пофиг. Завтра попробуем просто создать базу с нуля, посмотрим, может это вообще в железке какой дело…
1. Посмотрите активные сессии (можно на sql можно Toad поробовать у него самая удобная управлялка)
2. Если проблема найдена не будет в пункте 1, то
3. В том же тоаде можно посмотреть какие стадии запроса выполняются дольше всего (например ожидание блокировок, запись на диск и проч)
Далее есть уже варианты:
Если у вас с дисками все нормально, но пишется все равно очень долго стоит посмотреть как дела с кол-вом переключений файлов журнала (redo logs) например они могут быть слишком маленькими и туда не помещаются все транзакции
Но вариантов может быть очень много, и это зависит именно от того какие части выполнения запроса у вас тормозят
2. Если проблема найдена не будет в пункте 1, то
3. В том же тоаде можно посмотреть какие стадии запроса выполняются дольше всего (например ожидание блокировок, запись на диск и проч)
Далее есть уже варианты:
Если у вас с дисками все нормально, но пишется все равно очень долго стоит посмотреть как дела с кол-вом переключений файлов журнала (redo logs) например они могут быть слишком маленькими и туда не помещаются все транзакции
Но вариантов может быть очень много, и это зависит именно от того какие части выполнения запроса у вас тормозят
Да, спасибо. Все идет к тому, что где-то кончилось какое-то место. Ибо (как я уже говорил) инсерт трех полей, повторенный 100 раз тормозить не может в принципе.
А как в тоаде посмотреть эти стадии запроса?
И за реду лог тоже спасибо, туда мы еще не глядели.
А как в тоаде посмотреть эти стадии запроса?
И за реду лог тоже спасибо, туда мы еще не глядели.
в тоаде можно посмотреть статистику по сессии, те вы выполняете несколько раз запрос и смотрите что у вас занимает больше всего времени (возможно так можно и для запроса отдельного делать, но я уже все забыл). По сессии статистика в session manager (вроде так называется)
Не знаю как в конкретно тоаде, а вообще есть вьюха v$sql_plan_statistics_all с крайне полной информацией о всех стадиях. Не уверен, что есть в 9, но в 10g там 65 колонок.
В темпе хранятся служебные части, но туда пишутся данные в основном когда вы извекаете данные (оно используется для сортировки)
Посмотрите
v_$session - user session information
v_$sesstat - user session statistics
что там смотреть х.з. но может какие-то мысли появятся
Еще сть SQL Developery оракловскому плагин которыйй визуализирует работу бд т.е. показывает загруженость кешей, данные на шинах, закгрузку цпу.
v_$session - user session information
v_$sesstat - user session statistics
что там смотреть х.з. но может какие-то мысли появятся
Еще сть SQL Developery оракловскому плагин которыйй визуализирует работу бд т.е. показывает загруженость кешей, данные на шинах, закгрузку цпу.
А вот за последнюю подсказку особо спасибо, не знал — это, возможно, будет очень и очень полезно.
2008-04-22 13:55 (UTC)