將Varchar2字段更改爲NVarchar2後Oracle性能可怕

任何幫助或建議都非常歡迎。在過去的幾個月中，我一直在使用oracle（Ver 10.2）開發DotNet項目，並且在我的字符串數據字段中使用了Varchar2。這很好，如果連瀏覽項目頁面刷新都不會超過半秒鐘（這是一個數據密集型項目）。這些數據是從兩種不同的模式中引用的，一種是數據的集中存儲，另一種是我自己的。現在集中式模式將變爲unicode兼容（但還沒有），所以所有的Varchar2字段都將變成NVarchar2，爲此做準備，我將我的模式中的所有字段都更改爲NVarchar2，從那時起性能一直糟糕。高達30/40秒的第二頁刷新。將Varchar2字段更改爲NVarchar2後Oracle性能可怕

這可能是因爲集中式架構中的Varchar2字段將在我的架構中與某些存儲過程中的NVarchar2字段連接。我知道NVarchar2是Varchar2的兩倍，但這並不能解釋突然的巨大變化。正如我所說的，如果我沒有足夠詳細地解釋這個情景，並且要求提供更多信息，那麼尋求改進的任何提示都會很好。

問候

來源

2010-07-21 Israfel

您是否在模式更改後收集新統計信息？ – Tim 2010-07-21 08:19:28

Israfel，

這是很難根據您提供什麼話想說。當您將數據類型更改爲NVARCHAR2時，您是否設法檢查估計的基數和/或解釋計劃是否更改？您可能想閱讀以下博文，看看您是否可以找到潛在客戶 http://joze-senegacnik.blogspot.com/2009/12/cbo-oddities-in-determing-selectivity.html

來源

2010-07-21 08:33:43

它很可能不再能夠使用以前可以使用的索引。正如Narendra建議檢查解釋計劃以瞭解發生了什麼變化。有可能一旦更換了集中式商店，索引將再次可用。我建議測試這條路。

來源

2010-07-21 21:10:03

首先，做一個

select * from v$nls_parameters where parameter like '%SET%';

字符集可能會很複雜。您可以擁有單字節字符集，固定大小的多字節字符集和可變大小的多字節字符集。請參閱unicode描述here

其次，如果要將單字節字符集中的字符串連接到雙字節字符集中的字符串，則可以選擇。您可以執行二進制/字節比較（如果您比較單字節字符集和雙字節字符集，通常不會匹配任何內容）。或者你可以做一個語言比較，這通常意味着一些CPU成本，因爲一個值被轉換成另一個值，並且通常沒有使用索引。

索引被排序，A，B，C等。但像Ä這樣的字符可能會落在不同的地方，這取決於語言順序。假設索引結構在A和B之間放置Ä，但是接下來進行語言比較。該比較的語言可能會在Z之後放置Ä，在這種情況下，索引不能使用。（記住你的情況可能是一個BETWEEN而不是=）。

簡而言之，您需要在模式和中央存儲中進行大量準備工作，才能在不同字符集之間實現有效的連接。

來源

2010-07-22 06:16:57

乾杯的幫助，恢復架構的舊版本恢復到正常速度，並通過索引搜索發現一個失蹤的歸因於很多問題的轉換。仍然存在性能問題，但我認爲這將在集中式模式發生變化時執行。謝謝 – Israfel 2010-07-22 08:25:33

正確設置NLS_LANG初始化參數對於正確的數據轉換至關重要。由NLS_LANG初始化參數指定的字符集應反映客戶端操作系統的設置。正確設置NLS_LANG將啓用從客戶端操作系統代碼頁到數據庫字符集的正確轉換。當這些設置相同時，Oracle假定發送或接收的數據與數據庫字符集使用相同的字符集進行編碼，因此不進行驗證或轉換。如果需要轉換，這可能會導致數據損壞。

來源

2011-05-12 05:51:27 Darshan

將Varchar2字段更改爲NVarchar2後Oracle性能可怕

回答

相關問題