Apply Program Not Moving Data

[esmith2112]

Having a bear of a time trying to implement replication under 8.2
environment. I've created all of the control structures on both source
and target database and can actually see data being staged in the CD
tables. I look at the subscription sets and see that everything seems
to be pointing to the right tables, etc., and see that apply is
running. The apply log states that the program is running, but nothing
is moving. The only diagnostics that it has are the values of the
startup parameters and messages that is sleeping for 5 minutes. It's
running 8.2 FP9 under AIX 5.3.

I gave up on trying to replicate my real data, and created two simple
databases, with one table having only 1 column. Status of the
subscription set is 0. Both DBs are running under the same instance. I
used the Replication center to get everything kicked off, but was
unable to get apply to start from there and instead launched it from
the command line as: nohup asnapply CONTROL_SERVER=TRGT APPLY_QUAL=AAA
APPLY_PATH="/home/db2inst4" &

Have looked through the supplied documentation and the Redbook for
replication, but didn't find any clues. Hoping someone else here has
seen this before.

Evan
Apply log:

2005-08-03-07.51.41.054929 <setEnvDprRIB> ASN8003D "Apply" : "" :
"Initial" : Program "apply 8.2.0" is starting.
2005-08-03-07.51.43.126290 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "CONTROL_SERVER" was set to "TRGT"
at startup by the following method: "COMMANDLINE".
2005-08-03-07.51.43.126734 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "APPLY_QUAL" was set to "AAA" at s
tartup by the following method: "COMMANDLINE".
2005-08-03-07.51.43.126762 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "LOGREUSE" was set to "N" at start
up by the following method: "DEFAULT".
2005-08-03-07.51.43.126790 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "LOGSTDOUT" was set to "N" at star
tup by the following method: "DEFAULT".
2005-08-03-07.51.43.126817 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "TERM" was set to "Y" at startup b
y the following method: "DEFAULT".
2005-08-03-07.51.43.126844 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "PWDFILE" was set to "" at startup
by the following method: "DEFAULT".
2005-08-03-07.51.43.126870 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "APPLY_PATH" was set to "/home/db2
inst4/" at startup by the following method: "COMMANDLINE".
2005-08-03-07.51.43.126897 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "NOTIFY" was set to "N" at startup
by the following method: "DEFAULT".
2005-08-03-07.51.43.126923 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "SLEEP" was set to "Y" at startup
by the following method: "DEFAULT".
2005-08-03-07.51.43.126950 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "ERRWAIT" was set to "300" at star
tup by the following method: "DEFAULT".
2005-08-03-07.51.43.126976 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "COPYONCE" was set to "N" at start
up by the following method: "DEFAULT".
2005-08-03-07.51.43.127004 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "TRLREUSE" was set to "N" at start
up by the following method: "DEFAULT".
2005-08-03-07.51.43.127030 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "SPILLFILE" was set to "DISK" at s
tartup by the following method: "DEFAULT".
2005-08-03-07.51.43.127056 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "LOADXIT" was set to "N" at startu
p by the following method: "DEFAULT".
2005-08-03-07.51.43.127088 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "SQLERRCONTINUE" was set to "N" at
startup by the following method: "DEFAULT".
2005-08-03-07.51.43.127115 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "OPT4ONE" was set to "N" at startu
p by the following method: "DEFAULT".
2005-08-03-07.51.43.127141 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "DELAY" was set to "6" at startup
by the following method: "DEFAULT".
2005-08-03-07.51.43.127167 <asnParmClass::printParms> ASN0529I "Apply"
: "AAA" : "Initial" : The value of "INAMSG" was set to "Y" at startup
by the following method: "DEFAULT".
2005-08-03-07.51.43.166193 <Asnenv:setEnvIpcQRcvHdl> ASN0594I "Apply"
: "AAA" : "Initial" The program created an IPC queue with keys "(0x300
0004d)".
2005-08-03-07.51.43.167428 <CPCIMPC(08/07)> ASN1045I APPLY "AAA" :
"Initial". The Apply program was started using database "TRGT".
2005-08-03-07.51.43.190577 <CPREST(01/00)> ASN1044I APPLY "AAA" :
"WorkerThread". The Apply program will become inactive for "5" minutes
and
"0" seconds.

[esmith2112]

After running the asnanalyze command on the target database where apply
is running, it reported an "inconsistency between IBMSNAP_SUBS_MEMBER
and IBMSNAP_REGISTER tables." It found my subscription in the former,
but not the latter and had remarks of "Orphan Subscription."

There is no IBM_REGISTER in the target database, but there is one in
source database where capture is running. That table contains one row
for the table I want replicated, and another row that has blanks for
the SOURCE_OWNER and SOURCE_TABLE columns.

I couldn't find any reference in the docs or on the web for "orphan
subscriptions." Has anyone else seen this?

Thanks,
Evan

[Norbert Munkel]

Hi,

esmith2112 schrieb:

subscription set is 0. Both DBs are running under the same instance. I
used the Replication center to get everything kicked off, but was
unable to get apply to start from there and instead launched it from
the command line as: nohup asnapply CONTROL_SERVER=TRGT APPLY_QUAL=AAA
APPLY_PATH="/home/db2inst4" &

Have looked through the supplied documentation and the Redbook for
replication, but didn't find any clues. Hoping someone else here has
seen this before.

I remember having a lot of problems using replication center and went
for the manual approach as well. Have you created the asnpwd.aut file
and are the connections working?

check with

"asnanalyze -pw $pathtopasswordfile/asnpwd.aut -db $sourcedb $targetdb
-la DETAILED"

This produces a html-file you can view with any browser. The script
should run on both servers without any errors. If you have decided to
switch automatic full refreshes to off, search

http://www.ibm.com/support for "manual full refresh". There is a nice
article dated 2004-05-17, called

"How do I perform a manual full refresh for update-anywhere replication
instead of using the Apply program to do the full refresh?"

Works for user-copy scenarios as well.

Possibly you have decided to do manual full refreshs and did not set the
member-state to "L" or the appropriate synchtime, synchpoint in
ibmsnap_subs_set..just a guess

regards,

Norbert

[Norbert Munkel]

Hi,

esmith2112 schrieb:

After running the asnanalyze command on the target database where apply
is running, it reported an "inconsistency between IBMSNAP_SUBS_MEMBER
and IBMSNAP_REGISTER tables." It found my subscription in the former,
but not the latter and had remarks of "Orphan Subscription."

There is no IBM_REGISTER in the target database, but there is one in
source database where capture is running. That table contains one row
for the table I want replicated, and another row that has blanks for
the SOURCE_OWNER and SOURCE_TABLE columns.
There should be a corresponding row in ibmsnap_subs_membr in the target
database (or the database where the apply control tables resides). If it
is not, your replication setup is just incomplete.
I couldn't find any reference in the docs or on the web for "orphan
subscriptions." Has anyone else seen this?

Yes. Whenever corresponding entries in both capture control and apply
control tables do not match. The detailed asnanalyze output gives some
hints what needs to be where.

Hard to guess just by this few information.

regards,

Norbert

--
off for a Pint

[esmith2112]

I misspoke in an earlier post. I hadn't run the asnanalyze program with
both the source and target database options simultaneously. Once I did
that, the "orphan subscription" message went away.

I found the document on manually refreshing the data. I did that, but
it still leaves me with a bunch of rows in the CD tables that aren't
getting propagated.

Is there a definitive guide to DB2 replication published anywhere? I
found a book on Amazon, but since it was published in 1999, I have a
feeling that it's a little out of date. Even the Redbook for
replication in version 8 is approaching 3 years. Is it possible that
it's out of date as well?

Does this warrant a call to support? It doesn't seem like a technical
problem, but more of a logical problem where there's a step missing.