creating standby using rman is failing

[dalacit]

this is the case

primary: 11.2 , linux, stand alone db, using local disks to store db and backup
i back's up the db using BACKUP INCREMENTAL LEVEL 1 AS COMPRESSED BACKUPSET DATABASE TAG 'LEV1_BCKP_2011-06-27_11_54' PLUS ARCHIVELOG DELETE INPUT ( all previous full backups removed to this command should have taken another full backup! and not incremental correct? )
first logseq that this job back's up was: 35818


i am trying to create standlone physical standby on asm.
i have ftps backup to standby server
catalog's the backup on standby so its aware of the backup.
done restore database and worked fine
now doing recover database is failing with this

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/06/2011 13:50:40
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 1899 and starting SCN of 25926696

why is rman asking for sequence 1899 ?

checking the backup log to ensure it was full and not incremental i can see channel ORA_DISK_1: starting compressed incremental level 1 datafile backup set

does hits mean oracle has taken incremental backup ? the backup is huge and i can tell that its full backup by looking at size of it! incrmentals for this system is only couple of GB where as this backup is
300GB

[Thomasps]

BACKUP INCREMENTAL LEVEL 1 AS COMPRESSED BACKUPSET DATABASE TAG 'LEV1_BCKP_2011-06-27_11_54' PLUS ARCHIVELOG DELETE INPUT (all previous full backups removed to this command should have taken another full backup! and not incremental correct? )

Oracle docs says...

RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;

If no level 0 backup is available, then the behavior depends upon the compatibility mode setting. If compatibility is >=10.0.0, RMAN copies all blocks changed since the file was created, and stores the results as a level 1 backup. In other words, the SCN at the time the incremental backup is taken is the file creation SCN. If compatibility <10.0.0, RMAN generates a level 0 backup of the file contents at the time of the backup, to be consistent with the behavior in previous releases.

So, infact it is storing as a LEVEL 1 backup not LEVEL 0 - to avoid this complication, better to take a simple backup (BACKUP DATABASE PLUS ARCHIVELOG or INCREMENTAL LEVEL 0 ) for restore. BTW, are you using a new control file?

Thanks,

[dalacit]

hi thanks for reply, thats what i thought too!

compatible string 11.2.0.0.0

so it should be level 0 backup, but only some of the files are taken as level 0 the rest are taken as level 1 ..
i am using latest control file.
i am running another backup but that means waiting for another 4 days because system is huge

List of Datafiles in backup set 9113
File LV Type Ckp SCN Ckp Time Name
---- -- ----
--------------------------------------------------------------------------------
--------- ----
1 0 Incr 6105603243 01-JUL-11 /d01/oradata/prd01/system01.dbf
2 0 Incr 6105603243 01-JUL-11 /d01/oradata/prd01/sysaux01.dbf
3 0 Incr 6105603243 01-JUL-11 /d01/oradata/prd01/undotbs01.dbf
4 0 Incr 6105603243 01-JUL-11 /d01/oradata/prd01/users01.dbf

and level 1 for the rest of datafiles ..

Piece Name: //data/flash_recovery_area/PRD01/backupset/2011_06_29/o1_mf_nnnd1_LEV1_BCKP_2011_06_27_70o2sqrg_.bkp
List of Datafiles in backup set 9107
File LV Type Ckp SCN Ckp Time Name
---- -- ----
--------------------------------------------------------------------------------
--------- ----
9 1 Incr 6092322545 29-JUN-11 /d01/oradata/prd01/file_02.dbf
24 1 Incr 6092322545 29-JUN-11 /d02/oradata/prd01/file_16.dbf
36 1 Incr 6092322545 29-JUN-11 /d03/oradata/prd01/file_28.dbf
48 1 Incr 6092322545 29-JUN-11 /d04/oradata/prd01/file_40.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

--------------------------------------------------------------------------------
---- --
--------------------------------------------------------------------------------
-----------
--------------------------------------------------------------------------------
---------------
9108 Incr 1 21.06G DISK 15:27:37 30-JUN-11
BP Key: 9108 Status: AVAILABLE Compressed: YES Tag: LEV1_BCKP_2011-06-27_11_54
Piece Name: //data/flash_recovery_area/PRD01/backupset/2011_06_29/o1_mf_nnnd1_LEV1_BCKP_2011_06_27_70p84gym_.bkp
List of Datafiles in backup set 9108
File LV Type Ckp SCN Ckp Time Name
---- -- ----
--------------------------------------------------------------------------------
--------- ----
11 1 Incr 6095836100 29-JUN-11 /d01/oradata/prd01/file_04.dbf
25 1 Incr 6095836100 29-JUN-11 /d02/oradata/prd01/file_17.dbf
37 1 Incr 6095836100 29-JUN-11 /d03/oradata/prd01/file_30.dbf
54 1 Incr 6095836100 29-JUN-11 //data/oradata/prd01/file_46.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

--------------------------------------------------------------------------------
---- --
--------------------------------------------------------------------------------
-----------
--------------------------------------------------------------------------------
---------------
9109 Incr 1 21.83G DISK 13:35:13 30-JUN-11
BP Key: 9109 Status: AVAILABLE Compressed: YES Tag: LEV1_BCKP_2011-06-27_11_54
Piece Name: //data/flash_recovery_area/PRD01/backupset/2011_06_29/o1_mf_nnnd1_LEV1_BCKP_2011_06_27_70pnpgpg_.bkp
List of Datafiles in backup set 9109
File LV Type Ckp SCN Ckp Time Name
---- -- ----
--------------------------------------------------------------------------------
--------- ----
12 1 Incr 6099043402 29-JUN-11 /d01/oradata/prd01/file_05.dbf
26 1 Incr 6099043402 29-JUN-11 /d02/oradata/prd01/file_18.dbf
38 1 Incr 6099043402 29-JUN-11 /d03/oradata/prd01/file_29.dbf
49 1 Incr 6099043402 29-JUN-11 /d04/oradata/prd01/file_41.dbf

[dalacit]

could be because CONFIGURE BACKUP OPTIMIZATION was set to on??