>>-UPDATE QP_SYSTEM USING--------------------------------------->
>--+-DEFAULT------------------------------+--------------------><
'-CREATE_RESULT_TABLE_ALIASES--+-'Y'-+-'
'-'N'-'
當透過「Query Patroller 中心」或 Query Patroller 命令行來執行下列其中一項作業時， 將傳回一則警告訊息：
警告訊息如下：
DQP1024W 直到重新啟動 Query Patroller 伺服器後，建立、變更或除去查詢類別才會生效。
同樣地，DB2 Query Patroller(TM) Guide: Installation, Administration, and Usage 8.2 版指出，在建立、變更或除去查詢類別後， 您必須重新啟動 Query Patroller 伺服器，變更才能生效。
手冊中的訊息及陳述式不再正確。除非有置於佇列的查詢，或有執行中的查詢， 否則先前列出的三項查詢類別作業將立即生效。如果有置於佇列的查詢，或有執行中的查詢， 包括新提出的查詢，則在置於佇列的查詢或執行中的查詢完成時，查詢類別變更將生效。 如果您不想要等待所有置於佇列的查詢及執行中的查詢完成，則必須重新啟動 Query Patroller 伺服器。
已取消及完成查詢狀態意義更新如下：
執行 Query Patroller 的歷程資料產生器時，如果沒有「解譯」表格， 產生器就會為您建立這些表格。 但是，我們強烈建議您在執行歷程資料產生器之前，先建立「解譯」表格。 當您建立「解譯」表格時，請確實將它們建立在相同的分割區上。 主動將「解譯」表格建立在相同的分割區上，可增進「解譯」機能的效能。 這項改進可增加歷程資料產生器的效能。
如果 Query Activity over Time (歷程分析) 報告的 Explain Run 直欄顯示查詢的狀態為 Ran unsuccessfully，就表示尚未針對該查詢產生歷程分析。 因此，查詢將不會出現在任何歷程分析報告或圖形中。 如第 8 版所述，若要判定查詢失敗的原因，請檢查 qpuser.log 檔案。
除了檢查 qpuser.log 檔案之外，您也應該檢查 qpdiag.log 檔案。
如果您執行歷程資料產生器並以異常方法關閉它，則在下次嘗試執行歷程資料產生器時， 您將收到一個錯誤。異常關閉的範例包括：
當歷程資料產生器異常關閉時，您必須在嘗試重新執行歷程資料產生器之前， 發出下列命令：
qp -d database generate historical_data stop其中 database 識別正在對哪一個資料庫執行命令。
某些查詢類別作業不再需要 Query Patroller 停止並重新啟動，即可生效。
在底下的表格中，作用中查詢即是其狀態為「執行中」或「已置於佇列」的查詢。
巢狀查詢無法置於佇列中。相反地，如果巢狀查詢超出正常情況下將導致它置於佇列的臨界值時， 將立即執行。
與先前的文件相反，具有下列陳述式的查詢可以置於佇列：
以解析度 640x480 使用「終端機服務用戶端」，來連接至正在執行「Query Patroller 中心」的遠端桌上管理程式時， 「提出喜好設定」視窗可能會出現一片空白。若要能夠適當地顯示「提出喜好設定」視窗， 您必須使用高於 640x480 的解析度。
從 8.2 版開始，DB2 Universal Database (UDB) 支援作業系統群組以外的使用者群組。 因此，在「Query Patroller 中心」的「查詢提出喜好設定」視窗中， 要使用的提出者設定檔下拉清單中有稍微的變更。
如果您登入，但沒有 DBADM 權限或「編輯」專用權來進行 Query Patroller 使用者管理， 則您僅能為自己新增或更新提出喜好設定。在這種情況下， 要使用的提出者設定檔下拉清單將包含您所屬的 DB2(R) UDB 群組的現存提出者設定檔，而不只是您所屬的作業系統群組。
如果您登入，而且有 DBADM 權限或「編輯」專用權來進行 Query Patroller 使用者管理， 則您可以為其它使用者新增或更新提出喜好設定。在這種情況下， 要使用的提出者設定檔下拉清單包含所有現存的群組提出者設定檔。
在「Query Patroller 中心」使用排程時， 您可以使用「排程」視窗，將排程儲存至檔案，並在稍後匯入它們。 如果您具有一個已使用 FixPak 6 或更舊版本來儲存的排程， 將無法使用 8.2 版或更新版本來匯入排程。這個限制是因為 DB2 UDB 8.2 版已在 JDK 層次之間的序列化中引進了變更。
若要執行 RUN IN BACKGROUND QUERY 命令，您必須是原先提出查詢的提出者。
如同 Query Patroller 8.1 版 FixPak 5 一般，Query Patroller 已在符合查詢提出者之授權 ID 的綱目中停止建立結果表格。 Query Patroller 已改為在共同結果表格綱目中開始建立結果表格。 若要容許使用提出者的綱目來參照結果表格，Query Patroller 8.2 版引進一個選項， 它會自動為 Query Patroller 所建立的每一個新結果表格建立一個別名。 結果表格建立在 DB2QPRT 綱目中，而別名則建立在符合提出者授權 ID 的綱目中。
若要開啟或關閉這個選項，請利用 CREATE_RESULT_TABLE_ALIASES 選項， 來發出 UPDATE QP_SYSTEM 命令：
當捨棄結果表格時，會自動捨棄 CREATE_RESULT_TABLE_ALIASES 選項所建立的別名。 但是，有兩種情況，可能捨棄結果表格，但不會捨棄對應的別名。
為了清除沒有對應結果表格的別名，已建立了新的命令 REMOVE RESULT_TABLE_ALIASES。每當清除結果表格，作為 Query Patroller 排定的結果表格清除程序的一部份時，即會自動執行這個命令。 REMOVE RESULT_TABLE_ALIASES 命令會使用下列查詢， 來取得要清除的別名清單：
with a as (select tabschema, tabname from syscat.tables
where type = 'A' and tabname like 'QUERY%_RESULTS'),
t as (select tabname from syscat.tables
where type = 'T' and tabname like 'QUERY%_RESULTS')
select all tabschema, tabname from a
where not exists (select * from t where t.tabname=a.tabname)
您必須具有 DBADM 權限。
這個命令會除去在捨棄其對應結果表格後存在的所有別名。 這些別名原先是由結果表格的 Query Patroller 所建立的。
Query Patroller 使用一些隔離儲存程序，它們可能會將項目記載至 qpdiag.log 檔。因此，隔離使用者 ID 必須具有 qpdiag.log 檔及路徑 (qpdiag.log 檔所在的位置) 的寫入權。
[ 頁面頂端 |前一頁 | 下一頁 | 目錄 ]