Reviewing Your Data Targets
|
Topics: |
The data targets you use for your application affect the performance of DataMigrator. Consider the following issues that pertain to the tables or files being written by DataMigrator:
- Row processing logic. Is this a total refresh? Will the request be deleting all rows or dropping the table before starting? Is an update or delete necessary? The processing logic is specified in your data flows.
- Location of the tables. Are the tables local to the machine where the server will be running? What connection information will be needed to resolve the names for remote data sources? Can it be handled in the Access File for the synonym? The DMC allows you to specify these items, but in many cases it is best to allow the iWay Hub Server to manage the location of tables. Review the server profile (EDASPROF.PRF) or the profile for your user ID, as well as the Access File that is used with the DataMigrator Server to establish table names and their storage locations.
DataMigrator extracts the data from a data source and loads it into a data target, which may be:
- A relational data target. For details, see Relational Data Targets.
- A non-relational data target. For details, see Non-Relational Data Targets.
- Remote destination. For details, see Remote Target Destinations.
Relational Data Targets
Depending on the platform, supported relational data targets currently include the following: Access, Db2, Informix, MySQL, Nucleus, ODBC, Oracle, SQL Server, Sybase, Red Brick, and Teradata.
In the following diagram, DataMigrator creates a target table or writes to an existing target table in a local RDBMS which resides on the DataMigrator Server (the recommended configuration for a data target).
Note: EDA is only supported for existing targets. The name of the remote server must match the real server name of the subserver. This option should only be used for small data volumes. For large volumes, you should install the DataMigrator server on the platform where the data will be loaded.
Non-Relational Data Targets
You can create non-relational data targets of the following types on the DataMigrator Server (the recommended configuration for a data target): a FOCUS/FDS or XFOCUS data target, or a flat sequential file of different formats. A flat sequential file is created in the character set appropriate for the server platform (for example, ASCII on UNIX or EBCDIC on z/OS). In the following diagram, DataMigrator creates or writes to an existing non-relational data target.
Remote Target Destinations
|
Reference: |
Many relational data source management systems provide for remote table access. If properly configured, the DM server supports the syntax necessary to write to remote targets (for example, SQL*NET provides access to remote Oracle tables).
The following figure illustrates how a DBMS located on the DataMigrator Server uses networking capabilities to write to a remote data target.
Reference: General Guidelines for Data Targets
- DataMigrator
supports up to 64 character for the synonym name used with a data
target or the limit set by the operating system or DBMS. The 64-character
limit is for the total name, including data source and owner details.
For example, if you are loading a relational data target, the full name may exceed 64 characters since you can add data source and owner details to the synonym name.
- Avoid the following
when naming data targets:
- Names beginning with the capital letter E followed by a two or three digit number (for example, E01 - E999).
- Names beginning with the capital letter T followed by a number (for example, T1 - T16).
- When you write or move data to an existing relational target, ensure that the correct access rights are assigned to the approved group of designers. New relational targets generally default to assigning an owner ID equal to the logon ID, although this may vary based on the type of data source selected.
- DataMigrator
is often used to create data targets in the local relational subsystem. This
requires that the user ID processing flows has appropriate access
to the target RDBMS.
- If the data target is a new table, the user ID must have permission to issue CREATE TABLE statements.
- If the data target is an existing table, transaction update access is necessary.
- Relational data targets created in DataMigrator are owned by the user ID specified in the connection string in the server profile.
- Flat, FOCUS/FDS, and XFOCUS file data target attributes are controlled independently by the designer. Therefore, they may only create conflict if users select the same file name (operating system dependent) for their output. This can be avoided by establishing a convention for where users will write their extracted answer sets.
- Where flat file data targets are being created, the user ID of the processing request must have access to the subdirectory or data set that is currently allocated to receive the answer set. Flat files created in DataMigrator are owned by the server user ID.
Note: For the best throughput loading relational tables, the DataMigrator server should be on the same system as the RDBMS server. Throughput to a remote server is dependent on your network speed and traffic.
| WebFOCUS | |
|
Feedback |