ORA-03113在執行SQL查詢

ORA-03113 400行SQL查詢：結束文件上的通信信道

下面是要注意的事項：

我已經設置了超時10分鐘
沒有取出時的最後一個條件解決了這個埃羅河
只有當我分析索引時纔出現此錯誤。

令人不安的情況是這樣的：

AND UPPER (someMultiJoin.someColumn) LIKE UPPER ('%90936%')

所以我的假設是，查詢正從顯然是因爲其確定爲資源佔用服務器端終止。

我的假設是否合適？我應該如何解決這個問題？

編輯：我試圖得到錯誤查詢的解釋計劃，但解釋計劃查詢也給我一個ORA-03113錯誤。我明白我的查詢不是很高效，但爲什麼這應該是ORA-03113錯誤的原因。我試圖從運行蟾蜍查詢，並有生成警報日誌或跟蹤，我的數據庫版本是 Oracle9i企業版發行9.2.0.7.0 - 生產

來源

2010-07-28 Ravi Gupta

閱讀本 - 它開始與ORA-03113。 http://stackoverflow.com/questions/3347305/ora-07445-access-violation – 2010-07-28 13:45:28

請添加條件導致麻煩問題文本。 – ThinkJet 2010-07-29 11:09:23

@VincentMalgrat - 我不認爲你應該刪除你的答案。它包含有用的和相關的建議。您只需要從MOS筆記中刪除大量的引用。 – APC 2010-08-10 10:05:00

這意味着你已經斷開。這可能不是由於資源耗費。

我已經看到了與數據庫的連接正在通過NAT運行，並且因爲沒有流量，它關閉了隧道並因此斷開連接。通常如果你使用連接池，你不會得到這個。

來源

2010-07-28 07:31:55 Daniel

這不應該是這樣，因爲我反覆嘗試，仍然得到相同的錯誤。 – 2010-07-28 08:31:33

正如@Daniel所說，與服務器的網絡連接正在被破壞。你可以看看End-of-file on communication channel看看它是否提供了任何有用的建議。

分享和享受。

來源

2010-07-28 11:27:56

此錯誤的一個可能的原因是服務器端的線程崩潰。檢查Oracle服務器是否生成了任何跟蹤文件，或者在其警報日誌中記錄了任何錯誤。

你說從查詢中刪除一個條件導致問題消失。查詢需要多長時間才能在沒有這種情況下運行？你是否檢查過這兩個版本的查詢的執行計劃，看看是否添加該條件導致選擇一些效率低下的計劃？

來源

2010-07-28 12:32:41

查詢需要大約40秒，並且該條件被淘汰。當我嘗試獲得解釋計劃（有條件）時，我得到相同的ORA-03113錯誤。 – 2010-07-29 04:24:34

+1 - 首先檢查跟蹤和警報日誌。 – REW 2010-08-11 03:44:28

事實上，您在執行解釋計劃時遇到ORA-03113錯誤，這是Oracle CBO崩潰的進一步證據。您需要提出Oracle支持（如果您沒有支持，請嘗試升級到更高版本，因爲您正在訪問的錯誤可能已修復）。也許在常量上有UPPER（）的bug優化？ – 2011-03-23 23:27:59

這在使用複雜查詢的基於成本的優化器中經常是一個錯誤。

你可以嘗試做的是改變執行計劃。例如。使用WITH來拉出一些subquerys。或者使用SELECT/* + RULE * /提示來防止Oracle使用CBO。同樣，刪除統計數據也會有所幫助，因爲Oracle會使用其他執行計劃

如果您可以更新數據庫，請進行9.2.0的測試安裝。8並查看錯誤是否已經消失。

有時它有助於轉儲模式，將所有內容都放入並再次導入轉儲。

來源

2010-08-06 06:45:14 andrem

從目前爲止的信息來看，它看起來像後端崩潰，就像Dave Costa之前提出的那樣。你能檢查服務器日誌嗎？

你能用set autotrace traceonly explain得到計劃嗎？它是從本地SQL * Plus發生的，還是僅通過遠程連接發生？肯定聽起來像後端的ORA-600可能是罪魁禍首，特別是在解析時。成功運行時間比失敗時間長似乎排除了網絡問題。我懷疑它很快就會失敗，但客戶需要長達30秒的時間才能放棄死亡連接，或者服務器花了很長時間才能寫出跟蹤文件和核心文件。

這可能會讓您選擇修補（如果您可以在Metalink上找到特定ORA-600的相關修補程序）或升級數據庫;或者重寫查詢以避免它。如果這是一個已知的錯誤，你可以從Metalink中得到一些關於如何做到這一點的想法。如果你幸運的話，它可能就像提示一樣簡單，如果額外的條件對計劃產生了意想不到的影響。 someMultiJoin.someColumn是成功版本中使用的索引的一部分嗎？它可能會令人困惑，你可以通過暗示它使用索引來說服它回到成功的計劃，但這顯然是相當投機的。

來源

2010-08-10 11:21:43

+1 - 有幾個錯誤會導致這樣的事情。 – REW 2010-08-11 03:45:17

您可以安全地，如果你使用的是像用數字（即不區分大小寫）兩個部分刪除了「上」，這樣可以降低查詢時間檢查等等句子

AND UPPER (someMultiJoin.someColumn) LIKE UPPER ('%90936%')

是等於：

AND someMultiJoin.someColumn LIKE '%90936%'

編號不受UPPER（和％是獨立字符殼體）。

來源

2010-08-11 15:50:44 Dubas

我有類似的連接丟失的問題與查詢的某些變化。在我的情況下，在某些情況下使用rownum時，連接會下降。事實證明，這是一個通過調整特定Oracle數據庫配置設置來解決問題的錯誤。我們採取了一種解決方法，直到可以安裝補丁程序。我希望自己能記住更多細節，或者在此找到一封舊郵件，但我不知道具體情況會有助於解決您的問題。我發佈這只是說您可能遇到了一個錯誤，如果您有權訪問Oracle的支持站點（support.oracle.com），您可能會發現其他人已經報告了它。

編輯：我快速查看了Oracle的支持。有超過1000個與ORA-03113錯誤，但我發現了一個可能適用的：

錯誤5015257：QUERY WITH ORA-3113核心轉儲失敗時QUERY_REWRITE_ENABLED = 'TRUE'

總結：

在9.2.0.6.0中確定，在10.2.0中確定。1
運行特定的查詢（未鑑定）導致ORA-03113
運行在查詢說明它的相同
有一個在 $ ORACLE_HOME/dbs中
解決方法是設置核心文件QUERY_REWRITE_ENABLED爲false：alter system set query_rewrite_enabled = FALSE;

另一種可能性：

錯誤3659827：從長時間運行的查詢

9.2.0.5.0通過10.2.0.0
問題ORA-3113：客戶有長時間運行的查詢，始終產生ORA-3113錯誤。
在客戶系統上，他們收到core.log文件，但在alert.log中沒有收到任何錯誤。在測試系統上，我使用了我收到的ORA-7445錯誤。
解決方法：在會話級別或實例級別設置「_complex_view_merging」= false。

來源

2010-08-13 01:10:06 jlpp

ORA-03113在執行SQL查詢

回答

相關問題