Hey Helen Thanks for hour reply, let me see if i can clarify the problem, the actual delete of the 90.000 rows is not the problem, this completes in 10-30 seconds. That is just fine, performance does not matter here.
I have 2 web servers, on each of them, there is a background thread that inserts into the request table, these two threads are the only ones that insert into that table. Every hour the previous mentioned delete procedure is in executed from an application server. However when the procedure is executed every executing user-request on the webserver is waiting for the database server to respond, and the number of attachments spike on the database server, resulting i connection pool full exceptions. this image shows how the attachment count spikes, 95% of the attachments are from the two webservers. https://dl.dropboxusercontent.com/u/937321/attachement_spike.PNG https://dl.dropboxusercontent.com/u/937321/attachement_spike.PNG None of the user-requests on the webserver selects/inserts/updates/deletes from the request table, information about the request is handled over to the background thread that inserts a row into the table. From my perspective it looks like the delete of the 90.000 rows results in a complete hang/standstill on the database server. In those few seconds i looks like FB does not finish any statements. Thomas
