营销型网站建设微博百度app优化

---

前言

今天客户发来一个内部测试库数据库启动截图报错，描述是“上午出现服务卡顿，然后重启了一下，目前出现实例无法启动的问题”

这个情况来看提示比较明显：ORA-14695 MAX_STRING_SIZE 是和字符串大小有关，追查alert日志发现有过修改操作，只不过是在8月27日，使用scope=spfile但当时没有重启记录，此次是修改完参数第一次重启出现的报错。

冲浪后猜测当时想扩大varchar2的默认长度，但是操作的人员只是修改了这一个参数且没有让其生效。

---

一、MAX_STRING_SIZE–12C 新特性扩展数据类型 varchar2(32767)

这是在12c引入的新参数，varchar2在早期版本中最大长度限制为4000，12C版本可以通过修改参数MAX_STRING_SIZE将最大长度限制调整为32767。早期版本中虽然SQL数据类型限制为4000（如表中的列的varchar2类型），但在PL/SQL中的限制是32767（如在存储过程中的定义变量时用的varchar2类型）
在修改过程有以下情况需要注意：

1，需要在UPGRADE模式下修改参数和跑脚本utl32k.sql。
Use ALTER SYSTEM only when the database is in UPGRADE mode, and run the utl32k.sql script afterward, as explained in this section.
2，参数MAX_STRING_SIZE只控制 VARCHAR2, NVARCHAR2, and RAW这三个数据类型的最大值。
MAX_STRING_SIZE controls the maximum size of VARCHAR2, NVARCHAR2, and RAW data types in SQL.
3，STANDARD模式下，VARCHAR2 and NVARCHAR2最大值为4000，RAW最大为2000。
STANDARD means that the length limits for Oracle Database releases prior to Oracle Database 12c apply (for example, 4000 bytes for VARCHAR2 and NVARCHAR2, and 2000 bytes for RAW).
4，EXTENDED模式下，上述三个数据类型的最大值为32767。
EXTENDED means that the 32767 byte limit introduced in Oracle Database 12c applies.
5，COMPATIBLE这个兼容参数的版本为12.0.0.0及以上。
The COMPATIBLE initialization parameter must be set to 12.0.0.0 or higher to set MAX_STRING_SIZE = EXTENDED.
6，参数MAX_STRING_SIZE的值只能从STANDARD 修改为 EXTENDED，而不能从EXTENDED 修改为 STANDARD。
You can change the value of MAX_STRING_SIZE from STANDARD to EXTENDED. However, you cannot change the value of MAX_STRING_SIZE from EXTENDED to STANDARD.

二、恢复操作

1.尝试恢复MAX_STRING_SIZE参数为默认值

我创建了pfile，删除了对应MAX_STRING_SIZE所在行，然后通过pfile进行数据库启动。但不幸的是依旧报同样的错误。

那既然不好使，可能操作不止修改参数这一个地方，我只能把当初修改想法继续实现下去了。

2.在upgrade模式下执行utl32k.sql

SQL> startup upgradeSQL> @?/rdbms/admin/utl32k.sql

但是在执行过程中我又遇到了ORA-38301,提示回收站的对象无法执行，那只能清掉回收站再来一次喽。

SQL> shutdown immediateSQL> startup upgrade
#清空回收站
SQL> purge dba_recyclebinSQL> @?/rdbms/admin/utl32k.sql
#编译失效对象
SQL> @?/rdbms/admin/utlrp.sqlSQL> shutdown immediateSQL> startup

那么至此故障排查结束，数据库已完成启动。