将Varchar2字段更改为NVarchar2后，Oracle性能很糟糕

Question

我们非常欢迎任何帮助或建议。在过去的几个月里，我一直在oracle（Ver 10.2）上开发一个DotNet项目，并在我的字符串数据字段中使用Varchar2。这很好，当导航项目页面刷新时，如果是偶数，那就不会超过半秒（这是一个数据密集型项目的安静）。数据来自2个不同的模式，一个是集中的数据存储，另一个是我自己的模式。现在，集中式模式将变为unicode兼容（但尚未），因此所有Varchar2字段都将成为NVarchar2，为此做准备我将模式中的所有字段都更改为NVarchar2，从那以后性能一直很糟糕。高达30/40秒的页面刷新。

这可能是因为集中式架构中的Varchar2字段将在某些存储过程中与我的架构中的NVarchar2字段连接。我知道NVarchar2的大小是Varchar2的两倍，但这并不能解释突然发生的巨大变化。正如我所说，如果我没有充分解释这个场景，那么任何有关改进的建议的提示都会很棒。请提供更多信息。

此致

Answer 1

首先，做一个

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

字符集可能很复杂。您可以使用单字节字符集，固定大小的多字节字符集沙形可变大小的多字节字符集。请参阅unicode说明here

其次，如果要将单字节字符集中的字符串连接到双字节字符集中的字符串，则可以选择。您可以进行二进制/字节比较（如果您在单字节字符集和双字节字符集之间进行比较，则通常不会匹配任何内容）。或者您可以进行语言比较，这通常意味着一些CPU成本，因为一个值被转换为另一个值，并且通常无法使用索引。

索引是有序的，A，B，C等。但是，根据语言顺序，像Ä这样的字符可能会落在不同的地方。假设索引结构将Ä置于A和B之间。但是，然后进行语言比较。该比较的语言可以在Z之后放置Ä，在这种情况下，不能使用索引。 （记住你的情况可能是一个BETWEEN而不是=）。

简而言之，您需要在架构和中央存储中进行大量准备，以实现不同角色之间的有效连接。

Answer 2

Israfel，

根据您提供的内容很难说出任何内容。当您将数据类型更改为NVARCHAR2时，您是否设法检查估计的基数和/或解释计划是否已更改？您可能需要阅读以下博客文章，看看您是否能找到潜在客户 http://joze-senegacnik.blogspot.com/2009/12/cbo-oddities-in-determing-selectivity.html

Answer 3

它可能不再能够使用以前可以使用的索引。正如Narendra建议检查解释计划，看看有什么变化。一旦中心化存储被更改，索引将再次可用。我建议测试那条路。

Answer 4

正确设置NLS_LANG初始化参数对于正确的数据转换至关重要。 NLS_LANG初始化参数指定的字符集应反映客户端操作系统的设置。正确设置NLS_LANG可以正确地从客户端操作系统代码页转换为数据库字符集。当这些设置相同时，Oracle假定发送或接收的数据使用与数据库字符集相同的字符集进行编码，因此不执行验证或转换。如果需要进行转换，这可能会导致数据损坏。