Figure 5 shows a single express-mode load process. In express mode, the data is inserted directly into an extent without any evaluation of objects such as constraints, indexes, or triggers.
The onpload utility behaves the same way during express loads and deluxe loads, as described in Threads That the onpload Utility Uses. However, the database server behaves differently during an express load. The pl_wkr threads pass the data to stream threads (also called fragmenter threads) that decide where the data should be stored. The fragmenter threads pass the data to an exchange that distributes the data to setrw threads. The setrw threads write table rows to disk a page at a time, bypassing the buffer cache.
The number of input devices can be different from the number of table fragments. The exchange operator handles multiplexing of data. The data is processed in parallel with respect to the data read from the device array and also with respect to the data written out to table fragments on separate disks. Pipeline parallelism is also present in the data flow from input devices to table fragments on disk. Parallelism is the main mechanism for achieving high performance.
During express-mode load, the database server writes the data to new extents on disk, but those extents are not yet part of the table. At the end of an express-mode load, the database server adds the new extents to the table.
After the express-mode load, you must perform a level-0 backup before you can write to the target database. If you try to write to the table before you perform a level-0 backup, the database server issues ISAM error -197, as follows:
Partition recently appended to; can't open for write or logging.
If your database is ANSI compliant, all access (both read and write) is denied until you perform a level-0 backup. Because data is not logged in express mode, the level-0 backup is necessary to allow for recovery in case of media failure.