Results 1 to 10 of 10

Thread: Udb8.1 Fp4

  1. #1
    Join Date
    Jun 2003
    Posts
    24

    Unanswered: Udb8.1 Fp4

    Hi,

    Is it mandatory to compile the source code again if a new UDB patch has been applied to the system.
    Currently, we are on UDB8.1 FP1 , now we are planning tp upgrade to UDB8.1 FP4. Do I need to compile all the source
    code (to create obj and bind file) or running the old bind file against the database UDB8.1 FP4 will do thetrick for me?

    Basis question is : Why do we have to build/compile the system if a new patch is introduced by IBM?

  2. #2
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    You should issue the rebind command for all packages. In many cases it may not hurt if you don't rebind, but in some cases it will cause problems. This should be explained in the installation instructions. You do not need to recompile the programs.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  3. #3
    Join Date
    Jun 2003
    Posts
    24
    Thanks, could you also explain the differnce b/w rebind command and bind command. What exactly does rebind does.
    Additionally, can we run rebind when there is a version Upgrade. I mean if IBM moves from UDB8.0 to a higher version say UDB9.0?

  4. #4
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    DB2 stores the source bind file from the original bind for use with a rebind. A rebind keeps the same bind options used in the previous bind.

    There are two types of rebind:

    1. Explicit - This is where you issue the rebind command on a package.

    2. Automatic - This is done by DB2 automatically. When an object (table, index, etc.) is dropped that is used in a package, DB2 marks all the packages (or cached dynamic SQL statements) that use that object as "invalid." The first time an invalid package is executed, DB2 will attempt an automatic rebind. If the automatic rebind fails, the package is marked as "inoperative" and no more automatic rebinds will be attempted by DB2. This allows you to drop and recreate a table, and the package will still work when it is executed. If an index is dropped, DB2 will calculate a new access path (during the automatic rebind) without using the dropped index (unless it is recreated).

    Yes, you can usually do a rebind when migrating to a new version. But check the installation instructions, because what has been true in the past, may not always be true in the future.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  5. #5
    Join Date
    Jun 2003
    Posts
    24
    I am still unclear on the exact difference and usage of Bind and Rebind utilty.

  6. #6
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650
    BIND :

    Uses a bind file to create a new package or replace an existing one .. The bind file is generally created by precompiling source code (like C, COBOL etc) or CREATE PROCEDURE (which behind the screens creates a C program) statement.

    REBIND:

    Does not require a bind file ... The SQL statement and other information in the bind file are already stord in the catalog tables by a bind statement ... Rebind uses this information and then generates a new access plan with the latest statistics available ...

    Now read Marcus post ..

    If you are still not clear, please ask



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

  7. #7
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    Any time the program source code changes, you must do a precompile, compile, and bind. A bind add is for a package that did not exist before. A bind replace is for binding a package that was previously bound before. Both of these are binds (not a rebind).

    But if you only want to have DB2 choose a new access path (and the program has not changed), then you can do a rebind which uses the previous bind file that DB2 stored internally when you did the original bind. DB2 also stored the bind options from the previous bind and uses them for the rebind.

    When you install a fixpak or new release, the DB2 supplied utility programs may have changed. Therefore you must rebind the packages associated with those programs as described in the installation instructions.

    For user written applications, you usually don't have to rebind them after a fixpak, but it is often desirable since the optimizer may have been improved to choose a better access path. But this is not mandatory in most cases. The installation instructions for a particular fixpak or release will tell you if must rebind the packages for user applications.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  8. #8
    Join Date
    Jun 2003
    Posts
    24
    One more question, how and where can I see the access plan chosen by DB2 for a paricular package.

  9. #9
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    Check out the SQL explain tools in the "Administration Guide: Performance."
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  10. #10
    Join Date
    Jun 2003
    Posts
    24
    Thanks a lot.

Posting Permissions

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