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.
- Delphix Engine 22.214.171.124 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 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52
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
First log archive method (LOGARCHMETH1) = DISK:/delphix/db2_plugin/DB2/mnts/db2inst/DB2STG/db2inst/DB2STG/archlogs/
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)  0x09000000372F9AEC writeNew__16sqlpGLFHValLotchFv + 0x36C  0x0900000030BF982C sqlpgPrepareForSoftCheck__FP9SQLP_DBCB + 0xD2C  0x0900000030C141F0 sqlpLoggwMain__11sqpLoggwEduFv + 0x4F30  0x090000003382C294 RunEDU__11sqpLoggwEduFv + 0x34  0x090000002F9FB8E0 EDUDriver__9sqzEDUObjFv + 0x2F0  0x090000002F912594 sqloEDUEntry + 0x364  0x09000000005ABFE8 _pthread_body + 0xE8  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.
The following articles may provide more information or related information to this article: