之前整理的相关文章:
OracleConvert a 32-bit Database to 64-bit Database(32位 转到 64位)说明
http://blog.csdn.net/tianlesoftware/article/details/7252742
Oracle 单实例 从32位 迁移到 64位 方法(一)--直接 copydatafiles
http://blog.csdn.net/tianlesoftware/article/details/7258654
在这篇主要测试一下使用RMAN来将单实例从32位迁移到64位上。
MOS 上的文档:
RMAN Restoring A32 bit Database to 64 bit - An Example [ID 467676.1]
一.测试环境:
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
注意:
(1) 这里2个ORACLE_HOME 不一样,我们存放DATAFILE的文件目录也不一样,RMAN 可以恢复到相同的目录结构,也可以恢复到不同的目录结构,这个在之前的RMAN 测试中已经演示过。 我们这里演示恢复到不同的目录结构。
http://blog.csdn.net/tianlesoftware/article/details/6240983
(2)这里的OS 版本一样,我这里都是Oracle Linux,如果操作系统不一样,那么其对应ENDIA 格式可能也不一样,那样就牵涉到跨版本的迁移问题。所以只要我们的操作系统平台一致,我们从32迁移到64,只需要重新编译一下PL/SQL 模块就ok了。
二.具体操作
2.1 Source 操作
1. 在Source 端用RMAN 做full备份
RMAN 备份脚本,参考:
Nocatalog 下的RMAN 增量备份 shell脚本
http://blog.csdn.net/tianlesoftware/article/details/6164931
备份之后的文件:
[oracle@tianlesoftware backup]$ ls
anqing_lev0_01n3cena_1_1_20120215 arch_05n3ceq6_1_1_20120215
anqing_lev0_02n3cena_1_1_20120215 arch_06n3ceq6_1_1_20120215
anqing_spfile_08n3ceqe_1_1_20120215 ctl_file_07n3ceqb_1_1_20120215
2. 将口令文件和初始化文件拷贝到Target 库
3. 将备份文件传送到Target库
[oracle@tianlesoftware backup]$ scp *192.168.3.201:/u01/backup
oracle@192.168.3.201's password:
anqing_lev0_01n3cena_1_1_20120215 100% 601MB 5.2MB/s 01:55
anqing_lev0_02n3cena_1_1_20120215 100% 453MB 5.0MB/s 01:30
anqing_spfile_08n3ceqe_1_1_20120215 100% 96KB 96.0KB/s 00:00
arch_05n3ceq6_1_1_20120215 100% 33MB 4.1MB/s 00:08
arch_06n3ceq6_1_1_20120215 100%2560 2.5KB/s 00:00
ctl_file_07n3ceqb_1_1_20120215 100% 9568KB 3.1MB/s 00:03
这里要注意,对于Nocatalog 模式下的RMAN 备份,其备份信息是保存在控制文件里的,所以我们在备份文件copy 到Target 时的目录也必须和Source 一致,否则在Target 系统上识别不了这些备份文件。
这一点我们可以用list 命令来验证,即使我们在Target上执行,list 显示的目录也是Source 上的目录结构。
RMAN> list backup of database;
List of Backup Sets
===================
BS Key Type LV Size Device TypeElapsed Time Completion Time
------- ---- -- ---------- ----------------------- ---------------
1 Incr 0 453.23M DISK 00:01:15 15-FEB-12
BP Key: 1 Status: AVAILABLE Compressed: NO Tag: ANQING_LEV0
Piece Name: /u01/backup/anqing_lev0_02n3cena_1_1_20120215
List of Datafiles in backup set 1
File LV Type Ckp SCN CkpTime Name
---- -- ---- ---------- --------- ----
2 0 Incr 832532 15-FEB-12/u01/app/oracle/oradata/anqing/sysaux01.dbf
3 0 Incr 832532 15-FEB-12/u01/app/oracle/oradata/anqing/undotbs01.dbf
BS Key Type LV Size Device TypeElapsed Time Completion Time
------- ---- -- ---------- ----------------------- ---------------
3 Incr 0 600.79M DISK 00:01:25 15-FEB-12
BP Key: 3 Status: AVAILABLE Compressed: NO Tag: ANQING_LEV0
Piece Name: /u01/backup/anqing_lev0_01n3cena_1_1_20120215
List of Datafiles in backup set 3
File LV Type Ckp SCN CkpTime Name
---- -- ---- ---------- --------- ----
1 0 Incr 832530 15-FEB-12/u01/app/oracle/oradata/anqing/system01.dbf
4 0 Incr 832530 15-FEB-12/u01/app/oracle/oradata/anqing/users01.dbf
2.2 Target 操作
1. 创建相关的目录结构
rac1:/u02> cd app/oracle/
rac1:/u02/app/oracle> ls
checkpoints diag product
rac1:/u02/app/oracle> mkdir admin
rac1:/u02/app/oracle> mkdirfast_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>mkdiranqing
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
2. 修改pfile 中的相关参数值
修改之后的值:
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'
3. 恢复控制文件
--先用pfile 将db 启动到nomout 状态:
rac1:/u02/app/oracle/product/11.2.0/db_1/dbs>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production onWed Feb 15 11:08:03 2012
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup nomount pfile=?/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
--restore 控制文件
rac1:/home/oracle> rman target /
Recovery Manager: Release 11.2.0.3.0 -Production on Wed Feb 15 11:10:02 2012
Copyright (c) 1982, 2011, Oracle and/or itsaffiliates. All rights reserved.
connected to target database: ANQING (notmounted)
RMAN> restore controlfile from '/u02/backup/ctl_file_07n3ceqb_1_1_20120215';
Starting restore at 15-FEB-12
using channel ORA_DISK_1
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete,elapsed time: 00:00:03
output filename=/u02/app/oracle/oradata/anqing/control01.ctl
output filename=/u02/app/oracle/fast_recovery_area/anqing/control02.ctl
Finished restore at 15-FEB-12
--注意这里restore的控制文件的路径,是我们修改的pfile中指定的。
RMAN>
4. Restore 数据库
因为Target 和 Source 的目录就够不一样,所以在Restore db 的时候需要rename datafile 路径。
4.1 查看源库上datafile信息
SQL> select file_id,file_name fromdba_data_files;
FILE_ID FILE_NAME
---------- ---------------------------------------------------------------------
4 /u01/app/oracle/oradata/anqing/users01.dbf
3 /u01/app/oracle/oradata/anqing/undotbs01.dbf
2 /u01/app/oracle/oradata/anqing/sysaux01.dbf
1 /u01/app/oracle/oradata/anqing/system01.dbf
SQL> select file_id,file_name fromdba_temp_files;
FILE_ID FILE_NAME
-------------------------------------------------------------------------------
1 /u01/app/oracle/oradata/anqing/temp01.dbf
注意:restore 的时候不会对temp 表空间进行restore。所以等restore 之后,我们需要手工创建temp表空间。
4.2 在target 上restore DB
--db 启动到mount状态:
rac1:/home/oracle> rman target /
Recovery Manager: Release 11.2.0.3.0 -Production on Wed Feb 15 13:12:16 2012
Copyright (c) 1982, 2011, Oracle and/or itsaffiliates. All rights reserved.
connected to target database: ANQING (notmounted)
RMAN> set dbid=706107904
--DBID 从Source 上取:
SQL>Select dbid from v$database
executing command: SET DBID
RMAN> alter database mount;
using target database control file insteadof recovery catalog
database mounted
--restore 遇到小插曲了:
RMAN> run
2> {
3> set newname for datafile 1 to "/u02/app/oracle/oradata/anqing/system01.dbf";
4> set newname for datafile 2 to "/u02/app/oracle/oradata/anqing/sysaux01.dbf";
5> set newname for datafile 3 to "/u02/app/oracle/oradata/anqing/undotbs01.dbf";
6> set newname for datafile 4 to "/u02/app/oracle/oradata/anqing/users01.dbf";
7> restore database;
8> switch datafile all;
9> }
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
Starting restore at 15-FEB-12
using channel ORA_DISK_1
RMAN-00571:===========================================================
RMAN-00569: =============== ERROR MESSAGESTACK FOLLOWS ===============
RMAN-00571:===========================================================
RMAN-03002: failure of restore command at02/15/2012 13:21:41
RMAN-06026: some targets not found -aborting restore
RMAN-06023: no backup or copy of datafile 4found to restore
RMAN-06023: no backup or copy of datafile 3found to restore
RMAN-06023: no backup or copy of datafile 2found to restore
RMAN-06023: no backup orcopy of datafile 1 found to restore
--这里提示没有找得到备份文件,用list backup of database 查看是存在的,这种情况下,使用crosscheck backup; 命令执行一下,就ok了。
RMAN-06023 :no backup or copy of datafile found to restore 说明
http://blog.csdn.net/tianlesoftware/article/details/6460459
RMAN> crosscheck backup;
using channel ORA_DISK_1
crosschecked backup piece: found to be'AVAILABLE'
backup piecehandle=/u01/backup/anqing_lev0_02n3cena_1_1_20120215 RECID=1 STAMP=775305963
crosschecked backup piece: found to be'EXPIRED'
backup piecehandle=/u01/backup/anqing_lev0_03n3cepn_1_1_20120215 RECID=2 STAMP=775306046
crosschecked backup piece: found to be'AVAILABLE'
backup piecehandle=/u01/backup/anqing_lev0_01n3cena_1_1_20120215 RECID=3 STAMP=775305963
crosschecked backup piece: found to be'EXPIRED'
backup piecehandle=/u01/backup/anqing_lev0_04n3ceq0_1_1_20120215 RECID=4 STAMP=775306048
crosschecked backup piece: found to be'AVAILABLE'
backup piecehandle=/u01/backup/arch_06n3ceq6_1_1_20120215 RECID=5 STAMP=775306055
crosschecked backup piece: found to be'AVAILABLE'
backup piecehandle=/u01/backup/arch_05n3ceq6_1_1_20120215 RECID=6 STAMP=775306054
Crosschecked 6 objects
RMAN> run
2> {
3> set newname for datafile 1 to "/u02/app/oracle/oradata/anqing/system01.dbf";
4> set newname for datafile 2 to "/u02/app/oracle/oradata/anqing/sysaux01.dbf";
5> set newname for datafile 3 to "/u02/app/oracle/oradata/anqing/undotbs01.dbf";
6> set newname for datafile 4 to "/u02/app/oracle/oradata/anqing/users01.dbf";
7> restore database;
8> switch datafile all;
9> }
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
Starting restore at 15-FEB-12
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafilebackup set restore
channel ORA_DISK_1: specifying datafile(s)to restore from backup set
channel ORA_DISK_1: restoring datafile00002 to /u02/app/oracle/oradata/anqing/sysaux01.dbf
channel ORA_DISK_1: restoring datafile00003 to /u02/app/oracle/oradata/anqing/undotbs01.dbf
channel ORA_DISK_1: reading from backuppiece /u01/backup/anqing_lev0_02n3cena_1_1_20120215
channel ORA_DISK_1: piecehandle=/u01/backup/anqing_lev0_02n3cena_1_1_20120215 tag=ANQING_LEV0
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete,elapsed time: 00:00:35
channel ORA_DISK_1: starting datafilebackup set restore
channel ORA_DISK_1: specifying datafile(s)to restore from backup set
channel ORA_DISK_1: restoring datafile00001 to /u02/app/oracle/oradata/anqing/system01.dbf
channel ORA_DISK_1: restoring datafile00004 to /u02/app/oracle/oradata/anqing/users01.dbf
channel ORA_DISK_1: reading from backuppiece /u01/backup/anqing_lev0_01n3cena_1_1_20120215
channel ORA_DISK_1: piecehandle=/u01/backup/anqing_lev0_01n3cena_1_1_20120215 tag=ANQING_LEV0
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete,elapsed time: 00:00:45
Finished restore at 15-FEB-12
datafile 1 switched todatafile copy
input datafile copy RECID=5 STAMP=775315815file name=/u02/app/oracle/oradata/anqing/system01.dbf
datafile 2 switched to datafile copy
input datafile copy RECID=6 STAMP=775315815file name=/u02/app/oracle/oradata/anqing/sysaux01.dbf
datafile 3 switched to datafile copy
input datafile copy RECID=7 STAMP=775315815file name=/u02/app/oracle/oradata/anqing/undotbs01.dbf
datafile 4 switched to datafile copy
input datafile copy RECID=8 STAMP=775315815file name=/u02/app/oracle/oradata/anqing/users01.dbf
对switch datafile all命令的说明:
--对于nocatalog 模式下,rman备份的信息是保存在控制文件里的,包括文件的路径信息。 这里的switchdatafile all的作用,就是更新控制文件里的信息。
8. Recover DB
RMAN> recover database;
Starting recover at 15-FEB-12
using channel ORA_DISK_1
starting media recovery
channel ORA_DISK_1: starting archived logrestore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=5
channel ORA_DISK_1: reading from backuppiece /u01/backup/arch_05n3ceq6_1_1_20120215
channel ORA_DISK_1: piecehandle=/u01/backup/arch_05n3ceq6_1_1_20120215 tag=ARC_BAK
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete,elapsed time: 00:00:03
archived log filename=/u02/archivelog/1_5_775166151.arc thread=1 sequence=5
channel ORA_DISK_1: starting archived logrestore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=6
channel ORA_DISK_1: reading from backuppiece /u01/backup/arch_06n3ceq6_1_1_20120215
channel ORA_DISK_1: piece handle=/u01/backup/arch_06n3ceq6_1_1_20120215tag=ARC_BAK
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete,elapsed time: 00:00:01
archived log filename=/u02/archivelog/1_6_775166151.arc thread=1 sequence=6
unable to find archived log
archived log thread=1 sequence=7
RMAN-00571:===========================================================
RMAN-00569: =============== ERROR MESSAGESTACK FOLLOWS ===============
RMAN-00571:===========================================================
RMAN-03002: failure of recover command at02/15/2012 13:39:22
RMAN-06054: media recovery requestingunknown archived log for thread 1 with sequence 7 and starting SCN of 832585
之后会报一个错误:
RMAN-06054:media recovery requesting unknown archived log for thread 1 with sequence 7 andstarting SCN of 832585
这里是提醒恢复到一个未知的scn号。在alter database mount之后,通过set until scn或者set until time命令设置恢复到的scn号或时间。就可以避免这个错误。
我们看Source 库的日志序列:
SQL> select sequence# from v$archived_log;
SEQUENCE#
----------
5
6
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u01/archivelog
Oldest online log sequence 5
Next log sequence to archive 7
Current log sequence 7
以上信息可以看出,我们在备份时只有5和6 个归档,7还是online redo,所以没有copy过来,如果我们不指定recover的结束时间,最后就会提示我们上面的信息:RMAN-06054. 所以我们指定一些sequence,在recover 一次验证一下:
RMAN> run
2> {
3> set until sequence 7;
4> recover database;
5> }
executing command: SET until clause
Starting recover at 15-FEB-12
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time:00:00:00
Finished recover at 15-FEB-12
9. open resetlogs 并 处理onlineredo 问题
SQL> recoverdatabase until cancel using backup controlfile;
ORA-00279: change 832585 generated at02/15/2012 10:47:33 needed for thread 1
ORA-00289: suggestion :/u02/archivelog/1_7_775166151.arc
ORA-00280: change 832585 for thread 1 is insequence #7
Specify log: {<RET>=suggested |filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SQL> alterdatabase open resetlogs migrate;
alter database open resetlogs migrate
*
ERROR at line 1:
ORA-00344: unable to re-create online log
'/u01/app/oracle/oradata/anqing/redo01.log'
ORA-27040: file create error, unable tocreate file
Linux-x86_64 Error: 2: No such file ordirectory
Additional information: 1
--这里提示我们报错,因为我们在source库上的online redo 是在/u01 目录下,在Target上变成了/u02. 在open resetlogs 时,会重新创建online redo log。 所以这里会因为相关的目录不存在,而失败。
SQL> select open_mode from v$database;
OPEN_MODE
----------------------------------------
MOUNTED
SQL> select group#,type,member fromv$logfile;
GROUP# TYPE MEMBER
---------- --------------------------------------------------------------------
3 ONLINE /u01/app/oracle/oradata/anqing/redo03.log
2 ONLINE /u01/app/oracle/oradata/anqing/redo02.log
1 ONLINE /u01/app/oracle/oradata/anqing/redo01.log
--从这里可以判断,open resetlogs 时创建的redo 是根据这里的信息来创建的。
SQL> select group#,sequence#,bytes,members,status from v$log;
GROUP# SEQUENCE# BYTES MEMBERS STATUS
---------- ---------- ---------- ------------------------------------------
1 0 52428800 1 CLEARING_CURRENT
3 0 52428800 1 CLEARING
2 0 52428800 1 CLEARING
这里的状态官方文档有说明:
http://docs.oracle.com/cd/E11882_01/server.112/e25513/dynviews_2031.htm
(1)CLEARING - Log isbeing re-created as an empty log after an ALTER DATABASE CLEAR LOGFILE statement.After the log is cleared, the status changes to UNUSED.
(2)CLEARING_CURRENT -Current log is being cleared of a closed thread. The log can stay in thisstatus if there is some failure in the switch such as an I/O error writing thenew log header.
这里有2中方法,一种是先创建和Source 相同的目录,把DB 拉起来之后,在去修改online redo 的位置,二是现在修改,但是我们这里只能修改CLEARING状态的online redo。对于clearing_current 状态的,不能操作。
--处理方法:drop 原来的group,在添加新的group
SQL> alter database drop logfile group2;
Database altered.
SQL> alter database drop logfile group3;
alter database drop logfile group 3
*
ERROR at line 1:
ORA-01567: dropping log 3 would leave lessthan 2 log files for instance anqing
(thread 1)
ORA-00312: online log 3 thread 1:'/u01/app/oracle/oradata/anqing/redo03.log'
--至少要有2组onlinegroup
SQL> alter database add logfile group2('/u02/app/oracle/oradata/anqing/redo02.log') size 50M;
Database altered.
SQL> selectgroup#,sequence#,bytes,members,status from v$log;
GROUP# SEQUENCE# BYTES MEMBERS STATUS
---------- ---------- ---------- ------------------------------------------
1 0 52428800 1 CLEARING_CURRENT
3 0 52428800 1 CLEARING
2 0 52428800 1 UNUSED
SQL> alter database drop logfile group3;
Database altered.
SQL> alter database add logfile group3('/u02/app/oracle/oradata/anqing/redo03.log') size 50M;
Database altered.
SQL>
--当前的online还是不能操作:
SQL> alter database drop logfile group1;
alter database drop logfile group 1
*
ERROR at line 1:
ORA-01623: log 1 is current log forinstance anqing (thread 1) - cannot drop
ORA-00312: online log 1 thread 1:'/u01/app/oracle/oradata/anqing/redo01.log'
所以通过以上的测试,最好的方法还是先把库拉起来,以后在调整。因为在mount 状态下,我们也不能进行switchlogfile的操作。
与online redo 相关的故障处理参考:
http://blog.csdn.net/tianlesoftware/article/details/6106178
Currentonline Redo 和 Undo 损坏的处理方法
http://blog.csdn.net/tianlesoftware/article/details/6261475
这里我们还是创建目录,把库拉起来,在处理后续问题:
rac1:/> mkdir -p/u01/app/oracle/oradata/anqing/
--拉DB
SQL> alter database open resetlogs migrate;
alter database open resetlogs migrate
*
ERROR at line 1:
ORA-00392: log 1 ofthread 1 is being cleared, operation not allowed
ORA-00312: online log 1 thread 1:'/u01/app/oracle/oradata/anqing/redo01.log'
--之前我们保留的那个online 状态不对,无法使用,现在也不能进行归档的切换,只能先clear 一下,以后在处理了。
SQL> alter database clear logfile group1;
Database altered.
SQL> select group#,sequence#,bytes,members,status from v$log;
GROUP# SEQUENCE# BYTES MEMBERS STATUS
---------- ---------- ---------- ------------------------------------------
1 0 52428800 1 CURRENT
3 0 52428800 1 UNUSED
2 0 52428800 1 UNUSED
SQL> alter databaseopen resetlogs migrate;
Database altered.
SQL>
--至此,DB 已经拉起来了。
10. 迁移到64位: 编译PL/SQL模块
--执行utlirp.sql脚本:
SQL> @?/rdbms/admin/utlirp.sql
….
--大概5分钟
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>###############################################################
所有的PL/SQL 对象都变成无效,需要shutdown db,然后以normal 启动,并执行utlrp.sql 脚本。
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 1023414192 bytes
Database Buffers 369098752 bytes
Redo Buffers 8241152 bytes
Database mounted.
Database opened.
11. 编译无效对象
SQL> @?/rdbms/admin/utlrp.sql
--约一个小时
异常中断:
ORA-07445: exception encountered: core dump[__intel_new_memcpy()+2164] [SIGSEGV] [ADDR:0x7F9AFBD7026F] [PC:0x47ED7D4][Address not mapped to object] []
Incident details in:/u02/app/oracle/diag/rdbms/anqing/anqing/incident/incdir_10977/anqing_ora_3507_i10977.trc
Use ADRCI or Support Workbench to packagethe incident.
See Note 411.1 at My Oracle Support forerror and packaging details.
Wed Feb 15 15:46:31 2012
Dumping diagnostic data indirectory=[cdmp_20120215154631], requested by (instance=1, osid=3507),summary=[incident=10977].
Wed Feb 15 15:46:36 2012
Sweep [inc][10977]: completed
Sweep [inc2][10977]: completed
导致这个问题,是因为我们启动了OLAP,在32位转到64位时就会遇到这种错误。
具体的处理方法描述参考:
Oracle 单实例 从32位 迁移到 64位 方法(一)--直接 copydatafiles
http://blog.csdn.net/tianlesoftware/article/details/7258654
重建完毕之后,再次编译无效对象,正常,只是这里使用重建需要30+分钟,加上再次编译无效对象的时间,加起来需要1个多小时,太浪费时间,如果系统不需要启动OLAP组件,完全可以不用安装,这样可以减少很多的麻烦。
SQL> select count(*) from all_objectswhere status='INVALID';
COUNT(*)
----------
0
SQL> select comp_name,status fromdba_registry;
COMP_NAME STATUS
---------------------------------------------------------
OLAP Catalog VALID
OWB VALID
Oracle Application Express VALID
Oracle Enterprise Manager VALID
Spatial VALID
Oracle Multimedia VALID
Oracle XML Database VALID
Oracle Text VALID
Oracle Expression Filter VALID
Oracle Rules Manager VALID
Oracle Workspace Manager VALID
COMP_NAME STATUS
---------------------------------------------------------
Oracle Database Catalog Views VALID
Oracle Database Packages and Types VALID
JServer JAVA Virtual Machine VALID
Oracle XDK VALID
Oracle Database Java Packages VALID
Oracle OLAP API VALID
OLAP Analytic Workspace VALID
18 rows selected.
12. 重建 javashared data objects (SRO)
用SYS 用户执行如下脚本:
begin
update obj$ set status=5 where obj#=(select obj# from obj$,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 and u.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 amaxnumber of iterations
select count(*) into iterations from obj$ where type#=56;
exit when iterations=0 or iterations>=previous_iterations;
previous_iterations := iterations;
loop_count := 0;
open C1;
loop
begin
fetch C1 into ddl_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 from java$policy$shared$table');
update obj$ set status=1 where obj#=(select obj# from obj$,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
/
--十分钟左右
13. 重建TEMP 表空间
SQL> ALTER TABLESPACE TEMP ADDTEMPFILE'/u02/app/oracle/oradata/anqing/temp01.dbf' SIZE 30408704 REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;
Tablespace altered.
至此,用RMAN 将DB 从32位迁移到64位的工作结束。对于RAC 环境,当cluster_database 设置为FALSE 后,这种方法也使用。
小结:
使用直接copydatafiles 和 RMAN Restore 来进行迁移,都有一个问题,就是在启动OLAP 组件的情况下需要重建该组件,这是一个非常耗时的事情。如果用不到该组件,可以不安装,这样可以省很多时间。
在下篇Blog 将介绍最后一种简单的方法:使用导出导入。
-------------------------------------------------------------------------------------------------------
版权所有,文章允许转载,但必须以链接方式注明源地址,否则追究法律责任!
Email: tianlesoftware@gmail.com
Skype: tianlesoftware
Blog: http://www.tianlesoftware.com
Weibo: http://weibo.com/tianlesoftware
Twitter: http://twitter.com/tianlesoftware
Facebook:http://www.facebook.com/tianlesoftware
-------加群需要在备注说明Oracle表空间和数据文件的关系,否则拒绝申请----
DBA1 群:62697716(满); DBA2 群:62697977(满) DBA3 群:62697850(满)
DBA 超级群:63306533(满); DBA4 群:83829929 DBA5群: 142216823
DBA6 群:158654907 DBA7 群:172855474 DBA总群:104207940