Did you run archive as Stored procedure or as a service? If you executed it as an SP it might still be working in the DB.
This might be incorrect, try filtering the search criteria so that less results will be returned and check again. Whether you archive your data or not, MWS should be able to bring that data. Only relation with archive and process instances is it will take a lot longer to bring process results if you don’t archive frequently, hence this might be the case here. For instance, try searching with a specific process ID or limit it to half an hour or so. It should return results.
If you executed archive as SP (there is a parameter in the service which sets it to run as SP or as service) it can still be running if you haven’t archived your DB for a very long time. Did you check operations table? If you check archive DB you can see the operations table, and current status of the procedure (if its still running or not, or what happened when you executed it last time). You can update that value to stop SP execution and trigger it again. It will clear the status of SP.
What you explained so far made me believe the SP is still running. For a better comparison I had a db with 8TB non archived data. My archive SP took more then a week (I don’t remember how long exactly it took but it was between a month and a week), When we executed it first time, it really looked like it was stuck and we canceled the SP execution by updating the operation_control table. It turned out that we didn’t really need to do it though. we could forget about it and it would be finished. Instead, we limited the SP archive window programmatically and run it incrementally (as archive 01/01/2024, and then 02/01/2024 and so on). When we had that bloated DB process tables, any queries were taking several minutes to finish executing. If you executed it as service and if you canceled it it might be stopped but it should start running next time you trigger the same service again. Its usually preferred to archive using DB only, if you triggered this it will keep running until the first query finishes executing. Consequent calls will only update the parameters of the initial SP query. I am not sure if it changes the execution of the current ongoing SP execution though.
The table below controls the SP execution. The operation_status column will have the current status of the last execution. It will tell you if its running or failed etc. If its complete, that means your arhive SP has finished work.
**You can change operation_status to COMPLETE to stop execution, but do it only as last resort! You need to executre it again if you stop it this way. **
Table below shows last operation. You should be seeing lots of entries here if it is successfully running. You should see this table updating if the SP is running.
You can find the last execution parameters from the table below if you need them
You can also monitor the size of the DBs to verify if its running or not. These screenshots are taken from Sql Server, Oracle has a similar structure, Other DBs might be different. Also keep in mind that after archive, you need a shrink especially if its the first time archiving after a very long time. If you don’t shrink the DB your performance will be effected. Here in your case, it looks like your archive SP is still running and its degrading your performance, hence its taking longer to finish.
