Workflow SQL database size remains very large despite log files lifetime set to 1 day:
More specifically, the offending SQL tables are "search log" related:
How can I manage to regularize the situation ?
Thanks in advance.
Workflow SQL database size remains very large despite log files lifetime set to 1 day:
More specifically, the offending SQL tables are "search log" related:
How can I manage to regularize the situation ?
Thanks in advance.
Miruna,
I think we're at this point as well.
Thanks for your valuable (and usual) assistance.
Hello Miruna,
The Maintenance Tab shows:
...whereas there's been no intense activities over the last 2 weeks. I remember a couple of months ago Workflow was stuck with a great amount of running instances that I had to terminate manually. Could there be non significant data in the SQL tables and, if so, is there any safe way (i.e. not to corrupt) to cleanup those 'Activity Log' related tables?
Thanks
Is there actual data older than 2 days in those tables? If you look at the Server Timers node in the Workflow Admin Console, did the database maintenance time run? (it will show the last run time and results in the right pane)
Database Maintenance Timer was run tonight at 02:00.
SELECT DISTINCT CONVERT(date,[start_time])
FROM [WF_Goodfellow].[dbo].[search_activity_log]
...reports records dated from 2015-06-18 through 2015-07-13 (no holes).
Miruna,
Would it be ok (i.e preserve database integrity) to search for outdated logs in [dbo].[search_activity_log] then delete the corresponding records (based on search_id value) in the following (in addition to search_activity_log) tables:
search_activity_messages_log |
search_entry_log |
search_error_log |
search_instance_log |
search_parameters_log |
search_status_log |
No, but you can manually run the cleanup procedures: cleanup_message_table, cleanup_tracking_log_chunk and cleanup_reporting_log_chunk.
Hello Miruna,
I've executed all 3 stored procedures; problem persists:
Here's a snapshot of values (no sure about @chunk_size) provided for cleanup_reporting_log_chunk:
I've also attached the corresponding SQL reports.
The chunk size is how many rows the procedure should attempt to delete at a time (in order to minimize the performance impact on SQL). It should be something large, like 5,000. If you don't need to worry about SQL load, then you can run the cleanup_reporting_log and cleanup_tracking_log procedures which will attempt to clean up everything in one run.
Miruna,
Recap: I have run both cleanup_reporting_log and cleanup_tracking_log as follows:
and
Table search_activity_log keeps showing stuff as of 2015-06-17:
Did I miss anything ?
The dates in the table are after 2015-06-17 00:00:00, so the behavior looks correct to me.
I've just run both stored procedures against 2015-07-27 00:00:00. Rows dated 2015-06-17 in my previous message keep showing in SQL Server Management Studio.
notes:
Laserfiche Workflow 9.2.1.227 64-bits
SQL Server 2012 (11.0.2100) Standard Edition 64-bits
Please open a support case through your reseller.
Miruna,
I think we're at this point as well.
Thanks for your valuable (and usual) assistance.
You're showing the log files lifetime options. They apply to the log files stored in the Logs subfolder in the installation folder on the Workflow Server. The database cleanup options are on the Maintenance tab.