I had restarted the server many times and it still worked, so I don't think the data was cached. Maybe the different method of access caused the difference, because the non-corrupted entries were still accessible via their id, so direct access worked.
Could it be that slapcat doesn't correctly handle the case of invalid entries (entries with decoding errors)? Before this generic patch, I checked if the current entry had the id of the first invalid entry and in this case I incremented the ID by three, got the resulting entry and continued the export --> slapcat "skipped" the entries which it couldn't decode and then continued processing normally.
Sorry that I can't test catastrophic recovery any more, because I have deleted the corrupted database, but I think that the main problem was that slapcat (and also other ldap-tools) wasn't able to decode the few damaged entries and didn't try to work around that problem.