問題描述
作為升級 JRun 的一部分，我們正在從 1.4 JVM 遷移到 1.6 JVM.現在我收到一個非常奇怪的 oracle db 錯誤:OALL8 處于不一致狀態".我已經確定了插入根本不使用綁定變量的查詢的問題 - 所有內聯參數.如果我在沒有任何綁定變量的情況下運行查詢，則會收到上述錯誤.只要我用綁定變量替換其中一個硬編碼值 - 一切都會正常工作.
As part of upgrading JRun, we are moving from a 1.4 JVM to a 1.6 JVM. Now I am getting a really strange oracle db error: "OALL8 is in an inconsistent state". I have pinned down the problem to insert queries that do not use bind variables at all - all inline parameters. If I run the query without any bind variables, I get the above error. As soon as I replace one of the hard coded values with a bind variable - everything works without error.
另一個奇怪的地方是，在執行查詢之后，它實際上是提交給數據庫的.我可以從另一個會話連接并查看插入的行.我已經嘗試將查詢包裝在事務中，它似乎成功了，因為沒有顯式事務的查詢的行為沒有改變.
The other strange bit is that after executing the query, it is in fact committed to the database. I can connect from another session and see the inserted row. I have tried wrapping the query in a transaction and it seems to succeed as the behavior is unchanged from the query without an explicit transaction.
以下是相關細節:
Java 版本:1.6.0_12-b04
虛擬機版本:11.2-b01(HotSpot 服務器)
Oracle 服務器:10.2.0.4
Oracle 客戶端:11.1.0.7.0 到 ojdbc6.jar
Java Version: 1.6.0_12-b04
Virtual Machine Version: 11.2-b01 (HotSpot Server)
Oracle Server: 10.2.0.4
Oracle Client: 11.1.0.7.0 through ojdbc6.jar
更新: 我正在使用 cfqueryparam - 它們在 oracle 世界中被稱為綁定變量.雖然這確實解決了眼前的問題，但我們有一個相當大的遺留代碼庫，作為從 CF7 升級到 CF8 的一部分，我們實際上無法通過所有這些代碼庫來更新查詢.
Update: I am using cfqueryparam - they are called bind variables in the oracle world. While that does solve the immediate problem, we have a rather large legacy code base that we can't realistically go through all of to update the queries as part of upgrading from CF7 to CF8.
即使我已經確定了一種失敗的特定情況(并將其封裝在 mxunit 測試中)——這并不意味著沒有其他可能存在問題的領域.我真的很想有一個解決方案來消除 OALL8 錯誤，而不是圍繞它進行編碼.
Even though I have pinned down one specific situation that fails (and encapsulated it in an mxunit test) - that doesn't mean there aren't other areas where this may be an issue. I would really like to have a solution in place that removes the OALL8 error rather than coding around it.
更新 2: 在與我們的 DBA 核實后，他已將名為 CURSOR_SHARING 的參數設置為 SIMILAR.Oracle 默認值為 EXACT.發生的情況是，當 ColdFusion 將查詢交給執行時，Oracle 將所有文字值轉換為綁定變量，這似乎使 ColdFusion 感到困惑.將設置轉回 EXACT 可以讓文字查詢正常工作.
Update 2: After checking with our DBA he had set a parameter called CURSOR_SHARING to SIMILAR. The Oracle default is EXACT. What is happening is when ColdFusion hands the query off to be executed, Oracle is turning all the literal values to bind variables and that appears to be confusing ColdFusion. Turning the setting back to EXACT allows the literal queries to work just fine.
更新 3: Oracle 終于向我們發布了 JDBC 的帶外補丁.它被識別為 JDBC 錯誤.最新的驅動程序在最終更新時應該包含它.如果你有支持，你也可以通過他們的 TAR 系統請求補丁.
Update 3: Oracle finally issued us an out-of-band patch for JDBC. It was identified as a JDBC error. The latest drivers should include it when they are finally updated. If you have support you can also request the patch through their TAR system.
推薦答案
那么...使用綁定變量?
So... use bind variables?
無論如何，您都應該使用它們(通過 cfqueryparam)來確保安全，如果它解決了問題，那就更有理由這樣做了.
You should be using them (via cfqueryparam) for security anyway, and if it solves the problem that's even more reason to do so.
如果您對實際錯誤的含義感興趣，Google 有 很多 的 results，暗示這是一個JDBC 驅動程序出錯，甚至建議 補丁可用.
If you're interested in what the actual error means, Google has plenty of results, suggesting that it's an error with the JDBC driver, and even suggests a patch is available.
但是我在您的帖子中沒有看到實際問題...?
But I don't see an actual question in your post...?
這篇關于Oracle:OALL8 處于不一致狀態的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！