我有一个报表引擎，在Oracle 11上执行PreparedStatements，这是一个高度优先的任务。有没有办法解决共享池中的Oracle查询
我看到的是，第一个查询调用通常比之后的同一个查询执行得多得多（查询具有不同的参数并返回不同的数据）。
我想这是由于第一次查询调用Oracle完成的硬解析。
我想知道，有没有一种方式暗示Oracle，这个查询是高度优先的查询哪些会经常执行，哪些性能是关键的，所以它应该保留在共享池中，不管是什么？
我知道我可以修复Oracle 11中的执行计划，但我不想修复它，我希望Oracle仍然能够更改它，因为系统更改，我只想要排除查询硬解析。
Anton， 如果您的查询使用绑定变量，它将被重新使用。游标将被缓存，只要它被重用，游标将保留在游标缓存中。确保它使用绑定变量。这增加了重用性和可扩展性。
如果您不信任rdbms，则可以使用dbms_shared_pool.keep将其挂住。 请参阅http://psoug.org/reference/dbms_shared_pool.html
您需要找到光标才能这样做。 通常还有一个问题需要解决。
它确实使用绑定变量。但是如果缓存过载，它会被保留下来。正如我所看到的那样，问题在于缓存在当天移除此查询，之后再次解析它。 – mavarazy 2011-02-04 09:47:04
在这种情况下，shared_pool太小或应用程序的其他部分激发了太多不可共享的sql。通常情况下，rdbms会尝试重新使用和缓存它所能做的所有事情，而不是删除它认为有价值的东西。 – 2011-02-04 09:58:13
是的，这是原来的问题。我想知道，我可以提示Oracle不要从shared_pool中删除这个查询。换句话说，将其设置为共享池中最“有价值”的查询，关于可用性等。 – mavarazy 2011-02-04 11:11:49
也许你应该改变你的“我想......”变成了“我测试，并已确定......” :)
查询性能可能比仅仅解析更加受到影响;当它执行时，它必须从磁盘获取块到缓冲区缓存中 - 后续执行很可能利用了在内存中找到的块，因此速度更快。
编辑：回答你的直接问题 - 解决方法可能是定期运行一个作业，解析查询但不执行它。您甚至可以使用它来确定解析或提取是否是问题的发生位置。
您可以尝试使用dbms_shared_pool.keep
钉扎到共享池，但你已经老化了问题第一
你使用绑定变量我首先要确保？ – 2011-02-04 09:36:30