 |
|
| Computers Forum Index » Computer - Databases - IBM DB2 » logprune questions... |
|
Page 1 of 1 |
|
| Author |
Message |
| Bruce... |
 Posted: Tue Sep 29, 2009 12:32 pm |
|
|
|
Guest
|
Hi all -
prodhadr$ db2level
DB21085I Instance "db2inst1" uses "64" bits and DB2 code release
"SQL09014"
with level identifier "01050107".
Informational tokens are "DB2 v9.1.0.4", "s071028", "U811792", and Fix
Pack
"4".
Product is installed at "/opt/IBM/db2/V9.1".
AIX 6
I have 4 DB's on the main server in HADR peer. We copy and then do a
LOGPRUNE nightly on the 4 DB's. All's fine and it works well.
I notice however that the standby DB's are often not pruned to the
same LOG nbr as the primary and I'm curious as to why.
Isn't LOGPRUNE a logged-event in HADR?
Shouldn't I expect to see the same prune results on the HADR Standby
DB's as on the Primary DB's? Cause I am just not seeing it.
-B |
|
|
| Back to top |
|
|
|
| Frederik... |
| Posted: Tue Sep 29, 2009 2:09 pm |
|
|
|
Guest
|
On Sep 29, 2:32 pm, Bruce <bwmille... at (no spam) gmail.com> wrote:
Quote: Hi all -
prodhadr$ db2level
DB21085I Instance "db2inst1" uses "64" bits and DB2 code release
"SQL09014"
with level identifier "01050107".
Informational tokens are "DB2 v9.1.0.4", "s071028", "U811792", and Fix
Pack
"4".
Product is installed at "/opt/IBM/db2/V9.1".
AIX 6
I have 4 DB's on the main server in HADR peer. We copy and then do a
LOGPRUNE nightly on the 4 DB's. All's fine and it works well.
I notice however that the standby DB's are often not pruned to the
same LOG nbr as the primary and I'm curious as to why.
Isn't LOGPRUNE a logged-event in HADR?
Shouldn't I expect to see the same prune results on the HADR Standby
DB's as on the Primary DB's? Cause I am just not seeing it.
-B
Hey,
Maybe I'm overlooking something, but why do you prune on the standby?
Log archiving normally only happens on the primary.
Kind regards,
Frederik |
|
|
| Back to top |
|
|
|
| Steve Pearson (news only)... |
| Posted: Tue Sep 29, 2009 9:02 pm |
|
|
|
Guest
|
Nope, your eyes are not fooling you. The HADR standby manages its log
files somewhat independently from the primary. The primary tends to
recycle the greatest possible portion of LOGPRIMARY files into future
use log files (with higher-than-current sequences in the names); the
standby generally keeps fewer log files prepared in advance and thus
more of them have older-than-current names.
Btw, have you considered switching from LOGRETAIN to archival logging
(LOGARCHMETH*)?
Regards,
- Steve P.
--
Steve Pearson, DB2 for Linux, UNIX, and Windows, IBM Software Group
"Portland" Development Team, IBM Beaverton Lab, Beaverton, OR, USA |
|
|
| Back to top |
|
|
|
| Bruce... |
| Posted: Wed Sep 30, 2009 2:22 pm |
|
|
|
Guest
|
On Sep 29, 5:02 pm, "Steve Pearson (news only)" <stevep... at (no spam) my-
deja.com> wrote:
Quote: Nope, your eyes are not fooling you. The HADR standby manages its log
files somewhat independently from the primary. The primary tends to
recycle the greatest possible portion of LOGPRIMARY files into future
use log files (with higher-than-current sequences in the names); the
standby generally keeps fewer log files prepared in advance and thus
more of them have older-than-current names.
Btw, have you considered switching from LOGRETAIN to archival logging
(LOGARCHMETH*)?
Regards,
- Steve P.
--
Steve Pearson, DB2 for Linux, UNIX, and Windows, IBM Software Group
"Portland" Development Team, IBM Beaverton Lab, Beaverton, OR, USA
Hi Steve (long time no chat! I hope things are good with you and
yours)...
Thanks for the update re: logprune. Your explanation does help...I
was obviously expecting to see my standby HADR DB have the same LOG
files after the prune on the primary...so I see what's happening now.
I'll double-check why I'm on LOGRETAIN and definitely look into
LOGARCHMETH*...thanks.
-B |
|
|
| Back to top |
|
|
|
| cbielins at (no spam) gmail.com... |
| Posted: Mon Oct 19, 2009 8:45 pm |
|
|
|
Guest
|
On Sep 29, 3:02 pm, "Steve Pearson (news only)" <stevep... at (no spam) my-
deja.com> wrote:
Quote: Nope, your eyes are not fooling you. TheHADRstandby manages its log
files somewhat independently from the primary. The primary tends to
recycle the greatest possible portion of LOGPRIMARY files into future
use log files (with higher-than-current sequences in the names); the
standby generally keeps fewer log files prepared in advance and thus
more of them have older-than-current names.
Btw, have you considered switching from LOGRETAIN to archival logging
(LOGARCHMETH*)?
Regards,
- Steve P.
--
Steve Pearson, DB2 for Linux, UNIX, and Windows, IBM Software Group
"Portland" Development Team, IBM Beaverton Lab, Beaverton, OR, USA
So that mean, that you can write a script to delete those logfiles off
the standby with no issue?
I'm investigating this as we speak, and would like to know more about
what happens on the standby server if the primary is configured to
only retain one backup image (and with AUTO_DEL_REC_OBJ turned ON).
What happens if the STANDBY becomes the PRIMARY? Does that mean that
the AUTO_DEL_REC_OBJ would kick in deleting everything passed its
first full backup as well?
Chris |
|
|
| Back to top |
|
|
|
| cbielins at (no spam) gmail.com... |
| Posted: Mon Oct 19, 2009 8:45 pm |
|
|
|
Guest
|
On Sep 29, 3:02 pm, "Steve Pearson (news only)" <stevep... at (no spam) my-
deja.com> wrote:
Quote: Nope, your eyes are not fooling you. TheHADRstandby manages its log
files somewhat independently from the primary. The primary tends to
recycle the greatest possible portion of LOGPRIMARY files into future
use log files (with higher-than-current sequences in the names); the
standby generally keeps fewer log files prepared in advance and thus
more of them have older-than-current names.
Btw, have you considered switching from LOGRETAIN to archival logging
(LOGARCHMETH*)?
Regards,
- Steve P.
--
Steve Pearson, DB2 for Linux, UNIX, and Windows, IBM Software Group
"Portland" Development Team, IBM Beaverton Lab, Beaverton, OR, USA
So that mean, that you can write a script to delete those logfiles off
the standby with no issue?
I'm investigating this as we speak, and would like to know more about
what happens on the standby server if the primary is configured to
only retain one backup image (and with AUTO_DEL_REC_OBJ turned ON).
What happens if the STANDBY becomes the PRIMARY? Does that mean that
the AUTO_DEL_REC_OBJ would kick in deleting everything passed its
first full backup as well?
Chris |
|
|
| Back to top |
|
|
|
| Steve Pearson (news only)... |
| Posted: Tue Nov 10, 2009 9:43 pm |
|
|
|
Guest
|
Quote: So that mean, that you can write a script to delete those logfiles off
the standby with no issue?
Ideally you would not, because it is dangerous and removing the wrong
file can lead to Very Bad Things.
The standby should reuse them eventually. However, if you are pressed
for space, you could consider removing old log files from the
standby. The key would be to remove only those that would not be
needed for restart after a crash. I forget whether the standby
reports an accurate "first active log"; if so, you'd want to remove
only log files that are (a) prior to that, and (b) have already been
archived by the primary. Otherwise...if things go south, the standby
database could be locally unrecoverable, or worse (if primary also
failed). Since this is not a recommended user procedure, you may want
to do this with the counsel of your IBM service rep. if at all.
Quote: I'm investigating this as we speak, and would like to know more about
what happens on the standby server if the primary is configured to
only retain one backup image (and with AUTO_DEL_REC_OBJ turned ON).
What happens if the STANDBY becomes the PRIMARY? Does that mean that
the AUTO_DEL_REC_OBJ would kick in deleting everything passed its
first full backup as well?
After a standby takes over as primary, it will generally adhere to its
own configuration. Note that database configuration updates are not
logged and thus not replicated. HADR only takes special action for
LOGFILSZ. For that one, the standby must follow the primary's lead.
However, if the roles switch, the new primary/old standby will
eventually revert to its own configuration for LOGFILSZ if you haven't
made the same change to both copies of the database. (Eventually,
because config updates are not always dynamic, so may require the db
to be recycled before they take effect.)
Regards,
-Steve P. |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Wed Nov 25, 2009 10:28 am
|
|