问包/存储过程中的alter session NLS_LENGTH_SEMANTICS=CHAR

EN

修订：

我之所以修改我的答案，是因为另一位受人尊敬的Oracle员工专家(Sergiusz Wolicki)提出了建议，并且修改了有关此参数的文档以警告不要将其设置为CHAR作为初始化参数，以及警告仍然存在于12.1

http://docs.oracle.com/database/121/NLSPG/ch3globenv.htm#NLSPG234

警告: Oracle强烈建议您不要在实例或服务器参数文件中将NLS_LENGTH_SEMANTICS参数设置为CHAR。这可能会导致许多现有安装脚本意外创建具有字符长度语义的列，从而导致运行时错误，包括缓冲区溢出。

注意:如果DDL脚本是在没有显式语义的情况下编写的，那么设置参数不会对其产生影响，但是，显然不能在Oracle产品脚本中安全地对其进行全面更新。

对于写得很好的代码，它肯定不会影响“代码功能”，它只是一个影响新字段宽度的设置。这里的症结似乎是你在多大程度上能够保证这一点。

然而，如果甲骨文对此发出警告，他们有经验和证据这样做。不知道长度语义的遗留应用程序或工具可能会受到影响。

由于向后兼容性，Oracle默认值传统上是BYTE，但是对于没有遗留的新数据库，更改它没有风险，也不会影响内部数据字典，因为无论NLS_LENGTH_SEMANTICS的数据库设置如何，这些都锁定在BYTE语义上。

请注意，原来的问题是关于更改NLS_LENGTH_SEMANTICS的会话值的。文档中的警告未涵盖此情况。如果您想在使用旧脚本的会话中创建具有字符长度语义的对象，那么这个ALTER session是非常好的选择。

文档警告特别反对在init.ora中设置参数，因为这样的设置将影响所有未显式设置参数(通过ALTER SESSION或环境变量)的会话。如果您不小心，您可能会运行各种遗留脚本，包括Oracle的、第三方的或您自己开发的脚本，并使用错误的语义创建对象，这不是所拥有的应用程序所期望的。字符语义而不是字节语义不会对许多应用程序造成问题，也不会被检测为问题，但可能会导致问题，包括某些情况下的安全问题。因此，Oracle建议您在脚本中显式地设置length语义，而不是依赖于破坏旧程序兼容性的数据库范围的设置。

如果您坚持在init.ora中设置NLS_LENGTH_SEMANTICS，则必须记住对所有需要字节语义的脚本重置或覆盖它。这可能很麻烦。

对我来说，这个更新起作用了。您需要重新启动Oracle服务器。更新sys.props$集合NLS_LENGTH_SEMANTICS =字符