Loading tables from a Db2 for z/OS data source
You can select and load Db2 for z/OS tables individually. Consider the performance considerations and restrictions for this type of table.
About this task
- Loading can take a long time (for example minutes or hours) depending on the amount of data in the original Db2 for z/OS tables.
- The disk throughput can be volatile, depending on the disk configuration, the placement of
datasets, the number of parallel I/O operations, and so on. To a large extent, the throughput
depends on the following factors:
- Partitioning of tables in your Db2 subsystem. In Db2 for z/OS, this determines the degree of parallelism that is used internally by the Db2 Unload Utilities.
- Number of DATE, TIME, and TIMESTAMP columns in your original table. The conversion of the values in such columns is CPU-intensive.
- Compression of data in Db2 for z/OS.
- Number of available processors.
- Workload Manager (WLM) configuration.
- Workload on the IBM® Z server.
- Workload on the Data Gate for watsonx instances.
Restrictions:
- During a load process, you cannot close Cloud Pak for Data or the database connection before the loading is finished.
- If you change the partitioning type of the table space of a Db2 for z/OS table (for example, from segmented to partitioned by growth), you can no longer load the corresponding table in your Data Gate for watsonx instance. The operation fails. Therefore, you must remove the table from the instance and redefine it after changing the partitioning type.
- After a load, a replication-enabled Data Gate for watsonx table goes into Suspended state if
someone has stopped replication during the load.
Suspended means that the table is skipped when incremental updates are applied. To make this table part of the synchronization process again, you must reload it.
- You cannot use the lock mode
All tables. For more information, see step 7. - You can load no more than 100 synchronization-enabled tables concurrently. If you want to load more than 100 synchronization-enabled tables, you must issue multiple requests.
Procedure
Results
Trouble: If the load fails, first check whether DSNUTIL was started in Db2 for z/OS.
Attention: While the synchronization process is running, do not manually change the received data
in the storage object from the watsonx.data user interface. Doing so breaks the
synchronization process and compromises the integrity of the data.
FAQs
- Partition change of the table space: If you change the partitioning type of the table space of a Db2 for z/OS table (for example, from segmented to partitioned by growth), you can no longer load the corresponding table as the operation will fail. Therefore, you must remove the table from the instance and redefine it after changing the partitioning type.
- Suspended state: If someone has stopped the replication in the middle of a load, for example by stopping the connection, the state of the tables goes into the Suspended state. This means the table is skipped for any further changes. To make this table part of the synchronization process again, you must reload it.