Campaign：資料庫查詢間歇性地非常慢
本文說明如何使用Databricks FDA緩解長工作流程查詢的逾時。
說明 description
客戶一直使用Databricks FDA進行工作流程查詢，其查詢間歇性地非常緩慢並由於1小時逾時限制而失敗（1小時後為OAuth權杖到期的結果）。 工作流程記錄檔顯示的訊息：
ODB-240000 ODBC錯誤： [ Simba] [ Hardy] (115)連線失敗，錯誤為：傳回未獲授權/禁止的錯誤回應，但沒有收到權杖過期的訊息SQLState： 08S01
和
ODB-240000 ODBC錯誤：驗證權杖已過期。 使用者必須再次驗證。 SQLState： 08001
解決方法 resolution
到期本身不受Campaign工作流程設定或serverConf.xml設定檔控制。 在此設定中，ACC會使用nmsaccountName上的OAuth，透過Simba ODBC驅動程式連線至Databricks。 長效認證/應用程式密碼可能有效期至2031年，但為ODBC連線核發的存取權杖可能還有更短的存留期，通常為60分鐘。
緩解選項：
- 資料庫管理員可以檢閱Adobe Campaign使用的OAuth應用程式/整合，並增加存取權杖TTL，例如透過更新Databricks OAuth權杖存取原則（例如access_token_ttl_in_minutes）。 這應由客戶/資料庫管理員完成，並應遵循其安全性原則，因為如果存取權杖壽命較長，可能會增加洩露風險。
- 變更權杖原則之後，請在Databricks端允許傳輸時間，並使用新的ACC/ODBC連線重新測試。 現有開啟的連線可能會繼續使用原則變更前發行的先前權杖。
- 在操作上，分割或最佳化ACC工作流程查詢，讓每個個別DBX SQL陳述式完成的時間都遠低於權杖存留期。 這是更安全、更偏好的緩解措施，因為它也可解決間歇性緩慢/排入佇列的DBX執行問題，而非僅延長故障時段。
- 在「資料庫」一側，檢查SQL倉儲查詢記錄是否有慢速執行，並調整倉儲/查詢路徑：佇列時間、並行、縮放/最大叢集、冷啟動、查詢計畫、表格統計資料/配置，以及述詞/聯結的資料量。
- 如果客戶需要的DBX SQL敘述句可以合法執行超過OAuth存取權杖存留期，他們應該向Databricks/Simba確認ODBC驅動程式使用的OAuth模式是否支援其設定中長時間執行/開啟敘述句的權杖重新整理。 如果沒有，可能需要增加權杖TTL或使用其他支援的驗證模式。
因此，實用的短期緩解措施是增加ACC整合的Databricks OAuth存取權杖TTL，而長期修正是減少DBX查詢執行階段/佇列，讓工作流程不依賴能夠存活非常長時間執行SQL呼叫的權杖。
recommendation-more-help
experience-cloud-kcs-help-kbarticles