Apply Program Not Moving Data

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • esmith2112

    Apply Program Not Moving Data

    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: "COMMANDLIN E".
    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: "COMMANDLIN E".
    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: "COMMANDLIN E".
    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:setEnvI pcQRcvHdl> 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" :
    "WorkerThre ad". The Apply program will become inactive for "5" minutes
    and
    "0" seconds.

  • esmith2112

    #2
    Re: Apply Program Not Moving Data

    After running the asnanalyze command on the target database where apply
    is running, it reported an "inconsiste ncy between IBMSNAP_SUBS_ME MBER
    and IBMSNAP_REGISTE R 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

    Comment

    • Norbert Munkel

      #3
      Re: Apply Program Not Moving Data

      Hi,

      esmith2112 schrieb:
      [color=blue]
      > 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.[/color]

      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 $pathtopassword file/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_se t..just a guess

      regards,

      Norbert

      Comment

      • Norbert Munkel

        #4
        Re: Apply Program Not Moving Data

        Hi,

        esmith2112 schrieb:[color=blue]
        > After running the asnanalyze command on the target database where apply
        > is running, it reported an "inconsiste ncy between IBMSNAP_SUBS_ME MBER
        > and IBMSNAP_REGISTE R 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.[/color]

        There should be a corresponding row in ibmsnap_subs_me mbr in the target
        database (or the database where the apply control tables resides). If it
        is not, your replication setup is just incomplete.
        [color=blue]
        > I couldn't find any reference in the docs or on the web for "orphan
        > subscriptions." Has anyone else seen this?[/color]

        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

        Comment

        • esmith2112

          #5
          Re: Apply Program Not Moving Data

          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.

          Comment

          Working...