Oracle 单实例从32位迁移到 64位方法-MySQL 튜토리얼-php.cn

Oracle 单实例从32位迁移到 64位方法,直接 copy datafiles,使用 RMAN Restore 示例,使用导出导入说明

关于单实例从32位迁移到64位的说明，参考：Oracle Convert a 32-bit Database to 64-bit Database（32位转到 64位）说明

在这篇文章中演示第一种方法：直接copy datafile进行迁移。

一.测试环境：

Source：

DB：11.2.0.3 32 位

OS: Oracle Linux 6.1 32 位

IP:192.168.3.200

ORACLE_HOME：

[oracle@tianlesoftware ~]$ echo$ORACLE_HOME

/u01/app/oracle/product/11.2.0/db_1

Target ：

DB:11.2.0.3 64位

OS：Oracle Linux 6.1 64位

IP:192.168.3.201

ORACLE_HOME:

rac1:/home/oracle> echo $ORACLE_HOME

/u02/app/oracle/product/11.2.0/db_1

这里2个ORACLE_HOME 不一样，所以我们在操作过程中需要重建控制文件。

Oracle 控制文件

二．具体操作如下：

1. 冷备份整个DB，以防修改wordsize失败。

2. 将source 端的控制文件dump 到 trace文件里。

SQL> oradebug setmypid

Statement processed.

SQL> alter database backup controlfile to trace;

Database altered.

SQL> oradebug tracefile_name

/u01/app/oracle/diag/rdbms/anqing/anqing/trace/anqing_ora_8874.trc

查看trace 文件，获取控制文件重建脚本：

[oracle@tianlesoftware u01]$ cat /u01/app/oracle/diag/rdbms/anqing/anqing/trace/anqing_ora_8874.trc

STARTUP NOMOUNT

CREATE CONTROLFILE REUSE DATABASE"ANQING" NORESETLOGS ARCHIVELOG

MAXLOGFILES 16

MAXLOGMEMBERS 3

MAXDATAFILES 100

MAXINSTANCES 8

MAXLOGHISTORY 292

LOGFILE

GROUP 1 '/u01/app/oracle/oradata/anqing/redo01.log' SIZE 50M BLOCKSIZE 512,

GROUP 2'/u01/app/oracle/oradata/anqing/redo02.log' SIZE 50M BLOCKSIZE 512,

GROUP 3 '/u01/app/oracle/oradata/anqing/redo03.log' SIZE 50M BLOCKSIZE 512

-- STANDBY LOGFILE

DATAFILE

'/u01/app/oracle/oradata/anqing/system01.dbf',

'/u01/app/oracle/oradata/anqing/sysaux01.dbf',

'/u01/app/oracle/oradata/anqing/undotbs01.dbf',

'/u01/app/oracle/oradata/anqing/users01.dbf'

CHARACTER SET ZHS16GBK

;

RECOVER DATABASE

ALTER SYSTEM ARCHIVE LOG ALL;

ALTER DATABASE OPEN;

ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/oradata/anqing/temp01.dbf'

SIZE 30408704 REUSE AUTOEXTEND ONNEXT 655360 MAXSIZE 32767M;

3. 在Target 端安装64位的Oracle软件，这里仅安装，不创建实例。

64位 linux平台下Oracle安装文档

4. Clean shutdown Source 端的32位DB

Oracle 实例恢复时前滚（roll forward）后滚（rollback）问题

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

5. 将Source 端的所有datafile copy 到Target 端的对应目录。

注意这里的TEMP 表空间，虽然我们可以一起拷贝过去，但是还是建议重建TEMP，已避免其他的问题。

5.1 在Target 端创建相关的目录

rac1:/u02> cd app/oracle/

rac1:/u02/app/oracle> ls

checkpoints diag product

rac1:/u02/app/oracle> mkdir admin

rac1:/u02/app/oracle> mkdir fast_recovery_area

rac1:/u02/app/oracle/product/11.2.0/db_1/dbs>cd /u02/app/oracle/fast_recovery_area/

rac1:/u02/app/oracle/fast_recovery_area>mkdir anqing

rac1:/u02/app/oracle> mkdir oradata

rac1:/u02/app/oracle> ls

admin checkpoints diag fast_recovery_area oradata product

rac1:/u02/app/oracle> cd oradata

rac1:/u02/app/oracle/oradata> mkdiranqing

rac1:/u02/app/oracle/oradata> cd ../

rac1:/u02/app/oracle> ls

admin checkpoints diag fast_recovery_area oradata product

rac1:/u02/app/oracle> cd admin

rac1:/u02/app/oracle/admin> ls

rac1:/u02/app/oracle/admin> mkdir anqing

rac1:/u02/app/oracle/admin> cd anqing

rac1:/u02/app/oracle/admin/anqing> mkdiradump

rac1:/u02/app/oracle/admin/anqing> mkdirdpdump

rac1:/u02/app/oracle/admin/anqing> mkdirpfile

rac1:/u02/app/oracle/admin/anqing> mkdirscripts

rac1:/u02/app/oracle/admin/anqing> ls

adump dpdump pfile scripts

5.2 copy 所有datafiles

[oracle@tianlesoftware anqing]$ scp *192.168.3.201:/u02/app/oracle/oradata/anqing

oracle@192.168.3.201's password:

control01.ctl 100% 9520KB 9.3MB/s 00:01

redo01.log 100% 50MB 5.6MB/s 00:09

redo02.log 100% 50MB 6.3MB/s 00:08

redo03.log 100% 50MB 5.0MB/s 00:10

sysaux01.dbf 100% 510MB 4.2MB/s 02:01

system01.dbf 100% 710MB 5.3MB/s 02:13

temp01.dbf 100% 29MB 5.8MB/s 00:05

undotbs01.dbf 100% 75MB 5.0MB/s 00:15

users01.dbf 100%5128KB 5.0MB/s 00:01

6. 将source 端的初始化文件和口令文件copy到target 端

SQL> create pfile from spfile;

File created.

[oracle@tianlesoftware dbs]$ scp initanqing.ora 192.168.3.201:/u02/app/oracle/product/11.2.0/db_1/dbs

oracle@192.168.3.201's password:

initanqing.ora 100% 1017 1.0KB/s 00:00

7. 在Target 端修改初始化文件

修改的内容包括控制文件保存位置，user_dump_dest,background_dump_dest,core_dump_dest 等。

修改之后如下：

rac1:/u02/app/oracle/product/11.2.0/db_1/dbs>cat initanqing.ora

anqing.__db_cache_size=570425344

anqing.__java_pool_size=16777216

anqing.__large_pool_size=16777216

anqing.__oracle_base='/u02/app/oracle'#ORACLE_BASEset from environment

anqing.__pga_aggregate_target=570425344

anqing.__sga_target=838860800

anqing.__shared_io_pool_size=0

anqing.__shared_pool_size=218103808

anqing.__streams_pool_size=0

*.audit_file_dest='/u02/app/oracle/admin/anqing/adump'

*.audit_trail='db'

*.compatible='11.2.0.0.0'

*.control_files='/u02/app/oracle/oradata/anqing/control01.ctl','/u02/app/oracle/fast_recovery_area/anqing/control02.ctl'

*.db_block_size=8192

*.db_domain=''

*.db_name='anqing'

*.db_recovery_file_dest='/u02/app/oracle/fast_recovery_area'

*.db_recovery_file_dest_size=4194304000

*.diagnostic_dest='/u02/app/oracle'

*.dispatchers='(PROTOCOL=TCP)(SERVICE=anqingXDB)'

*.log_archive_dest_1='LOCATION=/u02/archivelog'

*.log_archive_format='%t_%s_%r.arc'

*.memory_target=1393557504

*.open_cursors=300

*.processes=150

*.remote_login_passwordfile='EXCLUSIVE'

*.undo_tablespace='UNDOTBS1'

8. 在Target 端重建控制文件

在重建控制之前先rm 掉我们从Source 端copy 过来的控制文件，同时修改我们的控制文件代码，使路径使用Target 的路径。

rac1:/u02/app/oracle/oradata/anqing> ls

control01.ctl redo02.log sysaux01.dbf temp01.dbf users01.dbf

redo01.log redo03.log system01.dbf undotbs01.dbf

rac1:/u02/app/oracle/oradata/anqing> rmcontrol01.ctl

rac1:/u02/app/oracle/oradata/anqing> rmtemp01.dbf

rac1:/u02/app/oracle/oradata/anqing> ls

redo01.log redo02.log redo03.log sysaux01.dbf system01.dbf undotbs01.dbf users01.dbf

--使用pfile 启动DB 致nomout 状态：

rac1:/u02/app/oracle/oradata/anqing>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production onMon Feb 13 21:20:08 2012

Connected to an idle instance.

SQL> startup nomount pfile='/u02/app/oracle/product/11.2.0/db_1/dbs/initanqing.ora';

ORACLE instance started.

Total System Global Area 1402982400 bytes

Fixed Size 2228304 bytes

Variable Size 822087600 bytes

Database Buffers 570425344 bytes

Redo Buffers 8241152 bytes

SQL>

--重建控制文件：

SQL> CREATE CONTROLFILE REUSE DATABASE"ANQING" NORESETLOGS ARCHIVELOG

MAXLOGFILES 16

2 3 MAXLOGMEMBERS 3

4 MAXDATAFILES 100

5 MAXINSTANCES 8

6 MAXLOGHISTORY 292

7 LOGFILE

8 GROUP 1'/u02/app/oracle/oradata/anqing/redo01.log' SIZE 50M BLOCKSIZE 512,

9 GROUP 2'/u02/app/oracle/oradata/anqing/redo02.log' SIZE 50M BLOCKSIZE 512,

10 GROUP 3 '/u02/app/oracle/oradata/anqing/redo03.log' SIZE 50M BLOCKSIZE 512

11 --STANDBY LOGFILE

12 DATAFILE

13 '/u02/app/oracle/oradata/anqing/system01.dbf',

14 '/u02/app/oracle/oradata/anqing/sysaux01.dbf',

15 '/u02/app/oracle/oradata/anqing/undotbs01.dbf',

16 '/u02/app/oracle/oradata/anqing/users01.dbf'

17 CHARACTER SET ZHS16GBK

18 ;

Control file created.

--打开DB:

SQL> alter database open;

Database altered.

--尝试重建TEMP表空间，报错：

SQL> ALTER TABLESPACE TEMP ADD TEMPFILE'/u02/app/oracle/oradata/anqing/temp01.dbf' SIZE 30408704 REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;

ALTER TABLESPACE TEMP ADD TEMPFILE'/u02/app/oracle/oradata/anqing/temp01.dbf' SIZE 30408704 REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M

ERROR at line 1:

ORA-00604: error occurred at recursive SQLlevel 1

ORA-06553: PLS-801: internal error [56327]

--这里出错，是因为我们从32迁移到64位，还没有进行PL/SQL 模块的重建，等我们重建完成，在重建TEMP就没有问题了。

9. 在Target 端重新编译64位的PL/SQL模块

SQL> SPOOL mig32-64.log;
SQL> @$ORACLE_HOME/rdbms/admin/utlirp.sql

……

--脚本大概执行2分钟

DOC>###############################################################

DOC> utlirp.sql completed successfully. All PL/SQL objects in the

DOC> database have been invalidated.

DOC>

DOC> Shut down and restart the database in normal mode and run utlrp.sql to

DOC> recompile invalid objects.

DOC>###############################################################

SQL>

SQL> SPOOL OFF;

--这里说的很清楚，所有的PL/SQL 对象都变成了无效，需要shut down 后，，用normal 默认启动，并执行utlrp.sql脚本，验证无效对象个数：

SQL> select count(*) from all_objectswhere status='INVALID';

COUNT(*)

----------

9768

--编译无效对象：

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup

ORACLE instance started.

Total System Global Area 1402982400 bytes

Fixed Size 2228304 bytes

Variable Size 822087600 bytes

Database Buffers 570425344 bytes

Redo Buffers 8241152 bytes

Database mounted.

Database opened.

SQL> @?/rdbms/admin/utlrp.sql;

--脚本执行半个小时

SQL> select count(*) from all_objectswhere status='INVALID';

COUNT(*)

----------

8054

--还是有很多无效对象，先放着，处理完Java在编译一次

10. 重建 javashared data objects (SRO)

用SYS 用户执行如下脚本：

begin
update obj$ set status=5 where obj#=(select obj# fromobj$,javasnm$
    where owner#=0 and type#=29 and short(+)=name and
   nvl(longdbcs,name)='oracle/aurora/rdbms/Compiler');
commit;
declare
    cursor C1 is select
       'DROP JAVA DATA "' || u.name||'"."' || o.name || '"'
       from obj$ o,user$ u where o.type#=56 andu.user#=o.owner#;
      ddl_statement varchar2(200);
    iterations number;
    previous_iterations number;
    loop_count number;
    my_err     number;
begin
    previous_iterations := 10000000;
   loop
      -- To make sure we eventually stop,pick a maxnumber of iterations
      select count(*) into iterations from obj$ wheretype#=56;
      exit when iterations=0 or iterations >=previous_iterations;
      previous_iterations := iterations;
      loop_count := 0;
      open C1;
      loop
        begin
          fetch C1 intoddl_statement;
          exit when C1%NOTFOUND orloop_count > iterations;
        exception when others then
           my_err := sqlcode;
           if my_err = -1555then --snapshot too old, re-execute fetch query
             exit;
           else
             raise;
           end if;
        end;
        initjvmaux.exec(ddl_statement);
        loop_count := loop_count + 1;
      end loop;
      close C1;
    end loop;
end;
commit;
initjvmaux.drp('delete fromjava$policy$shared$table');
update obj$ set status=1 where obj#=(select obj# fromobj$,javasnm$
    where owner#=0 and type#=29 and short(+)=name and
   nvl(longdbcs,name)='oracle/aurora/rdbms/Compiler');
commit;
end;
/
--2分钟左右

create or replace java system
/

--十分钟左右

11. 在编译一次无效对象

SQL> @?/rdbms/admin/utlrp.sql;

--脚本执行时会产生大量的online redo，所以要保证有足够的online redo 来切换。

--这里突然想到把第九步的编译无效对象省略，放到这里一起执行，应该可以节省半个小时，不过这里不能测试了。

在执行脚本的过程中，session异常中断，在alert log和 trace里都有：ORA-7445的错误：

ORA-07445: exception encountered: core dump[__intel_new_memcpy()+2164] [SIGSEGV] [ADDR:0x7F2F0CBBD2BF] [PC:0x47ED7D4][Address not mapped to object] []

----- Current SQL Statement for thissession (sql_id=2y0pxmcj6k00t) -----

ALTER VIEW"OLAPSYS"."ALL$OLAP2_AW_CATALOGS" COMPILE

导致这个问题，是因为我们启动了OLAP，在32位转到64位时就会遇到这种错误。

12. 处理OLAP 问题

--查看组件

SQL> select comp_id,comp_name,version,status from dba_registry;

COMP_ID COMP_NAME VERSION STATUS

----------------------------------------------- ------------ ------------------

OWB OWB 11.2.0.3.0 VALID

APEX Oracle Application Express 3.2.1.00.12 VALID

EM Oracle Enterprise Manager 11.2.0.3.0 VALID

AMD OLAP Catalog 11.2.0.3.0 INVALID

SDO Spatial 11.2.0.3.0 INVALID

ORDIM Oracle Multimedia 11.2.0.3.0 INVALID

XDB Oracle XML Database 11.2.0.3.0 INVALID

CONTEXT Oracle Text 11.2.0.3.0 VALID

EXF Oracle Expression Filter 11.2.0.3.0 INVALID

RUL Oracle Rules Manager 11.2.0.3.0 INVALID

OWM Oracle Workspace Manager 11.2.0.3.0 INVALID

COMP_ID COMP_NAME VERSION STATUS

----------------------------------------------- ------------ ------------------

CATALOG Oracle Database Catalog Views 11.2.0.3.0 INVALID

CATPROC Oracle Database Packages and Types 11.2.0.3.0 INVALID

JAVAVM JServer JAVA Virtual Machine 11.2.0.3.0 VALID

XML Oracle XDK 11.2.0.3.0 VALID

CATJAVA Oracle Database Java Packages 11.2.0.3.0 VALID

APS OLAP Analytic Workspace 11.2.0.3.0 INVALID

XOQ Oracle OLAP API 11.2.0.3.0 VALID

18 rows selected.

MOS 有篇文档提供了重建OLAP组件的方法：

How To Remove Or To Reinstall The OLAPOption To 10g And 11g [ID 332351.1]

这里提供了2种解决方法：

（1）在ORACLE_HOME 级别重建

--删除OLAP

备份DB和oraInventory,在关闭ORACLE_HOME上的所有Instance，使用Universal Installer (OUI) 移除ORACLE_HOME的OLAP 选项。在OUI 中选择升级已经存在的db，在selectoptions 选项可以控制是否启用OLAP。如下图：

在Unix 和Linux 平台上，也可以直接relink olap_off 的方式来删除，这样就避免使用OUI。

cd $ORACLE_HOME/rdbms/lib

make -f ins_rdbms.mk olap_off
make -f ins_rdbms.mk ioracle

非注册的OLAP将不在db 的banner 中限制，同时v$option 也会显示为FALSE.

--重新安装OLAP

1）在OUI中添加OLAP 组件，参考上图。

2）添加完毕之后执行如下脚本，在db 级别进行添加。

sqlplus /nolog
SQL> conn /as sysdba
SQL> spool add_olap.log
SQL> @?/olap/admin/olap.sql SYSAUX TEMP;
SQL> @?/rdbms/admin/utlrp.sql
SQL> spool off

（2）在Database 级别重建

--删除OLAP

--在db server 上开一个session，设定相关的变量，并用sys 用户执行如下脚本：

ORACLE_HOME=your_oracle_home
ORACLE_SID=your_db_sid
PATH=$ORACLE_HOME/bin:$PATH
sqlplus /nolog
SQL> conn / as sysdba

----> Remove OLAP Catalog
SQL> @?/olap/admin/catnoamd.sql

----> Remove OLAP API
SQL> @?/olap/admin/olapidrp.plb
SQL> @?/olap/admin/catnoxoq.sql

----> Deinstall APS - OLAP AW component
SQL> @?/olap/admin/catnoaps.sql
SQL> @?/olap/admin/cwm2drop.sql

----> Recompile invalids
SQL> @?/rdbms/admin/utlrp.sql

catnoamd.sqlused above will drop the OLAPSYS schema (which is completely OLAP specific).

--catnoamd.sql 脚本用来drop OLAPSYS 用户。

cwm2drop.sqlneeds to be run only in 11g. In 10g, catnoamd.sql already calls it.

--cwm2drop.sql 只需要在11g中执行。在10g中，catnoamd.sql 脚本中已经包含了该脚本，所以不用执行。

If you connectto the database in SQLPLUS, the banner still shows the OLAP option,this happensbecause the Oracle executable is still aware of OLAP, it is linked with OLAP, andalso the OLAP files are still present in the ORACLE_HOME.

Once running thedeinstall scripts, the utlrp.sql could report invalid objects with SYS andPUBLIC owners. If so, the following SQL can be used to report more details onthat:

--删除之后，可能导致一些无效的对象，可以使用如下SQL 来查看具体信息：

SQL> select owner, object_name,object_type, status from dba_objects where status='INVALID';

You could getsome invalid objects under SYS and PUBLIC owner, and they are the old duplicate OLAPSYS objects copied under these schemas when Olap has been installedpreviously.

Generally, theOlap objects are named with context like %OLAP%, %AWM%, or other Olap word keys intheir "object_name" field, however, if it needs a help to recognizethem, then please contact Oracle Support and create a Service Request toget assistance for this question.

Note that catnoadm.sql could fail from 10.1.0.5 to 11.1.0.7release.

Due to the factthat it refers to three scripts which don't get shipped until 11.2 this scriptwill fail.

Besides that itwill error on 7 non-existing synonyms to drop.

Prior 11.2, execute these three dropsynonym statements:

SQL> drop public synonym OlapFactView;
SQL> drop public synonym OlapDimView;
SQL> drop public synonym DBMS_ODM;

If there arefurther invalid OLAP specific objects after the above removal steps, pleaseconsult Note1060023.1, Note565773.1

If you do notwant to install OLAP into a newly created database, then in the DatabaseConfiguration Assistant (dbca), select a custom database template and uncheckOracle OLAP in the Database Components wizard step.

--添加OLAP

Assuming thatyou created your database manually or via DBCA, add the OLAP option to anexisting Enterprise Edition Database.

--假设我们在ORACLE_HOME 级别添加了OLAP。

Then open aterminal session on the database server machine, set ORACLE_HOME, ORACLE_SIDenvironment variables, and execute some script as user SYS AS SYSDBA, detailsbelow:

--在db server 端用SYS 用户执行如下脚本，来创建olap。

ORACLE_HOME=your_oracle_home
ORACLE_SID=your_db_sid
PATH=$ORACLE_HOME/bin:$PATH
sqlplus /nolog
SQL> conn /as sysdba
SQL> @?/olap/admin/olap.sql SYSAUX TEMP;

--这个脚本需要30+分钟

我这里按照DATABASE 的级别重建了OLAP。

13. 验证无效对象和组件状态

在我们重建OLAP 之前有很多的无效组件，现在查看，都变成了有效状态，并且也没有了无效对象，如果到这一步还有无效对象，那么继续执行utlrp.sql 来编译。

SQL> select count(*) from all_objectswhere status='INVALID';

COUNT(*)

----------

SQL> selectcomp_id,comp_name,version,status from dba_registry;

COMP_ID COMP_NAME VERSION STATUS

----------------------------------------------- ------------ ------------------

AMD OLAP Catalog 11.2.0.3.0 VALID

OWB OWB 11.2.0.3.0 VALID