Назад | Перейти на главную страницу

Учетная запись Oracle не отвечает

У меня есть экземпляр Oracle с учетными записями user1, user2 и user3. Вчера я смог войти во все три аккаунта. Сегодня я могу войти в user1 и user3, но user2 полностью «заморожен» каким-то образом, которого я не понимаю.

Если я попытаюсь войти в user2 с помощью sqlplus, он будет вращаться вечно. Он не подключается, не истекает время ожидания, ничего не происходит, пока я не нажму CTRL + C, чтобы убить процесс. Подключение от имени пользователя user1 или user3 происходит мгновенно.

Я думал, что попробую заблокировать user2, а затем попробовать его разблокировать. Запрос на блокировку пользователя выполнялся 25 минут, прежде чем я сдался! Блокировка user1 и затем разблокировка user1 выполнялись мгновенно.

С помощью ЖАБА и подключившись как администратор базы данных, я использовал Session Browser для исследования. Я нашел 11 подключений к базе данных как user2. Пять из них, похоже, были моими неудачными попытками подключения с помощью sqlplus. Ни одно из этих подключений не показывает никаких открытых курсоров, текущего оператора или каких-либо блокировок. На вкладке ожидания 10 подключений показывают «блокировку кеша строк» ​​с:

Одно из соединений выделяется тем, что кажется очень старым. Он показывает "сообщение SQL * Net от клиента" с:

Я не могу убить ни одну из этих 11 сессий. После того, как я ввожу команду kill (с помощью TOAD, с возможностью немедленного выполнения или без нее), она выполняется в течение 45-60 секунд, а затем сообщает: «Сессия отмечена для уничтожения». но сеанс никогда не уходит.

Есть идеи, что это означает или как я могу убить эти сеансы и восстановить доступ к учетной записи user2?

Обновить: В журнале предупреждений было несколько интересных строк:

Вт 29 дек, 09:37:45 2009 г.
ВНИМАНИЕ: время ожидания входящего соединения истекло (ORA-3136)
Вт 29 дек 10:25:45 2009
>>> WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! pid=17
System State dumped to trace file [snip]\udump\ora_1988.trc
Tue Dec 29 10:54:17 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 10:55:47 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 10:56:47 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 10:57:47 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 11:12:17 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 12:06:17 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 12:26:47 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 12:27:47 2009
WARNING: inbound connection timed out (ORA-3136)
Tue Dec 29 13:46:17 2009
WARNING: inbound connection timed out (ORA-3136)
Wed Dec 30 10:02:16 2009
>>> СЛИШКОМ ДОЛГО ЖДАЛ БЛОКИРОВКИ РЯДНОГО КЭША ENQUEUE LOCK! pid = 37
Состояние системы выгружено в файл трассировки [snip] \ udump \ ora_2860.trc
Ср 30 декабря 11:55:59 2009
orakill: попытка убить tid = 436
Ср 30 дек, 11:56:04 2009
orakill: ssthreadkill (tid = 436) не удалось получить мьютекс списка потоков: err = 0

разрешение: Похоже, это ошибка 10.2.0.3, и мне нужно перезапустить экземпляр, на что у меня нет разрешения, поэтому мне придется подождать несколько дней.

Попробуйте следующее:

select s.username, s.sid, p.spid 
  from v$session s join v$process p on addr=paddr
where s.username = 'USER2';

Используя значение spid из приведенного выше запроса, войдите на сервер и введите следующую команду из командной строки DOS:

orakill YOURSID spid

YOURSID - это SID экземпляра базы данных, с которым вы имеете дело.

orakill часто работает, когда инструменты графического интерфейса не могут убить процессы. Вот хороший обзор orakill. Обратите внимание на причину №1 для использования orakill - она ​​может объяснить, почему вы не можете использовать свой инструмент с графическим интерфейсом:

Оператор alter system не снимает существующие блокировки. Вместо этого сеанс будет оставаться подключенным до тех пор, пока не истечет время ожидания, затем сеанс будет завершен и блокировки будут сняты. Команда orakill мгновенно убьет поток и блокировки.

Обновить:

Вы также можете попробовать:

select sid, serial#, program from v$session;
alter system kill session '<SID>,<SERIAL#>' immediate;

хотя я бы не питал больших надежд ...