Table of contents

Scaling up Db2

You can run a script to add more memory and CPU to the Db2® service on Cloud Pak for Data to support high-availability or increase processing capacity.

About this task

Db2 does not support the cpd scale command, but you can use a provided script to scale up Db2 to use any increased operating system capacity.

Note: Proceed with the scaling up procedure only if your deployment is privileged (the default deployment behavior). If you have a limited-privilege deployment, see Scaling up in a limited privilege Db2 deployment.

Procedure

  1. Use the following command to edit the OpenShift® stateful set for the Db2 pod to set higher memory and CPU limits:
    oc edit sts c-db2-1603819662989-db2u

    You can find the correct stateful set (sts) in the project by using oc get sts | grep db2.

    In the following example sts, these entries set CPU to 12 vCPU and memory to 36 Gi:

    Limits:
      cpu:     12
      memory:  36Gi
    Requests:
      cpu:     12
      memory:  36Gi
    
  2. Exec into the Db2 pod.
  3. Disable the Wolverine high availability monitoring process:
    sudo wvcli system disable -m "Disable HA before Db2 maintenance"
  4. On the head pod of your Db2 cluster, run the following series of commands to:
    • Create the update_mem.sh script file.
    • Deactivate and stop Db2.
    • Disable any remote database connections.
    • Update the Db2 instance_memory configuration parameter to use the normalized percentage value that was derived from the higher system memory limit.
    • Re-run the autoconfigure command to start using updated instance_memory percentage and reapply any overrides.
    • Re-enable Db2 remote connections, start Db2, and activate the database.

    Replace dbname with the database name.

    #!/bin/bash
    source /etc/profile
    source /db2u/scripts/include/common_functions.sh
    source /db2u/scripts/include/db2_functions.sh
    
    # Get PID1 environ required for access OS envvar MEMORY_LIMIT
    export_pid1_env
    source /db2u/scripts/include/db2_memtune_functions.sh
    
    # Deactivate database and stop Db2
    db2 terminate
    db2 force applications all
    db2 deactivate db dbname
    db2stop force
    rah 'ipclean -a'
    
    # Disable remote connections
    db2set DB2COMM -null
    
    instance_memory_file_owner=$(stat --format=%U /mnt/blumeta0/SystemConfig/instancememory)
    sudo_cmd="sudo"
    if [[ "$instance_memory_file_owner" == "db2inst1" ]]; then
       sudo_cmd=""
    fi
    $sudo_cmd rm -f /mnt/blumeta0/SystemConfig/instancememory
    
    # db2start prior to activate db bludb and connection within db2_autoconf.clp
    db2start
    # Update the normalized instance_memory % value derived from higher MEMORY_LIMIT
    set_instance_memory
    db2stop
    
    # db2start prior to activate db bludb and connection within db2_autoconf.clp
    db2start
    # Re-run autoconfigure to start using updated instance_memory %, and reapply any overrides
    run_autoconfigure
    apply_cfg_setting_to_db2 "-all"
    
    # Re-enable Db2 remote connections, start Db2 and activate db
    db2stop force
    rah 'ipclean -a'
    db2set DB2COMM=TCPIP,SSL
    db2start
    db2 activate db dbname
  5. Set permissions on the update_mem.sh script and run the script:
    chmod +x /db2u/tmp/update_mem.sh
    su - db2inst1 -c "/db2u/tmp/update_mem.sh"
    The script runs the function export_pid1_env, which parses the PID 1 environment file /proc/1/env to get the value of the operating system memory limit environment variable and make the needed adjustments.
  6. Re-enable the Wolverine high availability monitoring process:
    sudo wvcli system enable -m "Enable HA after Db2 maintenance"