LOGRETAIN for SQL Replication
in [DB2]
|
From: Frederik Engelen on 22 Jun 2010 08:49 Hello, I was trying to use SQL Replication (free) to replicate a table on a DB2 9.5 (HADR primary) server. To my surprise, I would need to put LOGARCHMETH1 to LOGRETAIN. Can anyone explain me the need for this? I would like to keep log archiving to disk (as explained in the HADR Best Practices). Why can't the Capture program retrieve the logs from the archive location? This is a very simple use case, so the licensing costs for InfoSphere CDC (DataMirror) can't be justified. Thanks in advance, Frederik
From: Mark A on 22 Jun 2010 09:16 "Frederik Engelen" <engelenfrederik(a)gmail.com> wrote in message news:0ea9d878-f53e-4672-873f-931320f3445e(a)r27g2000yqb.googlegroups.com... > Hello, > > I was trying to use SQL Replication (free) to replicate a table on a > DB2 9.5 (HADR primary) server. To my surprise, I would need to put > LOGARCHMETH1 to LOGRETAIN. > > Can anyone explain me the need for this? I would like to keep log > archiving to disk (as explained in the HADR Best Practices). Why can't > the Capture program retrieve the logs from the archive location? > > This is a very simple use case, so the licensing costs for InfoSphere > CDC (DataMirror) can't be justified. > > Thanks in advance, > > Frederik Did you try LOGRETAIN ON (or YES since not sure which is correct), and then also keep LOGARCHMETH1 set to disk? Just guessing here.
From: Helmut Tessarek on 22 Jun 2010 13:21 Hi Frederik, > I was trying to use SQL Replication (free) to replicate a table on a > DB2 9.5 (HADR primary) server. To my surprise, I would need to put > LOGARCHMETH1 to LOGRETAIN. Since you are already using archival logging you don't have to do anything. > Can anyone explain me the need for this? I would like to keep log > archiving to disk (as explained in the HADR Best Practices). Why can't > the Capture program retrieve the logs from the archive location? Let's start at the beginning: DB2 has 2 logging modes: circular and archival. You have to use archival logging when you want to use online backups and rollforward recovery. You also have to use archival logging when other components are dependent on log files. (e.g. HADR, SQL replication, ...) In early days of DB2 there was no LOGARCHMETH1 parameter. Only LOGRETAIN was available. To turn on archival logging you set this parameter to ON or YES. That put the database in archival logging mode (after a full offline db backup). Later on an additional value was introduced: CAPTURE. For replication environments you could set LOGRETAIN to CAPTURE. Since DB2 9.5 the LOGRETAIN parameter is no longer used. Please ignore it. As soon as you set LOGARCHMETH1, the database is put in archival logging mode. You are in an HADR environment already, which means you are using archival logging. Therefore you are good to go for SQL replication w/o further changes. Well, you have to set up and configure the capture and apply components, but you don't have to change your LOGARCHMETH1 parameter. -- Helmut K. C. Tessarek DB2 Performance and Development /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
From: Frederik Engelen on 23 Jun 2010 05:00 On Jun 22, 7:21 pm, Helmut Tessarek <tessa...(a)evermeet.cx> wrote: > Hi Frederik, > > > I was trying to use SQL Replication (free) to replicate a table on a > > DB2 9.5 (HADR primary) server. To my surprise, I would need to put > > LOGARCHMETH1 to LOGRETAIN. > > Since you are already using archival logging you don't have to do anything. > > > Can anyone explain me the need for this? I would like to keep log > > archiving to disk (as explained in the HADR Best Practices). Why can't > > the Capture program retrieve the logs from the archive location? > > Let's start at the beginning: > > DB2 has 2 logging modes: circular and archival. > You have to use archival logging when you want to use online backups and > rollforward recovery. > You also have to use archival logging when other components are dependent on > log files. (e.g. HADR, SQL replication, ...) > > In early days of DB2 there was no LOGARCHMETH1 parameter. Only LOGRETAIN was > available. To turn on archival logging you set this parameter to ON or YES. > That put the database in archival logging mode (after a full offline db backup). > Later on an additional value was introduced: CAPTURE. For replication > environments you could set LOGRETAIN to CAPTURE. > > Since DB2 9.5 the LOGRETAIN parameter is no longer used. Please ignore it.. > > As soon as you set LOGARCHMETH1, the database is put in archival logging mode. > > You are in an HADR environment already, which means you are using archival > logging. Therefore you are good to go for SQL replication w/o further changes. > Well, you have to set up and configure the capture and apply components, but > you don't have to change your LOGARCHMETH1 parameter. > > -- > Helmut K. C. Tessarek > DB2 Performance and Development > > /* > Thou shalt not follow the NULL pointer for chaos and madness > await thee at its end. > */ Hello, I was confused by the Replication center and the documentation, where the use of LOGRETAIN is explicitely mentioned. I was under the impression that LOGARCHMETH1 was already enabled, but that was a slip- up on my side, so everything work fine now. Thanks for your answers, Mark and Helmut. Especially Helmut, you've been a great addition to this group recently, thanks. Kind regards, Frederik
|
Pages: 1 Prev: URGENT Help with STRIP on a Varchar(250) with TRANSLATE Next: Missing db2tcpcm process |