Emptying Logs Tables Reduces DB Size 355mb to 8 mb

Day-to-Day Users
1

Emptying Logs Tables Reduces DB Size 355mb to 8 mb.
Was struggling with db imports as phpmyadmin has a very low max upload file size.
I know we can tweak the php.ini file … but still was getting funny errors.
So emptied all the log tables and it reduced the db size dramatically.
Just a quick tip if anyone is havign size issues.

2

Hello @Robert_James
I can’t tell what your question is. Do you feel it’s unusual for the db to shrink if you delete the log files?
What were the funny errors you were getting? Did you also see malfunctions in the EMR performance?
I wonder if you looked at the log entries, would it tell you which processes were filling up the logs?
And if the system has been running for a long time maybe it’s just normal log contents.
Best- HT

3

Hi Htuck, my database had grown big in size, so it was a problem importing it into phpmyadmin without making changes to the php.ini file.

I was not getting any errors as such. No malfunction either of openemr.

I just shared my observation that log entries like so n so replied, edited a post, added a user etc these entries take a lot od database space which can be done with and thye wont affect the normal functioning of the software.

Also on second thoughts these log tables can be exported and saved separately and used later in future if the need arises.

I install opememr on my local host 1-2 times a day, altering, modifing files etc and seeing how it behaves. :slight_smile:

Regards

4

thanks for the clarification, I’m sure your observations will be useful to the community.
Best- Harley

1 Like
5

Keep in mind, that the logs are kept for a reason. If you truncate them and then need to find out in future who edited a patient’s chart and when, you won’t be able to without having those log records.
At least in the US, you are legally required to retain that log data for regulatory purposes, not sure exactly what laws apply in other parts of the world but I know the EU for sure has something similar.
A better plan is to regularly rotate and archive log data past a certain period, ( >6 months, > 12 months, or whatever). This of course is greatly complicated by DB encryption, but it still has to be done, on larger sites the log is useless if not managed because attempting to search will render the system unresponsive and the search will usually time out and fail anyway. Rotating the log data out to a different table, or better yet, to a separate database strictly for retaining logging information, is almost the only viable solution.

1 Like
6

Yes I fully agree… Log data is there for a reason.
We can export the log tables separately from time to time.
Or leave the logs intact all together.
All this was important till i didnt know how to edit the php.ini file safely. Now that i know how to do it and can upload sql file of any size via phpmyadmin or mysql command line, i wont be deleting the log data either. This was for my own clinic which has just started so not much legal data in there :slight_smile: