Home » RDBMS Server » Backup & Recovery » Recover to Cloud VM DB Error (Windows 2012 Oracle 12.2)
Recover to Cloud VM DB Error [message #678605] Wed, 18 December 2019 09:14 Go to next message
deay
Messages: 62
Registered: August 2005
Member
hi everyone - we have recently implemented an Oracle Cloud VM database (Linux) and have performed an on-premise backup to cloud object storage and are now trying to Restore/Recover to VM db. Restore has worked but I am having problems trying to Recover DB using RMAN (see error below). I have spent days trying to figure out what the problem is and how to fix it.
it states 'archive log already exists on disk as file'...what does that mean and why is there a copy of it in dbs folder?
thanks for any helps/tips trying to get this solved.


RMAN> recover database;

Starting recover at 18-DEC-19
using channel ORA_DISK_1
using channel ORA_SBT_TAPE_1

starting media recovery

archived log for thread 1 with sequence 194664 is already on disk as file /u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/archARC0000194664_0768258280.0001
archived log file name=/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/archARC0000194664_0768258280.0001 thread=1 sequence=194664
RMAN-00571: ===========================================================
RMAN-00569: =========
ERROR MESSAGE STACK FOLLOWS
=========
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 12/18/2019 14:52:46
RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/archARC0000194664_0768258280.0001'
ORA-10562: Error occurred while applying redo to data block (file# 1, block# 510995)
ORA-10564: tablespace SYSTEM
ORA-01110: data file 1: '+DATA/PLDG/DATAFILE/system.279.1026932689'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 673694
ORA-00600: internal error code, arguments: [ktbrcl:NOOP incompat_opt], [93], [], [], [], [], [], [], [], [], [], []


[Updated on: Wed, 18 December 2019 09:15]

Report message to a moderator

Re: Recover to Cloud VM DB Error [message #678606 is a reply to message #678605] Wed, 18 December 2019 10:07 Go to previous messageGo to next message
Michel Cadot
Messages: 67440
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator

Please read How to use [code] tags and make your code easier to read.

ORA-00600/ORA-07445/ORA-03113 = Oracle bug => search on Metalink/MOS and/or call Oracle support.
Have a look at alert.log and trace files.
You can also read this article: Troubleshooting Internal Errors.
And MOS notes:
ORA-600/ORA-7445/ORA-700 Error Look-up Tool (Doc ID 153788.1)
Master Note for Diagnosing ORA-600 (Doc ID 1092832.1)

Re: Recover to Cloud VM DB Error [message #678607 is a reply to message #678605] Wed, 18 December 2019 10:49 Go to previous messageGo to next message
John Watson
Messages: 8388
Registered: January 2010
Location: Global Village
Senior Member
I do have some experience of moving database to Oracle Cloud. It is not always easy. Can you describe in greater detail what you did? For example, you have shown a RECOVER command. What happened when you did the RESTORE?
Also, was there a reason for not using DUPLICATE?

(and one other thing - please use [code] tags, How to use code tags and make your code easier to read )
Re: Recover to Cloud VM DB Error [message #678608 is a reply to message #678607] Wed, 18 December 2019 11:03 Go to previous messageGo to next message
deay
Messages: 62
Registered: August 2005
Member
hi John - thanks, sorry about the formatting...yes learning Cloud has been one humdinger of an experience. below is the Restore process. everything appears ok to me.

RMAN> alter database mount;

Statement processed

RMAN> run {
  allocate channel c1 device type 'SBT_TAPE' PARMS='SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libopc.so,
  ENV=(OPC_PFILE=/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/ocipldg.ora)';
  set newname for database to '+DATA';
  set archivelog destination to '+RECO';
  restore database;
}2> 3> 4> 5> 6> 7> ;

allocated channel: c1
channel c1: SID=419 device type=SBT_TAPE
channel c1: Oracle Database Backup Service Library VER=19.0.0.1

executing command: SET NEWNAME

executing command: SET ARCHIVELOG DESTINATION

Starting restore at 13-DEC-19

channel c1: starting datafile backup set restore
channel c1: specifying datafile(s) to restore from backup set
channel c1: restoring datafile 00001 to +DATA
channel c1: restoring datafile 00006 to +DATA
channel c1: restoring datafile 00016 to +DATA
channel c1: restoring datafile 00019 to +DATA
channel c1: restoring datafile 00022 to +DATA
channel c1: restoring datafile 00025 to +DATA
channel c1: restoring datafile 00028 to +DATA
channel c1: restoring datafile 00031 to +DATA
channel c1: restoring datafile 00034 to +DATA
channel c1: restoring datafile 00037 to +DATA
channel c1: restoring datafile 00040 to +DATA
channel c1: restoring datafile 00043 to +DATA
channel c1: restoring datafile 00047 to +DATA
channel c1: restoring datafile 00050 to +DATA
channel c1: restoring datafile 00053 to +DATA
channel c1: restoring datafile 00056 to +DATA
channel c1: restoring datafile 00059 to +DATA
channel c1: restoring datafile 00062 to +DATA
channel c1: restoring datafile 00065 to +DATA
channel c1: restoring datafile 00069 to +DATA
channel c1: restoring datafile 00072 to +DATA
channel c1: restoring datafile 00075 to +DATA
channel c1: restoring datafile 00078 to +DATA
channel c1: restoring datafile 00079 to +DATA
channel c1: restoring datafile 00082 to +DATA
channel c1: restoring datafile 00085 to +DATA
channel c1: restoring datafile 00088 to +DATA
channel c1: restoring datafile 00091 to +DATA
channel c1: restoring datafile 00094 to +DATA
channel c1: restoring datafile 00097 to +DATA
channel c1: restoring datafile 00100 to +DATA
channel c1: restoring datafile 00103 to +DATA
channel c1: restoring datafile 00106 to +DATA
channel c1: restoring datafile 00109 to +DATA
channel c1: restoring datafile 00112 to +DATA
channel c1: restoring datafile 00115 to +DATA
channel c1: restoring datafile 00118 to +DATA
channel c1: restoring datafile 00121 to +DATA
channel c1: restoring datafile 00124 to +DATA
channel c1: restoring datafile 00127 to +DATA
channel c1: restoring datafile 00130 to +DATA
channel c1: restoring datafile 00133 to +DATA
channel c1: restoring datafile 00136 to +DATA
channel c1: restoring datafile 00139 to +DATA
channel c1: restoring datafile 00142 to +DATA
channel c1: restoring datafile 00145 to +DATA
channel c1: reading from backup piece lfui2odn_1_1
channel c1: piece handle=lfui2odn_1_1 tag=TAG20191129T081757
channel c1: restored backup piece 1
channel c1: restore complete, elapsed time: 00:43:06
channel c1: starting datafile backup set restore
channel c1: specifying datafile(s) to restore from backup set
channel c1: restoring datafile 00002 to +DATA
channel c1: restoring datafile 00004 to +DATA
channel c1: restoring datafile 00005 to +DATA
channel c1: restoring datafile 00008 to +DATA
channel c1: restoring datafile 00014 to +DATA
channel c1: restoring datafile 00015 to +DATA
channel c1: restoring datafile 00018 to +DATA
channel c1: restoring datafile 00021 to +DATA
channel c1: restoring datafile 00024 to +DATA
channel c1: restoring datafile 00027 to +DATA
channel c1: restoring datafile 00030 to +DATA
channel c1: restoring datafile 00033 to +DATA
channel c1: restoring datafile 00036 to +DATA
channel c1: restoring datafile 00039 to +DATA
channel c1: restoring datafile 00042 to +DATA
channel c1: restoring datafile 00045 to +DATA
channel c1: restoring datafile 00049 to +DATA
channel c1: restoring datafile 00052 to +DATA
channel c1: restoring datafile 00055 to +DATA
channel c1: restoring datafile 00058 to +DATA
channel c1: restoring datafile 00061 to +DATA
channel c1: restoring datafile 00064 to +DATA
channel c1: restoring datafile 00067 to +DATA
channel c1: restoring datafile 00068 to +DATA
channel c1: restoring datafile 00071 to +DATA
channel c1: restoring datafile 00074 to +DATA
channel c1: restoring datafile 00077 to +DATA
channel c1: restoring datafile 00081 to +DATA
channel c1: restoring datafile 00084 to +DATA
channel c1: restoring datafile 00087 to +DATA
channel c1: restoring datafile 00090 to +DATA
channel c1: restoring datafile 00093 to +DATA
channel c1: restoring datafile 00096 to +DATA
channel c1: restoring datafile 00099 to +DATA
channel c1: restoring datafile 00102 to +DATA
channel c1: restoring datafile 00105 to +DATA
channel c1: restoring datafile 00108 to +DATA
channel c1: restoring datafile 00111 to +DATA
channel c1: restoring datafile 00114 to +DATA
channel c1: restoring datafile 00117 to +DATA
channel c1: restoring datafile 00120 to +DATA
channel c1: restoring datafile 00123 to +DATA
channel c1: restoring datafile 00126 to +DATA
channel c1: restoring datafile 00129 to +DATA
channel c1: restoring datafile 00132 to +DATA
channel c1: restoring datafile 00135 to +DATA
channel c1: restoring datafile 00138 to +DATA
channel c1: restoring datafile 00141 to +DATA
channel c1: restoring datafile 00144 to +DATA
channel c1: reading from backup piece lgui2tqs_1_1
channel c1: piece handle=lgui2tqs_1_1 tag=TAG20191129T081757
channel c1: restored backup piece 1
channel c1: restore complete, elapsed time: 00:41:46
channel c1: starting datafile backup set restore
channel c1: specifying datafile(s) to restore from backup set
channel c1: restoring datafile 00003 to +DATA
channel c1: restoring datafile 00007 to +DATA
channel c1: restoring datafile 00009 to +DATA
channel c1: restoring datafile 00010 to +DATA
channel c1: restoring datafile 00011 to +DATA
channel c1: restoring datafile 00012 to +DATA
channel c1: restoring datafile 00013 to +DATA
channel c1: restoring datafile 00017 to +DATA
channel c1: restoring datafile 00020 to +DATA
channel c1: restoring datafile 00023 to +DATA
channel c1: restoring datafile 00026 to +DATA
channel c1: restoring datafile 00029 to +DATA
channel c1: restoring datafile 00032 to +DATA
channel c1: restoring datafile 00035 to +DATA
channel c1: restoring datafile 00038 to +DATA
channel c1: restoring datafile 00041 to +DATA
channel c1: restoring datafile 00044 to +DATA
channel c1: restoring datafile 00046 to +DATA
channel c1: restoring datafile 00048 to +DATA
channel c1: restoring datafile 00051 to +DATA
channel c1: restoring datafile 00054 to +DATA
channel c1: restoring datafile 00057 to +DATA
channel c1: restoring datafile 00060 to +DATA
channel c1: restoring datafile 00063 to +DATA
channel c1: restoring datafile 00066 to +DATA
channel c1: restoring datafile 00070 to +DATA
channel c1: restoring datafile 00073 to +DATA
channel c1: restoring datafile 00076 to +DATA
channel c1: restoring datafile 00080 to +DATA
channel c1: restoring datafile 00083 to +DATA
channel c1: restoring datafile 00086 to +DATA
channel c1: restoring datafile 00089 to +DATA
channel c1: restoring datafile 00092 to +DATA
channel c1: restoring datafile 00095 to +DATA
channel c1: restoring datafile 00098 to +DATA
channel c1: restoring datafile 00101 to +DATA
channel c1: restoring datafile 00104 to +DATA
channel c1: restoring datafile 00107 to +DATA
channel c1: restoring datafile 00110 to +DATA
channel c1: restoring datafile 00113 to +DATA
channel c1: restoring datafile 00116 to +DATA
channel c1: restoring datafile 00119 to +DATA
channel c1: restoring datafile 00122 to +DATA
channel c1: restoring datafile 00125 to +DATA
channel c1: restoring datafile 00128 to +DATA
channel c1: restoring datafile 00131 to +DATA
channel c1: restoring datafile 00134 to +DATA
channel c1: restoring datafile 00137 to +DATA
channel c1: restoring datafile 00140 to +DATA
channel c1: restoring datafile 00143 to +DATA
channel c1: reading from backup piece lhui33a8_1_1
channel c1: piece handle=lhui33a8_1_1 tag=TAG20191129T081757
channel c1: restored backup piece 1
channel c1: restore complete, elapsed time: 00:46:16
Finished restore at 13-DEC-19
released channel: c1
Re: Recover to Cloud VM DB Error [message #678611 is a reply to message #678608] Thu, 19 December 2019 01:14 Go to previous messageGo to next message
John Watson
Messages: 8388
Registered: January 2010
Location: Global Village
Senior Member
That all looks fine, doesn't it. Raising a TAR as MC says cannot hurt, but it might take a long time and get nowhere. If you want to try to get it going by yourself, you could some thing like

RECOVER DATABASE ALLOW 1 CORRUPTION;

(picking "1" out of the air) which might give you a working database for further investigation. If file# 1, block# 510995 does not actually have anything important, you might be OK.
Re: Recover to Cloud VM DB Error [message #678613 is a reply to message #678611] Thu, 19 December 2019 01:48 Go to previous messageGo to next message
Michel Cadot
Messages: 67440
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator

Isn't something like "FROM PLATFORM 'Linux x86 64-bit’" mandatory on both RESTORE and RECOVER commands?

Re: Recover to Cloud VM DB Error [message #678617 is a reply to message #678613] Thu, 19 December 2019 08:46 Go to previous messageGo to next message
deay
Messages: 62
Registered: August 2005
Member
hi John/Michel

John - yes I did try your recommendation and that didn't help as well

Michel - not sure about the "Platform" issue you raise but I did find this tidbit when I was doing research on the problem.

https://tutel.me/c/dba/questions/163074/duplicate+oracle+database+from+windows+to+linux

"Database Backup and Recovery Reference 12.2:

**Backup-Based Duplication'' [...] For backup-based duplication of databases in ARCHIVELOG mode, RMAN recovers by default up to the last archived redo log generated at the time the command was executed, or until a time specified with a SET UNTIL clause.

For backup-based duplication of databases without a connection to the target database, RMAN cannot determine whether the source database was in NOARCHIVELOG mode. Therefore, you must use the NOREDO option when the source database was in NOARCHIVELOG mode when the backups were taken. You can also use the NOREDO option when you do not want to apply archived redo log files to a consistent backup.

Edit:

It seems that Windows archive logs aren't compatible with Linux (the OP's answer). So use the way that avoids archive logs as described above:

Make a backup of the database in mounted state (not open)
use the NOREDO clause for duplication

@ArtOfWarfare 2017-05-21 11:46:03

An Oracle employee told me that redo logs are not platform independent. They told me I'd either have to shut down the Windows database and take a cold backup of it without any redo logs, or I'd have to restore the files I already have to another Oracle database running on Windows.

We ended up setting up a new Windows machine to restore the database to."

We have decided to delete the backup and perform a cold backup up to the Cloud then Restore, we should not have to Recover since db will be in a consistent state and see if we can then connect.

one last question...how do I delete the restore from cloud I can't find where the physical datafiles are. I looked at everything under root folder and couldn't find the +DATA files.

channel c1: restoring datafile 00137 to +DATA
channel c1: restoring datafile 00140 to +DATA
channel c1: restoring datafile 00143 to +DATA



[Updated on: Thu, 19 December 2019 09:10]

Report message to a moderator

Re: Recover to Cloud VM DB Error [message #678618 is a reply to message #678617] Thu, 19 December 2019 09:58 Go to previous messageGo to next message
deay
Messages: 62
Registered: August 2005
Member
comes to be you cannot do a cross-platform backup and recovery with RMAN unless it is a Standby DB.

Quote:
Restore From Windows To Linux using RMAN Fails (Doc ID 2003327.1)

Restoring backup of database created and running on 64-bit Windows 2008R2 to Oracle Linux 6 x86-64 using RMAN failed.

Restore of controlfile is successful.
Database change to mount mode is successful.
Restore of datafiles is successful.
When RMAN tries to recover database using archivelogs, it fails with error:


Solution
Note, redo application is not supported between Linux and Windows except with a standby database. This means that the backup must be</em><em> a cold (consistent) backup, which requires no redo application. If redo apply is required to recover the database on the new platform it will fail. Using consistent (cold) backup method should be used for duplicating cross platform.
hope this helps anyone else facing same dilemma.
Re: Recover to Cloud VM DB Error [message #678619 is a reply to message #678618] Thu, 19 December 2019 10:32 Go to previous messageGo to next message
Michel Cadot
Messages: 67440
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator

Thanks for the feedback and explanation.

Re: Recover to Cloud VM DB Error [message #678714 is a reply to message #678619] Fri, 03 January 2020 09:33 Go to previous messageGo to next message
deay
Messages: 62
Registered: August 2005
Member
happy new year Everyone - I'm back with more questions regarding backup maybe Michel or John can shed some light on this.

so we performed a 'cold backup' to Cloud on Dec 21, 2019 - see object storage 1 chunk backupset sample below(from 26 pages).

cold backup using below RMAN command: (since db was consistent excluded archivelogs)

RMAN> run{
allocate channel c1 DEVICE TYPE 'SBT_TAPE' 
PARMS='SBT_LIBRARY=G:\oracle\product\12.2.0\dbhome_12201\bin\lib\oraopc.dll,
SBT_PARMS=(OPC_PFILE=G:\oracle\product\12.2.0\dbhome_12201\dbs\opcplxx.ora)';
BACKUP DATABASE;
};
we got 26 pages of 100 MiB chunks like the one below:
OBJECT_STORAGE:
file_chunk/3850398090/PLXX/backuppiece/2019-12-21/tbujve3e_1_1/KTVs8w9V0wwD/0000000003 100 MiB Available Sat, Dec 21, 2019, 13:36:10 UTC


however when I run a List Backup I see the original SPFILE backup from Nov 25 2019 and why is Device Type 'DISK' when
I am using SBT_TAPE.

RMAN> list backup;

using target database control file instead of recovery catalog

List of Backup Sets
===================


BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
1       Full    17.94M     DISK        00:00:01     25-NOV-19
        BP Key: 1   Status: AVAILABLE  Compressed: NO  Tag: TAG20191125T174224
        Piece Name: +RECO/PLXX_IAD1GG/AUTOBACKUP/2019_11_25/s_1025286144.262.102    5286145
  SPFILE Included: Modification time: 25-NOV-19
  SPFILE db_unique_name: PLXX_IAD1GG
  Control File Included: Ckp SCN: 1784307      Ckp time: 25-NOV-19


RMAN> RESTORE DATABASE FROM TAG = 'TAG20191125T174224';

Starting restore at 03-JAN-20
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=28 device type=DISK

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 01/03/2020 14:59:27
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 12 found to restore
RMAN-06023: no backup or copy of datafile 11 found to restore
RMAN-06023: no backup or copy of datafile 10 found to restore
RMAN-06023: no backup or copy of datafile 9 found to restore
RMAN-06023: no backup or copy of datafile 8 found to restore
RMAN-06023: no backup or copy of datafile 7 found to restore
RMAN-06023: no backup or copy of datafile 6 found to restore
RMAN-06023: no backup or copy of datafile 5 found to restore
RMAN-06023: no backup or copy of datafile 4 found to restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore


can someone explain what is going on and do I need to include Archivelogs even if it is a 'Cold Backup'.

thanks for any advice and explanations.
Re: Recover to Cloud VM DB Error [message #678715 is a reply to message #678714] Fri, 03 January 2020 10:14 Go to previous messageGo to next message
John Watson
Messages: 8388
Registered: January 2010
Location: Global Village
Senior Member
From where did you restore the controlfile?
Re: Recover to Cloud VM DB Error [message #678716 is a reply to message #678715] Fri, 03 January 2020 10:29 Go to previous messageGo to next message
deay
Messages: 62
Registered: August 2005
Member
I guess that's my question, I thought "backup database" would include the SPFILE and Control File(s).

it appears the original backups from Nov 25, 2019 are still stored in the +RECO folder. how do I remove that one or replace
it with the new backup control/spfile.
Re: Recover to Cloud VM DB Error [message #678717 is a reply to message #678716] Fri, 03 January 2020 10:39 Go to previous messageGo to next message
deay
Messages: 62
Registered: August 2005
Member
also when I run my next test backup should I use commands like below and Tag it.

run{
allocate channel c1 DEVICE TYPE 'SBT_TAPE'
PARMS='SBT_LIBRARY=G:\oraclebase\product\12.2.0\dbhome_12201\bin\lib\oraopc.dll,
SBT_PARMS=(OPC_PFILE=G:\oraclebase\product\12.2.0\dbhome_12201\dbs\opcpdg.ora)';
backup database tag 'PDG_BACKUP';
backup current controlfile tag 'PDG_BACKUP';
backup spfile tag 'PDG_BACKUP';
}
Re: Recover to Cloud VM DB Error [message #678718 is a reply to message #678716] Fri, 03 January 2020 10:47 Go to previous messageGo to next message
John Watson
Messages: 8388
Registered: January 2010
Location: Global Village
Senior Member
deay wrote on Fri, 03 January 2020 16:29
I guess that's my question, I thought "backup database" would include the SPFILE and Control File(s).

it appears the original backups from Nov 25, 2019 are still stored in the +RECO folder. how do I remove that one or replace
it with the new backup control/spfile.
You have to understand some basic DBA stuff. Nothing to do with Cloud. It looks as though you restored a control file sometime before Christmas. I don't know where you go it from. Then today, that old controlfile is still mounted and you are trying to use it to restore the database from a new, consistent, backup. That cannot work.

The technique you need to follow is to remove everything from your previous attenmpt: stop the instance, delete all the datbase files. Then start an instance and use it to extract the current controlfile from your new backup. Mount that controlfile, catalog your backup pieces into it, then restore the datfiles.
Re: Recover to Cloud VM DB Error [message #678719 is a reply to message #678718] Fri, 03 January 2020 11:00 Go to previous message
deay
Messages: 62
Registered: August 2005
Member
thanks John, that makes sense. getting rid of everything we did with our first test when we performed an RMAN backup with archivelogs and couldn't get the recover to work because of platform specific issues. so every time we do a backup/restore will we need to delete the existing control/spfile or can we overwrite them.
Previous Topic: clone CDB and rename PDB
Next Topic: setting up RMAN for newly deployed RAC
Goto Forum:
  


Current Time: Tue Oct 20 18:37:44 CDT 2020