Yikes! That's not sounding good at all, but ...
There's a table in Moodle that has grown too large me thinks.
Moodle 3 should be set to use files as sessions rather than database. See if there is a sessions directory in moodledata. If there is not, it means, for some reason, sessions are being recorded in the DB. So IF there were no sessions directory with files in it, add this to the config.php file:
$CFG->dbsessions=0;
That tells Moodle to use the sessions directory in Moodledata rather than DB. Moodle will create a sessions directory if not present.
This next one involves some decision as we as SQL ... we need to find the largest table in the DB.
Have a feeling it might be a log table.
This query will generate a listing of all the tables and show size of them:
SELECT table_name AS "Table", round(((data_length +
index_length) / 1024 / 1024), 2) as TEST FROM
information_schema.TABLES WHERE table_schema = "moodle30" ORDER BY
TEST;
Change the moodle30 you see above to your DB name ... more likely it's 'moodle' but you can see that in the config.php file in the moodle code directory.
On a moodle30 site that's not used much the following shows:
|
|
| mdl_tool_customlang |
13.55 |
| mdl_question_answers |
6.77 |
| mdl_question |
5.44 |
| mdl_files |
3.25 |
| mdl_page |
2.53 |
| mdl_logstore_standard_log |
2.42 |
Of the top 6 tables in size you can see mdl_logstore_standard_log is one of the largest and one that could be truncated ... ie, data removed from it. This would mean, however, you've lost the history of whatever actions it was tracking. Stuff like user 2 logged on, etc..
Me thinks you might not need to keep that info in this case and could do without.
Don't know what's in your DB so run the query ... or get provider to do it for you so you can collect some information to share back here.
BTW, I just tested on a 3.0 site and truncating that table had no ill affect on the site ... I could login and could see actions being recorded in the table.
'spirit of sharing', Ken
