MyISAM storage tables also have this kind of problem.
I have try serval solutions for this problem , but can't work very well.
If your application isn't very import , you can let your application auto
repair this problem.
Just like this :
When your application catch this error information , run
Hi,
This table can be repaired using Repair table ; in mysql.
This should fix the corrupted index file, or if mysql is shutdown, you can
run myisamchk, also if its a myisam table.
Hope this helps.
Regards,
Akshay S
On Fri, Oct 19, 2012 at 11:52 AM, a bv wrote:
> Hi on a log management server
Looks like a MYISAM table... MYISAM is not a crash safe storage engine
and an instance crash could corrupt the tables. You should run CHECK
TABLE ; and REPAIR TABLE ; to repair this.
On 10/19/2012 11:52 AM, a bv wrote:
Hi on a log management server from the web interface i get the below
error
Hi on a log management server from the web interface i get the below
error . What can be the reason and how can i repair it ?
Regards
Mysql_error: Table ./x/y ' is marked as crashed and should be repaired
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscr
The reason this is significant is because we are speaking about INFILE
use. The server processes infile commands assuming the file is already
stored on the server. LOCAL INFILE tells mysql that file is local to the
mysql client and must be moved to the server before processing. I suspect
that thi
not sure i follow. what do you mean connect?!
there is a server (mysqld) and a client (mysql). the client gets to the
server via the socket. like on any other unix machine.
how did i connect mysql to what exactly?
On 10/18/12 6:42 AM, Ananda Kumar wrote:
how did u connect mysql on your lap
how did u connect mysql on your laptop
On Thu, Oct 18, 2012 at 1:19 AM, kalin wrote:
>
> thanks amanda... the "local" worked for some reason...
>
> in about 10 years of using mysql i have never had to do that.
>
> i still wonder why would the thing not stat it.
>
> file and dir are both 777 and
Hi Kent
How did you found the snmp traps ?
Would you give me some tips that how did you locate this problem?
On Thu, Oct 18, 2012 at 5:37 PM, Kent Ho wrote:
> Thanks for the replies.
>
> After examining the logs carefully. We found several devices sending snmp
> traps to the application m
Thanks for the replies.
After examining the logs carefully. We found several devices sending snmp
traps to the application making it composing large sql statements to mysql.
Statment over a meg on size on 1 line. We disabled those devices and the
problems have gone away.
Thanks.
Kent.
