RMAN issue, any feedback appreciated

Question

Guys,
Sorry, i shouldn't have posted it here..
We currently use the following script to take backup of our database on production. But this morning i've noticed that the RETENTION POLICY was set to redundancy 1 and it was deleting all backup prior to a day old, although the image copy script says, retain a recovery window of up to 3 days..
run {allocate channel daily_backup device type disk;recover copy of database with tag 'DAILY_BKP' until time 'SYSDATE - 3';backup incremental level 1 cumulative  copies=1 for recover of copy with tag 'DAILY_BKP' database;}So, i set the RENTENTION POLICY to 3 days and deleted all old backup pieces and started a fresh one.. But i am gobsmacked to see that the output below still shows it as incrmental level 1,( it should have been level 0) and the size of 890M for a database of size 50+ Gb.
What's going wrong ? Is RMAN doing something wrong ?
here is the output after the backup..
RMAN> list backup;using target database control file instead of recovery catalogList of Backup Sets===================BS Key  Type LV Size       Device Type Elapsed Time Completion Time------- ---- -- ---------- ----------- ------------ ---------------205     Incr 1  847.98M    DISK        00:00:24     24-JAN-07        BP Key: 201   Status: AVAILABLE  Compressed: NO  Tag: TAG20070124T095347        Piece Name: ORARECO/vfprod/backupset/2007_01_24/nnndn1_tag20070124t095347_0.2441.612698029  List of Datafiles in backup set 205  File LV Type Ckp SCN    Ckp Time  Name  ---- -- ---- ---------- --------- ----  1    1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/system.262.604149337  2    1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/undotbs1.261.604149337  3    1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/sysaux.263.604149337  4    1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/users.268.604149337  5    1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/undotbs2.260.604149411  6    1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/prod_data_01.258.604153527  7    1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/prod_data_02.259.604158465  8    1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/prod_index_02.266.604158515  9    1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/backup_01.265.607712919  10   1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/prod_index_01.256.604158593  11   1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/reports_01.269.604160179  12   1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/prod_data_03.270.607340425  13   1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/prod_data_04.271.607342515  14   1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/prod_index_03.272.607342557  15   1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/prod_index_04.273.607342857  16   1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/swe_data_01.285.611322965  17   1  Incr 58614445   24-JAN-07 ORADATA/vfprod/datafile/swe_index_01.286.611323027BS Key  Type LV Size       Device Type Elapsed Time Completion Time------- ---- -- ---------- ----------- ------------ ---------------206     Full    15.48M     DISK        00:00:01     24-JAN-07        BP Key: 202   Status: AVAILABLE  Compressed: NO  Tag: TAG20070124T095413        Piece Name: +ORARECO/vfprod/autobackup/2007_01_24/s_612698053.2423.612698053  Control File Included: Ckp SCN: 58614605     Ckp time: 24-JAN-07  SPFILE Included: Modification time: 22-JAN-07RMAN> exitAny comments will be valuable.
Thanks
G

Answer 1

'RMAN' seems to be a good work and is doing an incremental backup after the first full backup (this is the correct way).</BR>If you look to the files size you'll see that incremental backup is taking only 15.48M.</BR>It's normal a backup (or incremental backup) take more few space than a "conventional backup" because RMAN compress data.</BR></BR></BR>
[Please, in future format properly your code: lines with more than 2048 characters are difficult to read, format and understand.]