[B]jcn50 wrote on Wed, 12 September 2007 22:58[/B] |
A- No error report from the scripts’ side? After you answered that, we’ll see which next step you could do. |
A - I began to implement the error output into a logfile, but I haven’t had time to finish, I have over 4000 lines of code I need to go through…but rest assured it will be implemented as it is an excellent idea…
B - There is nothing too sensitive with my data so here it is in it’s full glory. This is AFTER I’ve already repaired the table.
mysql> select * from data_day limit 1;
±-----------±-----------±----------±-------±—±------ -±------±-------+
| device_id | timestamp | data_type | object | id | actual | gdata | gdata1 |
±-----------±-----------±----------±-------±—±------ -±------±-------+
| 1175214041 | 1189629601 | disk | C | | 1 | 31 | 0 |
±-----------±-----------±----------±-------±—±------ -±------±-------+
1 row in set (0.01 sec)
C - I don’t want to use the DELETE QUICK yet and the reason why, and I think you will agree, is that from a programming/troubleshooting standpoint, you want to do one method first. Find out if that has relieved or resolved the issue.
If I go with DELETE QUICK and also the BULK INSERTS, I won’t know which one was the actual fix. Since there are a lot more INSERTS, I think I want to try BULK INSERTS first…
D - Yes my tables are MYISAM.
E - If I can sleep better at night knowing my systems is crash-free, then bring it on!!!
Compared to what I’ve seen out there, others have a MYSQL DB of greater than 20GIGs and are running fine, so the fact that I am less than 1GIG, I feel it’s not so much the size of the DB causing the issue, it’s just improper or inefficient methods that I’m using to access the DB…