Db2

 View Only

  • 1.  SQL Replication complaining about LOGRETAIN1

    Posted Thu April 11, 2024 05:00 PM

    Hi,

    Setting up SQL Replication between 2 database. Both are on DB2 v10.5.0.8. Both set up with (LOGARCHMETH1) = LOGRETAIN and yet when I try to Start Capture Program via Replication Center it is giving me this error.

    Database [Ljava.lang.String;@aa50d18a needs to be configured with LOGARCHMETH1=LOGRETAIN. Use the Enable Database for Replication window to set the LOGARCHMETH1 value.

    Also, not sure why it is changing source db name to "[Ljava.lang.String;@aa50d18a"

    Thank you
    Alex



    ------------------------------
    Alex Kogan
    ------------------------------


  • 2.  RE: SQL Replication complaining about LOGRETAIN1

    Posted Fri April 12, 2024 09:24 AM
    Did you use the "immediate" clause when updating the database config?
    if you connect to the database and run: db2 get db config for <dbname> show detail | grep LOGARCHMETH1
    You should see the setting in both columns, if not, then it hasn't been instantiated.
    I ran into a problem once, where the config update said it worked with the immediate clause, but, in the end I had to stop/start the database for it to be instantiated.


    Doug Kostelnik

    Data Design/Admin Associate

    Email: Douglas.Kostelnik.vafh6j@statefarm.com




    Original Message


  • 3.  RE: SQL Replication complaining about LOGRETAIN1

    Posted Mon April 15, 2024 09:02 AM

    Douglas

    Sorry if I was not clear in my post. Both source and target db's are set up with (LOGARCHMETH1) = LOGRETAIN

    They were set this way even before I started implementing replication. Yes I have confirmed it with "show detail" that it has been set.



    ------------------------------
    Alex Kogan
    ------------------------------

    Original Message


  • 4.  RE: SQL Replication complaining about LOGRETAIN1

    Posted Fri April 12, 2024 09:53 AM

    Hi Alex,

    As per SQL replication documentation the value of (LOGARCHMETH1) should be to any value other than OFF, so in your case it shoud work fine.

    In my environment we have set it to DISK:

    Can you make sure that the value is set already not pending yet, waiting for stopping and starting the database (db2 get db cfg show detail).

    Thanks ..

    Khalid



    ------------------------------
    Khalid Qrines
    ------------------------------

    Original Message


  • 5.  RE: SQL Replication complaining about LOGRETAIN1

    Posted Mon April 15, 2024 09:04 AM

    Khalid, 

    As I replied to Douglas. Yes, LOGARCH was already set up correctly. Thank you



    ------------------------------
    Alex Kogan
    ------------------------------

    Original Message


  • 6.  RE: SQL Replication complaining about LOGRETAIN1

    Posted Tue April 16, 2024 10:28 AM

    Consider posting the full capture log here (or the lines that get appended when capture tries to begin), or at least selected columns/rows that get added in asn.ibmsnp_captrace when capture tries to begin from the replication-centre.  If the database-name is mangled in the log file and ibmsnap_captrace then all bets are off as to the real cause.

    Secondly, suggest you manually start asncap, taking care to specify all the arguments correctly on the command-line, simply to compare the behaviour and results. By doing it that way, you are temporarily eliminating any differences that might be caused by the GUI using unintended startup arguments for capture, due to misconfiguration.



    ------------------------------
    Mike O'Reilly
    ------------------------------

    Original Message