Incremental Hot backup question
This question originated from a different post of mine, but is somewhat different so I'm starting it up as a separate topic.
Each night we do an incremental hot backup around 4am. Yesterday I dropped a tablespace successfully and removed the original datafile along with it. Autobackup backed up the control file before and after the drop. Then when the incremental backups ran last night at 4am everything went just fine.
So up to this point we're all good.
However, in the flash recovery area where it writes the backups (backupsets, datafiles, etc) it still has a file for that tablespace... except that it did not appear to be updated like all the reset were. This is fine, but that file is taking up space on the box and the unix backup script that copies everything to a separate box still picks it up (that script copies everything.. and the author of the code doesn't want to hard code any names)
Can I just remove this file without causing the backup to be upset? Or do I need to do something else to accomplish this goal? And if so, what (still a newbie so be specific)?
Thanks in advance.
The first thing you need to do is to provide a complementary crystal ball in order to be able to guess nasty little details, like the contents of that script.
Even 'incremental hot backup' is an ambiguous term. One would expect a RMAN backup, but as you didn't use various RMAN commands to establish all of your files have been backed up, and you talk about 'backupsets' and seem to discuss a standalone datafile: The only thing I see is lots of fog, and the need to tear the information out of you.
No business for volunteers.
Sybrand Bakker
Senior Oracle DBA
Experts: those who did read documentation.
Similar Messages
-
Our DBA duties are currently outsourced and I'm just curious about something.
We asked them to copy a schema from our Production database (during the day) down to it's equivalents in the Acceptance and Test environments. We found a problem in that the maximum value of a primary key on a table was 100121, and the sequence uses to generate the value for the primary key was only at 100081.
Is this just one of the risks of taking a hot backup, and so should schedule a backup be taken after hours? Or did he possibly do something wrong?
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64biIf the request was to copy only one schema, then it is unlikely that a "hot backup" would have been used. Quite possibly exp/imp or expdp/impdp would have been used to export the schema from Production and import it into the other two databases.
Sequences are always "a problem" when export - import is used while the database is active. The export of the sequence and the export of the table (or tables) that use the sequence are not at the same time / SCN so the values may diverge as they get updated in the source database.
The plan is to reset the sequence in the target database by manually incrementing it till it reaches the desired target (100122).
Hemant K Chitale -
Retention policy for incremental cumulative backup question
Hi,
I have a production database configured with retention policy for 30 days window. No catalog is used.
The backup plan is:
Sunday - Level 0 backup.
Weekdays - Incremental 1 cumulative backup.
I also noticed that some archive logs since Mar 07 2010 has become obsolete in the recent few days.
Cannot figure out why the backup of Mar 07 2010 is going to be obsolete today.
Thanks for your help!
RMAN> list backup summary;
using target database control file instead of recovery catalog
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed
*14 B 0 A SBT_TAPE 07-MAR-10 5 1 NO*
*15 B 0 A SBT_TAPE 07-MAR-10 5 1 NO*
*17 B F A SBT_TAPE 07-MAR-10 1 1 NO*
21 B F A SBT_TAPE 08-MAR-10 1 1 NO
24 B 1 A SBT_TAPE 08-MAR-10 1 1 NO
25 B 1 A SBT_TAPE 08-MAR-10 1 1 NO
27 B F A SBT_TAPE 08-MAR-10 1 1 NO
35 B 1 A SBT_TAPE 09-MAR-10 1 1 NO
36 B 1 A SBT_TAPE 09-MAR-10 1 1 NO
38 B F A SBT_TAPE 09-MAR-10 1 1 NO
46 B 1 A SBT_TAPE 10-MAR-10 1 1 NO
47 B 1 A SBT_TAPE 10-MAR-10 1 1 NO
49 B F A SBT_TAPE 10-MAR-10 1 1 NO
57 B 1 A SBT_TAPE 11-MAR-10 1 1 NO
58 B 1 A SBT_TAPE 11-MAR-10 2 1 NO
60 B F A SBT_TAPE 11-MAR-10 1 1 NO
66 B A A SBT_TAPE 12-MAR-10 1 1 NO
67 B A A SBT_TAPE 12-MAR-10 1 1 NO
68 B 1 A SBT_TAPE 12-MAR-10 1 1 NO
69 B 1 A SBT_TAPE 12-MAR-10 2 1 NO
70 B A A SBT_TAPE 12-MAR-10 1 1 NO
71 B F A SBT_TAPE 12-MAR-10 1 1 NO
77 B A A SBT_TAPE 14-MAR-10 1 1 NO
78 B A A SBT_TAPE 14-MAR-10 1 1 NO
79 B 0 A SBT_TAPE 14-MAR-10 6 1 NO
80 B 0 A SBT_TAPE 14-MAR-10 6 1 NO
81 B A A SBT_TAPE 14-MAR-10 1 1 NO
82 B F A SBT_TAPE 14-MAR-10 1 1 NO
88 B A A SBT_TAPE 15-MAR-10 1 1 NO
89 B A A SBT_TAPE 15-MAR-10 1 1 NO
90 B 1 A SBT_TAPE 15-MAR-10 1 1 NO
91 B 1 A SBT_TAPE 15-MAR-10 1 1 NO
92 B A A SBT_TAPE 15-MAR-10 1 1 NO
93 B F A SBT_TAPE 15-MAR-10 1 1 NO
99 B A A SBT_TAPE 16-MAR-10 1 1 NO
100 B A A SBT_TAPE 16-MAR-10 1 1 NO
101 B 1 A SBT_TAPE 16-MAR-10 1 1 NO
102 B 1 A SBT_TAPE 16-MAR-10 1 1 NO
103 B A A SBT_TAPE 16-MAR-10 1 1 NO
104 B F A SBT_TAPE 16-MAR-10 1 1 NO
109 B A A SBT_TAPE 17-MAR-10 4 1 NO
110 B F A SBT_TAPE 17-MAR-10 1 1 NO
111 B A A SBT_TAPE 17-MAR-10 1 1 NO
112 B F A SBT_TAPE 17-MAR-10 1 1 NO
113 B A A SBT_TAPE 17-MAR-10 1 1 NO
114 B A A SBT_TAPE 17-MAR-10 1 1 NO
115 B 1 A SBT_TAPE 17-MAR-10 1 1 NO
116 B 1 A SBT_TAPE 17-MAR-10 2 1 NO
117 B A A SBT_TAPE 17-MAR-10 1 1 NO
118 B F A SBT_TAPE 17-MAR-10 1 1 NO
123 B A A SBT_TAPE 18-MAR-10 2 1 NO
124 B F A SBT_TAPE 18-MAR-10 1 1 NO
125 B A A SBT_TAPE 18-MAR-10 2 1 NO
126 B F A SBT_TAPE 18-MAR-10 1 1 NO
127 B A A SBT_TAPE 18-MAR-10 1 1 NO
128 B F A SBT_TAPE 18-MAR-10 1 1 NO
129 B A A SBT_TAPE 18-MAR-10 1 1 NO
130 B F A SBT_TAPE 18-MAR-10 1 1 NO
131 B A A SBT_TAPE 18-MAR-10 1 1 NO
132 B A A SBT_TAPE 18-MAR-10 1 1 NO
133 B 1 A SBT_TAPE 18-MAR-10 1 1 NO
134 B 1 A SBT_TAPE 18-MAR-10 2 1 NO
135 B A A SBT_TAPE 18-MAR-10 1 1 NO
136 B F A SBT_TAPE 18-MAR-10 1 1 NO
142 B A A SBT_TAPE 19-MAR-10 2 1 NO
143 B F A SBT_TAPE 19-MAR-10 1 1 NO
144 B A A SBT_TAPE 19-MAR-10 1 1 NO
145 B F A SBT_TAPE 19-MAR-10 1 1 NO
146 B A A SBT_TAPE 19-MAR-10 1 1 NO
147 B F A SBT_TAPE 19-MAR-10 1 1 NO
148 B A A SBT_TAPE 19-MAR-10 1 1 NO
149 B F A SBT_TAPE 19-MAR-10 1 1 NO
150 B A A SBT_TAPE 19-MAR-10 1 1 NO
151 B A A SBT_TAPE 19-MAR-10 1 1 NO
152 B 1 A SBT_TAPE 19-MAR-10 1 1 NO
153 B 1 A SBT_TAPE 19-MAR-10 2 1 NO
154 B A A SBT_TAPE 19-MAR-10 1 1 NO
155 B F A SBT_TAPE 19-MAR-10 1 1 NO
161 B A A SBT_TAPE 21-MAR-10 1 1 NO
162 B 0 A SBT_TAPE 21-MAR-10 6 1 NO
163 B 0 A SBT_TAPE 21-MAR-10 6 1 NO
164 B A A SBT_TAPE 21-MAR-10 1 1 NO
165 B F A SBT_TAPE 21-MAR-10 1 1 NO
171 B A A SBT_TAPE 22-MAR-10 1 1 NO
172 B F A SBT_TAPE 22-MAR-10 1 1 NO
173 B A A SBT_TAPE 22-MAR-10 1 1 NO
174 B F A SBT_TAPE 22-MAR-10 1 1 NO
RMAN> show all;
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE 'SBT_TAPE' TO '%F';
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO BACKUPSET;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE 'SBT_TAPE' TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt.ccbprod)' FORMAT '%d_inc_%T_%t_%U' MAXPIECESIZE 4608 M;
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/orasw/app/oracle/product/10.2.0/dbs/snapcf_ccbprod.f'; # default
RMAN> report obsolete;
RMAN retention policy will be applied to the command
RMAN retention policy is set to recovery window of 30 days
Report of obsolete backups and copies
Type Key Completion Time Filename/Handle
Control File Copy 108 19-FEB-10 /ccbprod/oradata/ccbprod/arc/control.bak.100219.21.21
Backup Set 8 07-MAR-10 Backup Piece 19 07-MAR-10 CCBPROD_inc_20100307_713034799_07l8031f_5_1
Backup Set 8 07-MAR-10 Backup Piece 18 07-MAR-10 CCBPROD_inc_20100307_713034799_07l8031f_4_1
Backup Set 8 07-MAR-10 Backup Piece 17 07-MAR-10 CCBPROD_inc_20100307_713034799_07l8031f_3_1
Backup Set 8 07-MAR-10 Backup Piece 16 07-MAR-10 CCBPROD_inc_20100307_713034799_07l8031f_2_1
Backup Set 8 07-MAR-10 Backup Piece 15 07-MAR-10 CCBPROD_inc_20100307_713034799_07l8031f_1_1
Backup Set 7 07-MAR-10 Backup Piece 14 07-MAR-10 CCBPROD_inc_20100307_713034799_08l8031f_5_1
Backup Set 7 07-MAR-10 Backup Piece 13 07-MAR-10 CCBPROD_inc_20100307_713034799_08l8031f_4_1
Backup Set 7 07-MAR-10 Backup Piece 12 07-MAR-10 CCBPROD_inc_20100307_713034799_08l8031f_3_1
Backup Set 7 07-MAR-10 Backup Piece 11 07-MAR-10 CCBPROD_inc_20100307_713034799_08l8031f_2_1
Backup Set 7 07-MAR-10 Backup Piece 10 07-MAR-10 CCBPROD_inc_20100307_713034799_08l8031f_1_1
Backup Set 10 07-MAR-10 Backup Piece 21 07-MAR-10 c-2894189962-20100307-00
Edited by: user12019850 on 22-Mar-2010 10:53 AMAnother database with the same configuration and same plan seems fine:
RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE 'SBT_TAPE' TO '%F';
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO BACKUPSET;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE 'SBT_TAPE' TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt.cisconf)' FORMAT '%d_inc_%T_%t_%U' MAXPIECESIZE 4608 M;
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/orasw/app/oracle/product/10.2.0/dbs/snapcf_cisconf.f'; # default
RMAN> list backup summary;
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed
774 B 0 A SBT_TAPE 19-FEB-10 1 1 NO
775 B 0 A SBT_TAPE 19-FEB-10 2 1 NO
795 B 1 A SBT_TAPE 20-FEB-10 1 1 NO
796 B 1 A SBT_TAPE 20-FEB-10 1 1 NO
797 B A A SBT_TAPE 20-FEB-10 1 1 NO
803 B A A SBT_TAPE 20-FEB-10 1 1 NO
804 B F A SBT_TAPE 20-FEB-10 1 1 NO
805 B A A SBT_TAPE 20-FEB-10 1 1 NO
806 B F A SBT_TAPE 20-FEB-10 1 1 NO
807 B A A SBT_TAPE 20-FEB-10 1 1 NO
808 B F A SBT_TAPE 20-FEB-10 1 1 NO
809 B A A SBT_TAPE 21-FEB-10 1 1 NO
810 B 0 A SBT_TAPE 21-FEB-10 1 1 NO
811 B 0 A SBT_TAPE 21-FEB-10 2 1 NO
812 B A A SBT_TAPE 21-FEB-10 1 1 NO
813 B F A SBT_TAPE 21-FEB-10 1 1 NO
818 B A A SBT_TAPE 21-FEB-10 1 1 NO
819 B F A SBT_TAPE 21-FEB-10 1 1 NO
820 B A A SBT_TAPE 21-FEB-10 1 1 NO
821 B F A SBT_TAPE 21-FEB-10 1 1 NO
822 B A A SBT_TAPE 21-FEB-10 1 1 NO
823 B F A SBT_TAPE 21-FEB-10 1 1 NO
824 B A A SBT_TAPE 22-FEB-10 1 1 NO
825 B 1 A SBT_TAPE 22-FEB-10 1 1 NO
826 B 1 A SBT_TAPE 22-FEB-10 1 1 NO
827 B A A SBT_TAPE 22-FEB-10 1 1 NO
828 B F A SBT_TAPE 22-FEB-10 1 1 NO
833 B A A SBT_TAPE 22-FEB-10 1 1 NO
834 B F A SBT_TAPE 22-FEB-10 1 1 NO
835 B A A SBT_TAPE 22-FEB-10 1 1 NO
836 B F A SBT_TAPE 22-FEB-10 1 1 NO
837 B A A SBT_TAPE 22-FEB-10 1 1 NO
838 B F A SBT_TAPE 22-FEB-10 1 1 NO
839 B A A SBT_TAPE 22-FEB-10 1 1 NO
840 B F A SBT_TAPE 22-FEB-10 1 1 NO
841 B A A SBT_TAPE 23-FEB-10 1 1 NO
842 B 1 A SBT_TAPE 23-FEB-10 1 1 NO
843 B 1 A SBT_TAPE 23-FEB-10 1 1 NO
844 B A A SBT_TAPE 23-FEB-10 1 1 NO
845 B F A SBT_TAPE 23-FEB-10 1 1 NO
850 B A A SBT_TAPE 23-FEB-10 1 1 NO
851 B F A SBT_TAPE 23-FEB-10 1 1 NO
852 B A A SBT_TAPE 23-FEB-10 1 1 NO
853 B F A SBT_TAPE 23-FEB-10 1 1 NO
854 B A A SBT_TAPE 23-FEB-10 1 1 NO
855 B F A SBT_TAPE 23-FEB-10 1 1 NO
856 B A A SBT_TAPE 24-FEB-10 1 1 NO
857 B 1 A SBT_TAPE 24-FEB-10 1 1 NO
858 B 1 A SBT_TAPE 24-FEB-10 1 1 NO
859 B A A SBT_TAPE 24-FEB-10 1 1 NO
860 B F A SBT_TAPE 24-FEB-10 1 1 NO
865 B A A SBT_TAPE 24-FEB-10 1 1 NO
866 B F A SBT_TAPE 24-FEB-10 1 1 NO
867 B A A SBT_TAPE 24-FEB-10 1 1 NO
868 B F A SBT_TAPE 24-FEB-10 1 1 NO
869 B A A SBT_TAPE 24-FEB-10 1 1 NO
870 B F A SBT_TAPE 24-FEB-10 1 1 NO
871 B A A SBT_TAPE 24-FEB-10 1 1 NO
872 B 1 A SBT_TAPE 24-FEB-10 1 1 NO
873 B 1 A SBT_TAPE 24-FEB-10 1 1 NO
874 B A A SBT_TAPE 24-FEB-10 1 1 NO
875 B F A SBT_TAPE 24-FEB-10 1 1 NO
880 B A A SBT_TAPE 24-FEB-10 1 1 NO
881 B F A SBT_TAPE 24-FEB-10 1 1 NO
882 B A A SBT_TAPE 25-FEB-10 1 1 NO
883 B 1 A SBT_TAPE 25-FEB-10 1 1 NO
884 B 1 A SBT_TAPE 25-FEB-10 1 1 NO
885 B A A SBT_TAPE 25-FEB-10 1 1 NO
886 B F A SBT_TAPE 25-FEB-10 1 1 NO
891 B A A SBT_TAPE 25-FEB-10 1 1 NO
892 B F A SBT_TAPE 25-FEB-10 1 1 NO
893 B A A SBT_TAPE 25-FEB-10 1 1 NO
894 B F A SBT_TAPE 25-FEB-10 1 1 NO
895 B A A SBT_TAPE 25-FEB-10 1 1 NO
896 B F A SBT_TAPE 25-FEB-10 1 1 NO
897 B A A SBT_TAPE 25-FEB-10 1 1 NO
898 B F A SBT_TAPE 25-FEB-10 1 1 NO
899 B A A SBT_TAPE 25-FEB-10 1 1 NO
900 B F A SBT_TAPE 25-FEB-10 1 1 NO
901 B A A SBT_TAPE 25-FEB-10 1 1 NO
902 B F A SBT_TAPE 25-FEB-10 1 1 NO
903 B A A SBT_TAPE 26-FEB-10 1 1 NO
904 B 1 A SBT_TAPE 26-FEB-10 1 1 NO
905 B 1 A SBT_TAPE 26-FEB-10 1 1 NO
906 B A A SBT_TAPE 26-FEB-10 1 1 NO
907 B F A SBT_TAPE 26-FEB-10 1 1 NO
912 B A A SBT_TAPE 26-FEB-10 1 1 NO
913 B F A SBT_TAPE 26-FEB-10 1 1 NO
914 B A A SBT_TAPE 26-FEB-10 1 1 NO
915 B F A SBT_TAPE 26-FEB-10 1 1 NO
916 B A A SBT_TAPE 26-FEB-10 1 1 NO
917 B F A SBT_TAPE 26-FEB-10 1 1 NO
918 B A A SBT_TAPE 27-FEB-10 1 1 NO
919 B 1 A SBT_TAPE 27-FEB-10 1 1 NO
920 B 1 A SBT_TAPE 27-FEB-10 1 1 NO
921 B A A SBT_TAPE 27-FEB-10 1 1 NO
922 B F A SBT_TAPE 27-FEB-10 1 1 NO
927 B A A SBT_TAPE 27-FEB-10 1 1 NO
928 B F A SBT_TAPE 27-FEB-10 1 1 NO
929 B A A SBT_TAPE 27-FEB-10 1 1 NO
930 B F A SBT_TAPE 27-FEB-10 1 1 NO
931 B A A SBT_TAPE 27-FEB-10 1 1 NO
932 B F A SBT_TAPE 27-FEB-10 1 1 NO
933 B A A SBT_TAPE 28-FEB-10 1 1 NO
934 B 0 A SBT_TAPE 28-FEB-10 1 1 NO
935 B 0 A SBT_TAPE 28-FEB-10 2 1 NO
936 B A A SBT_TAPE 28-FEB-10 1 1 NO
937 B F A SBT_TAPE 28-FEB-10 1 1 NO
942 B A A SBT_TAPE 28-FEB-10 1 1 NO
943 B F A SBT_TAPE 28-FEB-10 1 1 NO
944 B A A SBT_TAPE 28-FEB-10 1 1 NO
945 B F A SBT_TAPE 28-FEB-10 1 1 NO
946 B A A SBT_TAPE 28-FEB-10 1 1 NO
947 B F A SBT_TAPE 28-FEB-10 1 1 NO
948 B A A SBT_TAPE 01-MAR-10 1 1 NO
949 B 1 A SBT_TAPE 01-MAR-10 1 1 NO
950 B 1 A SBT_TAPE 01-MAR-10 1 1 NO
951 B A A SBT_TAPE 01-MAR-10 1 1 NO
952 B F A SBT_TAPE 01-MAR-10 1 1 NO
957 B A A SBT_TAPE 01-MAR-10 1 1 NO
958 B F A SBT_TAPE 01-MAR-10 1 1 NO
959 B A A SBT_TAPE 01-MAR-10 1 1 NO
960 B F A SBT_TAPE 01-MAR-10 1 1 NO
961 B A A SBT_TAPE 01-MAR-10 1 1 NO
962 B F A SBT_TAPE 01-MAR-10 1 1 NO
963 B A A SBT_TAPE 02-MAR-10 1 1 NO
964 B 1 A SBT_TAPE 02-MAR-10 1 1 NO
965 B 1 A SBT_TAPE 02-MAR-10 1 1 NO
966 B A A SBT_TAPE 02-MAR-10 1 1 NO
967 B F A SBT_TAPE 02-MAR-10 1 1 NO
970 B A A SBT_TAPE 02-MAR-10 1 1 NO
971 B F A SBT_TAPE 02-MAR-10 1 1 NO
972 B A A SBT_TAPE 02-MAR-10 1 1 NO
973 B F A SBT_TAPE 02-MAR-10 1 1 NO
974 B A A SBT_TAPE 02-MAR-10 1 1 NO
975 B F A SBT_TAPE 02-MAR-10 1 1 NO
976 B A A SBT_TAPE 03-MAR-10 1 1 NO
977 B 1 A SBT_TAPE 03-MAR-10 1 1 NO
978 B 1 A SBT_TAPE 03-MAR-10 1 1 NO
979 B A A SBT_TAPE 03-MAR-10 1 1 NO
980 B F A SBT_TAPE 03-MAR-10 1 1 NO
983 B A A SBT_TAPE 03-MAR-10 1 1 NO
984 B F A SBT_TAPE 03-MAR-10 1 1 NO
985 B A A SBT_TAPE 03-MAR-10 1 1 NO
986 B F A SBT_TAPE 03-MAR-10 1 1 NO
987 B A A SBT_TAPE 03-MAR-10 1 1 NO
988 B F A SBT_TAPE 03-MAR-10 1 1 NO
989 B A A SBT_TAPE 04-MAR-10 1 1 NO
990 B 1 A SBT_TAPE 04-MAR-10 1 1 NO
991 B 1 A SBT_TAPE 04-MAR-10 1 1 NO
992 B A A SBT_TAPE 04-MAR-10 1 1 NO
993 B F A SBT_TAPE 04-MAR-10 1 1 NO
996 B A A SBT_TAPE 04-MAR-10 1 1 NO
997 B F A SBT_TAPE 04-MAR-10 1 1 NO
998 B A A SBT_TAPE 04-MAR-10 1 1 NO
999 B F A SBT_TAPE 04-MAR-10 1 1 NO
1000 B A A SBT_TAPE 04-MAR-10 1 1 NO
1001 B F A SBT_TAPE 04-MAR-10 1 1 NO
1002 B A A SBT_TAPE 05-MAR-10 1 1 NO
1003 B 1 A SBT_TAPE 05-MAR-10 1 1 NO
1004 B 1 A SBT_TAPE 05-MAR-10 1 1 NO
1005 B A A SBT_TAPE 05-MAR-10 1 1 NO
1006 B F A SBT_TAPE 05-MAR-10 1 1 NO
1009 B A A SBT_TAPE 05-MAR-10 1 1 NO
1010 B F A SBT_TAPE 05-MAR-10 1 1 NO
1011 B A A SBT_TAPE 05-MAR-10 1 1 NO
1012 B F A SBT_TAPE 05-MAR-10 1 1 NO
1013 B A A SBT_TAPE 05-MAR-10 1 1 NO
1014 B F A SBT_TAPE 05-MAR-10 1 1 NO
1015 B A A SBT_TAPE 06-MAR-10 1 1 NO
1016 B 1 A SBT_TAPE 06-MAR-10 1 1 NO
1017 B 1 A SBT_TAPE 06-MAR-10 1 1 NO
1018 B A A SBT_TAPE 06-MAR-10 1 1 NO
1019 B F A SBT_TAPE 06-MAR-10 1 1 NO
1022 B A A SBT_TAPE 07-MAR-10 1 1 NO
1023 B 0 A SBT_TAPE 07-MAR-10 1 1 NO
1024 B 0 A SBT_TAPE 07-MAR-10 2 1 NO
1025 B A A SBT_TAPE 07-MAR-10 1 1 NO
1026 B F A SBT_TAPE 07-MAR-10 1 1 NO
1029 B A A SBT_TAPE 07-MAR-10 1 1 NO
1030 B F A SBT_TAPE 07-MAR-10 1 1 NO
1031 B A A SBT_TAPE 07-MAR-10 1 1 NO
1032 B F A SBT_TAPE 07-MAR-10 1 1 NO
1033 B A A SBT_TAPE 07-MAR-10 1 1 NO
1034 B F A SBT_TAPE 07-MAR-10 1 1 NO
1035 B A A SBT_TAPE 08-MAR-10 1 1 NO
1036 B 1 A SBT_TAPE 08-MAR-10 1 1 NO
1037 B 1 A SBT_TAPE 08-MAR-10 1 1 NO
1038 B A A SBT_TAPE 08-MAR-10 1 1 NO
1039 B F A SBT_TAPE 08-MAR-10 1 1 NO
1042 B A A SBT_TAPE 08-MAR-10 1 1 NO
1043 B F A SBT_TAPE 08-MAR-10 1 1 NO
1044 B A A SBT_TAPE 08-MAR-10 1 1 NO
1045 B 1 A SBT_TAPE 08-MAR-10 1 1 NO
1046 B 1 A SBT_TAPE 08-MAR-10 1 1 NO
1047 B A A SBT_TAPE 08-MAR-10 1 1 NO
1048 B F A SBT_TAPE 08-MAR-10 1 1 NO
1054 B A A SBT_TAPE 09-MAR-10 1 1 NO
1055 B A A SBT_TAPE 09-MAR-10 1 1 NO
1056 B 1 A SBT_TAPE 09-MAR-10 1 1 NO
1057 B 1 A SBT_TAPE 09-MAR-10 1 1 NO
1058 B A A SBT_TAPE 09-MAR-10 1 1 NO
1059 B F A SBT_TAPE 09-MAR-10 1 1 NO
1065 B A A SBT_TAPE 10-MAR-10 1 1 NO
1066 B 1 A SBT_TAPE 10-MAR-10 1 1 NO
1067 B 1 A SBT_TAPE 10-MAR-10 1 1 NO
1068 B A A SBT_TAPE 10-MAR-10 1 1 NO
1069 B F A SBT_TAPE 10-MAR-10 1 1 NO
1075 B A A SBT_TAPE 11-MAR-10 1 1 NO
1076 B 1 A SBT_TAPE 11-MAR-10 1 1 NO
1077 B 1 A SBT_TAPE 11-MAR-10 1 1 NO
1078 B A A SBT_TAPE 11-MAR-10 1 1 NO
1079 B F A SBT_TAPE 11-MAR-10 1 1 NO
1085 B A A SBT_TAPE 12-MAR-10 1 1 NO
1086 B 1 A SBT_TAPE 12-MAR-10 1 1 NO
1087 B 1 A SBT_TAPE 12-MAR-10 1 1 NO
1088 B A A SBT_TAPE 12-MAR-10 1 1 NO
1089 B F A SBT_TAPE 12-MAR-10 1 1 NO
1094 B A A SBT_TAPE 13-MAR-10 1 1 NO
1095 B A A SBT_TAPE 13-MAR-10 1 1 NO
1096 B 1 A SBT_TAPE 13-MAR-10 1 1 NO
1097 B 1 A SBT_TAPE 13-MAR-10 1 1 NO
1098 B A A SBT_TAPE 13-MAR-10 1 1 NO
1099 B F A SBT_TAPE 13-MAR-10 1 1 NO
1105 B A A SBT_TAPE 14-MAR-10 1 1 NO
1106 B 0 A SBT_TAPE 14-MAR-10 1 1 NO
1107 B 0 A SBT_TAPE 14-MAR-10 2 1 NO
1108 B A A SBT_TAPE 14-MAR-10 1 1 NO
1109 B F A SBT_TAPE 14-MAR-10 1 1 NO
1115 B A A SBT_TAPE 15-MAR-10 1 1 NO
1116 B 1 A SBT_TAPE 15-MAR-10 1 1 NO
1117 B 1 A SBT_TAPE 15-MAR-10 1 1 NO
1118 B A A SBT_TAPE 15-MAR-10 1 1 NO
1119 B F A SBT_TAPE 15-MAR-10 1 1 NO
1125 B A A SBT_TAPE 16-MAR-10 1 1 NO
1126 B A A SBT_TAPE 16-MAR-10 1 1 NO
1127 B 1 A SBT_TAPE 16-MAR-10 1 1 NO
1128 B 1 A SBT_TAPE 16-MAR-10 1 1 NO
1129 B A A SBT_TAPE 16-MAR-10 1 1 NO
1130 B F A SBT_TAPE 16-MAR-10 1 1 NO
1136 B A A SBT_TAPE 17-MAR-10 1 1 NO
1137 B A A SBT_TAPE 17-MAR-10 1 1 NO
1138 B 1 A SBT_TAPE 17-MAR-10 1 1 NO
1139 B 1 A SBT_TAPE 17-MAR-10 1 1 NO
1140 B A A SBT_TAPE 17-MAR-10 1 1 NO
1141 B F A SBT_TAPE 17-MAR-10 1 1 NO
1147 B A A SBT_TAPE 18-MAR-10 1 1 NO
1148 B A A SBT_TAPE 18-MAR-10 1 1 NO
1149 B 1 A SBT_TAPE 18-MAR-10 1 1 NO
1150 B 1 A SBT_TAPE 18-MAR-10 1 1 NO
1151 B A A SBT_TAPE 18-MAR-10 1 1 NO
1152 B F A SBT_TAPE 18-MAR-10 1 1 NO
1158 B A A SBT_TAPE 19-MAR-10 1 1 NO
1159 B A A SBT_TAPE 19-MAR-10 1 1 NO
1160 B 1 A SBT_TAPE 19-MAR-10 1 1 NO
1161 B 1 A SBT_TAPE 19-MAR-10 1 1 NO
1162 B A A SBT_TAPE 19-MAR-10 1 1 NO
1163 B F A SBT_TAPE 19-MAR-10 1 1 NO
1169 B A A SBT_TAPE 20-MAR-10 1 1 NO
1170 B 1 A SBT_TAPE 20-MAR-10 1 1 NO
1171 B 1 A SBT_TAPE 20-MAR-10 1 1 NO
1172 B A A SBT_TAPE 20-MAR-10 1 1 NO
1173 B F A SBT_TAPE 20-MAR-10 1 1 NO
1179 B A A SBT_TAPE 21-MAR-10 1 1 NO
1180 B 0 A SBT_TAPE 21-MAR-10 1 1 NO
1181 B 0 A SBT_TAPE 21-MAR-10 2 1 NO
1182 B A A SBT_TAPE 21-MAR-10 1 1 NO
1183 B F A SBT_TAPE 21-MAR-10 1 1 NO
1189 B A A SBT_TAPE 22-MAR-10 1 1 NO
1190 B 1 A SBT_TAPE 22-MAR-10 1 1 NO
1191 B 1 A SBT_TAPE 22-MAR-10 1 1 NO
1192 B A A SBT_TAPE 22-MAR-10 1 1 NO
1193 B F A SBT_TAPE 22-MAR-10 1 1 NO
RMAN> report obsolete;
RMAN retention policy will be applied to the command
RMAN retention policy is set to recovery window of 30 days
Report of obsolete backups and copies
Type Key Completion Time Filename/Handle
Control File Copy 47 20-FEB-10 /dbbackup/cisconf/control.bak.20100220
Backup Set 804 20-FEB-10
Backup Piece 551 20-FEB-10 c-3316101807-20100220-01
Edited by: user12019850 on 22-Mar-2010 11:03 AM -
Hi all,
i have a question related to hot backup
If we take a hot backup ie. alter tablespace tbs begin backup....then it freezed the datafile and all the entries happen to the redo log files.....if we a two log groups and and hot backup happens to continue from BOD(beginning of day) to EOD,then there might be a situation in which log switch happen it means it will archive the same,so how the datafile will recover the same...
here it freezed the whole datafile or only datafile header.....user00726 wrote:
Hi all,
i have a question related to hot backup
If we take a hot backup ie. alter tablespace tbs begin backup....then it freezed the datafile and all the entries happen to the redo log files.....if we a two log groups and and hot backup happens to continue from BOD(beginning of day) to EOD,then there might be a situation in which log switch happen it means it will archive the same,so how the datafile will recover the same...
here it freezed the whole datafile or only datafile header.....The crux of the hot backup done via manual cp command is that datafile is completely operational. So all the objects which can undergo changes like tables and all , they keep on working as like they used to do without the back up is on. As all the changed vectors are logged in the redo log files , so the same is true in this case also when the datafile goes into the backup mode. Oracle just freezes the header of teh datafile and freezes the SCN at that point for it to know where to start the recovery from in the order of a crash. When the file is put into the backup mode, the header is freezed and the checkpoint is done before putting the file into the backup mode. Makes sense as with the checkpointing , the related buffers for that file are put into the file , ensuring that the file now is a self consistent file.
There is no checkpoint that happens with the end backup though. The file is made in sync with the rest of the database files when the next full, system level checkopint will happen. All the changes required to make the file get in sync with the rest of the database is already logged in teh redo and archived files. So in the case of a crash, oracle just applies those to the respective file and the recovery is complete. So there won't be any impact on the recovery. Just there is one issue that there would be extra redo generation due to the first time logging of the whole data block in the redo stream to avoid the fractured block issue.
HTH
Aman.... -
Hi,
I have a hot backup taken every wednesday and archive log backups taken every day. (using RMAN and netbackup). Oracle is 10.2.0.3 and OS is RHEL4.
Do I still need or (will it be helpful to have ) incremental backups? What is its purpose? Will the recovery be faster if I have incremental backups? Please comment.
Thank you,i guess this is a good best practice found in Expert Oracle Database by Sam Alapati
"If you expect few changes in data, you are better off using incremental backups, since they
won’t consume a lot of space. Incremental backups, as part of your backup strategy, will reduce the
time required to apply redo during recovery. However, if most of your database blocks change frequently,
your incremental backups will be quite large. In such a case, you are better off making a
complete image copy of the database at regular intervals."
Edited by: doro on Aug 19, 2011 1:57 PM -
Question on recovery from Hot backup
Whenever I tried to recover from my hot backup using recover database untill cancel (or any other until option)..
I get messages similar to the following :
SQL> recover database using backup controlfile until cancel ;
ORA-00279: change 212733060 generated at 11/18/2008 23:50:58 needed for thread
1
ORA-00289: suggestion : /d01/oradata/devl/arc/1_282_667362770.dbf
ORA-00280: change 212733060 for thread 1 is in sequence #282
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/d01/oradata/devl/arc/1_282_667362770.dbf
ORA-00279: change 212733060 generated at needed for thread 2
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/d01/oradata/devl/arc/2_257_667362770.dbf
ORA-00279: change 212733060 generated at needed for thread 3
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/d01/oradata/devl/arc/3_258_667362770.dbf
ORA-00279: change 212733060 generated at needed for thread 4
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
I have all my archive files in the archive dest location.
Is there any way to prevent this warning messages and let oracle find all the archive files?
As you can see from the messages, Oracle is finding the correct file, then why there is an error message and why we have to provide the file names one-by one.
Please help !!!Oracle will look for needed archive logfile from your log archive destination.
If you are sure all these files are under /d01/oradata/devl/arc/, you can input AUTO, Oracle will work down the list until done. -
BRU incremental Backup Questions/Help
Hello Ladies and Gents,
I'm in desperate need of some help. I purchased Bru Le 1.3.0 about 2 weeks ago and going to use it for the clients Backup Strategy for over 2TB of data.
I used retrospect in the past but retro has been giving them major issues and has been unreliable; therefore the reason to switch to Bru.
Configuration: Xserve/XRAID backing up to Two sets of Lacie Drives 2x 1.8TB striped together = one single 3.6TB drive. One 3.6TB is daily and the Second is a weekly Off-site.
Let me preface this with the understanding that I'm not super savvy with Command-line....
The Goal is to Create incremental daily backup!
I started by creating a Full Backup compression level 1, now I'm trying to change that to an Incremental Backup - But when I try to select the base (which I thought would be the Full Backup I created) - I get an Error "Incorrect Base Definition" -- Which means I did this Wrong.
How do I Correctly create a proper Base Definition for an Incremental Backup?
Thanks
david
XServe - XRAID Mac OS X (10.4.10) Bru LE - 1.3.0
G5 Mac OS X (10.4.10)Have you run a backup of the datafiles already?
Looking the documentation it says the following:
When using these commands, there must already exist an image copy of every datafile specified in the command. If there are multiple copies of a datafile, the latest one is used. RMAN issues an error if image copies of every datafile in the database or tablespace do not exist.From what you're saying this looks like the case with your backups.
I suggest running a backup of the current datafiles, then running a backup copy and querying RMAN to check the copy exists.
RMAN> List backup;Documenation Link: http://download.oracle.com/docs/cd/B13789_01/server.101/b10734/rcmconc1.htm
Edited by: Kerri_Robberts on Aug 12, 2011 3:58 PM -
Consistent hot backup possible
Is a consistent hot backup possible?
I would like to perform hot backups while the database is in basically a read only state. I am currently using Oracle recommended backups via OEM, for example.
run {
allocate channel oem_disk_backup device type disk;
recover copy of database with tag 'ORA$OEM_LEVEL_0';
backup incremental level 1 cumulative copies=1 for recover of copy with tag 'ORA$OEM_LEVEL_0' database;
release channel oem_disk_backup;
allocate channel oem_sbt_backup1 type 'SBT_TAPE' format '%U';
backup recovery area;
Would executing the sql command "alter database begin backup;" before running the above RMAN script accomplish this task? Then off course when completed execute sql "alter database end backup;".
My basic concern is this type of RMAN hot backup usable in a disaster situation, i.e recreated on another server from tape backup.
I am open to any other ideas.
Thanks for your help in advance.
Ed - Wasilla, Alaska
Edited by: evankrevelen on Sep 11, 2008 10:18 PMThanks everyone who replied to this thread.
Just to clarify my complete backup strategy, there are two RMAN scripts run on daily and weekly basis. The daily does pickup the archivelogs. I had shown the weekly when first opening this thread. Here is the daily.
run {
allocate channel oem_disk_backup device type disk;
recover copy of database with tag 'ORA$OEM_LEVEL_0';
backup incremental level 1 cumulative copies=1 for recover of copy with tag 'ORA$OEM_LEVEL_0' database;
release channel oem_disk_backup;
allocate channel oem_sbt_backup1 type 'SBT_TAPE' format '%U';
backup archivelog all not backed up;
backup backupset all not backed up since time 'SYSDATE-1';
My question now is what RMAN does in the increments. It appears to be updating the original level 0 copies of datafiles with changed blocks only. Is the new copy of the datafile now a level 0 type file?
Here is a transcript from one of the daily backups.
Starting recover at 11-SEP-08
channel oem_disk_backup: starting incremental datafile backupset restore
channel oem_disk_backup: specifying datafile copies to recover
recovering datafile copy fno=00001 name=+DEVRVYG1/landesk/datafile/system.2576.616107783
recovering datafile copy fno=00002 name=+DEVRVYG1/landesk/datafile/undotbs1.2574.616107865
recovering datafile copy fno=00003 name=+DEVRVYG1/landesk/datafile/sysaux.2575.616107829
recovering datafile copy fno=00004 name=+DEVRVYG1/landesk/datafile/users.2572.616107871
recovering datafile copy fno=00005 name=+DEVRVYG1/landesk/datafile/landesk.2914.616107643
channel oem_disk_backup: reading from backup piece +DEVRVYG1/landesk/backupset/2008_09_10/nnndn1_tag20080910t220150_0.12330.665100189
channel oem_disk_backup: restored backup piece 1
piece handle=+DEVRVYG1/landesk/backupset/2008_09_10/nnndn1_tag20080910t220150_0.12330.665100189 tag=TAG20080910T220150
channel oem_disk_backup: restore complete, elapsed time: 00:05:16
Finished recover at 11-SEP-08
Starting backup at 11-SEP-08
channel oem_disk_backup: starting incremental level 1 datafile backupset
channel oem_disk_backup: specifying datafile(s) in backupset
input datafile fno=00005 name=+DEVG1/landesk/datafile/landesk.374.614072207
input datafile fno=00003 name=+DEVG1/landesk/datafile/sysaux.384.614002027
input datafile fno=00001 name=+DEVG1/landesk/datafile/system.383.614002025
input datafile fno=00002 name=+DEVG1/landesk/datafile/undotbs1.385.614002027
input datafile fno=00004 name=+DEVG1/landesk/datafile/users.386.614002027
channel oem_disk_backup: starting piece 1 at 11-SEP-08
channel oem_disk_backup: finished piece 1 at 11-SEP-08
piece handle=+DEVRVYG1/landesk/backupset/2008_09_11/nnndn1_tag20080911t220708_0.12999.665186835 tag=TAG20080911T220708 comment=NONE
channel oem_disk_backup: backup set complete, elapsed time: 00:02:26
channel oem_disk_backup: starting incremental level 1 datafile backupset
channel oem_disk_backup: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel oem_disk_backup: starting piece 1 at 11-SEP-08
channel oem_disk_backup: finished piece 1 at 11-SEP-08
piece handle=+DEVRVYG1/landesk/backupset/2008_09_11/ncsnn1_tag20080911t220708_0.2301.665186983 tag=TAG20080911T220708 comment=NONE
channel oem_disk_backup: backup set complete, elapsed time: 00:00:21
Finished backup at 11-SEP-08
It appears to be updating the previous copy with updated blocks thus rolling forward the datafile copy to a new level 0 copy.
Then to restore from the backup RMAN would first use this new copy of the datafile and then apply any archivelogs to them to bring the database to the point in time the incremental backup was taken.
Are these assumptions true?
Thanks for your help,
ED -
Hot backup : Rman vs. ALTER TABLESPACE...BEGIN BACKUP
Dear Experts,
I'm currently using the following statements
- ALTER TABLESPACE (...) BEGIN BACKUP
- host ocopy (...)
- ALTER TABLESPACE (...)END BACKUP state
I'm going for rman now but I've got 2 questions for those who did that in the past:
1/ Will rman reduce the size of my hotbackup ?
2/ Does the hot backup run faster using rman ?
Thanks.
Best Regards,
Jerome1/ Will rman reduce the size of my hotbackup ? rman backup only those blocks which get accessed by oracle, means it doesn't copy the empty blocks as a part of backup as your OS copy command does. So yeah, the size of the backup will be smaller if there are huge datafiles but with comparably less data. Moreover if you are on 10g then you can use compressed backupset feature which will compress the backupsets.
2/ Does the hot backup run faster using rman ?
By using rman, there is no need to put every tablespace in backup mode, you can run the backup in parallel by allocating multiple channels, on 10g you can use block change tracking feature to speed up your incremental backups AND as explained in point 1 there is no need to copy the whole datafile. These all are the benefits of RMAN and I can't make a state statement that by all this the backup will run faster but will definitely go for it.
Daljit Singh -
Dear all,
I want to take a full hot backup every week on sunday and the followings are the commands.
run
allocate channel ch1 type disk format '/db/BACKUP/RMAN/backup_%d_%t_%s_%p_%U.bck';
backup
incremental level 0
database
plus archivelog delete input;
backup current controlfile;
backup spfile;
release channel ch1;
I have the following questions:
1) Am I need to define a directory named as "'/db/BACKUP/RMAN/backup_%d_%t_%s_%p_%U.bck", so that the backup copies will put it here,right?
2) What format needs to be save in where and how to run it on weekly schedule basis?
3) I saw above script with "channel ch1", can I change it to "channel ch2"?
I am a beginner using RMAN, please let me know.
Best Regards,
amyWhich database version on which OS (looks like Unix/Linux)?
You have to create the directory '/db/BACKUP/RMAN', 'backup_%d...' is the filename created by RMAN.
%d Specifies the name of the database;
%t Specifies the backup set time stamp, which is a 4-byte value derived as the number of seconds elapsed since a fixed reference time. The combination of %s and %t can be used to form a unique name for the backup set;
%s Specifies the backup set number. This number is a counter in the control file that is incremented for each backup set. The counter value starts at 1 and is unique for the lifetime of the control file. If you restore a backup control file, then duplicate values can result. Also, CREATE CONTROLFILE initializes the counter back to 1;
%p Specifies the piece number within the backup set. This value starts at 1 for each backup set and is incremented by 1 as each backup piece is created;
%U Specifies a system-generated unique filename (default).
For scheduling a cron job could be defined or you use Enterprise Manager (10g and higher)
Channel name doesn't matter.
Werner -
Frequency of Hot backups using RMAN
Hello.
After years of running various inhouse utilities to backup our Oracle databases we are now going to implement RMAN in our shop. We are running Oracle 10.2.0.4 EE databases on Solaris servers in Archivelog mode, so we'd like to perform "hot" backups. A caveat to this is that we also have "standby" databases that we manually manage via a series of scripts that works rather well and helps our CIO sleep at night.
So what we're trying to do is tackle one obstacle at a time. We'd like to implement RMAN hot backups (including archivelogs) without having RMAN remove the archivelog backups that are out there. We simply want RMAN to backup the archivelog files, we'll manage their movement and removal ourselves for the time being.
The script I have put together simply issues: Backup database plus archivelog format='/dumps/rman/F_Database_%d_set%s_%T_%U';
The configuration settngs (we want at least a 2 day recovery period) are:
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/dumps/rman/controlfiles/%F';
CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO BACKUPSET;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/dumps/rman/W_Database_%d_set%s_%T_%U';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/xora01/app/oracle/product/10g/dbs/snapcf_glprd.f'; # default
We are using an RMAN catalog.
So my question is, if I perform the backup of the database (using the above command) once or twice a week and back-up only the archivelogs on a daily basis, would I be covered and save space at the same time? I think this might cover me as far as the archivelogs are concerned as well until my management is more comfortable with RMAN and allows us to install/use Data Guard.
Thanks for you opinions/suggestions...Hi,
So my question is, if I perform the backup of the database (using the above command) once or twice a week and back-up only the archivelogs on a daily basis, would I be covered and save space at the same time? I think this might cover me as far as the archivelogs are concerned as well until my management is more comfortable with RMAN and allows us to install/use Data Guard.Your idea also not bad to save disk space. it is also depends on database size and space availability on your server.
or else you can go for weekly once fulll backup, remaining days incremental backups & archivelog backups.
rman incremental backups take only chanegd blocks so it wont occupy much space
1) sunday - full backup - level 0
2) monday - inc1 & arch
3) tuesday - inc2 & arch
4) wednesday - inc1 & arch
5) thursday - inc2 & arch
6) friday - inc1 & arch
7) saturday - inc2 & arch... & so on...
Thanks -
How to find out which archived logs needed to recover a hot backup?
I'm using Oracle 11gR2 (11.2.0.1.0).
I have backed up a database when it is online using the following backup script through RMAN
connect target /
run {
allocate channel d1 type disk;
backup
incremental level=0 cumulative
filesperset 4
format '/san/u01/app/backup/DB_%d_%T_%u_%c.rman'
database
}The backup set contains the backup of datafiles and control file. I have copied all the backup pieces to another server where I will restore/recover the database but I don't know which archived logs are needed in order to restore/recover the database to a consistent state.
I have not deleted any archived log.
How can I find out which archived logs are needed to recover the hot backup to a consistent state? Can this be done by querying V$BACKUP_DATAFILE and V$ARCHIVED_LOG? If yes, which columns should I query?
Thanks for any help.A few ways :
1a. Get the timestamps when the BACKUP ... DATABASE began and ended.
1b. Review the alert.log of the database that was backed up.
1c. From the alert.log identify the first Archivelog that was generated after the begin of the BACKUP ... DATABASE and the first Archivelog that was generated after the end of the BACKUP .. DATABASE.
1d. These (from 1c) are the minimal Archivelogs that you need to RECOVER with. You can choose to apply additional Archivelogs that were generated at the source database to contininue to "roll-forward"
2a. Do a RESTORE DATABASE alone.
2b. Query V$DATAFILE on the restored database for the lowest CHECKPOINT_CHANGE# and CHECKPOINT_TIME. Also query for the highest CHECKPOINT_CHANGE# and CHECKPOINT_TIME.
2c. Go back to the source database and query V$ARCHIVED_LOG (FIRST_CHANGE#) to identify the first Archivelog that has a higher SCN (FIRST_CHANGE#) than the lowest CHECKPOINT_CHANGE# from 2b above. Also query for the first Archivelog that has a higher SCN (FIRST_CHANGE#) than the highest CHECKPOINT_CHANGE# from 2b above.
2d. These (from 2c) are the minimal Archivelogs that you need to RECOVER with.
(why do you need to query V$ARCHIVED_LOG at the source ? If RESTORE a controlfile backup that was generated after the first Archivelog switch after the end of the BACKUP ... DATABASE, you would be able to query V$ARCHIVED_LOG at the restored database as well. That is why it is important to force an archivelog (log switch) after a BACKUP ... DATABASE and then backup the controlfile after this -- i.e. last. That way, the controlfile that you have restored to the new server has all the information needed).
3. RESTORE DATABASE PREVIEW in RMAN if you have the archivelogs and subsequent controlfile in the backup itself !
Hemant K Chitale -
Incrementally updated backup and EMC NMDA
Hello Everyone,
I'm kind of a newbie in setting up networker module for oracle, to backup database to tape. We use the oracle's suggested backup strategy to backup DB to Disk first using the incrementally updated backups with recovery set to 3 days (RECOVER COPY OF DATABASE WITH TAG ... UNTIL TIME 'SYSDATE-3') , which helps us to recover DB to any point in time using the backup files in disks vs. going to tape. After backup to disk, we backup recovery area to tape nightly. However, we do want to maintain backup Retention Policy of 1 month. Couple of questions,
1. If i set RP to recovery window of 31 days in RMAN, then backups don't obsolete at all. this forces me to set RP in networker and they don't recommend setting RP in both RMAN and networker. how is this done generally to obsolete backups from tape as well as rman (catalog in CF) with above strategy. perhaps in this case i should set RP in netwoker and set RP in RMAN to none and rely on crosscheck and delete expired commands to sync with RNAM catalog.
2. Wondering if nightly backup of recovery area to tape is going to take incremental from previous day and NOT full backup. The reason i ask is, i do not want the tape to do full backup of FRA every day cause full backup datafiles change once in 3 days based on the until time set. is there an option do set in networker to do incremental only or that's the default.
Thanks in Advance!
11gR2, 4 Node RAC, Linux, NMDA 1.1, Networker 7.6 sp1Loic wrote:
You do a full backup of the FRA on tape ?No, I do a full backup of the database on tape. Using RMAN together with Veritas NetBackup.
I mean if you use incremental updated backup it'll not work on tape... Because the level 0 backup that will be updated with the backup of the day after will be on tape and will not be updated.The incrementally updated backup is in the FRA only, on disk (both the image copy and the following backup sets that are used for recovery of the image copy). Never gets written to tape or updated on tape.
Why don't you use then normal incremental backup ? That will have no problem with the tape backup even if level0, or level1,2 becomes reclaimable... ?I think I do :-)
Maybe:
To keep that you can put the redundancy to 2 out of 1 copy. Like this even with one copy on disk and tape it'll say keep the 2 copies.
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;I'll think about that. -
When to use REUSE/SET, NO-ARCHIVELOGS in create controlfile in HOT BACKUP?
I am a trainee Oracle DBA and have the following queries. Kindly reply with detailed explanation as I want to get my concepts cleared!
Q1>> While doing a user managed hot backup, when we are creating a control file(CREATE CONTROLFILE) from trace for recovery when do we use the create control file with the following options:
*1. REUSE / SET*
*2. ARCHIVELOGS / NOARCHIVELOGS*
Q2>> In what scenarios do we re-create the control file while recovering datafiles from a hot backup??
Thanks a tonne!
Regards,
BhaviHemant K Chitale wrote:
1.1 It is not "REUSE/SET". These are two very different clauses.
REUSE is when you want the CREATE to overwrite the existing controlfile(s). If the controlfile(s) {as named in the instance parameter file, initSID.ora or spfileSID.ora} is/are already present, the CREATE fails unless REUSE is specified.
SET is when you want to change the database name. Oracle then creates the controlfile(s) with the specified database name and updates the headers of all the datafiles. If you run a CREATE with a database name that is different from that in the datafile headers, the CREATE fails unless you include a SET to specify that the name must be changed. Note that this also means that the name in the instance parameter file must already have been updated.
1.2 ARCHIVELOG/NOARCHIVELOG is to set the database state. The same is achieved by issuing an "ALTER DATABASE ARCHIVELOG/NOARCHIVELOG" when the database is MOUNTed but not OPEN.
2. You'd run the CREATE CONTROLFILE if you do not have a binary backup of the controlfile.
Optionally, you can also use CREATE CONTROLFILE to rename all the datafiles by specifying the new locations of the datafiles -- the datafiles must already be present in the new locations, else the CREATE fails if it doesn't find a datafile that is included in the list of datafiles included in the CREATE statement.
RMAN is the correct way to run Backups. User Managed Backup scripts are used in cases like Storage-based Snapshots / SnapClones / BCV.
Hemant K ChitaleThanks that was really helpful..One last question when to use the resetlogs/noresetlogs clause in the create controlfile statement. I have noticed that at times it accepts resetlog while at times it accepts noresetlogs -
Using Data Guard and hot backups - 9.2.0.6.0
Hi all,
I have an existing 9.2.0.6.0 database that is setup in a DataGuard environment - one primary database with a physical standby in a separate datacenter. It is all setup and it works beautifully. On our primary database, we currently have 2 different types of backups we are doing - we do an export of the main schema (all of the application data is all in this one schema) 4 times a day, and we do a full database hot backup once a night.
My question is in regards to the hot backup - I don't know that it is even worth doing a hot backup of this database? I am trying to think of a situation where we would actually want to restore a hot backup of the primary database... If we ran into some kind of a data issue, it would probably be quickest and easiest to restore data from one of the exports, and when we did that restore (import), I assume that data change would be replicated through DataGuard to the standby site. But if there was some kind of situation where we wanted to restore a recent hot backup of the primary database, that would essentially break the Data Guard configuration, and I assume that after the hot backup was restored, we would have to somehow re-instantiate Data Guard on the standby site.
Does anyone have any input on this? If you are running with DataGuard, is it even worth it to be doing hot backups? What kind of situation would call for restoring a hot backup, instead of just failing over to the standby?
Thanks!
--BradIf we ran into some kind of a data issue, it would probably be quickest and easiest to restore data from one of the exportsIt would be quickest to failover to stand by database than restroing from dump file. After all you maintaing stand by db for that reason.
How can you restore database up to the latest changes using export/import ? You may have to restore using rman and apply the logs.
You can backup from stand by database. You do not need to back up primary.
Maybe you are looking for
-
IPad Air WiFi (5GHz) issues after iOS 8 upgrade
Same problem with my ipad air with ios 8.02, lost connectivity with 5Ghz band. It works for about 5 seconds, then hangs in Safari, email, etc. When I connect to 2.4 ghz band, it all works fine. Please fix this. Thank you.
-
Change After Effects Default Settings?
Hello Smarties! My output settings from the render que are generally very similar...and completely different from the default settings. Is there a way to CHANGE the default setting permanently? More detail is avaialble if you need it.
-
Looking up Managed ConnectionFactory by JNDI Resource-Ref
Thank you in advance for your help... I'm writing an Enterprise Java Bean using WebLogic Workshop that needs to access a connection factory defined in a deployed Resource Adapter. I'm trying to access the server managed connection factory through the
-
Other than the GPS chip in ipad 2 wifi+3g...
Are there anything else the 3G version has that a regular wifi only doesn't have? I am still having a tough time deciding which one to get tomorrow. I already have a data plan on my iphone 4, but it would be nice to have the option to add a data plan
-
Uploading a Keynote file using iTunes 11.1.12
I'm using iTunes 11.1.12 for a PC and I need to upload a keynote file. In iTunes I don't see a place to upload or file share. This feature existed in the last version. Can anyone help?