更改 nls_length_semantics 后重新编译包答案

【问题标题】：Package recompile after changing nls_length_semantics更改 nls_length_semantics 后重新编译包
【发布时间】：2014-10-15 03:43:53
【问题描述】：

我有一个数据库，其中 nls_length_semantics 值已从字节更改为字符。是否需要重新编译所有具有可从外部访问的基于 varchar2 的数据类型的包（例如 dbms_sql）？

【问题讨论】：

更改是否使任何内容无效？ DBA_PLSQL_OBJECT_SETTINGS 还包含一个列，指示编译包时的语义，但我不知道它是否在运行时使用它，这可能会使更改无效，但意味着包仍将传递的数据视为字节。
这听起来像是非常有用的信息。我怀疑更改设置不会使任何对象无效，但它会保留“字节”设置。由于包不是无效的，DBA 不希望无缘无故地重新编译它，但如果我能在该表中找到该条目，那么我可以证明它确实需要重新编译。

【解决方案1】：

@GWu 在我看来是错误的。至少，他在精神上是错误的。这不是想要的问题，而是需要的问题。然而，在他所说的意义上，他也是正确的：这取决于。

如果数据库中的基础数据是多字节的，您需要重新编译您的包。

我今天遇到了包以 BYTE 格式编译的问题，尽管我的表中的基础数据是 Unicode。这些表已明确定义为（例如）VARCHAR2(20 CHAR)，而我的 PL/SQL 包中的代码仅定义为 VARCHAR2(20)。

这意味着数据库中定义为长度为 50 的列并不总是适合定义为长度为 50 的 PL/SQL 变量。我的用户报告了很多“字符缓冲区太小”类型的错误，例如结果。

如果你和我有同样的情况，需要重新编译包。

但是，我真正想知道的是，我如何知道一个包是否以 BYTE 格式编译。这样我就可以确切地知道我的哪些包需要重新编译。在不知道这一点的情况下，我没有主动去重新编译它们的方法。我只需要等待用户报告问题。

我想我当然可以重新编译它们，但这会在用户仍在其中时锁定我的数据库。所以我必须再次安排一些停机时间来解决整个问题:-(

--编辑--

在发布之前应该阅读@AlexPoole 的评论。 dba_plsql_object_settings 视图提供了我需要的信息！

【讨论】：

【解决方案2】：

简短回答：这取决于:-)

如果您希望您的现有包使用 char 语义，则需要重新编译。否则，它们将保持编译时的设置。从技术角度来说，不需要重新编译。

而且绝对不需要重新编译 SYS 拥有的包（如 dbms_sql）。

【讨论】：