我们的应用程序适用于oracle 10g数据库，我们现在计划将其迁移到exadata。 为此，我们必须遵循exadata接受的一些合规性。 其中之一是在定义的开头将每个现有的包/过程/函数添加语句
alter session set NLS_LENGTH_SEMANTICS='CHAR'
任何线索都将受到高度赞赏
答案 0 :(得分：4)
REVISION：
我正在修改我的答案，因为来自另一位受人尊敬的Oracle员工专家（Sergiusz Wolicki）的建议，以及文档在此参数上进行了修订以警告不要将其设置为CHAR作为初始化参数，以及事实是警告仍然存在于12.1
http://docs.oracle.com/database/121/NLSPG/ch3globenv.htm#NLSPG234
警告：Oracle强烈建议您不要设置 实例或服务器中的CHAR的NLS_LENGTH_SEMANTICS参数 参数文件。这可能会导致许多现有的安装脚本 意外地创建具有字符长度语义的列，结果 在运行时错误中，包括缓冲区溢出。
CAVEAT： 如果在没有显式语义的情况下编写DDL脚本，那么设置参数不会影响它，但是，它显然不是在Oracle产品脚本中全面安全更新的。
使用编写良好的代码，它肯定不会影响“代码功能”，它只是一个简单影响新字段宽度的设置。这里的关键似乎是你可以保证这是多么舒服。
但是，如果甲骨文警告它，他们就有这方面的经验和证据。不知道长度语义的遗留应用程序或工具可能会受到影响。
由于向后兼容性，Oracle默认值通常为BYTE，但对于无遗留内容的新数据库，更改它没有风险，并且不会影响内部数据字典，因为它们被锁定为BYTE语义，而不管NLS_LENGTH_SEMANTICS的数据库设置。
答案 1 :(得分：2)
请注意，原始问题是关于更改NLS_LENGTH_SEMANTICS的会话值。文档中的警告未涵盖此案例。如果你想使用较旧的脚本在会话中创建具有字符长度语义的对象，那么这个ALTER SESSION非常好。
doc警告专门针对在init.ora中设置参数，因为此类设置将影响所有未明确设置参数的会话（通过ALTER SESSION或环境变量）。如果您不小心，您可以运行各种遗留脚本，包括Oracle，第三方或您自己开发的脚本，并创建具有错误语义的对象，而不是拥有的应用程序所期望的。字符语义而不是字节语义不会导致许多应用程序出现问题，也不会被检测为问题，但可能会导致问题，包括某些情况下的安全问题。因此，Oracle建议您在脚本中显式设置长度语义，而不是依赖于破坏旧东西兼容性的数据库范围设置。
如果您坚持在init.ora中设置NLS_LENGTH_SEMANTICS，则必须记住重置它或覆盖所有期望BYTE语义的脚本。这可能很麻烦。
答案 2 :(得分：0)
对我来说，此更新有效。 您需要重新启动Oracle服务器。 更新sys.props $ set NLS_LENGTH_SEMANTICS = CHAR