SCN in redologs

Hi
The scn of the controlfile and datafile headers updated after checkpoint,
How about the SCN in redologs, Are they updated after every checkpoint or every commit ?

Dear scofield!
You can find a very interesting article about "Checkpointing in Oracle" at the following site:
[http://www.vldb.org/conf/1998/p665.pdf]
Yours sincerely
Florian W.

Similar Messages

Scn in redologs and controlfile

Hi
The checkpoint scn in datafile headers are updated after checkpoint.
How about redologs and controlfile?
As far I read from the docs
scn's are written to redo logs continuously, it should also stored in controlfile continuesly(every commit) so that controlfile will know where redochain ends ..
Is that right?

Hi,
The checkpoint scn in datafile headers are updated after checkpoint.
Yes. By CKPT process.
scn's are written to redo logs continuously
Yes, by LGWR every COMMIT IMMEDIATE.
+ it should also stored in controlfile continuesly(every commit) so that controlfile will know where redochain ends ..+
Even if it is in controlfile then it is NOT updated every commit.
Bartek

Scn of redologs

Hi
I know that when I start the database the scn of controlfile,datafile headers and redologs
shoud be same.
I can compare scn of datafiles from v$datafile_header
Control file from v$datafile
redolog from v$log
For example:
sys@XE> select CHECKPOINT_CHANGE# from v$datafile;
CHECKPOINT_CHANGE#
4344269
4344269
4344269
4344269
sys@XE> select first_Change# from v$log;
FIRST_CHANGE#
4341385
4341016
My database is up at the moment and above confirms that redolog scn is behind than controlfile and datafile.
What I want to ask is,
When I shutdown the database and restore old redologs and create a controlfile with noresetlogs option
It fails with:
ORA-01229: data file 4 is inconsistent with logs.
How can oracle understand if the current online redologs are consistent or not?
As I showed above, the redo scn is already behind while the db is up.
It should compare something else..

Oracle does check the redo logs. There is more information in the redo logs (and datafile headers, for that matter) than you can see in V$LOG or V$DATAFILE_HEADER.
e.g. I see :
SQL> select checkpoint_change# from v$datafile;
CHECKPOINT_CHANGE#
          13491047
          13491047
          13491047
          13491047
          13491047
          13491047
          13491047
          13491047
8 rows selected.
SQL> select group#, first_change# from v$log;
    GROUP# FIRST_CHANGE#
         1      13487614
         2      13488637
         3      13489762
SQL>But if I take a dump of the Group#3 log file, I can see :
Last redo scn: 0x0000.00cddcd0 (13491408)Hemant K Chitale
http://hemantoracledba.blogspot.com

Checkpoint scn in redolog and controlfile

Hi
The checkpoint scn in datafile headers are updated after checkpoint.
How about redologs and controlfile?
As far I read from the docs
scn's are written to redo logs continuously (every commit), it should also stored in controlfile continuesly(every commit) so that controlfile will know where redochain ends ..
Is that right?

Pascal Nouma wrote:
Yes Aman, I read it.
As I said,
I learned that scn is incremented in controlfile and datafile after checkpoint.
However still have doubts about redologs..No, that's what my doubt is. If you have read the thread thoroughly, it explains that in the redo logs, there is open/close SCN. And I have shown its behavior too there. SCN is nothing but a time stamp(see Hans's reply also for the explanation, in the thread too , I have posted one) and as redologs contain nothing but transactions, each one would be having its starting and ending SCN(the article posted by Hans goes into great length to show it) . The files would have the high and low scn. I would suggest that you reread the thread one more time and come back with a more detailed question. I am not still sure that what is your doubt regarging the scn in the redologs. Control file's mechanism or data files's mechanism are different as the writes happen at certain events while redo logs are constantly being fliushed with the minimum frequency of 3seconds. So things are not really alike and its not good to compare bit by bit all the aspects in every file IMHO.
HTH
Aman....

REDOLOG SEQUENCE NO / SCN

what is difference between redo log sequence no and scn(system change no, it is true that when transaction commit then a scn assign to redolog, to compare to scn of rollback segment but what is purpose of the redo log sequence no ) .
beside it, obiously commited transation will also written in rollback segment(
due to maintain read consistency[ because all dirty block will not immiditally written to the disk, they will written at same time]) ,if commited data will be written in TO ROLLBACK segment(i.e. i/o operation ) then why we not written diry block to disk at commit time.
siddharth

Hi,
Sequence number can be assingned in the header of the Production order or Planned order. It is the unique number which also identifies the operations asigned to that order.
While doing Capacity levelling, you can sort the order and display the same based on the Sequence number. Also you can "Dispatch" the orders based on the Sequence nmber by choosing the appropriate "Dispatching sequence" in the Strategy profile.
Hope this helps..
-Thaila Shree

Max SCN Number in redolog file

Hi ,
I have configured a data guard environment using below configuration
STANDBY TYPE : - PHYSICAL STANDBY
LOG TRANSPORT SERVICE : - ARCH [ ARCHIVE PROCESS ]
STANDBY LOG :- NO STANDBY LOG IN PRIMARY AND STANDBY
SYNC STATUS OF PRIMARY AND STANDBY : - FULLY SYNC
OPERATION : - FAIL OVER USING 'ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;'
ACTIVATING THE STANDBY USING ' ALTER DATABASE ACTIVATE STANDBY DATABASE;'
PRIMARY AND STANDBY ARE IN FULLY SYNC
ON PRIMARY
LAST ARCHIVED SEQUENCE NUMBER IS 12 AND FIRST AND LAST SCN ASSOCIATED WITH SEQUENCE 12 IS AS BELOW
SELECT SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE# FROM V$ARCHIVED_LOG WHERE SEQUENCE#=12;
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
12 669447 670246
ON STANDBY
THE ARCHIVE LOG WITH SEQUENCE NUMBER 12 HAS ARCHIVED AND APPLIED ON STANDBY DATABASE SUCCESSFULLY.
NOW I AM DOING A FAIL OVER BY USING THE BELOW COMMANDS
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE ACTIVATE STANDBY DATABASE;
ALERT LOG ON STANDBY DATABASE
Media Recovery Log /data/PRD_DR/arch/arch_1_11_834360625.arch
Media Recovery Log /data/PRD_DR/arch/arch_1_12_834360625.arch
Media Recovery Waiting for thread 1 sequence 13
Error 12154 received logging on to the standby
FAL[client, MRP0]: Error 12154 connecting to PRD for fetching gap sequence
Errors in file /apps/oracle/diag/rdbms/stand/PRD/trace/PRD_mrp0_7865.trc:
ORA-12154: TNS:could not resolve the connect identifier specified
Thu Dec 26 18:00:36 2013
alter database recover managed standby database cancel
Thu Dec 26 18:00:36 2013
MRP0: Background Media Recovery cancelled with status 16037
Errors in file /apps/oracle/diag/rdbms/stand/PRD/trace/PRD_mrp0_7865.trc:
ORA-16037: user requested cancel of managed recovery operation
Shutting down recovery slaves due to error 16037
Recovery interrupted!
Errors in file /apps/oracle/diag/rdbms/stand/PRD/trace/PRD_mrp0_7865.trc:
ORA-16037: user requested cancel of managed recovery operation
MRP0: Background Media Recovery process shutdown (PRD)
Waiting for MRP0 pid 7865 to terminate
Managed Standby Recovery Canceled (PRD)
Completed: alter database recover managed standby database cancel
Thu Dec 26 18:00:59 2013
alter database activate standby database
ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE (PRD)
tkcrrxms: Killing 2 processes (all RFS)
RESETLOGS after incomplete recovery UNTIL CHANGE 670246
Resetting resetlogs activation ID 1898010833 (0x712158d1)
Online log /data/PRD_DR/REDOLOG11.LOG: Thread 1 Group 1 was previously cleared
Online log /data/PRD_DR/REDOLOG21.LOG: Thread 1 Group 2 was previously cleared
Online log /data/PRD_DR/REDOLOG33.LOG: Thread 1 Group 3 was previously cleared
Standby became primary SCN: 670244
Thu Dec 26 18:01:01 2013
Setting recovery target incarnation to 3
Converting standby mount to primary mount.
ACTIVATE STANDBY: Complete - Database mounted as primary (PRD)
Completed: alter database activate standby database
IN STANDBY ALERT LOG I CAN SEE BELOW THINGS
RESETLOGS after incomplete recovery UNTIL CHANGE 670246
Standby became primary SCN: 670244
MY QUESTION IS ON 'SCN NUMBER OF 'Standby became primary SCN: 670244'.
I HAVE CHECKED THE SCN NUMBERS OF THE ARCHIVE LOG OF SEQUENCE 12 [ USING LOGMINER ] THE MAX SCN ASSOCIATED WITH THE ARCHIVE LOG IS 670242
SELECT MAX(SCN) FROM V$LOGMNR_CONTENTS; [ FOR LOGMINER I HAVE USED '
EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DDL_DICT_TRACKING + DBMS_LOGMNR.DICT_FROM_REDO_LOGS); ]
MAX(SCN)
670242
- WHY IN LOGMINER MAX(SCN) IS NOT SHOWING AS 670246 ?
- HOW I CAN SEE THE SCN 670244 FOR ARCHIVE LOG FOR SEQUENCE NUMBER 12 ?
Thanks,

IN STANDBY ALERT LOG I CAN SEE BELOW THINGS
RESETLOGS after incomplete recovery UNTIL CHANGE 670246
Standby became primary SCN: 670244
MY QUESTION IS ON 'SCN NUMBER OF 'Standby became primary SCN: 670244'.
I HAVE CHECKED THE SCN NUMBERS OF THE ARCHIVE LOG OF SEQUENCE 12 [ USING LOGMINER ] THE MAX SCN ASSOCIATED WITH THE ARCHIVE LOG IS 670242
in fact, it is really intelligent question.
First you have to know the sequence 12, next_change# is not belongs to 12 but it belongs to the 13th sequence first_change...
So in the real, the seqeunce 12 change number is only up to 670245 and the change 670246 is the starting change of sequence numebr 13.
It is not using any real time apply, Now as per the my above conclusion the sequence number last change is only 670245 , As per the recovery concepts.. If you want to perform recovery change up to 100, you need to mention as "until 100 + 1", i.e. 101.. So if you mention 101 then it performs recovery until 100.
1) the 12 sequence max change is 670245
2) when it performs recovery until that sequence, then then usually it performs recovery until 6740244 as per the recovery rules.
From http://docs.oracle.com/cd/B19306_01/server.102/b14357/ch12033.htm
UNTIL CHANGE integer
Processes managed recovery up to but not including the specified system change number (SCN).
Still at this point am not giving conclusion 100%, am testing same as you using log miner and will let you know sure..
- WHY IN LOGMINER MAX(SCN) IS NOT SHOWING AS 670246 ?
When you analyze archive redo log file, Have you used starttime and end time? Note that if you give end time bit less then there is chance to truncate to gather information for log miner and important thing is Oracle writes checksum information and change information in terms of metadata into headers.Also note that oracle uses some of records for SYSTEM CHANGE, so some of them may not visible.
HTH.

SAP GoLive : File System Response Times and Online Redologs design

Hello,
A SAP Going Live Verification session has just been performed on our SAP Production environnement.
SAP ECC6
Oracle 10.2.0.2
Solaris 10
As usual, we received database configuration instructions, but I'm a little bit skeptical about two of them :
1/
We have been told that our file system read response times "do not meet the standard requirements"
The following datafile has ben considered having a too high average read time per block.
File name -Blocks read - Avg. read time (ms) -Total read time per datafile (ms)
/oracle/PMA/sapdata5/sr3700_10/sr3700.data10 67534 23 1553282
I'm surprised that an average read time of 23ms is considered a high value. What are exactly those "standard requirements" ?
2/
We have been asked to increase the size of the online redo logs which are already quite large (54Mb).
Actually we have BW loading that generates "Chekpoint not comlete" message every night.
I've read in sap note 79341 that :
"The disadvantage of big redo log files is the lower checkpoint frequency and the longer time Oracle needs for an instance recovery."
Frankly, I have problems undertanding this sentence.
Frequent checkpoints means more redo log file switches, means more archive redo log files generated. right ?
But how is it that frequent chekpoints should decrease the time necessary for recovery ?
Thank you.
Any useful help would be appreciated.

Hello
>> I'm surprised that an average read time of 23ms is considered a high value. What are exactly those "standard requirements" ?
The recommended ("standard") values are published at the end of sapnote #322896.
23 ms seems really a little bit high to me - for example we have round about 4 to 6 ms on our productive system (with SAN storage).
>> Frequent checkpoints means more redo log file switches, means more archive redo log files generated. right?
Correct.
>> But how is it that frequent chekpoints should decrease the time necessary for recovery ?
A checkpoint is occured on every logswitch (of the online redologfiles). On a checkpoint event the following 3 things are happening in an oracle database:
Every dirty block in the buffer cache is written down to the datafiles
The latest SCN is written (updated) into the datafile header
The latest SCN is also written to the controlfiles
If your redologfiles are larger ... checkpoints are not happening so often and in this case the dirty buffers are not written down to the datafiles (in the case of no free space in the buffer cache is needed). So if your instance crashes you need to apply more redologs to the datafiles to be in a consistent state (roll forward). If you have smaller redologfiles more log switches are occured and so the SCNs in the data file headers (and the corresponding data) are closer to the newest SCN -> ergo the recovery is faster.
But this concept does not really fit the reality because of oracle implements some algorithm to reduce the workload for the DBWR in the case of a checkpoint.
There are also several parameters (depends on the oracle version) which control that a required recovery time is kept. (for example FAST_START_MTTR_TARGET)
Regards
Stefan

GG SCN..........

Hi,
Could you please clarify the following question,
1. Once enabled the supplemental log data in database , whether that supplemental log data consume the more space on disk from actual redolog file size?
2.how extract process fetch the changed datas from online redo log file?
3. We have the scn number in database so we can start the extract process based on the SCN(CSN in gg) then why we need RBA? Where actually RBA will be generated and what scenario we can use RBA detail?
3. What is the difference between SCN and RBA?
Please kindly clarify the above queries that would be very much helpful to understand the internal functionality of GG?

Because of the need for supplemental logging, you will have more log switching. The files are still about the same size (when archiving, for example, Oracle will place additional info in the log files, so even though you say 100M for a size, you may see something a bit different). Using some numbers, suppose your before G ORL held 1000 committed txns. With supplemental logging, maybe now it gets switched at 800 txns "full."
Files are files are files. There are utilities to read data in database files (BBED, for example). Reading the contents of a transaction log is no different. The contents of the log contain not only the SQL, but also who and when. Extract simply reads/extracts transactions of interest, i.e., those tables you identified in the extract param file with the TABLE parameter. Extract (GoldenGate, to be more precise) extracts committed transactions, not every transaction with changes (around 40% or so overall for committed txns).
RBA allows you to start at a more specific point within a trail file. Trail files contain unstructured data. The RBA is like a pointer or address within the file. Same exact idea used to reposition through a data file (if you ever use BBED).
statement, statement, statement, then commit. One SCN, but multiple RBAs within the trail.

Cold Backup and Redolog vs. Note1026631.6

Dear Experts,
I never include the online redolog files in my cold backup but at the end of the note it is said "However, other Oracle documentation states that cold (offline) backups should include backing up online redo log files (see page 8 of Oracle Backup and Recovery Handbook from Oracle Press)..."
Let's imagine we take a coldbackup with online redolog:
- The SCN was 100 at the time of this backup.
- The DB crashes (lost datafiles). The SCN is 250.
- We copy the datafiles and the redolog online.
- The DB checks the Control file which has SCN=250, the Datafiles and the redolog have got 100. The DB doesn't know what to do isn't it ? I mean it can' recover.
- If we copy only the Datafiles from the backup, the DB sees 250 in both Control and online redolog and sees 100 in datafiles and knows it has to perform a recovery from 100 to 250.
To me copying the online redolog in a cold back up is more than useless , it can be quite dangerous.
Am I totally wrong and do I miss something fundamental ?
Thanks for your expertise.
Regards,
Guillaume

i totally disagree with you, 393781.
They are two reasons not to backup the redo logs.
reason 1)
it is consuming tapes and time...
reason 2)
if you restore it, you may overwrite existing redologs by mistake while running your os-restore, and the existing may be used (with little chance..) to recover the database, even if running in NOARCHIVELOG mode.
They are also a lot of oracle customers which are backing up the redo logs. It is an "easier" approach. You backup everything (the whole filesystem or so), then restore everything, so you are sure you have everything and it is really straightforward.
If you do not have your redologs, you must open your db with resetlogs, which seems to be the correct procedure (you have a new incarnation, have not you? ) but open resetlogs may be dangerous for a junior dba.
HTH
Laurent Schneider
OCM DBA

Online backup and the Redolog mechanism

Hello,
During a backup I understand that the redolog mechanism changes, so that when a block is changed for the first time after the backup commences, it's entire content is copied to the redolog files, rather than just the change vector.
My question is, does this happen even when the oracle block size is the same as the operating system block size?
My understanding is that the change in redolog mechanism is because a single oracle block can be made up multiple operating system blocks, so that within an oracle block a change can be done to a few blocks, then a read by the online backup, so that the oracle block read by the backup is inconsistent.
But if the oracle block size was the same as the operating system block size, each change would be atomic, so the problem of having inconsistent oracle blocks would not arise. So the change in redolog mechanism would no longer be necessary. Does the redolog mechanism change anyway?
Kind regards,
Peter

Hi Peter,
I will try to make the issue more clear eventhough so much useful has been written and said in this thread !!
During Online Backup the tablespaces enter the backup mode this has following effects:
1) A checkpoint on TS level is triggered before the backup of this TS starts and DBWR writes all corresponding dirty blocks of this TS to data files.
2) The SCN corresponding to TS Checkpoint remains Frozen in the headrers of all TS files until the end of backup mode.
3) Every change in this TS is logged in the redolog on data block level instead of data record level ; not only the redo info for a modified record is written into the redolg but the whole 8 KB block containing this record ( immaterial whether OS block size is 8 KB or not). The reason for this granual logging is the possibility that
CPIO or DD may copy an oracle block to the backup medium in smaller units than 8 KB while the block is being changed by DBWR which can lead to inconsistencies whithin such a block.
Now When the backup later used for restoring the TS, all blocks written to the redo log during the backup mode overwrite therir "suspicious"versions saved directly in the backup of the data files.
Hope this useful
Regards
Umesh

How to skip or edit scn (system change number) for brarchive

hi experts,
I have searched for procedures but didnt find any accurate solution. I wanted to skip the scn or the system change number for my brarchive. I have manually transported my files in the DR site because of seems to be FTP problems. I have to skip those redologs which i have already transfered. How am i suppose to do these? I'm looking forward to a textfile or control file wherein i could edit the number of the next redolog to process or sql commands or something?
Thanks in advance.

Still not sure what exactly your problem is.
You transferred redologs; are they still available in their original oraarch location?
If no : See my answer above. Did that many times myself.
If yes : Log files will be copied by brarchive as always. Make sure that no harm will be done if they are overwritten at a place where they already exist, and where they maybe currently are processed by another program!
regards

Restore with brtools - need more archive redolog files

Good day
I will make online backup my oracle database with brtools
(Oracle 10g, BRBACKUP 7.00 (39))
brbackup -c -d util_file_online -t online -m all -u /
bdztoexw anf 2009-01-23 15.27.40 ; 2009-01-23 16.47.21 ; 1 ............... 57 56 0 17671 226215105 17676 226268039 ALL
online util_file_online -
7.00 (39)
BR0280I BRBACKUP time stamp: 2009-01-23 16.43.38
BR0232I 57 of 57 files saved by backup utility
BR0230I Backup utility called successfully
BR0280I BRBACKUP time stamp: 2009-01-23 16.43.40
BR0340I Switching to next online redo log file for database instance VPP ...
BR0321I Switch to next online redo log file for database instance VPP successful
BR0117I ARCHIVE LOG LIST after backup for database instance VPP
Parameter Value
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /oracle/VPP/oraarch/VPParch
Archive format %t_%s_%r.dbf
Oldest online log sequence 17673
Next log sequence to archive 17676
Current log sequence 17676 SCN: 226268039
Database block size 8192 Thread: 1
Current system change number 226268041 ResetId: 603135330
After brbackup I'll do "brarchive" in the same script:
brarchive -c -d util_file -sd -u / > $br_out_file
#ARCHIVE.. 17670 /oracle/VPP/oraarch/VPParch1_17670_603135330.dbf ; 2009-01-23 15.10.36 ; 43450368 226202112 1
#SAVED.... adztolzu svd *VXF1232718526 2009-01-23 16.51.11 ........... ............
#COPIED... ........ ... ................. .......... ........ ........... ............
#DELETED.. adztolzu svd 2009-01-23 16.51.11
#ARCHIVE.. 17671 /oracle/VPP/oraarch/VPParch1_17671_603135330.dbf ; 2009-01-23 15.36.12 ; 43430912 226215105 1
#SAVED.... adztolzu svd *VXF1232718526 2009-01-23 16.51.11 ........... ............
#COPIED... ........ ... ................. .......... ........ ........... ............
#DELETED.. adztolzu svd 2009-01-23 16.51.11
#ARCHIVE.. 17672 /oracle/VPP/oraarch/VPParch1_17672_603135330.dbf ; 2009-01-23 15.40.27 ; 43515904 226227928 1
#SAVED.... adztolzu svd *VXF1232718526 2009-01-23 16.51.11 ........... ............
#COPIED... ........ ... ................. .......... ........ ........... ............
#DELETED.. adztolzu svd 2009-01-23 16.51.11
#ARCHIVE.. 17673 /oracle/VPP/oraarch/VPParch1_17673_603135330.dbf ; 2009-01-23 15.41.06 ; 43729408 226238784 1
#SAVED.... adztolzu svd *VXF1232718526 2009-01-23 16.51.11 ........... ............
#COPIED... ........ ... ................. .......... ........ ........... ............
#DELETED.. adztolzu svd 2009-01-23 16.51.11
#ARCHIVE.. 17674 /oracle/VPP/oraarch/VPParch1_17674_603135330.dbf ; 2009-01-23 16.06.06 ; 43450368 226250315 1
#SAVED.... adztolzu svd *VXF1232718526 2009-01-23 16.51.11 ........... ............
#COPIED... ........ ... ................. .......... ........ ........... ............
#DELETED.. adztolzu svd 2009-01-23 16.51.11
#ARCHIVE.. 17675 /oracle/VPP/oraarch/VPParch1_17675_603135330.dbf ; 2009-01-23 16.43.40 ; 13243904 226263012 1
#SAVED.... adztolzu svd *VXF1232718526 2009-01-23 16.51.11 ........... ............
#COPIED... ........ ... ................. .......... ........ ........... ............
#DELETED.. adztolzu svd 2009-01-23 16.51.11
VPP util_file adztolzu svd 2009-01-23 16.47.22 ; 2009-01-23 16.54.47 ; 1 ........... 17670 17675 0 0 ------- 7.00 (39) @0603135330
BR0280I BRARCHIVE time stamp: 2009-01-23 16.51.11
BR0232I 6 of 6 files saved by backup utility
BR0230I Backup utility called successfully
BR0016I 6 offline redo log files processed, total size 220.128 MB
Then I take tape with this data and try restore only from this tape
all datafiles and relevant archive redologs files (17670-17675) restored without errors
but in the end ERROR occurred
ERROR at line 1:
ORA-01195: online backup of file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oracle/VPP/sapdata1/system_1/system.data1'
ORA-00279: change 226268039 generated at 01/23/2009 16:43:40 needed for thread
1
ORA-00289: suggestion : /oracle/VPP/oraarch/VPParch1_17676_603135330.dbf
ORA-00280: change 226268039 for thread 1 is in sequence #17676
My online backup ended, before switch to redolog 17676
Why I need this file? I think files (17670-17675) should be enough?
Besides, the change 226268039 generated exactly at moment Switching to next online redo.
Can I try open database regardless of this error?
Thank you for your prompt response
Andrey Timofeev
Edited by: Andrey Timofeev on Jul 21, 2009 3:52 PM

Good day, sorry for TAG. Once more time. 
I will make online backup my oracle database with brtools 
(Oracle 10g, BRBACKUP 7.00 (39))
brbackup -c -d util_file_online -t online -m all -u /
<HR>
bdztoexw anf 2009-01-23 15.27.40 2009-01-23 16.47.21 1 ............... 57 56 0 17671 226215105 17676 226268039 ALL 
online util_file_online 
<HR>
 BR0280I BRBACKUP time stamp: 2009-01-23 16.43.38
<HR>
 
BR0232I 57 of 57 files saved by backup utility 
BR0230I Backup utility called successfully
BR0280I BRBACKUP time stamp: 2009-01-23 16.43.40 
BR0340I Switching to next online redo log file for database instance VPP ... 
BR0321I Switch to next online redo log file for database instance VPP successful
BR0117I ARCHIVE LOG LIST after backup for database instance VPP
Parameter Value
Database log mode Archive Mode 
Automatic archival Enabled 
Archive destination /oracle/VPP/oraarch/VPParch 
Archive format %t_%s_%r.dbf 
Oldest online log sequence 17673 
Next log sequence to archive 17676 
Current log sequence 17676 SCN: 226268039 
Database block size 8192 Thread: 1 
Current system change number 226268041 ResetId: 603135330
<HR>
 
After brbackup I'll do "brarchive" in the same script:
brarchive -c -d util_file -sd -u / > $br_out_file
<HR>
#ARCHIVE.. 17670 /oracle/VPP/oraarch/VPParch1_17670_603135330.dbf 2009-01-23 15.10.36 43450368 226202112 1 
#SAVED.... adztolzu svd *VXF1232718526 2009-01-23 16.51.11 ........... ............ 
#COPIED... ........ ... ................. .......... ........ ........... ............ 
#DELETED.. adztolzu svd 2009-01-23 16.51.11 
# 
#ARCHIVE.. 17671 /oracle/VPP/oraarch/VPParch1_17671_603135330.dbf 2009-01-23 15.36.12 43430912 226215105 1 
#SAVED.... adztolzu svd *VXF1232718526 2009-01-23 16.51.11 ........... ............ 
#COPIED... ........ ... ................. .......... ........ ........... ............ 
#DELETED.. adztolzu svd 2009-01-23 16.51.11 
# 
#ARCHIVE.. 17672 /oracle/VPP/oraarch/VPParch1_17672_603135330.dbf 2009-01-23 15.40.27 43515904 226227928 1 
#SAVED.... adztolzu svd *VXF1232718526 2009-01-23 16.51.11 ........... ............ 
#COPIED... ........ ... ................. .......... ........ ........... ............ 
#DELETED.. adztolzu svd 2009-01-23 16.51.11 
# 
#ARCHIVE.. 17673 /oracle/VPP/oraarch/VPParch1_17673_603135330.dbf 2009-01-23 15.41.06 43729408 226238784 1 
#SAVED.... adztolzu svd *VXF1232718526 2009-01-23 16.51.11 ........... ............ 
#COPIED... ........ ... ................. .......... ........ ........... ............ 
#DELETED.. adztolzu svd 2009-01-23 16.51.11 
# 
#ARCHIVE.. 17674 /oracle/VPP/oraarch/VPParch1_17674_603135330.dbf 2009-01-23 16.06.06 43450368 226250315 1 
#SAVED.... adztolzu svd *VXF1232718526 2009-01-23 16.51.11 ........... ............ 
#COPIED... ........ ... ................. .......... ........ ........... ............ 
#DELETED.. adztolzu svd 2009-01-23 16.51.11 
# 
#ARCHIVE.. 17675 /oracle/VPP/oraarch/VPParch1_17675_603135330.dbf 2009-01-23 16.43.40 13243904 226263012 1 
#SAVED.... adztolzu svd *VXF1232718526 2009-01-23 16.51.11 ........... ............ 
#COPIED... ........ ... ................. .......... ........ ........... ............ 
#DELETED.. adztolzu svd 2009-01-23 16.51.11 
# 
VPP util_file adztolzu svd 2009-01-23 16.47.22 2009-01-23 16.54.47 1 ........... 17670 17675 0 0 
<HR>
#
<HR>
BR0280I BRARCHIVE time stamp: 2009-01-23 16.51.11 
BR0232I 6 of 6 files saved by backup utility 
BR0230I Backup utility called successfully 
BR0016I 6 offline redo log files processed, total size 220.128 MB
<HR>
Then I take tape with this data and try restore only from this tape 
all datafiles and relevant archive redologs files (17670-17675) restored without errors 
but in the end ERROR occurred
<HR>
 
ERROR at line 1: 
ORA-01195: online backup of file 1 needs more recovery to be consistent 
ORA-01110: data file 1: '/oracle/VPP/sapdata1/system_1/system.data1'
ORA-00279: change 226268039 generated at 01/23/2009 16:43:40 needed for thread 
1 
ORA-00289: suggestion : /oracle/VPP/oraarch/VPParch1_17676_603135330.dbf 
ORA-00280: change 226268039 for thread 1 is in sequence #17676
<HR>
 
My online backup ended, before swith to redolog 17676 
Why I need this file? I think files (17670-17675) should be enough?
Besides, the cange 226268039 generated exactly at moment Switching to next online redo. 
Can I try open database regardless of this error?
 
Thank you for your prompt response 
Andrey Timofeev
Edited by: Andrey Timofeev on Jul 21, 2009 4:53 PM
Edited by: Andrey Timofeev on Jul 21, 2009 4:54 PM

Question on recovery of redolog file

hii,
how to open database,
when block corruption error in redolog file.
there are two archive redo log groups.
and database in non archive mode.
thank's in advance

I think this is a very difficult situation. You cannot proceed in opening your database as your redo log is corrupt (current I guess :( ). Your database is no noarchivelog mode, which makes it more diffidcult.
When you say you have two archive log groups, do you mean redo log groups?
Are those groups multiplexed?
In this case you can still recover from this error by dropping the corrupt redo log file and using the valid surviving redo log member.
If you have only two redo log groups, not multiplexed members an no archivelog mode, then I suggest you to dump the contents of your redo log file and detect up to which point you still can find a valid SCN, so can execute an incomplete recover until that scn.
Procedure to dump the contents of your redo log file is:
alter system dump logfile '/xxxx';
This will create a text file with the contents from your redo log file, once you have it you can check up to whic valid SCN you can get. Next perform an incompete recover until that found SCN.
~ Madrid.

Capture process status waiting for Dictionary Redo: first scn....

Hi
i am facing Issue in Oracle Streams.
below message found in Capture State
waiting for Dictionary Redo: first scn 777777777 (Eg)
Archive_log_dest=USE_DB_RECOVERY_FILE_DEST
i have space related issue....
i restored the archive log to another partition eg. /opt/arc_log
what should i do
1) db start reading archive log from above location
or
2) how to move some archive log to USE_DB_RECOVERY_FILE_DEST from /opt/arc_log so db start processing ...
Regard's

Hi -
Bad news.
As per note 418755.1
A. Confirm checkpoint retention. Periodically, the mining process checkpoints itself for quicker restart. These checkpoints are maintained in the SYSAUX tablespace by default. The capture parameter, checkpoint_retention_time, controls the amount of checkpoint data retained by moving the FIRST_SCN of the capture process forward. The FIRST_SCN is the lowest possible scn available for capturing changes. When the checkpoint_retention_time is exceeded (default = 60 days), the FIRST_SCN is moved and the Streams metadata tables previous to this scn (FIRST_SCN) can be purged and space in the SYSAUX tablespace reclaimed. To alter the checkpoint_retention_time, use the DBMS_CAPTURE_ADM.ALTER_CAPTURE procedure.
Check if the archived redologfile it is requesting is about 60 days old. You need all archived redologs from the requested logfile onwards; if any are missing then you are out of luck. It doesnt matter that there have been mined and captured already; capture still needs these files for a restart. It has always been like this and IMHO is a significant limitation for streams.
If you cannot recover the logfiles, then you will need to rebuild the captiure process and ensure that any gap in data captures has been resynced manually using tags tofix the data.
Rgds
Mark Teehan
Singapore

Blockrecover datafile wants more and more redologs

Hello,
in our prod. system we have a block corruption at datafile 5 block 988626; It's Oracle 11.2.0.2.
DBV at 10.03.2012 was red.
DBV at 03.03.2012 was green.
We have tried a blockrecover like discribed in sap note 540463 with a copy
of affected datafile from 07.03.2012.
But the recovery process wants more and more redologs. Not only these
up to this backup time. The last redolog in the list is from 01.12.2011.
Have anyone a suggestion, why?
RMAN> blockrecover datafile 5 block 988626;
Starting recover at 13-MAR-12
using channel ORA_DISK_1
channel ORA_DISK_1: restoring block(s) from datafile copy /oracle/ABP/sapbackup/beibwemz.spa/sr4.data2
ORA-19505: failed to identify file "/oracle/ABP/sapbackup/beibwemz.spa/sr4.data2"
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
ORA-19600: input file is datafile copy 0 (/oracle/ABP/sapbackup/beibwemz.spa/sr4.data2)
failover to previous backup
channel ORA_DISK_1: restoring block(s) from datafile copy /oracle/ABP/sapbackup/beibmiwu.spa/sr4.data2
ORA-19505: failed to identify file "/oracle/ABP/sapbackup/beibmiwu.spa/sr4.data2"
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
ORA-19600: input file is datafile copy 0 (/oracle/ABP/sapbackup/beibmiwu.spa/sr4.data2)
failover to previous backup
channel ORA_DISK_1: restoring block(s) from datafile copy /oracle/ABP/sapbackup/beibhlbt.spa/sr4.data2
ORA-19505: failed to identify file "/oracle/ABP/sapbackup/beibhlbt.spa/sr4.data2"
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
ORA-19600: input file is datafile copy 0 (/oracle/ABP/sapbackup/beibhlbt.spa/sr4.data2)
failover to previous backup
channel ORA_DISK_1: restoring block(s) from datafile copy /oracle/ABP/sapbackup/beibcngr.spa/sr4.data2
ORA-19505: failed to identify file "/oracle/ABP/sapbackup/beibcngr.spa/sr4.data2"
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
ORA-19600: input file is datafile copy 0 (/oracle/ABP/sapbackup/beibcngr.spa/sr4.data2)
failover to previous backup
channel ORA_DISK_1: restoring block(s) from datafile copy /oracle/ABP/sapbackup/beiaxplp.spa/sr4.data2
starting media recovery
archived log for thread 1 with sequence 746 is already on disk as file /oracle/ABP/oraarch/ABParch1_746_762960509.dbf
archived log for thread 1 with sequence 747 is already on disk as file /oracle/ABP/oraarch/ABParch1_747_762960509.dbf
archived log for thread 1 with sequence 748 is already on disk as file /oracle/ABP/oraarch/ABParch1_748_762960509.dbf
archived log for thread 1 with sequence 749 is already on disk as file /oracle/ABP/oraarch/ABParch1_749_762960509.dbf
archived log for thread 1 with sequence 750 is already on disk as file /oracle/ABP/oraarch/ABParch1_750_762960509.dbf
archived log for thread 1 with sequence 751 is already on disk as file /oracle/ABP/oraarch/ABParch1_751_762960509.dbf
archived log for thread 1 with sequence 752 is already on disk as file /oracle/ABP/oraarch/ABParch1_752_762960509.dbf
archived log for thread 1 with sequence 753 is already on disk as file /oracle/ABP/oraarch/ABParch1_753_762960509.dbf
archived log for thread 1 with sequence 754 is already on disk as file /oracle/ABP/oraarch/ABParch1_754_762960509.dbf
archived log for thread 1 with sequence 755 is already on disk as file /oracle/ABP/oraarch/ABParch1_755_762960509.dbf
archived log for thread 1 with sequence 756 is already on disk as file /oracle/ABP/oraarch/ABParch1_756_762960509.dbf
archived log for thread 1 with sequence 757 is already on disk as file /oracle/ABP/oraarch/ABParch1_757_762960509.dbf
archived log for thread 1 with sequence 758 is already on disk as file /oracle/ABP/oraarch/ABParch1_758_762960509.dbf
archived log for thread 1 with sequence 759 is already on disk as file /oracle/ABP/oraarch/ABParch1_759_762960509.dbf
archived log for thread 1 with sequence 760 is already on disk as file /oracle/ABP/oraarch/ABParch1_760_762960509.dbf
archived log for thread 1 with sequence 761 is already on disk as file /oracle/ABP/oraarch/ABParch1_761_762960509.dbf
archived log for thread 1 with sequence 762 is already on disk as file /oracle/ABP/oraarch/ABParch1_762_762960509.dbf
archived log for thread 1 with sequence 763 is already on disk as file /oracle/ABP/oraarch/ABParch1_763_762960509.dbf
archived log for thread 1 with sequence 764 is already on disk as file /oracle/ABP/oraarch/ABParch1_764_762960509.dbf
archived log for thread 1 with sequence 765 is already on disk as file /oracle/ABP/oraarch/ABParch1_765_762960509.dbf
archived log for thread 1 with sequence 766 is already on disk as file /oracle/ABP/oraarch/ABParch1_766_762960509.dbf
archived log for thread 1 with sequence 767 is already on disk as file /oracle/ABP/oraarch/ABParch1_767_762960509.dbf
archived log for thread 1 with sequence 768 is already on disk as file /oracle/ABP/oraarch/ABParch1_768_762960509.dbf
archived log for thread 1 with sequence 769 is already on disk as file /oracle/ABP/oraarch/ABParch1_769_762960509.dbf
archived log for thread 1 with sequence 770 is already on disk as file /oracle/ABP/oraarch/ABParch1_770_762960509.dbf
archived log for thread 1 with sequence 771 is already on disk as file /oracle/ABP/oraarch/ABParch1_771_762960509.dbf
archived log for thread 1 with sequence 772 is already on disk as file /oracle/ABP/oraarch/ABParch1_772_762960509.dbf
archived log for thread 1 with sequence 773 is already on disk as file /oracle/ABP/oraarch/ABParch1_773_762960509.dbf
archived log for thread 1 with sequence 774 is already on disk as file /oracle/ABP/oraarch/ABParch1_774_762960509.dbf
archived log for thread 1 with sequence 775 is already on disk as file /oracle/ABP/oraarch/ABParch1_775_762960509.dbf
archived log for thread 1 with sequence 776 is already on disk as file /oracle/ABP/oraarch/ABParch1_776_762960509.dbf
archived log for thread 1 with sequence 777 is already on disk as file /oracle/ABP/oraarch/ABParch1_777_762960509.dbf
archived log for thread 1 with sequence 778 is already on disk as file /oracle/ABP/oraarch/ABParch1_778_762960509.dbf
archived log for thread 1 with sequence 779 is already on disk as file /oracle/ABP/oraarch/ABParch1_779_762960509.dbf
archived log for thread 1 with sequence 780 is already on disk as file /oracle/ABP/oraarch/ABParch1_780_762960509.dbf
archived log for thread 1 with sequence 781 is already on disk as file /oracle/ABP/oraarch/ABParch1_781_762960509.dbf
archived log for thread 1 with sequence 782 is already on disk as file /oracle/ABP/oraarch/ABParch1_782_762960509.dbf
archived log for thread 1 with sequence 783 is already on disk as file /oracle/ABP/oraarch/ABParch1_783_762960509.dbf
archived log for thread 1 with sequence 784 is already on disk as file /oracle/ABP/oraarch/ABParch1_784_762960509.dbf
archived log for thread 1 with sequence 785 is already on disk as file /oracle/ABP/oraarch/ABParch1_785_762960509.dbf
archived log for thread 1 with sequence 786 is already on disk as file /oracle/ABP/oraarch/ABParch1_786_762960509.dbf
archived log for thread 1 with sequence 787 is already on disk as file /oracle/ABP/oraarch/ABParch1_787_762960509.dbf
archived log for thread 1 with sequence 788 is already on disk as file /oracle/ABP/oraarch/ABParch1_788_762960509.dbf
archived log for thread 1 with sequence 789 is already on disk as file /oracle/ABP/oraarch/ABParch1_789_762960509.dbf
archived log for thread 1 with sequence 790 is already on disk as file /oracle/ABP/oraarch/ABParch1_790_762960509.dbf
archived log for thread 1 with sequence 791 is already on disk as file /oracle/ABP/oraarch/ABParch1_791_762960509.dbf
archived log for thread 1 with sequence 792 is already on disk as file /oracle/ABP/oraarch/ABParch1_792_762960509.dbf
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/13/2012 15:09:22
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of archived log for thread 1 with sequence 745 and starting SCN of 142871345 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 744 and starting SCN of 142857584 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 743 and starting SCN of 142610445 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 742 and starting SCN of 142603818 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 741 and starting SCN of 142251070 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 740 and starting SCN of 142208140 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 739 and starting SCN of 141900635 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 738 and starting SCN of 141801729 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 737 and starting SCN of 141456008 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 736 and starting SCN of 141317333 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 735 and starting SCN of 141011498 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 734 and starting SCN of 140788707 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 733 and starting SCN of 140456236 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 732 and starting SCN of 140092943 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 731 and starting SCN of 139966473 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 730 and starting SCN of 139696804 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 729 and starting SCN of 139315095 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 728 and starting SCN of 138927651 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 727 and starting SCN of 138554231 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 726 and starting SCN of 138162447 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 725 and starting SCN of 137802351 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 724 and starting SCN of 137373198 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 723 and starting SCN of 137255943 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 722 and starting SCN of 136991580 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 721 and starting SCN of 136597023 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 720 and starting SCN of 136580858 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 719 and starting SCN of 136189970 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 718 and starting SCN of 136133619 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 717 and starting SCN of 135766210 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 716 and starting SCN of 135392432 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 715 and starting SCN of 135082730 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 714 and starting SCN of 134596523 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 713 and starting SCN of 134575210 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 712 and starting SCN of 134190321 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 711 and starting SCN of 133795473 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 710 and starting SCN of 133727100 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 709 and starting SCN of 133390114 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 708 and starting SCN of 133373937 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 707 and starting SCN of 132974335 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 706 and starting SCN of 132547468 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 705 and starting SCN of 132122752 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 704 and starting SCN of 131577534 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 703 and starting SCN of 131537977 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 702 and starting SCN of 131026543 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 701 and starting SCN of 130595253 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 700 and starting SCN of 130194501 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 699 and starting SCN of 129782971 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 698 and starting SCN of 129727897 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 697 and starting SCN of 129362109 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 696 and starting SCN of 128921639 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 695 and starting SCN of 128523499 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 694 and starting SCN of 128397227 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 693 and starting SCN of 128014237 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 692 and starting SCN of 127938320 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 691 and starting SCN of 127563046 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 690 and starting SCN of 127534952 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 689 and starting SCN of 127161442 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 688 and starting SCN of 126745054 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 687 and starting SCN of 126744547 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 686 and starting SCN of 126340344 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 685 and starting SCN of 125912026 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 684 and starting SCN of 125507870 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 683 and starting SCN of 125373198 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 682 and starting SCN of 125097576 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 681 and starting SCN of 125077928 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 680 and starting SCN of 124690471 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 679 and starting SCN of 124267563 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 678 and starting SCN of 124230819 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 677 and starting SCN of 123840628 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 676 and starting SCN of 123441068 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 675 and starting SCN of 123415609 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 674 and starting SCN of 122950744 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 673 and starting SCN of 122556598 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 672 and starting SCN of 122430129 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 671 and starting SCN of 122149270 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 670 and starting SCN of 122085303 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 669 and starting SCN of 121737110 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 668 and starting SCN of 121321405 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 667 and starting SCN of 121293299 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 666 and starting SCN of 120892235 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 665 and starting SCN of 120750679 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 664 and starting SCN of 120464633 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 663 and starting SCN of 120187281 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 662 and starting SCN of 119993667 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 661 and starting SCN of 119596331 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 660 and starting SCN of 119470712 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 659 and starting SCN of 119169365 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 658 and starting SCN of 119121238 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 657 and starting SCN of 118607425 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 656 and starting SCN of 118564465 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 655 and starting SCN of 118002497 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 654 and starting SCN of 117907719 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 653 and starting SCN of 117587712 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 652 and starting SCN of 117162707 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 651 and starting SCN of 116706893 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 650 and starting SCN of 116316027 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 649 and starting SCN of 116229494 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 648 and starting SCN of 115930397 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 647 and starting SCN of 115885601 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 646 and starting SCN of 115522122 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 645 and starting SCN of 115434304 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 644 and starting SCN of 115013992 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 643 and starting SCN of 114755115 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 642 and starting SCN of 114548484 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 641 and starting SCN of 114502983 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 640 and starting SCN of 114454681 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 639 and starting SCN of 114426164 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 638 and starting SCN of 114397043 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 637 and starting SCN of 114371074 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 636 and starting SCN of 114345017 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 635 and starting SCN of 114317260 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 634 and starting SCN of 114289017 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 633 and starting SCN of 114259554 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 632 and starting SCN of 114231181 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 631 and starting SCN of 114149584 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 630 and starting SCN of 114073784 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 629 and starting SCN of 113996145 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 628 and starting SCN of 113958802 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 627 and starting SCN of 113938233 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 626 and starting SCN of 113923193 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 625 and starting SCN of 113908773 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 624 and starting SCN of 113889975 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 623 and starting SCN of 113847827 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 622 and starting SCN of 113781007 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 621 and starting SCN of 113715692 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 620 and starting SCN of 113639496 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 619 and starting SCN of 113565059 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 618 and starting SCN of 113514947 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 617 and starting SCN of 113422709 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 616 and starting SCN of 113315273 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 615 and starting SCN of 113281018 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 614 and starting SCN of 113235876 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 613 and starting SCN of 113194388 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 612 and starting SCN of 113150748 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 611 and starting SCN of 113119377 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 610 and starting SCN of 113090724 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 609 and starting SCN of 113056412 found to restore
RMAN-00567: Recovery Manager could not print some error messages
kind regards
Ch.Fischer

Ok, nobody help :(
Help myself :)
Need only
crosscheck archivelog all;
Then recovery are made.

SCN in redologs

Similar Messages

Maybe you are looking for