I have been receiving a number of emails from my moodle 1.9 installation with the following contents:
Insert into log table failed at Tuesday 15th of April 2008 02:26:19 PM. It is possible that your disk is full.
I do not think that the disk is anyway near full. What could be the issue here, how serious is it and how to fix it.
Hi Marcus, phpMyAdmin says the database has utf8_general_ci collation and MySQL charset: UTF-8 Unicode (utf8). Each table of the database says utf8_general_ci collation. Keeping this into consideration if you think I should create new database in utf8, export the existing one and then import it into this newly created one then I can go for it.
Manish,
Does your problem was solved with the actions you mentioned in your message? I am with the same problem.
Thanks in advance,
Edgar Amorim
...
"Hi Marcus, phpMyAdmin says the database has utf8_general_ci collation and MySQL charset: UTF-8 Unicode (utf8). Each table of the database says utf8_general_ci collation. Keeping this into consideration if you think I should create new database in utf8, export the existing one and then import it into this newly created one then I can go for it."
Hi Edgar,
As I mentioned, I noticed nothing in the database that could suggest UTF issue, so I did not try exporting and then importing the database.
Have a look at http://tracker.moodle.org/browse/MDL-14100 .
The issue remains!
Manish.
As I mentioned, I noticed nothing in the database that could suggest UTF issue, so I did not try exporting and then importing the database.
Have a look at http://tracker.moodle.org/browse/MDL-14100 .
The issue remains!
Manish.
try running a repair on your database? - if you're running mysql and had a forced shutdown or power outage while your site was being used, the logs table may have become corrupt.
Dan
Dan
Hi Dan,
Repairing has been done several times. The issue persists.
I was wondering if disk hitting the limit for some hours can create this issue even though at present there is no disk limit issue.
Manish.
Repairing has been done several times. The issue persists.
I was wondering if disk hitting the limit for some hours can create this issue even though at present there is no disk limit issue.
Manish.
The fact that MySQL has a 4GB limit..
MyISAM table with dynamic (variable length) rows, the index file for the table (tablename.MYI) stores row locations using 32-bit pointers into the data file (tablename.MYD). That means it can address only 4GB of space.
For a long time 4GB was an entire hard disk and most operating systems had trouble with files larger than 2GB, so when MySQL designed their engine they didnt
think for a while that there will be someone who will use that much of storage or at least reach millions of records in his table :s
from my point of view; the 32-bit pointer is ideal becasue most people are running MySQL on 32-bit hardware (Intel/Linux), hence, the 32-bit pointer is most efficient way to do this on 32-bit hardware.
okay okay.. I know I talked so much.. but how to overcome this problem? and enlarge the limit or 4 GB?
here we go,
we need first to show the table status by executing:
MYSQL>show table status like ‘mdl_log’ \G
then in the result set you will find Max_data_length: 4294967295 (4 GB).
To change the 4 GB, just execute
MYSQL>alter table mdl_log max_rows = 200000000000 avg_row_length = 50;
now you are done, but notice that the alter statement may take long time.
another note that if you are using 64-bit machine you will not need to execute the alter statement becasue the installation of mysql will increase the max_data_length accordingly.
cheers..
Amr Hourani!
MyISAM table with dynamic (variable length) rows, the index file for the table (tablename.MYI) stores row locations using 32-bit pointers into the data file (tablename.MYD). That means it can address only 4GB of space.
For a long time 4GB was an entire hard disk and most operating systems had trouble with files larger than 2GB, so when MySQL designed their engine they didnt
think for a while that there will be someone who will use that much of storage or at least reach millions of records in his table :s
from my point of view; the 32-bit pointer is ideal becasue most people are running MySQL on 32-bit hardware (Intel/Linux), hence, the 32-bit pointer is most efficient way to do this on 32-bit hardware.
okay okay.. I know I talked so much.. but how to overcome this problem? and enlarge the limit or 4 GB?
here we go,
we need first to show the table status by executing:
MYSQL>show table status like ‘mdl_log’ \G
then in the result set you will find Max_data_length: 4294967295 (4 GB).
To change the 4 GB, just execute
MYSQL>alter table mdl_log max_rows = 200000000000 avg_row_length = 50;
now you are done, but notice that the alter statement may take long time.
another note that if you are using 64-bit machine you will not need to execute the alter statement becasue the installation of mysql will increase the max_data_length accordingly.
cheers..
Amr Hourani!
Hi, I have this problem too. mdl_log was "in use" and I repair it in phpmyadmin. It's the thirth (3) time who I was recived this warning. I don't understand the problem of my moodle.
1.9.3 - Centos 5.2 - MySQL 5.0.45 - Php 5.2.6
Thanks
1.9.3 - Centos 5.2 - MySQL 5.0.45 - Php 5.2.6
Thanks
In reply to Manish Verma
This forum post has been removed
The content of this forum post has been removed and can no longer be accessed.
Any comments, I have the same problem. It is a Moodle issue, I am sure about this.
Greetings.
Greetings.
I realize that this is an older post, but I am having a similar problem.
We are using 2.0.1 with utf8_general_ci.
Any help would be greatly appreciated.
---------------------------------------------------
Insert into log table failed at Thursday 10th of February 2011
It is possible that your disk is full.
The failed query parameters are:
array (
'time' => 43215125,
'userid' => '321',
'course' => '5',
'ip' => '192.168.1.1'
'module' => 'forum',
'cmid' => '10309',
'action' => 'delete discussion',
'url' => 'view.php?id=1031',
'info' => '134',
)
We have the same problem (randomly), but we are using ORACLE 10g R2.
(studiying the issue)
Best regards,
Mauricio Pérez
Hello all,
We have also been having this issue. From my investigations, I believe the problem is related to php/mysql interaction, rather than just a mysql issue. The reason is as follows:
we wanted to make sure that the data was logged in the log table, so we wrote a .net web service that would perform the insert when the regular insert function failed. We added a web service call immediately after the insert into log call; if the insert fails using the regular function, we then call the web service, using the exact same SQL statement! The .net service is able to successfully make the entry when the php call fails. So, if we're able to write to the log table using .net, then it means that there's an issue with php.
One thing we did notice is that all the failed calls - as far as we can tell - appear to be exclusively related to the scorm/view entries. Of course, because we haven't received any emails for failed entries in other tables doesn't necessarily mean that there are not other failures out there, but I can tell you that entering courses, scorm pre-views, viewing forums, etc.. are all being logged properly (eg, no insert fail messages).
So, I'm pointing the figure to php... The mystery is why...
Kim
SCORM ones could be related to MDL-27545
In our case, this particular error was caused when a user tried to use a .pptx file rather than a text file as the initial content of a wiki. Please see the attached screenshot from the wiki settings page to see where and what I mean. I hope this helps somebody!
