Hi Simone,
At this point I have come to the conclusion that it is a combination of bad indexes, increased in data volume and a oder by in the statement when the field to be ordered is not in the index.
A closer look at the performance trace shows that out of the 6 fields in the secondary index, only 2 key columns are satisfied. On top of that, we have 4 rather similar indexes that differs only by the last 2 fields. It basically confuses the DB optimizer to go through each index and finally uses the last index because it is the last. Adding to the load is the order by syntax.
On the same table we have another index just with the transaction ID and search on transaction ID is super fast.
Does that sounds like the explanation?
Thanks!