STMM with Log shipping

[db2dude]

Hello,

We have a DR instance of our primary production database which is kept
in sync using log shipping and roll forward at the DR site. However,
our SLA permits us to run our production system under reduced capacity
in the event of a real DR. Having said that, we would ideally like to
reduce available memory at our DR site to half of what we have at our
primary (our primary database has 128 GB whereas we want to set our DR
instance to have 64 GB). Since we have STMM running on our primary
database, I wanted to confirm that this is indeed possible since STMM
does not log any memory related changes and so these changes would not
propagate over to the DR. Our database instance is on UDB 9.5 FP4 on
AIX 5.3 TL9 SP1.

Thanks,
SA

[Frederik Engelen]

It does for HADR, so this probably applies for you as well.

Perhaps you c

[Pierre StJ]

It's always been my understanding the db cfg on the dr system is
copied from the backup when initially created.
Afterwards, the changes on the db cfg are logged and they will replay
as you rollforward. The logs identify the true name of the db so they
can verify that they are rolling the proper db. (That's why you should
not change the true name. However, you could do the initial restore
with a new alias and then thereafter use the same alias to resore, as
in: db2 restore db <current name> as <newalias> ...... )
If you use HADR services of DB2 then it's a bit different as that
setup will only propagate one db cfg change and that's for the
parm:LOGFILSIZ. In HADR, that's the only one that propagates.
In your case, you start from a full db restore and propagate logs. As
you apply the shipped logs, that db is not in HADR mode so changes to
db cfg and buffer pools will propagate and be applied. You could stop
that by turning off STMM on the DR system and configure as you need.
Remeber that the db cfg is not replaced on the receiving system during
restore unless it has been damaged or is unaccessible.

But still, I can't see how the roll forward could ignore the changes
applied to the db cfg or other pools that are in the logs.

Regards, Pierre..

On Dec 8, 10:07 am, Frederik Engelen <engelenfrede...@gmail.com>
wrote:

> Perhaps you c- Hide quoted text -
>
> - Show quoted text -

[Steve Pearson (news only)]

Actually, db cfg changes are not logged, so neither HADR nor regular
old rollforward will keep up to date on them via replay. (HADR keeps
track of log file size changes by another means.) However, with
restore + rollforward, it is possible that the latest version of the
db config will be there in the end because it was not overwritten at
the time of restore.

Regards,
- Steve P.
--
Steve Pearson, DB2 for Linux, UNIX, and Windows, IBM Software Group
"Portland" Development Team, IBM Beaverton Lab, Beaverton, OR, USA