Vraag Problemen met het Oracle-opgehangen proces oplossen


Ik probeer een probleem te begrijpen dat we hebben met een Java-proces dat loopt. Dit proces is ongeveer 4 maanden in productie en eerder deze week begon het te hangen. Wanneer ik naar een threaddump van het proces kijk, hebben alle relevante threads (3) stacks zoals de volgende:

    "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)

Er wachten geen threads op vergrendelingen, dus het proces loopt niet vast. Deze 3 threads die het werk doen, worden gewoon geblokkeerd in afwachting van een reactie van Oracle, zo ziet het er tenminste voor mij uit.

Als ik naar Oracle kijk, lijkt het erop dat een van de verbindingen die aan deze threads zijn gekoppeld, op dit moment een query uitvoert, hoewel ik de SQL niet kan zien.

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

Mijn vragen zijn:

  1. Heb ik in mijn analyse gelijk dat het proces gewoon geblokkeerd is in afwachting van een reactie van Oracle?
  2. Waar moet ik naar zoeken in Oracle om te begrijpen waarom dit proces blokkeert?

bijgewerkt:

Gebaseerd op de opmerking over zoeken in DBA_WAITERS en DBA_LOCKS

select * from dba_waiters;

no rows selected

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

no rows selected 

Er waren 98 rijen in dba_locks maar omdat ze allemaal 'Niet blokkeren' zijn, denk ik niet dat het een sluitingsprobleem is? Het proces in kwestie bevindt zich al meer dan 3 uur in deze staat, zodat nu een impasse gedetecteerd zou zijn.

Ik ben van de theorie dat het exemplaar van Oracle niet "gezond" is, maar ik heb geen idee waar ik naar moet kijken. Ik heb een verzoek om de Oracle-server opnieuw op te starten, maar dat is nog niet gebeurd.

Vervolgvraag: Is het normaal dat de v $ -sessie een sql_id bevat die niet bestaat in v $ sql en, zo ja, onder welke voorwaarden?


17
2017-07-26 16:36


oorsprong


antwoorden:


Het probleem was opgelost en het antwoord lag in de tabel v $ session. Blijkbaar kunnen Oracle-sessies blokkeren om andere redenen dan alleen vergrendeling. Let op de kolom FINAL_BLOCKING_SESSION - deze identificeert de sessie die de oorzaak van de blokkering is. We hebben sessie 845 onderzocht en vastgesteld dat het clientproces (geïdentificeerd door MACHINE en PORT) niet langer bestond. De DBA doodde sessie 845 en alle keerde terug naar normaal.

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

9
2017-07-27 14:42



Ik ben dit probleem onlangs tegengekomen en gebruikte deze query om vergrendelings- / vergrendelingssessies te vinden in 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;

Bron: http://www.dba-oracle.com/t_final_blocking_session_final_blocking_instance.htm


2
2018-04-11 04:50



Als de instantie zelf "ongezond" is, moet het opnieuw opstarten van de Oracle-server dat herstellen en het terugbrengen naar de gezonde staat. Tot die tijd kon u een HTTP Load Balancer configureren om de status van verschillende instanties te controleren door een URL te pollen en een resultaat tussen 100 en 500 voor een gezonde sessie te retourneren.


-3
2017-07-26 18:31