MySQL Forums
Forum List  »  Data Recovery

cant reovey data
Posted by: Amin El-Zein
Date: January 09, 2014 05:44AM

hello,
i have mysql server 5.0
i have a fu data storage and i dont have anybackup it tried to restore ibdata1 and frm and log files but when i set innodb foce recovery to 4 or 5 or 6 it's give me this log file:

nnoDB: The user has set SRV_FORCE_NO_LOG_REDO on
InnoDB: Skipping log redo
InnoDB: Error: page n:o stored in the page read in is 4275744496, should be 7!
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.
InnoDB: You may have to recover from a backup.
140109 13:34:51 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex a34acb9ffedaaef07983d2baec90232a363ecac862782128dfcbd41f1c12652da33069a14d79286995 @ sl Vc )E 4 T ua ! W g y'| ; b z [ )6 : N~ H Y E d ,~! vc) l 7 + On8 s, 0 = z b( _# "L:!D N8 G 8D yd : P V{ p( : i ` A D8 $ Q ~ F Y~F0(h >;InnoDB: End of page dump
140109 13:34:51 InnoDB: Page checksum 3313674583, prior-to-4.0.14-form checksum 2530488021
InnoDB: stored checksum 2739587999, prior-to-4.0.14-form stored checksum 113581822
InnoDB: Page lsn 910084808 1652039976, low 4 bytes of lsn at page end 2309813054
InnoDB: Page number (if stored to page already) 4275744496,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 1772178809
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
InnoDB: Error: page n:o stored in the page read in is 1064579791, should be 3!
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 3.
InnoDB: You may have to recover from a backup.
140109 13:34:51 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex "} J <@ ~tN|p -bq qHC y D w { [a C : 8 = , M < V` Gd5 E W C w . ^%L " U Q e k Zj =$ j l# r _ : I s p+ @ 1 ) I 5B g Zu! V ;InnoDB: End of page dump
140109 13:34:51 InnoDB: Page checksum 3446027269, prior-to-4.0.14-form checksum 608971063
InnoDB: stored checksum 3518502659, prior-to-4.0.14-form stored checksum 3260708129
InnoDB: Page lsn 1006802876 1749312083, low 4 bytes of lsn at page end 4250323619
InnoDB: Page number (if stored to page already) 1064579791,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 3984535542
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 3.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
140109 13:34:51 InnoDB: Error: trying to access tablespace 3651632377 page no. 2282727790,
InnoDB: but the tablespace does not exist or is just being dropped.


tha last two lines is always repated and the sql server going to starting service and the log file is going to be to larg.
so what i have to do ?
thanks.

Options: ReplyQuote


Subject
Views
Written By
Posted
cant reovey data
2614
January 09, 2014 05:44AM
1250
January 10, 2014 04:47AM
1160
January 21, 2014 12:03AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.