Oracle OCI - 获取延迟并失败
我有一个 Oracle OCI 程序，该程序正在各种平台上运行：SLES Linux、Ubuntu、AIX、Solaris 和 HP-UX。我试图在 Redhat 上运行同样的东西，但遇到了困难。
当使用可滚动游标（使用 OCI_STMT_SCROLLABLE_READONLY 调用 OCIStmtExecute）并使用执行二分搜索的函数来获取准确的结果集大小时，似乎会出现此问题。更一般地说，问题似乎是在读取 OK 值之前读取超过结果集的末尾。
我编写了一个测试实用程序，它执行一个必须返回 1 行的简单语句 (SELECT COUNT(*) FROM xxx)。然后它从结果集中检索数据：
如果我首先检索第 1 行，它工作正常。如果我超出了结果集的末尾，当我返回时它仍然可以正常工作。但是，如果我的第一次检查是在结果集之后，则一切都会出错：
> rdb_test 1
12:06:32.365 Checking row 1 - OK
> rdb_test 3
12:06:35.510 Checking row 3 - NO DATA
12:06:35.511 Checking row 2 - NO DATA
12:06:45.549 Checking row 1 - NO DATA
> rdb_test -3
12:06:49.344 Checking row 1 - OK
12:06:49.344 Checking row 3 - NO DATA
12:06:49.345 Checking row 2 - NO DATA
12:06:49.345 Checking row 1 - OK
此外，在检索应该没问题的行时，还会出现奇怪的延迟，在上面的示例中为 10 秒。在调试器中，它位于 OCIStmtFetch2 函数的深处 - 毫不奇怪，在等待服务器响应的 __read_nocancel 函数中。
以前有其他人见过这个问题吗？
I've got an Oracle OCI program, which is in production on various platforms: SLES Linux, Ubuntu, AIX, Solaris and HP-UX. I'm trying to get the same thing running on Redhat, and I'm having difficulties.
The problem seems to arise when using a scrollable cursor (calling OCIStmtExecute with OCI_STMT_SCROLLABLE_READONLY), and using a function that does a binary search to get the exact result set size. More generically, the problem seems to be reading past the end of the result set, before reading an OK value.
I have written a test utility which executes a simple statement that must return 1 row (SELECT COUNT(*) FROM xxx). It then retrieves data from the result set:
If I first retrieve row 1, it works fine. If I then go past the end of the result set, it continues to work fine when I return. But if my first check is after the result set, everything goes wrong:
> rdb_test 1
12:06:32.365 Checking row 1 - OK
> rdb_test 3
12:06:35.510 Checking row 3 - NO DATA
12:06:35.511 Checking row 2 - NO DATA
12:06:45.549 Checking row 1 - NO DATA
> rdb_test -3
12:06:49.344 Checking row 1 - OK
12:06:49.344 Checking row 3 - NO DATA
12:06:49.345 Checking row 2 - NO DATA
12:06:49.345 Checking row 1 - OK
Also there is a strange delay, 10s in the example above, while it retrieves the row which should be OK. In the debugger, this is deep within the OCIStmtFetch2 function - unsurprisingly in the __read_nocancel function waiting for the server response.
Has anyone else seen this problem before?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
该问题似乎与版本 11 OCI 库有关。我刚刚尝试了 v10 库，似乎又可以正常工作了。不幸的是，这需要旧版本的 C++ 标准库，因此如果有替代方案，我仍然希望避免此修复。
The problem seems to be related to the version 11 OCI library. I have just tried the v10 library, and it seems to work OK again with that. Unfortunately, that requires an old version of the C++ standard library, so I would still prefer to avoid this fix if an alternative is available.