oracle - ORA-14696 : MAX_STRING_SIZE migration is incomplete for pluggable database

Question

我目前正在测试 Oracle 12.1 并且我正在尝试扩展我的数据类型字符串。我做了以下事情:-

sqlplus /nolog
conn / as sysdba
shutdown imediate;
startup upgrade
alter system set max_string_size=EXTENDED scope=spfile;
@$ORACLE_HOME/rdbms/admin/utl32k.sql
shutdown
startup

然后我收到了消息

ORA-14696: MAX_STRING_SIZE migration is incomplete for pluggable database

我发现的唯一在线文档只是告诉我运行 utl32k.sql - 但我已经这样做了，不知道从哪里开始。希望有人可以提供帮助。

更多信息

Todsay 我发现了另一个网页，上面写着:-

SQL> @utlrp.sql

这仍然不起作用:-(

TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_BGN  2013-07-11 06:30:04

DOC>   The following PL/SQL block invokes UTL_RECOMP to recompile invalid
DOC>   objects in the database. Recompilation time is proportional to the
DOC>   number of invalid objects in the database, so this command may take
DOC>   a long time to execute on a database with a large number of invalid
DOC>   objects.
DOC>
DOC>   Use the following queries to track recompilation progress:
DOC>
DOC>   1. Query returning the number of invalid objects remaining. This
DOC>      number should decrease with time.
DOC>         SELECT COUNT(*) FROM obj$ WHERE status IN (4, 5, 6);
DOC>
DOC>   2. Query returning the number of objects compiled so far. This number
DOC>      should increase with time.
DOC>         SELECT COUNT(*) FROM UTL_RECOMP_COMPILED;
DOC>
DOC>   This script automatically chooses serial or parallel recompilation
DOC>   based on the number of CPUs available (parameter cpu_count) multiplied
DOC>   by the number of threads per CPU (parameter parallel_threads_per_cpu).
DOC>   On RAC, this number is added across all RAC nodes.
DOC>
DOC>   UTL_RECOMP uses DBMS_SCHEDULER to create jobs for parallel
DOC>   recompilation. Jobs are created without instance affinity so that they
DOC>   can migrate across RAC nodes. Use the following queries to verify
DOC>   whether UTL_RECOMP jobs are being created and run correctly:
DOC>
DOC>   1. Query showing jobs created by UTL_RECOMP
DOC>         SELECT job_name FROM dba_scheduler_jobs
DOC>            WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>
DOC>   2. Query showing UTL_RECOMP jobs that are running
DOC>         SELECT job_name FROM dba_scheduler_running_jobs
DOC>            WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>#

PL/SQL procedure successfully completed.


TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_END  2013-07-11 06:30:17

DOC> The following query reports the number of objects that have compiled
DOC> with errors.
DOC>
DOC> If the number is higher than expected, please examine the error
DOC> messages reported with each object (using SHOW ERRORS) to see if they
DOC> point to system misconfiguration or resource constraints that must be
DOC> fixed before attempting to recompile these objects.
DOC>#

OBJECTS WITH ERRORS
-------------------
                  0

DOC> The following query reports the number of errors caught during
DOC> recompilation. If this number is non-zero, please query the error
DOC> messages in the table UTL_RECOMP_ERRORS to see if any of these errors
DOC> are due to misconfiguration or resource constraints that must be
DOC> fixed before objects can compile successfully.
DOC>#

ERRORS DURING RECOMPILATION
---------------------------
                          0


Function created.


PL/SQL procedure successfully completed.


Function dropped.

...Database user "SYS", database schema "APEX_040200", user# "98" 07:50:32
...Compiled 0 out of 2998 objects considered, 0 failed compilation 07:50:33
...263 packages
...255 package bodies
...453 tables
...11 functions
...16 procedures
...3 sequences
...458 triggers
...1322 indexes
...207 views
...0 libraries
...6 types
...0 type bodies
...0 operators
...0 index types
...Begin key object existence check 07:50:33
...Completed key object existence check 07:50:33
...Setting DBMS Registry 07:50:33
...Setting DBMS Registry Complete 07:50:33
...Exiting validate 07:50:33

PL/SQL procedure successfully completed.

SQL> shutdown
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  839282688 bytes
Fixed Size                  2293928 bytes
Variable Size             562040664 bytes
Database Buffers          272629760 bytes
Redo Buffers                2318336 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-14696: MAX_STRING_SIZE migration is incomplete for pluggable database
PDB$SEED
Process ID: 5878
Session ID: 18 Serial number: 5

Answer 1

我首先遇到了同样的问题，当发现时，您只能在非 cdb(数据库的独立形式)或可插拔中设置 MAX_STRING_SIZE。在 pdb$seed 中进行这种转换有点棘手，正如文档所说，它应该处于升级模式，但您不能在升级模式下“启动”可插拔数据库，因为仅启动了容器数据库，可插拔数据库是打开。所以我做了以下事情:

SQL> 启动挂载
SQL> 更改数据库打开迁移；

数据库已更改。

SQL> select con_id, name, open_mode from v$pdbs;

CON_ID 名称 OPEN_MODE
---------- ------------------------------ ----------
2 PDB$种子迁移
3 PDBN1 安装

SQL> 更改 session 集容器=PDB$SEED;

session 已更改。

SQL> 更改系统设置 max_string_size = EXTENDED;

系统变了。

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

session 已更改。
......
...设置 DBMS 注册表完成 09:33:59
...退出验证 09:33:59

PL/SQL 过程成功完成。

查询>

或者，您可以创建一个非 cdb，将其迁移并将其插入 cdb。这无需先迁移 cdb 即可工作。

我不知道，这是否是推荐的方法。
注意:如果你从 pdb$seed 克隆一个数据库，你会在打开它时得到一个错误:
MAX_STRING_SIZE 的默认值在创建后立即为“STANDARD”。
请执行下列操作:

SQL> 创建可插拔数据库 pdb1 ADMIN 用户 pdb1asmin 密码标识为roles=(DBA);

可插入数据库已创建。

SQL> 更改 session 集容器 = pdb1;

session 已更改。

SQL> 更改系统设置 max_string_size = EXTENDED scope=spfile;

系统变了。

SQL> 更改数据库打开；

数据库已更改。

我必须更精确一点:我说过，你不能在升级模式下启动可插拔数据库。没错，但是你可以在升级模式下打开它:

SQL>alter pluggable database pdb1 open upgrade;

完成后，您可以将 MAX_STRING_SIZE 设置为 EXTENDED 并按照上述说明运行 utl32k