Troubleshooting Table with Failed Load (SQL0668N)


You may also like...

8 Responses

  1. Chris Aldrich says:

    I would also suggest setting LOCKTIMEOUT to 120 and DLCHKTIME to 60000 for warehouse/OLAP based loads. From what I have researched on the web (including DBI’s blogs) these are the recommended settings for warehouses to prevent lock timeouts and dead locks.

  2. Isaac Munoz says:

    Hi Ember,

    Thanks for sharing your problem. I would also suggest if the customer is happy with an empty accessible table then you could also just drop and recreate it.


  3. Masheed says:

    Hi Ember,

    on db2 V10.5 load job was cancelled by the developer and let me know that table is not responding.
    When I check the load utility status with query (load query table table-name), it shows “table is in progress”. When I checked for lock it has locked as well.

    I had try multiple times to kill the session db2 force application all. But it is not kill the session till 4 hours.

    I had execute db2 load terminate command as well, it has still running from couple of hours. And its blocked by the load id user.

    Can you please help how I can terminate the load utility when table is in progress stat and table level lock on it

    • Ember Crooks says:

      Is this a load replace where the entire content of the table is intended to be replaced?

      • Masheed says:

        Its a partition table and load job first truncate the table and then insert the data. Every time load job failed or cancel, table goes to hang state and show table level locked and we are unable to query. And to put table back to normal state I have to restart the DB.

  4. Babasaheb Sawant says:

    Many thanks Ember for sharing your exp, even I faced same issue and resolved.

  5. Andra Radulescy says:

    Hi Ember,

    An article related to difference between warmns start replication, full refresh and cold start will be very useful!
    I had a problem on my project this week, it seems that I started replication warmns mode + enable full refresh and tables got into set integrity pending state. I solved the problem, but I forgot to disable full refresh and after a couple of days, we had a SEV1 again because tables were not accessible.


Leave a Reply

Your email address will not be published. Required fields are marked *