This content has been marked as final. Show 20 replies
When the database files are open normally, they are continuously being updated, so they are not in a consistent state - they are "fuzzy." One applies logs in a recovery to bring them into a consistent state. These are either archived logs, or online redo logs. So a typical recovery could be, a tablespace is messed up, you copy the data files for that tablespace in, recover the database, and Oracle figures out from the SCN information in the data file headers and controlfile what out of the redo stream it needs to recover those files. In that situation, the online redo has the most current information, as does the controlfile. The recovery can finish fine, nothing gets lost. That's why you shouldn't (and rman doesn't) copy online redo logs - if you copied back the online redo from when you copied the data files, you lose the most recent data, and cannot do a complete recovery. If you want to tell Oracle you have archived logs that go beyond the current controlfile, you use the recovery syntax to tell Oracle that - and you have to tell Oracle to resetlogs, because the online logs aren't the most recent.
Putting tablespaces into backup mode tells Oracle to keep additional information in the redo stream so it can figure all this out - rman doesn't need to do that, because it is smart enough (for more information, google "split blocks" and search asktom for more redo generated in backup mode - actually, the redo saves an entire block into the redo stream when it is first modified).
So here you have the situation where you are trying to apply redo to files that have not been placed into backup mode - they are fuzzy and the redo doesn't have the extra information it may need.
DBA job #1 is to not lose data. The Peasland article was very useful for getting a db up when some customer sends you wrong data file information, but not something you would normally want to do. In fact, you definitely don't want to do that, you want to use rman and know (and you don't know until you test!) you can recover completely.
You definitely do not want to migrate data by applying later archives to an unrestored set of data files. If you need something like that, use standby databases (dataguard, or you can do it manually in an older style). Standby works by being in continuous recovery, with a special controlfile. There are also other ways to propagate data, depending on your requirements and how much money you have.
Also see v$datafile_header in the docs.
948024 wrote:No. Once you opened that second database, it started life with it's own set of archive sequences, it's own set of scn's. You can't just graft in an archivelog from some other database, no matter how closely you think those databases are related. As far as oracle is concerned, they have zero relationship to each other.
great thanks guys it really helped,
i recoverd the database completely i cross checked the rows which i inserted after taking the backup and they are in the new database
guys just one more thing.
now both the databses hav same data......
again if i want to insert rows in primary database and do
alter system archive log current;
then cn i directly paste that archive log into second database archvive folder and do shutdown immediate
948024 wrote:If that's what you want, you need to look at DataGuard. There are variations on a theme, but the basic idea is that the secondary database stays in 'recovery mode', and all redo from the primary is shipped to the secondary and applied. But both databases have to be specifically configured for it, not simply you grabbing the archives from one database and trying to force them onto another.
thanks alot buddy, i was in a wrong perception tht if i keep adding archvie log from main database to this clone database it will keep updating.