Skip to main content
Delphix

DB2 VDB Provision Fails When Using Staging Push and dSource is Using Archive Location in Unmounted Location (KBA9120)

 

 

KBA

KBA# 9120

 

Issue

During VDB provisioning from a dSource configured with the DB2 staging push methodology the VDB job fails with this error:

db2 => rollforward db VUSCFI query status
       SQL1035N  The operation failed because the specified database cannot be connected to in the mode requested.  SQLSTATE=57019
db2 =>
Fail Message Desc               Failed to execute rollforward command on database VUSCFI

The issue is related to a missing step in preparing the dSource for provisioning.

Prerequisites

  • Delphix Engine 6.0.10.0 and higher.
  • Db2 plugin 4.1.0 and higher.

 

Applicable Delphix Versions

Click here to view the versions of the Delphix engine to which this article applies
Major Release All Sub Releases
6.0 6.0.10.0, 6.0.10.1, 6.0.11.0, 6.0.12.0, 6.0.12.1, 6.0.13.0, 6.0.13.1, 6.0.14.0

Resolution

 

The issue can be identified and resolved by inspecting the database configuration of the dSource.  If the dSource staging database is kept consistent with backups and logs, the dSource configuration needs to set the archive log location to the mounted directory of the dSource staging database.

After the dSource is ingested check the database configuration for the archive log location with the following command:

db2 get db cfg for <dSource Staging database name> | grep -i LOGARCHMETH1

If the value returned is a non-Delphix mounted drive:

First log archive method                 (LOGARCHMETH1) = DISK:/Some_Local_Drive_or_Non-Delphix_mounted/

Change it to a location on the mounted drive using the following Db2 command:

db2 update db cfg for <dSource Staging database name> using LOGARCHMETH1 “DISK:/delphix/db2_plugin/DB2/mnts/db2inst/DB2STG/db2inst/DB2STG/archlogs/“

Using the following values where:

  • Db2 plugin location is /delphix/db2_plugin
  • db2inst is the Db2 instance name 
  • DB2STG is the staging database name
  • archlogs is the name for the directory which must be manually created after that initial ingestion
    • The instance user must be allowed to access this directory for reading

Then, check the result by checking the output from the following command:

db2 get db cfg for DB2STG | grep -i LOGARCHMETH1

Output:

First log archive method                 (LOGARCHMETH1) = DISK:/delphix/db2_plugin/DB2/mnts/db2inst/DB2STG/db2inst/DB2STG/archlogs/

Troubleshooting

You can check the db2diag.log, usually found in the Db2 instance user home under sqllib/db2dump.

  • You can check on your instance for location if not in the default:
    db2 get dbm cfg |grep -i diagpath
    Diagnostic data directory path               (DIAGPATH) = /home/auto1112/sqllib/db2dump/
    Current member resolved DIAGPATH                        = /home/auto1112/sqllib/db2dump/
    Alternate diagnostic data directory path (ALT_DIAGPATH) =
    Current member resolved ALT_DIAGPATH                    = 
    
  • Check to see if you find messages similar to this:
    2022-04-08-17.04.00.148546-420 I4471180A1066        LEVEL: Severe
    PID     : 15532310             TID : 29154          PROC : db2sysc 0
    INSTANCE: db2inst              NODE : 000           DB   : DB2STG
    HOSTNAME: db2_Hostname.com
    EDUID   : 29154                EDUNAME: db2loggw (DB2STG) 0
    FUNCTION: DB2 UDB, data protection services, sqlpGLFHValLotch::writeNew, probe:610
    MESSAGE : ZRC=0x8610000D=-2045771763=SQLP_BADLOG "Log File cannot be used"
            DIA8414C Logging can not continue due to an error.
    CALLSTCK: (Static functions may not be resolved correctly, as they are resolved to the nearest symbol)
    [0] 0x09000000372F9AEC writeNew__16sqlpGLFHValLotchFv + 0x36C
    [1] 0x0900000030BF982C sqlpgPrepareForSoftCheck__FP9SQLP_DBCB + 0xD2C
    [2] 0x0900000030C141F0 sqlpLoggwMain__11sqpLoggwEduFv + 0x4F30
    [3] 0x090000003382C294 RunEDU__11sqpLoggwEduFv + 0x34
    [4] 0x090000002F9FB8E0 EDUDriver__9sqzEDUObjFv + 0x2F0
    [5] 0x090000002F912594 sqloEDUEntry + 0x364
    [6] 0x09000000005ABFE8 _pthread_body + 0xE8
    [7] 0xFFFFFFFFFFFFFFFC ?unknown + 0xFFFFFFFF
    

When you find "Log File cannot be used" and it correlates in time to the error, check the staging database configuration as indicated in the Resolution.

 

 


Related Articles

The following articles may provide more information or related information to this article: