Устранение неполадок в Oracle - зависший процесс

17

Я пытаюсь понять проблему, с которой мы сталкиваемся с процессом Java, который висит. Этот процесс работает в производстве около 4 месяцев, а ранее на этой неделе он начал висит. Когда я смотрю на дамп потока процесса, все соответствующие потоки (3) имеют следующие стеки:

    "TxnParser_1" prio=6 tid=0x69bd3400 nid=0x2534 runnable [0x6aa2f000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:129)
        at oracle.net.ns.Packet.receive(Unknown Source)
        at oracle.net.ns.DataPacket.receive(Unknown Source)
        at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
        at oracle.net.ns.NetInputStream.read(Unknown Source)
        at oracle.net.ns.NetInputStream.read(Unknown Source)
        at oracle.net.ns.NetInputStream.read(Unknown Source)
        at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1099)
        at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1070)
        at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:478)
        at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:207)
        at oracle.jdbc.driver.T4CStatement.executeForDescribe(T4CStatement.java:790)
        at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1039)
        at oracle.jdbc.driver.T4CStatement.executeMaybeDescribe(T4CStatement.java:830)
        at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1132)
        at oracle.jdbc.driver.OracleStatement.executeInternal(OracleStatement.java:1687)
        at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:1653)
        - locked <0x40e22f88> (a oracle.jdbc.driver.T4CStatement)
        - locked <0x28f8d398> (a oracle.jdbc.driver.T4CConnection)
        at com.gcg.data.LogParsingInfo.initFromDB(LogParsingInfo.java:262)
        at com.gcg.om.OmQueueEntry.initParseInfoFromDB(OmQueueEntry.java:104)
        at com.gcg.om.GenericQueueEntry.run(GenericQueueEntry.java:237)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)

Нет потоков, ожидающих блокировок, поэтому процесс не зашел в тупик. Эти 3 потока, которые выполняют работу, просто заблокированы, ожидая ответа от Oracle, по крайней мере, это то, что мне кажется.

Глядя на Oracle, когда я запрашиваю v $session, похоже, что одно из соединений, связанных с этими потоками, в настоящее время выполняет запрос, хотя я не вижу sql.

select ... from v$session where ...;
SQL_ADDRESS      SQL_HASH_VALUE SQL_ID        SQL_CHILD_NUMBER SQL_EXEC_START SQL_EXEC_ID PREV_SQL_ADDR    PREV_HASH_VALUE PREV_SQL_ID   PREV_CHILD_NUMBER PREV_EXEC_START PREV_EXEC_ID
---------------- -------------- ------------- ---------------- -------------- ----------- ---------------- --------------- ------------- ----------------- --------------- ------------
              00              0                                                           0000000239F59EE8      1483377872 fqr8pndc6p36h                 5 26-JUL-12           32080545
              00              0                                                           0000000239F59EE8      1483377872 fqr8pndc6p36h                 5 26-JUL-12           32080546
0000000148CABD88     1784444892 a16hxxtp5sxyw                                             0000000239F59EE8      1483377872 fqr8pndc6p36h                 5 26-JUL-12           32080544

select * from v$sql where sql_id = 'a16hxxtp5sxyw';

no rows selected

Мои вопросы:

  • Правильно ли в моем анализе, что процесс просто заблокирован, ожидая ответа от Oracle?
  • Что я должен искать в Oracle, чтобы понять, почему этот процесс блокируется?

Обновлено:

На основе комментариев относительно поиска в DBA_WAITERS и DBA_LOCKS

select * from dba_waiters;

no rows selected

select * from dba_locks where BLOCKING_OTHERS <> 'Not Blocking';

no rows selected 

В dba_locks было 98 строк, но поскольку все они не блокируются, я не думаю, что это проблема блокировки? Процесс, о котором идет речь, находился в этом состоянии более 3 часов, поэтому любой тупик был бы обнаружен к настоящему времени.

Я полагаю, что экземпляр Oracle не "здоров", но я не понимаю, на что смотреть. У меня есть запрос на перезагрузку сервера Oracle, но это еще не сделано.

Последующий вопрос: нормально ли для v $session содержать sql_id, который не существует в v $sql, и если да, то при каких условиях?

  • 3
    "повесил" хе-хе-хе-хе;]
  • 1
    Это верно - мой процесс больше, чем ваш процесс. ;)
Показать ещё 3 комментария
Теги:
database

3 ответа

9
Лучший ответ

Проблема была решена, и ответ был правильным в таблице сеансов v $. По-видимому, сеансы Oracle могут блокироваться по причинам, отличным от просто блокировки. Обратите внимание на столбец FINAL_BLOCKING_SESSION - он идентифицирует сеанс, который является основной причиной блокировки. Мы исследовали сеанс 845 и обнаружили, что клиентский процесс (идентифицированный MACHINE и PORT) больше не существует. DBA убил сеанс 845, и все вернулись к нормальному.

SID     SERIAL# STATUS    PROGRAM          TYPE SQL_ID        PREV_SQL_ID    BLOCKING_SESSION_STATUS BLOCKING_INSTANCE BLOCKING_SESSION FINAL_BLOCKING_SESSION_STATUS FINAL_BLOCKING_INSTANCE FINAL_BLOCKING_SESSION EVENT
------- ------- --------- ---------------- ---- ------------- -------------- ----------------------- ----------------- ---------------- ----------------------------- ----------------------- ---------------------- ----------------------------
 108    22447   ACTIVE    Gcg log parser 1 USER               fqr8pndc6p36h  VALID                   1                 1581             VALID                         1                       845                    library cache: mutex X
 639    40147   ACTIVE    Gcg log parser 3 USER               fqr8pndc6p36h  VALID                   1                 1581             VALID                         1                       845                    library cache: mutex X
 742    34683   ACTIVE    Gcg log parser 2 USER a16hxxtp5sxyw fqr8pndc6p36h  VALID                   1                 1581             VALID                         1                       845                    library cache: mutex X
  • 0
    Не могли бы вы уточнить, как вы отфильтровали и определили, что эти три записи являются основной причиной блокировки? Что подарило их? У меня точно такая же проблема. Благодарю.
  • 1
    3 показанные записи не являются основной причиной - это сеансы Oracle из моего приложения, которые были заблокированы. Если вы прокрутите вправо и посмотрите на столбцы BLOCKING_SESSION и FINAL_BLOCKING_SESSION, вы увидите, что там есть значения SID. Когда мы исследовали SID 845 (FINAL_BLOCKING_SESSION), сеанс был для клиента, которого больше не было - по какой-то причине Oracle не смог обнаружить, что процесс клиента пропал.
Показать ещё 1 комментарий
2

Недавно я столкнулся с этой проблемой и использовал этот запрос для поиска блокировки/блокировки в Oracle:

select 
   inst_id||' '||sid||','||serial# inst_sid_s#, 
   username,
   row_wait_obj#||','||row_wait_block#||','||row_wait_row# obj_lck,
   blocking_session_Status||' '||blocking_instance||','||blocking_session blk_info,
   final_blocking_session_Status||' '||final_blocking_instance||','||final_blocking_session f_blk_info,
   event, 
   seconds_in_wait 
from 
   gv$session 
where 
   lockwait is not null
order by 
   inst_id;

Источник: http://www.dba-oracle.com/t_final_blocking_session_final_blocking_instance.htm

-3

Если сам экземпляр "нездоровый", то перезагрузка сервера Oracle должна исправить это и вернуть его в здоровое состояние. До тех пор вы можете настроить Балансировщик нагрузки HTTP, чтобы проверить работоспособность различных экземпляров, опросив URL-адрес и вернув результат от 100 до 500 для здорового сеанса.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню