在Oracle數據庫中，掛起（hang）指某一個進程由於無法獲得申請的資源而進入的等待狀態，這種等待狀態只有在獲得申請的資源後才能夠解除，HM實現對hang的管理，包括了對於hang的監控，分析，記錄和解決。
hang的情況分爲兩類：死鎖（Dead Lock）和等待鏈（Wait Chain）
死鎖的發現方式
步驟1：每個實例的LMD進程定期（默認爲10s）申請DI資源，獲得DI資源的LMD進程會搜索各個實例沒有被滿足的鎖請求，並繪製鎖的等待鏈路。
步驟2：如果LMD進程發現存在閉合環路（死鎖）的存在，那麼就會將導致這個環路的進程的當前DML語句回滾，以解決死鎖，並釋放資源，如果沒有發現死鎖，也會釋放資源。
DI資源在整個數據庫層面是唯一的，目的是爲了確保在整個數據庫層面只能有一個LMD進程執行死鎖發現過程
等待鏈是由阻塞進程和等待進程構成的，而阻塞進程中會存在一個或多個根阻塞進程，這個進程阻塞了所有的其他進程，如果根阻塞進程正在忙於一些操作，那麼也許這種等待鏈的出現是正常的，如果阻塞進程處於空閒狀態，那麼也許這種等待鏈的出現就是不正常的，而打破等待鏈的方法，就是終止根阻塞進程。HM能夠主動發現數據庫中存在的等待鏈，並從對個角度對它們分析，如果發現了真正影響數據塊性能的hang，會根據具體的情況來決定是否要解決問題，而且即使不能直接解決，也會將相應的診斷信息記錄下來並持續監控。
HM的工作由七個階段構成
階段1（蒐集階段）：在這個階段，每個實例的dia0進程會定期蒐集hang analyze信息。
階段2（發現階段）：在這個階段，每個實例的dia0進程會分析蒐集到的hang alalyze信息，找到出現hang的會話，併發送給主節點的dia0進程。
階段3（繪製階段）：在這個階段，主節點的dia0進程根據每個實例的dia0進程發送過來的信息，繪製等待鏈。
階段4（分析階段）：在這個階段，主節點dia0進程根據繪製的等待鏈，分析是否的確出現了hang。
階段5（驗證階段）：在這個階段，主節點dia0進程會再次執行階段1-4，之後將階段4的分析結果和這一次的分析結果進行對比，驗證是否真的發生了hang。
階段6（定位階段）：在這個階段，主節點dia0進程更加驗證階段的結果定位到等待鏈的根阻塞進程。
階段7（解決階段）：在這個階段，主節點dia0進程根據參數_hang_resoluton_scope的值判斷hang是否能夠被解決。
HM的參數
_hang_detection_enabled：該參數決定HM特性在數據庫中是否被啓用，默認值爲true。
_hang_detection_interval：該參數指定HM蒐集hang analyze信息的時間間隔，默認值爲32s。
_hang_verification_interval：該參數指定HM驗證hang的時間間隔，默認值爲46s。
_hang_resolution_scope：該參數指定HM解決hang時能夠操作的範圍,默認值爲process，允許的值如下：
off：表示HM只會繼續監控hang,而不會做任何操作去解決hang。
process：表示HM可以通過終止根阻塞進程的方式來解決hang，但是這裏的根阻塞進程不能是數據庫重要的後臺進程，因爲這會導致實例crash。
instance：表示HM可以通過終止實例的方式來解決hang。
DIA0進程的跟蹤日誌文件
主跟蹤文件（<sid>_DIA0_<pid>.trc）：這個日誌文件會記錄dia0進程工作的詳細信息，包括髮現，分析，處理hang的過程。
歷史跟蹤文件（<sid>_DIA0_<pid>_n.trc）：由於dia0進程的跟蹤日誌文件會隨着數據庫的運行不斷產生信息，可能使這個日誌文件變得很大，dia0進程會定期將日誌信息寫到它的歷史日誌文件中，歷史日誌文件的n爲正整數，會隨着時間推移不斷增加。
incident日誌文件：如果HM通過終止進程方式來解決hang，會首先在alert.log中記錄ORA-32701錯誤，而由於ADR的存在，dia0進程同時會產生一個incident日誌文件記錄本次問題的詳細信息。
與hang相關的視圖
V$HANG_INFO：該視圖包含了HM發現的hang的詳細信息。
V$HANG_SESSION_INFO：該視圖包含了與hang相關的會話信息。
V$HANG_STATISTICS：該視圖包含了與hang相關的統計信息。