Prune on HADR standby
in [DB2]
|
From: Kelly Rodger on 22 Feb 2010 09:50 Hi Ian, I actually think of the two flavours of the PRUNE command as distinct, independent commands. You're right about the PRUNE LOGFILE command. It is for pruning logs from the active log path, not the log archives. The earlier discussion in this thread was about the PRUNE HISTORY command, or at least that's what I was talking about. ;-) Kelly Rodger
From: Ian on 22 Feb 2010 11:17 On 2/22/10 7:50 AM, Kelly Rodger wrote: > Hi Ian, > > I actually think of the two flavours of the PRUNE command as distinct, > independent commands. You're right about the PRUNE LOGFILE command. > It is for pruning logs from the active log path, not the log > archives. The earlier discussion in this thread was about the PRUNE > HISTORY command, or at least that's what I was talking about. ;-) OK -- you were talking about log files in the earlier discussion, but I now take it to mean that the history file entries referring to those log files are getting pruned, not the actual log files themselves. This is unfortunate, though -- it would be a really nice enhancement if PRUNE LOGFILE could handle cleaning up log files that are archived by IBM-supplied logarchmeth[1|2] methods (DISK, TSM). Thanks for the clarification! Ian
From: Steve Pearson (news only) on 23 Feb 2010 12:21 Hi Ian. You might want to take a look at the "AND DELETE" option of the "PRUNE HISTORY" command: From http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.admin.cmd.doc/doc/r0001992.html: <quote> AND DELETE Specifies that the associated log archives will be physically deleted (based on the location information) when the history file entry is removed. This option is especially useful for ensuring that archive storage space is recovered when log archives are no longer needed. If you are archiving logs via a user exit program, the logs cannot be deleted using this option. If you set the auto_del_rec_obj database configuration parameter to ON, calling PRUNE HISTORY with the AND DELETE parameter will also physically delete backup images and load copy images if their history file entry is pruned. </quote> I believe that PRUNE LOGFILE was intended for use with "LOGRETAIN" and thus I can see why it would not do the deletion of archives, because in that configuration DB2 would not be aware of where, if anywhere, the user may have archived the log files. I would be interested to know if you are using PRUNE LOGFILE and if so to what end. Regards, - Steve P. --- Steve Pearson IBM DB2 UDB Development Portland, OR, USA
From: Norm on 21 Mar 2010 09:40
On Feb 23, 1:21 pm, "Steve Pearson (news only)" <stevep...(a)my- deja.com> wrote: > Hi Ian. > > You might want to take a look at the "AND DELETE" option of the "PRUNE > HISTORY" command: > > Fromhttp://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=... > > <quote> > AND DELETE > Specifies that the associated log archives will be physically deleted > (based on the location information) when the history file entry is > removed. This option is especially useful for ensuring that archive > storage space is recovered when log archives are no longer needed. If > you are archiving logs via a user exit program, the logs cannot be > deleted using this option. > If you set the auto_del_rec_obj database configuration parameter to > ON, calling PRUNE HISTORY with the AND DELETE parameter will also > physically delete backup images and load copy images if their history > file entry is pruned. > </quote> > > I believe that PRUNE LOGFILE was intended for use with "LOGRETAIN" and > thus I can see why it would not do the deletion of archives, because > in that configuration DB2 would not be aware of where, if anywhere, > the user may have archived the log files. > > I would be interested to know if you are using PRUNE LOGFILE and if so > to what end. > > Regards, > - Steve P. > --- > Steve Pearson > IBM DB2 UDB Development > Portland, OR, USA What is needed is a merged history files between the HADR pair of databases. This would allow auto_del_rec_obj to clean up backups and archive log files regardless of which instance was managing the database at the time. In situations where the backups and logs are accessible from both servers, it makes sense that the complete database history is available from both nodes. If successful backup events and archive log events were logged, the information could be shipped to the HADR partner, then the history file for the logical database would be complete across the pair. auto_del_rec_obj is only looked at when a backup is taken. If a HADR take-over event occurs, then the archive logs created by the alternate server may exist indefinitely if not enough backups are taken on the alternate server to qualify the num_backups and rec_hist_retn thresholds. Norm |