[Windows]

判斷 Windows 上應用程式、指令及訊息的問題

如果您遇到 IBM® MQ 應用程式、指令及訊息的問題，您可以考量一些問題，以協助您判斷問題的原因。

關於此作業

請使用下列問題作為指標，以協助您識別問題的原因:

在您瀏覽清單時，請記下可能與問題相關的任何事項。 即使您的觀察沒有立即提出原因，但如果您需要進行有系統的問題判斷工作，則稍後可能會有用。

當您使用 IBM開啟案例時，可以包括您為了協助調查問題而收集的其他 IBM MQ 疑難排解資訊 (MustGather 資料)。 如需相關資訊，請參閱 收集 IBM 支援中心的疑難排解資訊。

程序

  1. 訊息是否無法抵達佇列?
    如果訊息未在您預期時送達，請檢查訊息是否已順利放入佇列:
    • 是否已正確定義佇列? 例如， MAXMSGL 是否足夠大?
    • 是否已啟用佇列放置?
    • 佇列是否已滿?
    • 是否有另一個應用程式取得佇列的專用存取權?
    也請檢查您是否能夠從佇列中取得任何訊息:
    • 您需要取得同步點嗎? 如果正在同步點內放置或擷取訊息，則在確定回復單元之前，其他作業無法使用這些訊息。
    • 您的等待間隔是否足夠長? 您可以將等待間隔設為 MQGET 呼叫的選項。 請確定您等待回應的時間足夠長。
    • 您是否在等待由訊息或相關性 ID (MsgId 或 CorrelId) 識別的特定訊息? 請確認您正在等待具有正確 MsgId 或 CorrelId的訊息。 成功的 MQGET 呼叫會將這兩個值設為所擷取訊息的值，因此您可能需要重設這些值，才能順利取得另一個訊息。 此外，請檢查您是否可以從佇列取得其他訊息。
    • 其他應用程式可以從佇列取得訊息嗎?
    • 您預期的訊息定義為持續性嗎? 如果沒有，且 IBM MQ 已重新啟動，則訊息已遺失。
    • 是否有另一個應用程式取得佇列的專用存取權?
    如果您找不到佇列的任何錯誤，且 IBM MQ 正在執行中，請檢查您預期將訊息放入佇列的處理程序，以取得下列各項:
    • 應用程式是否已啟動? 如果應該已觸發它，請檢查是否已指定正確的觸發選項。
    • 應用程式已停止嗎?
    • 觸發監視器是否在執行中?
    • 是否已正確定義觸發程式程序?
    • 應用程式是否正確完成? 在工作日誌中尋找異常結束的證明。
    • 應用程式已確定其變更，還是已取消?

    如果多個交易負責處理佇列，則它們可能會彼此衝突。 例如，假設一個交易發出緩衝區長度為零的 MQGET 呼叫，以找出訊息的長度，然後發出指定該訊息 MsgId 的特定 MQGET 呼叫。 不過，在此期間，另一個交易會針對該訊息發出成功 MQGET 呼叫，因此第一個應用程式會收到原因碼 MQRC_NO_MSG_AVAILABLE。 預期在多伺服器環境中執行的應用程式必須設計成處理此狀況。

    請考量可能已收到訊息，但您的應用程式無法以某種方式處理該訊息。 例如，訊息預期格式的錯誤是否導致您的程式拒絕它? 如果是的話，請參閱這個主題中的後續資訊。

  2. 訊息是否包含非預期或毀損的資訊?
    如果訊息中包含的資訊不是您應用程式所預期的，或已在某些方面毀損，請考量下列事項:
    • 您的應用程式或將訊息放入佇列的應用程式是否已變更? 請確定所有變更同時反映在所有需要注意變更的系統上。 例如，訊息資料的格式可能已變更，在此情況下，必須重新編譯這兩個應用程式以取得變更。 如果一個應用程式尚未重新編譯，另一個應用程式會出現毀損的資料。
    • 應用程式是否將訊息傳送至錯誤佇列? 請檢查應用程式正在接收的訊息是否預期用於服務不同佇列的應用程式。 必要的話，請變更安全定義，以防止未獲授權的應用程式將訊息放入錯誤佇列。 如果您的應用程式使用別名佇列，請檢查別名是否指向正確的佇列。
    • 是否已正確指定此佇列的觸發資訊? 請檢查您的應用程式是否應該已啟動; 或是否應該已啟動不同的應用程式?

    如果這些檢查無法讓您解決問題，請檢查應用程式邏輯，包括傳送訊息的程式，以及接收訊息的程式。

  3. 使用分散式佇列時是否收到非預期的訊息?
    如果您的應用程式使用分散式佇列，請考量下列要點:
    • IBM MQ 是否已正確安裝在傳送端和接收端系統上，以及是否已正確配置分散式佇列?
    • 兩個系統之間是否有鏈結可用? 檢查這兩個系統是否可用，並連接至 IBM MQ。 請檢查兩個系統之間的連線是否處於作用中。 您可以針對佇列管理程式 (PING QMGR) 或通道 (PING CHANNEL) 使用 MQSC 指令 PING ，以驗證鏈結可運作。
    • 傳送系統中是否有觸發設定?
    • 您正在等待來自遠端系統之回覆訊息的訊息嗎? 檢查是否在遠端系統中啟動觸發。
    • 佇列是否已滿? 如果是的話，請檢查訊息是否已放入無法傳送郵件的佇列中。 無法傳送郵件的佇列標頭包含原因或回饋碼，說明訊息無法放入目標佇列的原因。 如需相關資訊，請參閱 使用無法傳送的郵件 (未遞送的訊息) 佇列 及 MQDLH-無法傳送的郵件標頭。
    • 傳送端和接收端佇列管理程式之間是否不符? 例如，訊息長度可能超過接收端佇列管理程式所能處理的長度。
    • 傳送及接收通道的通道定義是否相容? 例如，序號折返中的不符可能停止分散式佇列元件。 如需相關資訊，請參閱分散式佇列和叢集。
    • 是否涉及資料轉換? 如果傳送端與接收端應用程式之間的資料格式不同，則需要進行資料轉換。 當發出 MQGET 呼叫時，如果將格式辨識為其中一種內建格式，則會發生自動轉換。 如果無法辨識轉換的資料格式，則會採用資料轉換結束程式，以容許您使用自己的常式執行轉換。 如需相關資訊，請參閱 資料轉換。

    如果您無法解決問題，請聯絡「 IBM 支援中心」以取得協助。

  4. 您沒有收到 PCF 指令的回應嗎?
    如果您已發出指令，但尚未收到回應，請考量下列檢查:
    • 指令伺服器是否在執行中? 使用 dspmqcsv 指令來檢查指令伺服器的狀態。 如果此指令的回應指出指令伺服器不在執行中，請使用 strmqcsv 指令來啟動它。 如果指令的回應指出 SYSTEM.ADMIN.COMMAND.QUEUE ，請啟用 MQGET 要求的佇列。
    • 回覆是否已傳送至無法傳送郵件的佇列? 無法傳送郵件的佇列標頭結構包含說明問題的原因或回饋碼。 如需相關資訊，請參閱 MQDLH-無法傳送的郵件標頭 及 使用無法傳送的郵件 (未遞送訊息) 佇列。 如果無法傳送郵件的佇列包含訊息，您可以使用提供的瀏覽範例應用程式 (amqsbcg) ，利用 MQGET 呼叫來瀏覽訊息。 範例應用程式會逐步執行具名佇列管理程式之具名佇列上的所有訊息，同時顯示具名佇列上所有訊息的訊息描述子及訊息環境定義欄位。
    • 訊息是否已傳送至錯誤日誌? 如需相關資訊，請參閱 AIX、 Linux及 Windows 上的錯誤日誌目錄。
    • 是否已針對放置及取得作業啟用佇列?
    • WaitInterval 夠長嗎? 如果 MQGET 呼叫已逾時，則會傳回完成碼 MQCC_FAILED 及原因碼 MQRC_NO_MSG_AVAILABLE。 如需 WaitInterval 欄位以及 MQGET 的完成碼和原因碼的相關資訊，請參閱 WaitInterval (MQLONG) 。
    • 如果您使用自己的應用程式將指令放置到 SYSTEM.ADMIN.COMMAND.QUEUE，您需要取得同步點嗎? 除非您已從同步點排除要求訊息，否則您需要在接收回覆訊息之前取得同步點。
    • 您佇列的 MAXDEPTH 及 MAXMSGL 屬性設定是否足夠高?
    • 您是否正確使用 CorrelId 和 MsgId 欄位? 在應用程式中設定 MsgId 及 CorrelId 的值，以確保您從佇列接收所有訊息。

    請嘗試停止指令伺服器，然後重新啟動它，以回應所產生的任何錯誤訊息。 如果系統仍未回應，則問題可能在於佇列管理程式或整個 IBM MQ 系統。 首先，請嘗試停止個別佇列管理程式，以隔離失敗的佇列管理程式。 如果此步驟未顯示問題，請嘗試停止並重新啟動 IBM MQ，以回應錯誤日誌中產生的任何訊息。 如果重新啟動之後仍發生問題，請聯絡「 IBM 支援中心」以取得協助。

  5. 只有部分佇列失敗嗎?
    如果您懷疑只有一部分佇列發生問題，請檢查您認為有問題的本端佇列。

    使用 MQSC 指令 DISPLAY QUEUE 來顯示每一個佇列的相關資訊。 如果 CURDEPTH 位於 MAXDEPTH，則不會處理佇列。 請檢查所有應用程式是否正常執行。

    如果 CURDEPTH 不在 MAXDEPTH，請檢查下列佇列屬性以確定它們是正確的:
    • 如果正在使用觸發，觸發監視器是否在執行中? 觸發深度是否太大? 也就是說，它是否經常產生觸發事件? 程序名稱是否正確? 程序是否可用且可運作?
    • 佇列可以共用嗎? 如果沒有，則另一個應用程式可能已開啟它以供輸入。
    • 是否已針對 GET 及 PUT 適當地啟用佇列?

    如果沒有應用程式程序從佇列取得訊息，請判斷原因。 可能是因為應用程式需要啟動、連線已中斷，或 MQOPEN 呼叫因某些原因而失敗。 請檢查佇列屬性 IPPROCS 及 OPPROCS。 這些屬性指出是否已開啟佇列以供輸入及輸出。 如果值為零，則表示無法執行該類型的作業。 值可能已變更，或佇列可能已開啟，但現在已關閉。

    請檢查您預期放置或取得訊息時的狀態。

    如果您無法解決問題，請聯絡「 IBM 支援中心」以取得協助。

  6. 問題是否僅影響遠端佇列?
    如果問題只影響遠端佇列，請執行下列檢查:
    • 請確認必要通道已啟動、可以觸發，且任何必要的起始程式都在執行中。
    • 請檢查應該將訊息放入遠端佇列的程式是否未報告問題。
    • 如果您使用觸發來啟動分散式佇列程序，請檢查傳輸佇列是否已設定觸發。 此外，請檢查觸發監視器是否在執行中。
    • 請檢查錯誤日誌，以取得指出通道錯誤或問題的訊息。
    • 必要的話，請手動啟動通道。
  7. 在 Windows上建立或啟動佇列管理程式時是否收到錯誤碼?
    如果 IBM MQ Explorer或 amqmdain 指令無法建立或啟動佇列管理程式，指出發生權限問題，可能是因為執行 IBM MQ Windows 服務的使用者權限不足。

    確保配置 IBM MQ Windows 服務的使用者具有 IBM MQ Windows 服務所需的使用者權限中說明的權限。 依預設，此服務會配置成以 MUSR_MQADMIN 使用者身分執行。 對於後續安裝， Prepare IBM MQ Wizard 會建立名為 MUSR_MQADMINx的使用者帳戶，其中 x 是下一個可用的數字，代表不存在的使用者 ID。

  8. 您的應用程式或系統是否執行緩慢?
    如果您的應用程式執行緩慢，則可能是在迴圈中，或等待無法使用的資源，或可能有效能問題。

    您的系統運作可能已接近其容量限制。 這種類型的問題可能在尖峰系統負載時間最差，通常是在上午中及下午中。 (如果您的網路延伸到多個時區，則其他時間可能會出現尖峰系統負載。)

    硬體限制可能導致效能問題。

    如果您發現效能降低並不取決於系統負載，但有時會在系統負載較輕時發生，可能是設計不佳的應用程式所造成。 這可能是只有在存取特定佇列時才會發生的問題。

    應用程式效能變慢或在佇列上建立訊息 (通常是傳輸佇列) 的常見原因是一或多個應用程式在工作單元之外寫入持續訊息。 如需相關資訊，請參閱 訊息持續性。

    如果效能問題持續存在，問題可能在於 IBM MQ 本身。 如果您懷疑這樣做，請聯絡 IBM 支援中心以取得協助。