數據庫是Oracle。我們的目標是在代碼，執行狀態檢查：低影響端到端數據庫連接和查詢測試
就夠了這些不同的要求，我想出了以下查詢：
SELECT NULL FROM VIEW_NAME WHERE NULL IS NOT NULL
因此，讓我們來分析一下：
SELECT NULL是企圖「以小博大」 SQL result caching通過顯式指定的值。FROM VIEW_NAME將失敗，如果VIEW_NAME不存在於數據庫中（即端到端）。WHERE NULL IS NOT NULL是避免表掃描，返回0的記錄，企圖等任何想法，改進建議等，將不勝感激。我特別想知道這個查詢或方法是否有任何可以想象的問題。
您最好檢查您連接的用戶下的VALID對象。
select count(*) from user_objects where status != 'VALID';
，或者如果你正在尋找數據庫中的所有有效的對象，那麼：
select count(*) from obj$ where status != 'VALID';
只需確保查詢不會運行過於頻繁 - 像一分鐘50次。
一個更好的方法將是樂觀的，並嘗試操作 - 選擇/更新/插入/刪除，你想對數據庫做。
無效的對象會導致錯誤（無論如何您都需要在代碼中處理這些錯誤），所以請專注於在應用程序中進行可靠的錯誤處理，並且不要擔心只是爲了查看是否在D B。
您的測試檢查DB對象狀態可能會通過，但在下一個瞬間，DB對象可能會失效。
我可能需要更新需求列表以包含此內容，但是我也希望緩解的另一個副作用是可能先前已施加最小（或超過期望的）連接或查詢超時的「fail-slow」查詢。在這方面，我想我提到的問題將在各種「系統監視器」的背景下更加準確地描述。我確實喜歡「檢查有效對象」的概念，並且需要進一步探索。 – rdev5
您是否能夠爲每個視圖和表格運行此操作，以防萬一脫機或丟失？將'SELECT NULL FROM DUAL'用於連接，並且可能查看數據字典以查看脫機/丟失/無效的問題，有什麼優勢？ –
@AlexPoole爲了您的理解和澄清，這可能是對特定應用程序對單個視圖的依賴。在這種情況下，其他視圖是否脫機並不重要，但對於應用程序本身而言，這個目標視圖的大部分都是無法訪問的。它並非真正用於對每個視圖/表進行系統範圍的檢查等。另外，針對視圖（例如'FROM VIEW_NAME'）實際上是端到端的，因爲'SELECT NULL FROM DUAL'不會測試所述視圖的可訪問性。然而，我還沒有看過數據字典。 – rdev5