Home/ Questions/Q 8581299
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-11T21:00:53+00:00

By mistake, I performed this query in informix using dbaccess session. Delete from table

  • 0

By mistake, I performed this query in informix using dbaccess session.

Delete from table #without where condition

Realizing my mistake, that I should have used TRUNCATE, I did another foolishness.
I killed the dbaccess session. But the table is exclusively locked and I am not able to do any action on that table.

What are the steps I can do to remove the lock and truncate the table.

1) Restart Informix server
2) onmode -z <sessionid>  # Does not work. 
                            I see hell lot of sessions created for the delete query

Is there any other easy way to fix this issue?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Assuming that you are not using Informix SE…

    Is the database logged? If so, did you run the statement inside an explicit (BEGIN WORK) transaction?

    Analysis

    If you’ve got an unlogged database, then each row that the server’s deleted is gone. If you stop the DELETE, it will not undo the partially complete changes. Using an unlogged database means that you do not want guaranteed statement level recovery.

    If you’ve got a regular logged database and no explicit transaction, then the statement is probably still running after the DB-Access session is terminated. Because it is running as a singleton statement, it will complete and commit. Until it does that, if you forcibly take the server down, then fast recovery will rollback the statement (transaction). Given that I see ‘5 hours ago’, I fear your chances of taking the server down in time now are limited.

    If you’ve got a logged database with an explicit transaction, or a MODE ANSI database (where you’re always in a transaction), then when the DELETE statement completes, the server will wait for the COMMIT, realize that the session connection is terminated, and will rollback the uncommitted work.

    Recovery

    If you’ve got an unlogged database, you can only recover to your last archive. Because it is unlogged, you can’t recover it from the logical logs (but other databases in the same instance that are logged can be recovered up to the last logical log).

    If you’ve got a logged database and you can take the server down — preferably under control, but crashing it if necessary — before the DELETE statement completes, then fast recovery will deal with the issue.

    If the DELETE has completed and committed and you have good backups, you can consider a point-in-time restore of the database. It will take it offline while you do that (but if the data from the table is all missing, your DB is not going to be functional for a while).

    If none of these scenarios applies, then you should contact IBM Technical Support, who may be able to perform minor (and not so minor) miracles.

    But, as you may have noticed, a lot depends on the type of database (unlogged, logged, MODE ANSI) and whether there was an explicit transaction in effect when you ran the statement.

    The trouble with DBMS is that they’re trusting creatures. If you’re authorized to do an operation, they assume that you intend to do what you say you want to do, and they go ahead and do it to the best of their ability. When you don’t ask it to do what you intended to request, life gets tricky; the DBMS still trusts you and does what you actually asked it to do.

    • 0