Hi Kevin, I apologize for the delay in response.
DVM would not be the technology to do this type of activity, really. This is more replication and DVM doesn't deliver ACID, nor enforce transactional integrity outside of support for that which the underlying source supports, or by way of CICS, IMS TS, etc. DVM will support 2PC where possible, but I don't think DVM is geared as a 1:1 replacement here. DVM will be useful in the augmenting of data integration activities as part of ingesting into an ETL data pipeline.
Specifically, DVM doesn't copy at the database level, but rather more granularly, at the table level, as we map to and define Virtual Tables. Even then, we materialize the access to the data and don't really create a copy of that data. We access and either read or write directly to the location of the data. In this regard, DVM is helpful to offset the cost of processing by way of zIIPs. I worry that the setup and administration for this through DVM could become cumbersome. Feasible, yes, but perhaps not fully endorsed or recommended.
Ultimately, DVM needs an application requestor to pull or query the data. Use of Data Stage, for example, in conjunction with DVM, could pull and load data. Otherwise, tools like the Db2 Cloning tools can copy at the tablespace set level or an entire Db2 SSID.
------------------------------
Doug Dailey
------------------------------
Original Message:
Sent: Tue April 13, 2021 12:50 PM
From: Kevin Flanagan
Subject: DVM used to copy DB for later IIDR use
During discussions with DVM technical and marketing folks, we were advised that one of the cases for DVM was to copy a DB that would then be available for IIDR (or other) usage, and that this can utilize zIIP processors to use much less GP than similar IIDR functions.
We are currently looking at a IBM cloning tool and other options.
The first plan was to set up IIDR subscriptions to copy many dbs for an app (or apps).
At a point, do an iidr refresh (of many at once) and go.
Sending large tables via iidr ends up doing inserts which is GP prohibitive, (quite so for very large tables.)
We're also looking at unloads / loads for specific instances as well.
Please advise...
------------------------------
Kevin Flanagan
Mainframe Infrastructure Architect
General Motors
------------------------------
#Db2Toolsforz/OS