Data Ship Limitations
Some resource constraints limit the use of data ship optimization. Most limitations are related to data type mismatches. Data type mismatches are handled by a transformation of the data, but certain data types from different sources are incompatible for a selected target. Typically, these data type mismatches are most notable for numeric precision.
The following is a list of cases where use of the Data Ship optimization is not recommended.
|
Microsoft SQL Server
|
When using Microsoft SQL Server with the bcp utility, you might get data type mismatch errors if you are using BLOB or CLOB data types.
|
|
To Netezza
|
Netezza cannot be the data ship target for source tables containing data of type BINARY or VARBINARY (for example Oracle).
|
|
Netezza cannot be the data ship target for tables with LONGVARCHAR or VARCHAR columns more than 64 KB long, because creation of the temporary table fails.
|
|
When Netezza is the data ship source, data types of FLOAT or DOUBLE might lose precision because of rounding of values sent to a target of a different type.
|
|
Netezza to Sybase IQ
|
With data ship from Netezza to Sybase IQ, NULL values are replaced with zeroes, which results in different query results than when data ship is disabled.
|
|
Sybase IQ or Netezza to Oracle
|
When Sybase IQ or Netezza data sources use Oracle as a data ship target, trailing spaces sent in the shipped table are trimmed in the result sets with the Oracle table.
|
|
Sybase IQ to Netezza
|
When Sybase IQ data sources use Netezza as the data ship target can cause a data mismatch because the Netezza database appends a padding space character in result set data.
|
|
To Oracle
|
If an Oracle database is a data ship target and the transferred data contains UTF-8-encoded East Asian characters, a column length limitation exception can occur.
Oracle databases with a UTF-16 character set does not have this problem.
|
|
To Sybase IQ
|
If you are moving data of type FLOAT to a Sybase IQ database, the scale of the data can be lost because of the way that the Sybase IQ JDBC driver handles the FLOAT data type.
|
|
Sybase IQ Type4 Driver
|
Sybase IQ Type4 driver appears to lose the precision of time stamp columns by promoting or demoting it. To avoid this issue, use the Sybase IQ Type2 driver.
|
|
Teradata
|
Teradata controls the number of concurrent FastLoad and FastExport tasks using the MaxLoadTasks and MaxLoadAWT parameters. Excess FastLoad or FastExport tasks are rejected.
|
|
The maximum number of sessions for each FastLoad or FastExport job is limited to the number of AMPs of the Teradata database. Eight sessions work well for most scenarios.
|
|
Teradata’s implementation of UNION does not follow the SQL standard, which can result in a data mismatch when the data is shipped to Teradata.
|
|
A row fetch size bigger than 64 KB causes a Teradata error. Refer to Teradata documentation for the best solution to this problem.
|
|
Teradata FastLoad requires that the target table be empty. If the target Teradata table is not empty, JDBC is used to load data into the table.
|
|
To Vertica
|
For Vertica, the maximum length of a BINARY or VARBINARY column is 65000.
|