Results 1 to 10 of 10
  1. #1
    Join Date
    Mar 2004
    Location
    Finland
    Posts
    22

    Unanswered: Package problem after restoring 8.2 db to 9.7

    I have recently moved a 8.2 database (linux) to 9.7 environment using restore from backup. All seems to have went well and database seems to be functioning ok.

    However when trying to connect to this 9.7 database with IBM Warehouse Manager 8.2 and import table definitions it always fails. The same feature works well with every 9.7 database created originally in 9.7 environment as well as the original 8.2 database before move to 9.7 environment.

    I have tried running 9.7 binds to this database, I have done db2rbind -l all and even run all the binds from 8.2 to a new 9.7 database... nothing seems to affect the problem.

    Anyone have ideas what might be the cause of this? What could I try? It seems clear that the problem somehow relates to the way this database was created (from 8.2 backup) since I don't have the same problem with any directly to 9.7 created database.

  2. #2
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650
    it always fails
    any DB2 specific error message ?

    If the error message is not useful, raise a PMR


    =
    Visit the new-look IDUG Website , register to gain access to the excellent content.

  3. #3
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    Quote Originally Posted by mitait View Post
    Anyone have ideas what might be the cause of this? What could I try? It seems clear that the problem somehow relates to the way this database was created (from 8.2 backup) since I don't have the same problem with any directly to 9.7 created database.
    Compare the db and dbm configs for the 9.7 database created with a 8.2 backup, and a database directly created in 9.7.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  4. #4
    Join Date
    Mar 2004
    Location
    Finland
    Posts
    22
    Quote Originally Posted by sathyaram_s View Post
    any DB2 specific error message ?

    DWC07356E An agent's processing of a command of type
    "importColumnsInformation" failed for edition "0" of step "?".
    RC = 7356 RC2 = 8615

    ..did not help me, but don't know if it tells something to someone. As you know db2 8.2 is out of support so, no sense raising a pmr.

  5. #5
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    Does the problem happens for a particular table, or for any table? If it is a specific table, what's the table definition?

  6. #6
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    It would be a good idea to recreate all UDF's and SP's using db2look output.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  7. #7
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650
    Is it possible to generate a trace ?

    developerWorks : Information Management : IBM DB2 for Linux, Unix, and Windows Forum : DWC07356E Agent error: ...

    A discussion from a few years back on the forums : http://www.dbforums.com/db2/1161734-...ss-tables.html
    See it this provides any leads.
    Visit the new-look IDUG Website , register to gain access to the excellent content.

  8. #8
    Join Date
    Mar 2004
    Location
    Finland
    Posts
    22
    Quote Originally Posted by n_i View Post
    Does the problem happens for a particular table, or for any table? If it is a specific table, what's the table definition?
    It does happen for every table.

    Quote Originally Posted by Marcus_A View Post
    It would be a good idea to recreate all UDF's and SP's using db2look output.
    I'm afraid I'm not familiar with UDF's and SP's, what are they and how to recreate them?

    Looking into db and dbm configurations I did not find anything that would have explained / helped with the problem.

    Same with the old link, it did not give me any new ideas or did not seem like a same case exactly. I will look into running a trace..

  9. #9
    Join Date
    Mar 2004
    Location
    Finland
    Posts
    22
    [QUOTE=sathyaram_s;6547923]Is it possible to generate a trace ?

    I am not too familiar with doing traces, but I did put up a CLI-trace on the DB2 8.2 machine. Not sure if this was the optimal kind of trace to run or weather it should be on 8.2 machine trying to connect the 9.7 machine or other way around. If some other kind of trave is more helpfull then please let me know. This trace now however gave me tons of data from where I found this :

    [1335175293.742884 - 23.04.2012 13.01.33.742884] SQLColumnsW( hStmt=1:1, szTableQualifier=<NULL pointer>, cbTableQualifier=0, szTableOwner="CRM", cbTableOwner=-3, szTableName="PALAUTEPOSTI", cbTableName=-3, szColumnName=<NULL pointer>, cbColumnName=0 )
    [1335175293.821640 - 23.04.2012 13.01.33.821640] ---> Time elapsed - +6,530000E-004 seconds
    [1335175293.822537 - 23.04.2012 13.01.33.822537] ( StmtOut="CALL SYSIBM.SQLCOLUMNS(?,?,?,?,?)" )
    [1335175293.859107 - 23.04.2012 13.01.33.859107]
    [1335175293.859817 - 23.04.2012 13.01.33.859817] ( Package="SYSSH100 ", Section=4 )
    [1335175293.861069 - 23.04.2012 13.01.33.861069]
    [1335175293.893675 - 23.04.2012 13.01.33.893675] ( Row=1, iPar=1, fCType=SQL_C_CHAR, rgbValue=<NULL pointer>, pcbValue=-1, piIndicatorPtr=-1 )
    [1335175293.926368 - 23.04.2012 13.01.33.926368]
    [1335175293.926797 - 23.04.2012 13.01.33.926797] ( Row=1, iPar=2, fCType=SQL_C_CHAR, rgbValue="CRM" - x'43524D', pcbValue=3, piIndicatorPtr=3 )
    [1335175293.988163 - 23.04.2012 13.01.33.988163]
    [1335175294.055480 - 23.04.2012 13.01.34.055480] ( Row=1, iPar=3, fCType=SQL_C_CHAR, rgbValue="PALAUTEPOSTI" - x'50414C41555445504F535449', pcbValue=12, piIndicatorPtr=12 )
    [1335175294.086413 - 23.04.2012 13.01.34.086413]
    [1335175294.087176 - 23.04.2012 13.01.34.087176] ( Row=1, iPar=4, fCType=SQL_C_CHAR, rgbValue=<NULL pointer>, pcbValue=-1, piIndicatorPtr=-1 )
    [1335175294.155413 - 23.04.2012 13.01.34.155413]
    [1335175294.157110 - 23.04.2012 13.01.34.157110] ( Row=1, iPar=5, fCType=SQL_C_CHAR, rgbValue="DATATYPE='ODBC';UNICODE=1;ODBCVER=2;GRAP HIC=0;REPORTUDTS=0;LUWUDT=1;DB2LUW=1;" - x'44415441545950453D274F444243273B554E49434F44453D 313B4F4442435645523D323B475241504849433D303B524550 4F5254554454533D303B4C55575544543D313B4442324C5557 3D313B', pcbValue=77, piIndicatorPtr=77 )
    [1335175294.232824 - 23.04.2012 13.01.34.232824]
    sqlccsend( Handle - 18787904 )
    sqlccsend( ulBytes - 582 )
    sqlccsend( ) rc - 0, time elasped - +6,100000E-005
    sqlccrecv( )
    sqlccrecv( ulBytes - 314 ) - rc - 0, time elapsed - +9,694400E-002
    Elapsed Server Processing Time - +2,810246E+012
    Elapsed Server Processing Time - +2,668101E+012
    Elapsed Server Processing Time - -4,796614E+012

    [1335175294.333806 - 23.04.2012 13.01.34.333806] SQLColumnsW( )
    [1335175294.334295 - 23.04.2012 13.01.34.334295] <--- SQL_ERROR Time elapsed - +5,914110E-001 seconds

  10. #10
    Join Date
    Mar 2004
    Location
    Finland
    Posts
    22
    Problem solved... and actually it was quite simple and something Marcus_A hinted on earlier. There was a difference in memory handling between database created from a backup and a newly created 9.7 database. After looking at db2diag.log I came to notice there was an error pointing to statement heap size. It was set to automatic on new databases but was only 2048 on old database, setting this to automatic resolved the problem.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •