Results 1 to 11 of 11
  1. #1
    Join Date
    Mar 2009
    Posts
    16

    Unanswered: SYSPROC.ADMIN_MOVE_TABLE giving error

    Hi,
    DB2 version : 9.7 WSE (Windows)


    I am trying to move a table to different tablespace using SYSPROC.ADMIN_MOVE_TABLE procedure but I am geting the following error.


    SQL0444N Routine "*VE_TABLE" (specific name "ADMIN_MOVE_TABLE1") is
    implemented with code in library or path "...ine\db2dbroutext", function
    "admin_move_table_nf1" which cannot be accessed. Reason code: "6".
    SQLSTATE=42724

    Can someone suggest what does this mean and what to do to resolve this issue?

    Thanks.

  2. #2
    Join Date
    Apr 2006
    Location
    Belgium
    Posts
    2,514
    Provided Answers: 11
    new installation ? migrated db ?
    have you tried db2updv97
    Best Regards, Guy Przytula
    Database Software Consultant
    Good DBAs are not formed in a week or a month. They are created little by little, day by day. Protracted and patient effort is needed to develop good DBAs.
    Spoon feeding : To treat (another) in a way that discourages independent thought or action, as by overindulgence.
    DB2 UDB LUW Certified V7-V8-V9-V9.7-V10.1-V10.5 DB Admin - Advanced DBA -Dprop..
    Information Server Datastage Certified
    http://www.infocura.be

  3. #3
    Join Date
    Jan 2009
    Location
    Zoetermeer, Holland
    Posts
    746
    FP3 is un-usable for this function. you need FP4 at least
    Somewhere between " too small" and " too large" lies the size that is just right.
    - Scott Hayes

  4. #4
    Join Date
    Aug 2008
    Location
    Toronto, Canada
    Posts
    2,367
    Quote Originally Posted by dr_te_z View Post
    FP3 is un-usable for this function. you need FP4 at least
    How did you determine dbBash is using FP3 and why you need at least FP4 for SYSPROC.ADMIN_MOVE_TABLE? I remember testing it with FP3 or even lower fixpacks.

  5. #5
    Join Date
    Mar 2009
    Posts
    16
    We are on FP4.

  6. #6
    Join Date
    Mar 2009
    Posts
    16
    We have restored a 9.5 image on 9.7 version. This probably is causing the issue.
    Because when I created a new database in 9.7, the procedure worked fine.

  7. #7
    Join Date
    Mar 2003
    Posts
    280
    Don't know the answer to your question, but the error message means:

    $ db2 "? SQL0444N"


    SQL0444N Routine "<routine-name>" (specific name "<specific-name>") is
    implemented with code in library or path "<library-or-path>",
    function "<function-code-id>" which cannot be accessed. Reason
    code: "<code>".

    Explanation:

    The database manager is trying to access the body of code that
    implements routine "<routine-name>" (specific name "<specific-name>"),
    and cannot access it for the reason given by reason code "<code>" (the
    codes are listed below). The file implementing the routine is identified
    by "<library-or-path>", and the function by "<function-code-id>".

    The library name, path name, or the function name might be truncated due
    can be used to get the complete library path and function names from the
    system catalog views:

    SELECT implementation
    FROM syscat.routines
    WHERE specificname = 'specific-name'

    [...]

    6
    The function "<function-code-id>" could not be found in the
    library that was named.

    [...]

    User response:

    Given for each reason code:

    [....]

    3, 6, and 7


    See the routine creator or your database administrator. Provide
    them with the full text of the appropriate reason code. The
    routine definition or the location of the routine library will
    need to be corrected.



    /Lennart

  8. #8
    Join Date
    Jan 2009
    Location
    Zoetermeer, Holland
    Posts
    746
    Quote Originally Posted by db2girl View Post
    How did you determine dbBash is using FP3
    Did not. I just mentioned that FP3 is not good when you want to use this function.
    Quote Originally Posted by db2girl View Post
    why you need at least FP4 for SYSPROC.ADMIN_MOVE_TABLE? I remember testing it with FP3 or even lower fixpacks.
    I remember a lot of errors which were not solved until we installed the higher fixpack. But I must admit: not the same errors as the topic starter.

    I am starting to doubt my own words now... I did have trouble with admin_move and it was fixed by the higher fixpack... but was it from 3 to 4 or was it from 4 to 5? Do not remember: it was only a few weeks apart and it was still all in test. I cannot check because I am no longer contracted by that client. We went into production with FP5 and the move_table function worked well there. I am sure of that
    Somewhere between " too small" and " too large" lies the size that is just right.
    - Scott Hayes

  9. #9
    Join Date
    Aug 2008
    Location
    Toronto, Canada
    Posts
    2,367
    Try what przytula_guy suggested. If I needed it to move a table(s) from one tablespace to another, I would do it manually and not use this procedure.

  10. #10
    Join Date
    Mar 2009
    Posts
    16
    I ran db2updv97 and db2iupdt commands also. Still the same issue.

    The database where the issue is coming has the following entries in the sysibm.sysversions.

    VERSIONNUMBER:
    9050500
    9070400
    -9070500

    The issue is with -9070500 . We have degraded our db from 9.7.5 to 9.7.4.

    Any idea how to update the db to 9070400 version.

    Thanks.

  11. #11
    Join Date
    Aug 2008
    Location
    Toronto, Canada
    Posts
    2,367
    I believe a negative value in sysibm.sysversions is not a problem. Did you execute db2updv97 after restoring from a v9.5 backup image and prior to installing FP5? Was this procedure working prior to backing out FP5? Any relevant errors logged in the db2diag.log?

Posting Permissions

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