When I check the locks on the database there are several that are state types with shared locks and one with an exclusive lock. There are not users/owners associated with these locks. I can only assume that this is why, after a compress, hundreds of adds and deletes tables still have data - some have large amounts of data 3+GB. How do I get rid of these locks? Disconnect user fails. If this is not the problem with the compress not reconciling all the adds/deletes tables, if anyone has other ideas that would be great.
The db has no versions or replicas except the default version. All users were out of the system when the compress was done.
When was the compress run last time? Was the compress successful? What does the SDE Compress table indicate? I would run the Compress again after reconcile process.
Last compress was successful yesterday. There is nothing to reconcile as there are no versions. Compress table indicates success - start state count 5415, end state count - 11 (I think that are 11 non-user state locks but not sure).
I assume you are running compress via python script? Are you using ArcPy.disconnect function to disconnect all connections ? I am also wondering if you have featue services shared out on server that could be causing this?
I shut down my ArcServer before the compress. I also put our Cartegraph server in maintenance mode, which got rid of their lock. I ran the compress directly in ArcCatalog - Administer - Compress. When I list the current users using ArcPy, it gives me nothing, as the locks are not associated with users.
Do you get an error with the disconnect users in the lock window or it does not remove the locks?
Based on the dates, those may be really old ones. I would recommend working with Technical Support before deleting them in the DB.
No errors, that's the strange thing...
I would reach out to support and have them take a look. The ultimate fix may be to drop the records in the locks table, but that could cause other potential issues.
Are there any performance issues after the compress?
As long as the compress is completing, with no errors. You should be ok.
Ok, that is understandable. Having some tables with large amount of records should not be an issue for the RDBMS.
I would reach out to Esri Technical Support for further guidance.