Requirements for Using Fastload
The following requirements must be met to perform a fastload:
• Since the fastload command creates its own server, if simultaneous access to the database is required for additional sessions, the following DBMS parameter changes are required for any DBMS that has access to the same database:
– cache_sharing ON
– fast_commit OFF
– sole_server OFF
• The fastload operation must be able to obtain an exclusive lock on the table or fastload exits.
• The file’s data format must match the table’s data format. That is, the file format must match the result of an unformatted unload (COPY INTO) of the table.
If the formats do not match, incorrect data are loaded into the table. For example, if each record in a file contains a 5-byte char and a 4-byte integer—and this file is loaded into a table that has a 4-byte char field followed by a 4-byte integer field—fastload reads 8-bytes of the file and load it as a row into the table. This means that the integer field does not contain the actual integer in the original file because the last byte of the 5-byte char field plus 3-bytes of the integer field are interpreted as a 4-byte integer. The problem grows as more data is read because the data are off by one more byte for each row.
Check that the record length in the file matches the record length expected by the table. For tables that do not include large object columns (such as long varchar and long byte), the record length should match the row width, as given by the SQL HELP TABLE statement.
In many cases, fastload is unable to determine the record size of a binary file (this is the case on all Linux platforms); in these cases, fastload generates a message warning that no format checking can be performed. The warning also contains the expected size of records in the binary file.
• Be aware of the extra data added by the varchar data type and all nullable fields. Fastload expects to read a 2-byte integer at the beginning of a varchar field that contains the length of the varchar data. All nullable fields must be terminated with a single byte null indicator that determines whether the field is null. The indicator byte is 0 for not-null, nonzero for null.
• Fastload does not support complex data types such as intlist, ord_pair, or UDTs.
• Binary format files cannot be transported between byte-swap and non-byte swap machines. The data can be generated programmatically, but you should be careful to generate the correct record format, taking into account additional bytes needed for some field types.
• Fastload cannot be run against a remote database using Ingres Net.
Last modified date: 08/14/2024