IBM Support

IZ28339: FCM_NUM_BUFFERS database manager configuration parameter incorrectly calculated during migration on AIX

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • The database manager configuration (dbm) file parameters are
    migrated during the instance migration process.  The
    fcm_num_buffers parameter value should be recalculated in data
    partitioning feature environments (DPF) according to:
    
    DB2_FORCE_FCM_BP registry variable setting
    DB2_NUM_FAILOVER_NODES registry variable setting
    Number of logical nodes on the machine
    
    Due to a programming error, if DB2_FORCE_FCM_BP=YES on DB2
    Version 8, the new calculated value is not as expected and the
    value for fcm_num_buffers may be too high for a DB2 Version 9.1
    environment on AIX.  The end result may lead to an unreasonable
    amount of memory being allocated to FCM buffers.
    
    If the DB2_FORCE_FCM_BP registry variable is not set or set
    explicitly to NO , the calculation will be done correctly.
    
    The allocation of FCM buffers has changed in DB2 Version 9.1 and
    later releases.
    
    In DB2 Version 8, FCM buffers were allocated based on the
    setting of the DB2_FORCE_FCM_BP registry variable.  If it was
    set to YES, then one pool of FCM buffers was created and shared
    between all of the logical partitions on a system; its size was
    determined by the database manager configuration parameter
    FCM_NUM_BUFFERS.  If it was set to NO, then a pool of FCM
    buffers was allocated in each logical partition on the system;
    the size of each of these was determined by FCM_NUM_BUFFERS.
    
    In DB2 Version 9.1 and later, one pool of FCM buffers is created
    and shared between all of the logical partitions on a system.
    The initial size of this pool is determined by the following
    formula:
    
    (number of logical partitions on the system +
    DB2_NUM_FAILOVER_NODES registry variable) * FCM_NUM_BUFFERS
    
    DB2_NUM_FAILOVER_NODES defaults to 2 if not set on a system.
    In addition to calculating the initial value for
    FCM_NUM_BUFFERS, the migration code sets the AUTOMATIC attribute
    for FCM_NUM_BUFFERS.  AUTOMATIC allows DB2 to adjust the number
    of FCM buffers up and down, starting from the initial value,
    based on the demand for buffers.
    
    During the migration from DB2 Version 8 to DB2 Version 9.1 the
    value of FCM_NUM_BUFFERS will be calculated incorrectly if the
    DB2_FORCE_FCM_BP registry variable is set to YES on DB2 Version
    8, and when the instance is started more FCM buffers will be
    allocated than were used on DB2 Version 8.  This over allocation
    of FCM buffers can be corrected by calculating what the value
    should be based on the DB2 Version 8 settings, and then updating
    the FCM_NUM_BUFFERS configuration parameter.
    

Local fix

  • If DB2_FORCE_FCM_BP is set to YES on DB2 Version 8, then to
    calculate the value of FCM_NUM_BUFFERS in DB2 Version 9.1, use
    the following formula:
    
    V91_FCM_NUM_BUFFERS =  V8_FCM_NUM_BUFFERS / (number of logical
    partitions on the system + DB2_NUM_FAILOVER_NODES)
    
    Where V8_FCM_NUM_BUFFERS is the value of the FCM_NUM_BUFFERS
    database manager configuration parameter in the Version 8
    instance, and the default value of the DB2_NUM_FAILOVER_NODES
    registry variable is 2.
    
    Use this calculated value to update the database manager
    configuration using the following command:
    UPDATE DBM CFG USING FCM_NUM_BUFFERS DB2_V91_FCM_NUM_BUFFERS
    AUTOMATIC
    where DB2_V91_FCM_NUM_BUFFERS is the value from the calculation
    above.
    
    For example, if FCM_NUM_BUFFERS was 65536 on DB2 Version 8, you
    had 8 logical partitions per system, and DB2_NUM_FAILOVER_NODES
    was not set on DB2 Version 8 so that it defaulted to 2, then the
    calculation is:
     V91_FCM_NUM_BUFFERS = 65536/(8+2) = 6554
    
    The command to update the database manager configuration is as
    follows:
     UPDATE DBM CFG USING FCM_NUM_BUFFERS 6554 AUTOMATIC
    
    Notes:
    
    1) If the number of logical partitions per system varies in your
    DFP environment, FCM_NUM_BUFFERS was most likely set to
    accommodate the largest number of logical partitions on a system
    in your environment.  Use the largest number of logical
    partitions in the above formula to calculate the initial value.
    
    2) InfoSphere Balanced Warehouse (BCU) customers migrating from
    DB2 Version 8 should calculate the value of FCM_NUM_BUFFERS
    manually based on their DB2 Version 8 configuration, and then
    update the value of FCM_NUM_BUFFERS in the database manager
    configuration following the migration of the instance to DB2
    Version 9.1.  In the calculation you should use the number of
    logical partitions on a data node in the formula; using the
    number of logical partitions on an administrative node will
    result in an FCM buffer pool on the data nodes of DB2 Version 9
    instance that is several times larger than on DB2 Version 8.
    
    3) To determine the initial value of FCM_NUM_BUFFERS, issue the
    following commands:
    db2 ATTACH TO <instance_name>
    db2 GET DBM CFG SHOW DETAIL
    A sample of the line in the output that pertains to
    FCM_NUM_BUFFERS follows:
    
    No. of int. communication buffers(4KB)(FCM_NUM_BUFFERS) =
    AUTOMATIC(6554)            AUTOMATIC(6554)
    
    The number in brackets following AUTOMATIC is the initial value.
    Without the SHOW DETAIL parameter, the initial value of
    FCM_NUM_BUFFERS is not displayed.
    

Problem summary

  • ERROR DESCRIPTION:
    The database manager configuration (dbm) file parameters are
    migrated during the instance migration process.  The
    fcm_num_buffers parameter value should be recalculated in data
    partitioning feature environments (DPF) according to:
    
    DB2_FORCE_FCM_BP registry variable setting
    DB2_NUM_FAILOVER_NODES registry variable setting
    Number of logical nodes on the machine
    
    Due to a programming error, if DB2_FORCE_FCM_BP=YES on DB2
    Version 8, the new calculated value is not as expected and the
    value for fcm_num_buffers may be too high for a DB2 Version 9.1
    environment on AIX.  The end result may lead to an unreasonable
    amount of memory being allocated to FCM buffers.
    
    If the DB2_FORCE_FCM_BP registry variable is not set or set
    explicitly to NO , the calculation will be done correctly.
    
    The allocation of FCM buffers has changed in DB2 Version 9.1 and
    later releases.
    
    In DB2 Version 8, FCM buffers were allocated based on the
    setting of the DB2_FORCE_FCM_BP registry variable.  If it was
    set to YES, then one pool of FCM buffers was created and shared
    between all of the logical partitions on a system; its size was
    determined by the database manager configuration parameter
    FCM_NUM_BUFFERS.  If it was set to NO, then a pool of FCM
    buffers was allocated in each logical partition on the system;
    the size of each of these was determined by FCM_NUM_BUFFERS.
    
    In DB2 Version 9.1 and later, one pool of FCM buffers is created
    and shared between all of the logical partitions on a system.
    The initial size of this pool is determined by the following
    formula:
    
    (number of logical partitions on the system +
    DB2_NUM_FAILOVER_NODES registry variable) * FCM_NUM_BUFFERS
    
    DB2_NUM_FAILOVER_NODES defaults to 2 if not set on a system.
    In addition to calculating the initial value for
    FCM_NUM_BUFFERS, the migration code sets the AUTOMATIC attribute
    for FCM_NUM_BUFFERS.  AUTOMATIC allows DB2 to adjust the number
    of FCM buffers up and down, starting from the initial value,
    based on the demand for buffers.
    
    During the migration from DB2 Version 8 to DB2 Version 9.1 the
    value of FCM_NUM_BUFFERS will be calculated incorrectly if the
    DB2_FORCE_FCM_BP registry variable is set to YES on DB2 Version
    8, and when the instance is started more FCM buffers will be
    allocated than were used on DB2 Version 8.  This over allocation
    of FCM buffers can be corrected by calculating what the value
    should be based on the DB2 Version 8 settings, and then updating
    the FCM_NUM_BUFFERS configuration parameter.
    

Problem conclusion

  • First Fixed in DB2 UDB Version v9.1 Fixpak 6
    

Temporary fix

  • If DB2_FORCE_FCM_BP is set to YES on DB2 Version 8, then to
    calculate the value of FCM_NUM_BUFFERS in DB2 Version 9.1, use
    the following formula:
    
    V91_FCM_NUM_BUFFERS =  V8_FCM_NUM_BUFFERS / (number of logical
    partitions on the system + DB2_NUM_FAILOVER_NODES)
    
    Where V8_FCM_NUM_BUFFERS is the value of the FCM_NUM_BUFFERS
    database manager configuration parameter in the Version 8
    instance, and the default value of the DB2_NUM_FAILOVER_NODES
    registry variable is 2.
    
    Use this calculated value to update the database manager
    configuration using the following command:
    UPDATE DBM CFG USING FCM_NUM_BUFFERS DB2_V91_FCM_NUM_BUFFERS
    AUTOMATIC
    where DB2_V91_FCM_NUM_BUFFERS is the value from the calculation
    above.
    
    For example, if FCM_NUM_BUFFERS was 65536 on DB2 Version 8, you
    had 8 logical partitions per system, and DB2_NUM_FAILOVER_NODES
    was not set on DB2 Version 8 so that it defaulted to 2, then the
    calculation is:
     V91_FCM_NUM_BUFFERS = 65536/(8+2) = 6554
    
    The command to update the database manager configuration is as
    follows:
     UPDATE DBM CFG USING FCM_NUM_BUFFERS 6554 AUTOMATIC
    
    Notes:
    
    1) If the number of logical partitions per system varies in your
    DFP environment, FCM_NUM_BUFFERS was most likely set to
    accommodate the largest number of logical partitions on a system
    in your environment.  Use the largest number of logical
    partitions in the above formula to calculate the initial value.
    
    2) InfoSphere Balanced Warehouse (BCU) customers migrating from
    DB2 Version 8 should calculate the value of FCM_NUM_BUFFERS
    manually based on their DB2 Version 8 configuration, and then
    update the value of FCM_NUM_BUFFERS in the database manager
    configuration following the migration of the instance to DB2
    Version 9.1.  In the calculation you should use the number of
    logical partitions on a data node in the formula; using the
    number of logical partitions on an administrative node will
    result in an FCM buffer pool on the data nodes of DB2 Version 9
    instance that is several times larger than on DB2 Version 8.
    
    3) To determine the initial value of FCM_NUM_BUFFERS, issue the
    following commands:
    db2 ATTACH TO <instance_name>
    db2 GET DBM CFG SHOW DETAIL
    A sample of the line in the output that pertains to
    FCM_NUM_BUFFERS follows:
    
    No. of int. communication buffers(4KB)(FCM_NUM_BUFFERS) =
    AUTOMATIC(6554)            AUTOMATIC(6554)
    
    The number in brackets following AUTOMATIC is the initial value.
    Without the SHOW DETAIL parameter, the initial value of
    FCM_NUM_BUFFERS is not displayed.
    

Comments

APAR Information

  • APAR number

    IZ28339

  • Reported component name

    DB2 DPF

  • Reported component ID

    5724N7400

  • Reported release

    910

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2008-07-28

  • Closed date

    2008-11-07

  • Last modified date

    2008-11-07

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    IZ28581 IZ28582

Fix information

  • Fixed component name

    DB2 DPF

  • Fixed component ID

    5724N7400

Applicable component levels

  • R910 PSY

       UP

[{"Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"DB2 for Linux- UNIX and Windows"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"910"}]

Document Information

Modified date:
04 October 2021