Wednesday, March 10, 2010

Packet Too Large

While importing (restoring) a relatively large MySQL backup file, this error occured:
packet too large.
After googling for a while I found this page. So the cure is to increase max_allowed_packet in my.ini.

Thursday, March 4, 2010

Dont ever put online redo log and its mirror in one drive

Everything is fine in the last one year or so, even if the server crashed several times (maybe bad power line..). Thanks to the RAID5 mechanism (which I must re-add with manual commands each time one drive kicked out of the array), no data were lost in each of the crashes in the past.
In 25 February, 2010, my server's system crashed again. It seems that I overlooked the fact that I placed mirrlog and origlog in one partition. The mirrlogA directory contains a member of redo log group 1 & one member of redo log group 3, and origlogA directory contains another member of the same redo log group. The file in origlogA is mirrored in mirrlogA, and the thing is, I symlinked them both to the same partition (different directory, of course). The better practice is, to make those two directory (mirrlogA and origlogA) resides in different physical hard drive. If they reside in the same drive, the probability of both of the online redo log corrupted is becoming significant. And thats exactly what happened, the file in the origlog has I/O errors when I tried to read it, and the file in the mirrlog is.. corrupted.
OK, so my data weren't lost.. its just takes me a lot of hours puzzled over what should be done to my Oracle Database. First I tried to copy the second file to the first one (they should be identical, they are members of the same group). And Oracle started.. churning happily.. but not for long. As soon as I activated the Netweaver ABAP app server, errors churned in alert log. And oracle grinds to halt.

These two magic lines worked for me to solve this problem :
alter database recover until cancel;
alter database open resetlogs;

And now i moved the mirrlog to one of the RAID5 partition.