Hi Vlad, the indices are used, but only the server knows why he scans the whole table.
SQL: DELETE FROM DETAIL WHERE ID=? /* ID */ Execution Plan: PLAN (DETAIL INDEX (I_DETAILS_ID)) Statement Statistics: Reads: 1,0 GB Inserts: 25 Indexed Reads: 25 Writes: 180,0 KB Updates: 0 Sequential Reads: 8.259.025 Deletes: 25 Table Scan: 100% btw: after backup and restore the behavior is ok, but that can't be the solution... regards Malte ---In [email protected], <hvlad@...> wrote: > we use nbackup only > my gstat accept no parameter -list It was a typo, i mean gfix of course > The transaction was cancelled after DB shutdown -> Firebird restart -> DB > online. Then also sweep takes > effect. Then it was not a limbo transaction... > BUT: Sinatica Monitor alarmed me again because every delete statement still > generate millions > of sequential reads. Consider to add some indices to satisfy WHERE condition in your DELETE statement Regards, Vlad
