数据库是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