Linux平臺下RMAN異機恢復總結
瀟湘隱者
Linux平臺下RMAN異機恢復總結
2017-05-29 16:30 by 瀟湘隱者, ... 閱讀, ... 評論, 收藏, 編輯html
下面總結、整理一下RMAN異機恢復這方面的知識點，這篇筆記在我的筆記裏面躺了幾年了，直到最近偶然被翻看到，遂整理、總結一下。以下所示，我的將整個RMAN異機恢復分爲準備工做和操做步驟兩大部分。固然，準備工做裏面，有些步驟不是必須的，能夠跳過或忽略的。這個取決於你的實際環境和你對RMAN異機恢復的熟悉程度。sql
準備工做數據庫
1：瞭解一下目標服務器與源服務器的操做系統版本信息服務器
須要對比一下目標服務器與源服務器的操做系統版本是否一致，具體來講，操做系統版本信息、內核信息（例如Oracle Linux是否使用Unbreakable Enterprise Kernel內核等），以及操做系統是32bit仍是64bit等。若是RMAN異機恢復只是準備Dev、Test、UAT環境，那麼這個徹底能夠忽略，若是是正式環境的遷移，那麼最好關注一下，避免一些問題。例如，有些版本的操做系統對不是官方認證的，若是在遷移前不關注這些，那麼遷移後，有可能出現一些意想不到的問題。session
# uname -a
# uname -m
# more /etc/redhat-release
注意：這些工做是前期準備工做，不能到RMAN還原恢復的時候才作。oracle
2：檢查目標服務器與源服務器的數據庫版本信息app
若是源數據庫和目標數據庫版本一致，那麼徹底能夠跳過這一步。可是，有時候多是從32位還原升級到64位；有些是從ORACLE 10g 遷移升級到ORACLE 11g，那麼在後面的RMAN還原後，還需作一些額外的Upgrade工做。我的剛作DBA的第一年，在一次遷移過程，事先安裝過程當中不當心選錯了版本（標準版弄成了企業版，安裝過程當中因爲檢查某個選項，點擊後退過程當中系統默認選擇了企業版，當時沒有發現），後續沒有仔細檢查，遷移完成後，驗證時才發現版本是企業版。結果將整個遷移進度所有打亂了！post
32bit測試
64bitspa
3：檢查實例安裝路徑以及數據文件等路徑
這裏指數據庫實例的安裝路徑，以及數據文件、控制文件、參數文件是否一致，若是所有一致的話，那麼能夠避免不少問題，可是不少時候，
咱們須要從新規劃存儲路徑或者其它一些緣由，這些數據文件、參數文件等，頗有可能跟源服務器不一致，那麼事先了解這些，在遷移過程當中
就必須注意到這些狀況。做出相應的處理。不然RMAN還原過程當中就會遇到一些問題。
4：將備份文件拷貝的相關目錄
能夠將備份拷貝到恢復目錄解壓或指定目錄解壓。若是源服務器與目標服務器的RMAN備份路徑一致，那麼能夠省去不少沒必要要的麻煩。
5： 建立相關的目錄
例如，目標服務器安裝ORACLE實例時，選擇了「只安裝實例」選項，那麼在RMAN還原以前，咱們必須建立下面一些目錄（這些不是必須的，有些環境甚至徹底沒必要要。具體根據實際狀況判斷）：
1： 建立$ORACLE_BASE/admin/$ORACLE_SID/下的六個目錄；
2： $ORACLE_BASE/oradata下建立$ORACLE_SID目錄；
3： RMAN備份路徑目錄（這個地方最好與源數據庫一致，建立好後，把源數據庫備份的數據文件複製到這個目錄裏）；--非必須。
4： 歸檔日誌目錄（一樣，建立好後，把須要的歸檔日誌文件複製到此目錄） --非必須。
[root@getlnx14dev ~]#mkdir -p admin/SCM2/{adump,bdump,cdump,dpdump,pfile,udump}
[root@getlnx14dev ~]#mkdir -p oradata/$ORACLE_SID
[root@getlnx14dev ~]# chown -R oracle:oinstall /data
[root@getlnx14dev ~]# su - oracle
Last login: Fri May 26 13:38:38 CST 2017 on pts/2
[oracle@getlnx14dev ~]$ cd /data/
[oracle@getlnx14dev data]$ mkdir scm2
[oracle@getlnx14dev data]$
操做步驟
下面測試，是將數據庫經過RMAN備份恢復到一臺測試服務器，出於測試目的，故意將實例的安裝路徑，以及恢復路徑所有故意弄成不一致。具體測試環境以下：
源服務器：
操做系統： Red Hat Enterprise Linux Server release 5.1
數據庫版本： Oracle Database 10g Release 10.2.0.4.0 32bit 標準版
目標服務器：
操做系統： Red Hat Enterprise Linux Server release 7.2 (Maipo) #注意，這個版本不是官方認證版本，僅作測試而已。
數據庫版本： Oracle Database 10g Release 10.2.0.4.0 64bit 標準版
1：查詢DBID信息
DBID是DataBase IDentifier的縮寫，意思就是數據庫的惟一標識符。這個DBID在數據文件頭和控制文件都是存在的，能夠用於標示數據文件的歸屬。
對於不一樣數據庫來講，DBID應當不一樣，而db_name則多是相同的。通常在nocatalog模式而且控制文件丟失時才須要這個。
SQL> select name,dbid from v$database;
NAME DBID
--------- ----------
SCM2 3990839260
SQL>
若是源服務器已經宕機，那麼如何查詢DBID相關信息呢？ 關於這個，其實也有不少方法獲取，例如，若是你曾經作過AWR報告，能夠從AWR中找到對應的DBID，也能夠從恢復的控制文件獲取等。
2：啓動數據庫實例到nomount狀態
使用RMAN還原恢復時，DB必須啓動到nomout狀態。
[oracle@getlnx14dev SCM2]$ rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Sun May 28 21:14:36 2017
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database (not started)
RMAN> startup nomount pfile='/home/oracle/oracle/product/10.2.0/db_1/dbs/init.ora';
Oracle instance started
Total System Global Area 159383552 bytes
Fixed Size 2082400 bytes
Variable Size 150997408 bytes
Database Buffers 4194304 bytes
Redo Buffers 2109440 bytes
3：還原參數文件spfile
RMAN>set DBID=3990839260;
RMAN>restore spfile to pfile '/home/oracle/oracle/product/10.2.0/db_1/dbs/spfileSCM2.ora' from '/app/backup/backup/backupsets/ora_cfc-3990839260-20170518-00';
參數文件恢復後，須要修改相關參數，這裏因爲測試緣故，咱們故意在目標服務器安裝ORACLE實例時，隨意選擇了一個路徑，故意與源服務器ORACLE實例的安裝路徑不一致，固然，還有其它一些狀況，也有可能致使你必須修改一些參數。
db_name=SCM2
db_block_size=8192
db_file_multiblock_read_count=16
sga_target=1200M
pga_aggregate_target=760M
audit_file_dest=/u01/app/oracle/admin/SCM2/adump
background_dump_dest=/u01/app/oracle/admin/SCM2/bdump
user_dump_dest=/u01/app/oracle/admin/SCM2/udump
core_dump_dest=/u01/app/oracle/admin/SCM2/cdump
control_files=('/u01/app/oracle/oradata/SCM2/control01.ctl','/u01/app/oracle/oradata/SCM2/control02.ctl','/u01/app/oracle/oradata/SCM2/control03.ctl')
compatible=10.2.0.1.0
remote_login_passwordfile=exclusive
open_cursors=300
sessions=450
processes=300
undo_management=auto
undo_tablespace=UNDOTBS1
修改後的pfile參數文件。
db_name=SCM2
db_block_size=8192
db_file_multiblock_read_count=16
sga_target=1200M
pga_aggregate_target=760M
audit_file_dest=/home/oracle/oracle/admin/SCM2/adump
background_dump_dest=/home/oracle/oracle/admin/SCM2/bdump
user_dump_dest=/home/oracle/oracle/admin/SCM2/udump
core_dump_dest=/home/oracle/oracle/admin/SCM2/cdump
control_files=('/home/oracle/oracle/oradata/SCM2/control01.ctl','/home/oracle/oracle/oradata/SCM2/control02.ctl','/home/oracle/oracle/orada
ta/SCM2/control03.ctl')
compatible=10.2.0.1.0
remote_login_passwordfile=exclusive
open_cursors=300
sessions=450
processes=300
undo_management=auto
undo_tablespace=UNDOTBS1
若是前面準備步驟，沒有建立對應的udmp等目錄，就會遇到下面錯誤
RMAN> startup nomount pfile='/home/oracle/oracle/product/10.2.0/db_1/dbs/initSCM2.ora';
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of startup command at 05/26/2017 15:27:45
RMAN-04014: startup failed: ORA-00444: background process "PMON" failed while starting
ORA-07446: sdnfy: bad value '' for parameter .
Problem
The path to bdump,adump or udump does not exist. Oracle itself does not create any path if a path does not exist. So, you have to change the value of user_dump_dest in the initialize parameter.
Solution
If you use pfile to start your database then edit the pfile with any editor (for example vi on unix) and either change the location of user_dump_dest or remove the parameter user_dump_dest from pfile. And then perform. startup
4: 還原控制文件（control file）。
若是你實在不知道控制文件在那個備份集的那個文件，那麼能夠在源服務器使用list命令查看。以下所示。 固然若是經驗豐富或者你對備份與還原瞭如指掌的話， 徹底不用這一步驟。
RMAN> list backup of controlfile;
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
4 Full 7.58M DISK 00:00:00 18-MAY-17
BP Key: 4 Status: AVAILABLE Compressed: NO Tag: TAG20170518T224247
Piece Name: /u03/backup/backupsets/ora_cfc-3990839260-20170518-00
Control File Included: Ckp SCN: 22876629756 Ckp time: 18-MAY-17
後續具體操做操做以下所示
RMAN> shutdown immediate;
using target database control file instead of recovery catalog
Oracle instance shut down
RMAN> exit
Recovery Manager complete.
[oracle@getlnx14dev ~]$ export ORACLE_SID=SCM2;
[oracle@getlnx14dev ~]$ rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Mon May 29 08:41:17 2017
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: SCM2 (DBID=3990839260)
RMAN>
RMAN> startup nomount pfile='/home/oracle/oracle/product/10.2.0/db_1/dbs/initSCM2.ora';
connected to target database (not started)
Oracle instance started
Total System Global Area 1258291200 bytes
Fixed Size 2083624 bytes
Variable Size 318768344 bytes
Database Buffers 922746880 bytes
Redo Buffers 14692352 bytes
RMAN>
RMAN>restore controlfile from '/app/backup/backup/backupsets/ora_cfc-3990839260-20170518-00';
Starting restore at 26-MAY-17
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=437 devtype=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
output filename=/home/oracle/oracle/oradata/SCM2/control01.ctl
output filename=/home/oracle/oracle/oradata/SCM2/control02.ctl
output filename=/home/oracle/oracle/oradata/SCM2/control03.ctl
Finished restore at 26-MAY-17
RMAN>
5：啓動數據庫到mount狀態
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
RMAN>
6：檢查數據庫備份有效性
RMAN> crosscheck backup;
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=437 devtype=DISK
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=/u03/backup/backupsets/ora_df944345823_s1_s1 recid=1 stamp=944345824
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=/u03/backup/backupsets/ora_df944345828_s2_s1 recid=2 stamp=944345829
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=/u03/backup/backupsets/ora_df944347364_s3_s1 recid=3 stamp=944347365
Crosschecked 3 objects
經過下面這個命令能夠將備份集註冊到控制文件。catalog start with命令將之前的備份集信息從新導入到當前控制文件中, 通常應用於RMAN恢復, 控制文件又是舊的或者是手工建立的(這樣的控制文件固然沒有最新的備份集的信息),或者恢復目錄不一致的狀況, 經過catalog start with 能夠將最新的備份集以及歸檔日誌文件列表導入到控制文中, 而後就能夠進行rman的恢復了.
RMAN> catalog start with '/app/backup/backup';
searching for all files that match the pattern /app/backup/backup
List of Files Unknown to the Database
=====================================
File Name: /app/backup/backup/backuplogs/rman_backup_db_EELSCM2_2017-05-18.log
File Name: /app/backup/backup/backupsets/ora_df944345828_s2_s1
File Name: /app/backup/backup/backupsets/ora_df944347364_s3_s1
File Name: /app/backup/backup/backupsets/ora_cfc-3990839260-20170518-00
File Name: /app/backup/backup/backupsets/controlfile.copy
File Name: /app/backup/backup/backupsets/ora_df944345823_s1_s1
Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /app/backup/backup/backupsets/ora_df944345828_s2_s1
File Name: /app/backup/backup/backupsets/ora_df944347364_s3_s1
File Name: /app/backup/backup/backupsets/ora_cfc-3990839260-20170518-00
File Name: /app/backup/backup/backupsets/controlfile.copy
File Name: /app/backup/backup/backupsets/ora_df944345823_s1_s1
List of Files Which Where Not Cataloged
=======================================
File Name: /app/backup/backup/backuplogs/rman_backup_db_EELSCM2_2017-05-18.log
RMAN-07517: Reason: The file header is corrupted
RMAN> crosscheck backup;
using channel ORA_DISK_1
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=/u03/backup/backupsets/ora_df944345823_s1_s1 recid=1 stamp=944345824
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/app/backup/backup/backupsets/ora_df944345823_s1_s1 recid=7 stamp=945013360
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=/u03/backup/backupsets/ora_df944345828_s2_s1 recid=2 stamp=944345829
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/app/backup/backup/backupsets/ora_df944345828_s2_s1 recid=4 stamp=945013360
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=/u03/backup/backupsets/ora_df944347364_s3_s1 recid=3 stamp=944347365
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/app/backup/backup/backupsets/ora_df944347364_s3_s1 recid=5 stamp=945013360
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/app/backup/backup/backupsets/ora_cfc-3990839260-20170518-00 recid=6 stamp=945013360
Crosschecked 7 objects
RMAN> restore database preview summary;
Starting restore at 26-MAY-17
using channel ORA_DISK_1
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
2 B F A DISK 18-MAY-17 1 1 YES TAG20170518T221708
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
3 B A A DISK 18-MAY-17 1 1 YES TAG20170518T224244
Media recovery start SCN is 22876629141
Recovery must be done beyond SCN 22876629141 to clear data files fuzziness
Finished restore at 26-MAY-17
RMAN>
7： Restore database
若是要將數據文件還原到不一樣的地方（恢復路徑不一樣），那麼就要用set命令指定新位置。 而且使用switch datafile all將信息更新的到控制文件。不然就能夠直接使用restore database命令。
run
{
set newname for datafile 1 to "/data/scm2/system01.dbf";
set newname for datafile 2 to "/data/scm2/undotbs01.dbf";
set newname for datafile 3 to "/data/scm2/sysaux01.dbf";
set newname for datafile 4 to "/data/scm2/users01.dbf";
set newname for datafile 5 to "/data/scm2/bookt_d01.dbf";
set newname for datafile 6 to "/data/scm2/data_consol_d01.dbf";
set newname for datafile 7 to "/data/scm2/data_consol_x01.dbf";
set newname for datafile 8 to "/data/scm2/escmowner_d01.dbf";
set newname for datafile 9 to "/data/scm2/escmowner_x01.dbf";
set newname for datafile 10 to "/data/scm2/escmowner_x02.dbf";
set newname for datafile 11 to "/data/scm2/escmowner_x03.dbf";
set newname for datafile 12 to "/data/scm2/escmupdate_d01.dbf";
set newname for datafile 13 to "/data/scm2/escmupdate_x01.dbf";
set newname for datafile 14 to "/data/scm2/gent_d03.dbf";
set newname for datafile 15 to "/data/scm2/gent_d01.dbf";
set newname for datafile 16 to "/data/scm2/gent_d02.dbf";
set newname for datafile 17 to "/data/scm2/gent_x01.dbf";
set newname for datafile 18 to "/data/scm2/gsot_d01.dbf";
set newname for datafile 19 to "/data/scm2/inventory_d01.dbf";
set newname for datafile 20 to "/data/scm2/inventory_d02.dbf";
set newname for datafile 21 to "/data/scm2/inventory_x01.dbf";
set newname for datafile 22 to "/data/scm2/mit_d01.dbf";
set newname for datafile 23 to "/data/scm2/ppot_d01.dbf";
set newname for datafile 24 to "/data/scm2/sct_d01.dbf";
set newname for datafile 25 to "/data/scm2/smt_d01.dbf";
set newname for datafile 26 to "/data/scm2/smt_x01.dbf";
set newname for datafile 27 to "/data/scm2/statspack_d01.dbf";
set newname for datafile 28 to "/data/scm2/stat_d01.dbf";
set newname for datafile 29 to "/data/scm2/stat_x01.dbf";
set newname for datafile 30 to "/data/scm2/tna_d01.dbf";
set newname for datafile 31 to "/data/scm2/tna_x01.dbf";
set newname for datafile 32 to "/data/scm2/tracking_d01.dbf";
set newname for datafile 33 to "/data/scm2/gent_d04.dbf";
set newname for datafile 34 to "/data/scm2/ANTIDUMP_D02.dbf";
set newname for datafile 35 to "/data/scm2/ANTIDUMP_x01.dbf";
set newname for datafile 36 to "/data/scm2/escmupdate_d02.dbf";
set newname for datafile 37 to "/data/scm2/users02.dbf";
set newname for datafile 38 to "/data/scm2/escmupdate_d03.dbf";
set newname for datafile 39 to "/data/scm2/TDC_SHIPING_DATA01.dbf";
set newname for datafile 40 to "/data/scm2/TDC_SHIPING_IDX01.dbf";
set newname for datafile 41 to "/data/scm2/escmowner_d02.dbf";
restore database ;
switch datafile all;
}
8 Recover database;
RMAN> recover database;
Starting recover at 28-MAY-17
using channel ORA_DISK_1
starting media recovery
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=7242
channel ORA_DISK_1: reading from backup piece /app/backup/backup/backupsets/ora_df944347364_s3_s1
channel ORA_DISK_1: restored backup piece 1
piece handle=/app/backup/backup/backupsets/ora_df944347364_s3_s1 tag=TAG20170518T224244
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archive log filename=/home/oracle/oracle/product/10.2.0/db_1/dbs/arch1_7242_720647799.dbf thread=1 sequence=7242
unable to find archive log
archive log thread=1 sequence=7243
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/28/2017 22:13:21
RMAN-06054: media recovery requesting unknown log: thread 1 seq 7243 lowscn 22876629745
RMAN>
這裏是提醒恢復到一個未知的scn號。在alter database mount以後，經過set until scn或者set until time命令設置恢復到的scn號或時間。就能夠避免這個錯誤。
9：處理redo log和temp表空間
如前面所說，若是實例安裝路徑不一樣，或者redo log和臨時表空間對應的文件在目標服務器上找不到。那麼就必須操做下面
SQL> col status for a7
SQL> col type for a7;
SQL> col member for a64;
SQL> select * from v$logfile;
GROUP# STATUS TYPE MEMBER IS_
---------- ------- ------- ---------------------------------------------------------------- ---
4 ONLINE /u01/app/oracle/oradata/SCM2/redo04.log NO
3 ONLINE /u01/app/oracle/oradata/SCM2/redo03.log NO
2 ONLINE /u01/app/oracle/oradata/SCM2/redo02.log NO
1 ONLINE /u01/app/oracle/oradata/SCM2/redo01.log NO
SQL>
SQL> alter database rename file '/u01/app/oracle/oradata/SCM2/redo01.log'
2 to '/home/oracle/oracle/oradata/SCM2/redo01.log';
Database altered.
SQL> alter database rename file '/u01/app/oracle/oradata/SCM2/redo02.log'
2 to '/home/oracle/oracle/oradata/SCM2/redo02.log';
Database altered.
SQL> alter database rename file '/u01/app/oracle/oradata/SCM2/redo03.log'
2 to '/home/oracle/oracle/oradata/SCM2/redo03.log';
Database altered.
SQL> alter database rename file '/u01/app/oracle/oradata/SCM2/redo04.log'
2 to '/home/oracle/oracle/oradata/SCM2/redo04.log';
Database altered.
SQL>
若是不處理，不然就會出現這樣的錯誤：
RMAN> alter database open resetlogs;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 05/26/2017 16:28:37
ORA-00344: unable to re-create online log '/u01/app/oracle/oradata/SCM2/redo01.log'
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 2: No such file or directory
SQL> col name for a80;
SQL> select name from v$tempfile;
NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/SCM2/temp01.dbf
SQL> alter database tempfile '/u01/app/oracle/oradata/SCM2/temp01.dbf' drop;
SQL> alter tablespace temp
2 add tempfile '/home/oracle/oracle/oradata/temp01.dbf'
3 size 200M
4 autoextend on
5 next 128M
6 maxsize 4G;
Tablespace altered.
10：用open resetlogs 打開數據庫
正常狀況下應該是
SQL> alter database open resetlogs;
Database altered.
可是，這個是從32位數據庫還原到64bit數據庫，那麼就可能出現下面狀況。
RMAN> alter database open resetlogs;
database opened
RMAN-06900: WARNING: unable to generate V$RMAN_STATUS or V$RMAN_OUTPUT row
RMAN-06901: WARNING: disabling update of the V$RMAN_STATUS and V$RMAN_OUTPUT rows
ORACLE error from target database:
ORA-06553: PLS-801: internal error [56319]
具體的告警日誌以下。
Completed: alter database open resetlogs
Sun May 28 22:34:47 2017
Errors in file /home/oracle/oracle/admin/SCM2/bdump/scm2_mmon_20272.trc:
ORA-06553: PLS-801: internal error [56319]
Sun May 28 22:34:47 2017
Errors in file /home/oracle/oracle/admin/SCM2/bdump/scm2_mmon_20272.trc:
ORA-06553: PLS-801: internal error [56319]
Sun May 28 22:34:47 2017
Starting background process CJQ0
CJQ0 started with pid=19, OS id=21562
Sun May 28 22:34:50 2017
Errors in file /home/oracle/oracle/admin/SCM2/bdump/scm2_j000_21565.trc:
ORA-12012: error on auto execute of job 42567
ORA-06553: PLS-ORA-06553: PLS-801: internal error [56319]
:
Sun May 28 22:34:50 2017
Errors in file /home/oracle/oracle/admin/SCM2/bdump/scm2_j001_21567.trc:
ORA-12012: error on auto execute of job 42568
ORA-06553: PLS-ORA-06553: PLS-801: internal error [56319]
:
Sun May 28 22:34:50 2017
Errors in file /home/oracle/oracle/admin/SCM2/bdump/scm2_j002_21569.trc:
ORA-12012: error on auto execute of job 5329
ORA-06544: PL/SQL: internal error, arguments: [ORA-06544: PL/SQL: internal error, arguments: [56319], [], [], [], [], [], [], []
ORA-06553: PLS-801: internal error [56319]
], [], [], [], [], [], [], []
這個是因爲Oracle的軟件版本和以前restore進去的數據庫版本不一致致使。以下便可修復，具體能夠參考RMAN還原32位數據庫到64位實例的錯誤處理
SQL> startup upgrade;
SQL> @?/rdbms/admin/utlip.sql
SQL> shutdown immediate;
SQL> startup
@?/rdbms/admin/utlrp.sql
- 1. oracle rman異機恢復
- 2. RMAN異地恢復
- 3. Oracle 11G RMAN 單實例異機恢復
- 4. 異機rman數據不完全恢復
- 5. RMAN學習過程之九，實戰rman恢復之異機恢復
- 6. Oracle9i rman備份恢復總結
- 7. oracle備份恢復之rman恢復到異機
- 8. rman恢復方案和oracle異機恢復
- 9. RMAN 備份恢復
- 10. rman備份/恢復
- 更多相關文章...
- • ionic 平臺 - ionic 教程
- • Web Services 平臺元素 - Web Services 教程
- • 算法總結-雙指針
- • 算法總結-回溯法
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 融合阿里雲，牛客助您找到心儀好工作
- 2. 解決jdbc(jdbctemplate)在測試類時不報錯在TomCatb部署後報錯
- 3. 解決PyCharm GoLand IntelliJ 等 JetBrains 系列 IDE無法輸入中文
- 4. vue+ant design中關於圖片請求不顯示的問題。
- 5. insufficient memory && Native memory allocation (malloc) failed
- 6. 解決IDEA用Maven創建的Web工程不能創建Java Class文件的問題
- 7. [已解決] Error: Cannot download ‘https://start.spring.io/starter.zip?
- 8. 在idea讓java文件夾正常使用
- 9. Eclipse啓動提示「subversive connector discovery」
- 10. 帥某-技巧-快速轉帖博主文章（article_content）
- 1. oracle rman異機恢復
- 2. RMAN異地恢復
- 3. Oracle 11G RMAN 單實例異機恢復
- 4. 異機rman數據不完全恢復
- 5. RMAN學習過程之九，實戰rman恢復之異機恢復
- 6. Oracle9i rman備份恢復總結
- 7. oracle備份恢復之rman恢復到異機
- 8. rman恢復方案和oracle異機恢復
- 9. RMAN 備份恢復
- 10. rman備份/恢復