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迁移不完整数据库

我在网上发现的唯一的doc只是告诉我运行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> startup mount
SQL> alter database open migrate;

Database altered.

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

    CON_ID NAME                           OPEN_MODE
---------- ------------------------------ ----------
         2 PDB$SEED                       MIGRATE
         3 PDBN1                          MOUNTED

SQL> alter session set container=PDB$SEED;

Session altered.

SQL> alter system set max_string_size = EXTENDED;

System altered.

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

Session altered.
......
...Setting DBMS Registry Complete 09:33:59
...Exiting validate 09:33:59

PL/SQL procedure successfully completed.

SQL>

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

我不知道，如果这是推荐的方法。注意：如果从pdb $ seed克隆数据库，打开它时会出错： MAX_STRING_SIZE的默认值在创建后立即为“STANDARD”。执行以下操作：

SQL> create pluggable database pdb1 ADMIN user pdb1asmin identified by password roles=(DBA);

Pluggable database created.

SQL> alter session set container=pdb1;

Session altered.

SQL> alter system set max_string_size = EXTENDED scope=spfile;

System altered.

SQL> alter database open;

Database altered.

我必须更准确一点：我说过，你无法在升级模式下启动可插拔数据库。没错，但你可以在升级模式下打开它：

SQL> alter pluggable database pdb1 open upgrade;

完成后，您可以将MAX_STRING_SIZE设置为EXTENDED并运行utl32k，如上所述

Answer 2

此页面提供了很多帮助 - 我在pdb$root上也遇到了问题我写了一个SQL查询，我认为这将有助于使流程顺利进行。我会单独运行生成的sql语句，而不是一个大的剪切和粘贴：

    alter session set container=cdb$root;
    set heading off;
    set linesize 100;
    spool dynamic_pdb_extendable_cols.sql
    set serveroutput on size 999999;
    declare 
    sql_stmt varchar2(100);
    cursor c1 is select  name, open_mode from v$pdbs where name ^= 
      'PDB$SEED' order by name;  
   begin
    dbms_output.put_line('alter system set max_string_size=EXTENDED'||
      ' scope=spfile;');
    dbms_output.put_line('alter session set container = CDB$ROOT;');
    dbms_output.put_line('shutdown immediate;');
    dbms_output.put_line('startup upgrade;');
    dbms_output.put_line('@?/rdbms/admin/utl32k.sql');
    dbms_output.put_line('alter session set container = PDB$SEED;');
    dbms_output.put_line('@?/rdbms/admin/utl32k.sql ;');
    dbms_output.put_line('shutdown immediate;');
    dbms_output.put_line('startup;');

    for c1rec in c1 loop
     dbms_output.put_line('alter session set container = '||c1rec.name|| ';');
     dbms_output.put_line('alter pluggable database '||c1rec.name||
       ' close immediate;');
     dbms_output.put_line('alter pluggable database '||c1rec.name||
      ' open upgrade;');
     dbms_output.put_line('@?/rdbms/admin/utl32k.sql');
     dbms_output.put_line('alter pluggable database '||c1rec.name||
      ' close immediate;');
     dbms_output.put_line('alter pluggable database '||c1rec.name||
      ' open read write;');

    end loop;
    end;
    /
    spool off;

--- tom

ORA-14696：可插拔数据库的MAX_STRING_SIZE迁移不完整

2 个答案: