After setting up a database connection in the Metadata folder and
reuse it in your Jobs, if you want to change the database type from one to another, you can
migrate the source database connection to a target connection if the target connection is
also set up in the Metadata folder.
Information noteNote: This feature
applies to data integration Jobs only. The HBase, Hive, Impala, Iceberg, and MapR-DB
database types cannot be migrated. The Snowflake database will be supported from 8.0
R2024-10.
Procedure
Expand Metadata > Db Connections in the Repository tree view, right-click the
database connection you want to migrate and select Migrate Db connection
to... from the contextual menu.
The database migration wizard opens.
In the Source column of the wizard, the source connection
and schemas retrieved from it are shown with the number of Jobs they are reused in.
In the Target column, select the database connection you want
to migrate. The schemas in the source connection that exist in the target connection
with the same name (case insensitive) are marked with the icons. Click Next to go to the next step.
All Jobs in the closed state that use the source connection are displayed in the
wizard.
A database component is migratable if the following conditions are met:
The component reuse the database connection in the repository. If the
Property Type of the component is set to
Built-in, the component will not be detected and
thus not changed.
The schema reused in the component exists in the target connection with the
same name (case insensitive).
The component has an equivalent in the target database.
The ELT components are migratable if the last Map component in the subJob
use a repository connection. If the property type of the last Map component
is set to Built-in, all the ELT components in the
subJob will not be detected.
Information noteNote: For ELT UniteMap cases, only migration
between Oracle and Teradata databases is supported.
Each component is marked with a or icon indicating if it is migratable or not. If a component is migratable
and it reuses a schema in the source connection, the schema name is shown after
the component name. If a component is not migratable, the reason is highlighted. A
Job is migratable only if all detected components in it are migratable.
If the component reuses a schema in the source connection and the table name is
the same as the schema name, after the migration, the table name will be changed to
schema name in the target connection. For example, the schema
table_1 in the source connection matches TABLE_1
in the target connection. If a component reuse this schema and its table name is also
table_1, after the migration, the table name will be changed to
TABLE_1. Note that Talend Studio
does not validate columns in target table.
If a component uses the source connection but it does not use the schema from this
connection, the component will be migrated to the target connection but the schema
and table name will not be changed.
For example, to migrate from a MySQL database connection to Oracle:
Source connection
Target connection
Name
Schemas
Name
Schemas
source_conn (MySQL)
table_1
target_conn (Oracle)
TABLE_1
table_2
TABLE_2
table_3
TABLE_3
table_4
The following table shows the migratable and not migratable Jobs/components
and the schema types and table names before and after the migration.
Migration cases
Before migration
Is component Migratable
Is Job Migratable
After migration
Job
Component
Property type
Schema type
Table name
Component
Property type
Schema type
Table name
Job1
tMysqlInput
source_conn
source_conn-table_1
table_1
Yes
Yes
tOracleInput
target_conn
target_conn-TABLE_1
TABLE_1
tMysqlOutput
source_conn
source_conn-table_2
table_2
Yes
tOracleOutput
target_conn
target_conn-TABLE_2
TABLE_2
tMysqlBulkExe
source_conn
source_conn-table_3
table_3
Yes
tOracleBulkExe
target_conn
target_conn-TABLE_3
TABLE_3
tMysqlOutputBulkExe
source_conn
source_conn-table_3
table_X
Yes
tOracleOutputBulkExe
target_conn
target_conn-TABLE_3
table_X
tMysqlSP
source_conn
built-in/generic
table_Y
Yes
tOracleSP
target_conn
built-in/generic
table_Y
tMysqlValidRow
built-in
built-in/generic
table_Z
N/A
tMysqlValidRow
built-in
built-in/generic
table_Z
tMysqlInput
built-in
built-in
table_A
N/A
tMysqlInput
built-in
built-in
table_A
tMysqlInput
built-in
source_conn-table_3
table_3
N/A
tMysqlInput
built-in
source_conn-table_3
table_3
Job2
tMysqlInput
source_conn
source_conn-table_1
table_1
Yes
No
tMysqlOutput
source_conn
source_conn-table_4
table_4
No
tMysqlTableList
source_conn
Yes
tMysqlColumnList
source_conn
No
Job3
tELTMysqlInput
source_conn-table_1
table_1
Yes
Yes
tELTOracleInput
target_conn-TABLE_1
TABLE_1
tELTMysqlMap_1
Yes
tELTOracleMap
tELTMysqlMap_2
source_conn
Yes
tELTOracleMap
target_conn
tELTMysqlOutput
built-in/generic
table_X
Yes
tELTOracleOutput
built-in/generic
table_X
For CDC use cases, to migrate from one database to another, both the connection to
the source data warehouse and to the CDC dedicated database must have target
connections set up in the repository. The migration should be triggered from the CDC
dedicated database connection.
You can use the search field to filter the Jobs or select from the drop down list
to show all migratable and not migratable Jobs. Click Next to
go to the next step.
A summary of migratable Jobs is shown in the wizard. Click
Apply to perform the migration.
The migration report page is shown. You can click the Check the
report link to open the report, or click the
Browse button to go to the
<Studio_Home>\workspace\report\massUpdate directory
where the report is saved.
The migration report is in CSV format containing the following information of
the migrated Jobs:
Did this page help you?
If you find any issues with this page or its content – a typo, a missing step, or a technical error – please let us know!
In the Source column of the wizard, the source connection and schemas retrieved from it are shown with the number of Jobs they are reused in. In the Target column, select the database connection you want to migrate. The schemas in the source connection that exist in the target connection with the same name (case insensitive) are marked with the
icons. Click Next to go to the next step.
A database component is migratable if the following conditions are met:
icon indicating if it is migratable or not. If a component is migratable
and it reuses a schema in the source connection, the schema name is shown after
the component name. If a component is not migratable, the reason is highlighted. A
Job is migratable only if all detected components in it are migratable.If the component reuses a schema in the source connection and the table name is the same as the schema name, after the migration, the table name will be changed to schema name in the target connection. For example, the schema table_1 in the source connection matches TABLE_1 in the target connection. If a component reuse this schema and its table name is also table_1, after the migration, the table name will be changed to TABLE_1. Note that Talend Studio does not validate columns in target table.If a component uses the source connection but it does not use the schema from this connection, the component will be migrated to the target connection but the schema and table name will not be changed.For example, to migrate from a MySQL database connection to Oracle:The following table shows the migratable and not migratable Jobs/components and the schema types and table names before and after the migration.
