Manage the violations and diagnostics tables

You can turn on or turn off the generation of constraint-violation information. If you turn on the generation of constraint-violation information, onpload writes the information to the violations and diagnostics tables.

The manages the violations and diagnostics tables in the following manner:
  1. Starts the load job.
  2. Starts the violations and diagnostics tables if they do not exist. (If a violations and diagnostics table exists, the HPL uses that table).
    The HPL uses the following SQL statement to start the violations table:
    START VIOLATIONS TABLE FOR tablename
  3. Performs the load job.
  4. Stops the violations and diagnostics tables if they were started at step 2.
    The HPL uses the following SQL statement to stop the violations and diagnostics tables:
    STOP VIOLATIONS TABLE FOR tablename
  5. Drops the violations table if the violations table is empty.

The START VIOLATIONS TABLE statement creates the violations and diagnostics tables and associates them with the load table. The STOP VIOLATIONS TABLE statement dissociates the violations and diagnostics tables from the load table.

The violations table (tablename_vio) and the diagnostics table (tablename_dia) are always owned by the owner of the table with which they are associated. The Resource privilege lets a user start and stop a violations table, but it does not let the user drop a table that the user does not own. Thus, the HPL cannot drop the violations table in step 5 if the user is not the owner.

Failure to drop the violations table does not cause the load job to fail. However, this failure leaves in the database a violations table that is not associated with a table. If the user tries to run the job again, the START VIOLATIONS TABLE statement in step 2 fails because the table tablename_vio exists.

To solve this problem, the owner of the table or the database administrator must explicitly create the violations and diagnostics tables by using the START VIOLATIONS statement. When the owner creates the violations table, the following actions take place:
  • In step 2, the HPL uses the existing violations table.
  • In step 4, the HPL does not stop the violations table because the table was not started in step 2.
  • In step 5, the HPL does not drop the violations table because the user does not own the table.

After the load job is complete, an active violations table remains in the database. This table might be empty, but does no harm. When the user runs the load job a second time, the violations table is available, and the load job succeeds.