Roger,
Thanks for the info!
I am examining the file in a HEX editor right now and have identified the
pattern. The table size divided by the pattern byte length is 8 bytes. The
last byte is always one of three characters ('S', 'B', or 'U') as defined by
the program that feeds this table. So I *know* that part is correct. The
file size in bytes divided by 8 accurately reflects the number of rows in
the table (it is perfectly divisible, no remainder, which is either lucky or
means I used an enum() or char()).
Nonetheless, I've been going through the remaining 7 characters with a
HEX -> integer conversion, which I believe may be incorrect.
I do have a pattern in the MYD file:
F1 02 18 00 54 7A ED 01 53 <-- the first line of the file
F1 66 17 00 7C 0A 84 01 53 <-- about 80% into the file
F1 6E 11 00 FC 0E 00 00 53 <-- the last line of the file
So it's clear that the first byte is always, at least generally, F1. The
second two bytes represent something. Then there's always hex 00, followed
by three more bytes, then a 01 or 00. Of course, there are 180 million
rows... so I can't be entirely certain, but random sampling of about 1000
rows shows the pattern is true.
I'm having a time deciphering this stuff. The mediumint and int say they use
3 bytes and 4 bytes each, respectively, but using that in the table
definition yields invalid numbers.
Any ideas?
-- Robert
----- Original Message -----
From: "Roger Baklund" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Robert" <[EMAIL PROTECTED]>
Sent: Thursday, December 04, 2003 9:52 AM
Subject: Re: FRM file disappears -- any way to rebuild or recover?
> Whoops. Then we are beyond "Very difficult repair", maybe an "extremely
> difficult repair"...? ;)
>
> Do you know the max values? Do you know the combined width in the .MYD
file
> for these two columns? (16 = bigint+bigint, 12 = bigint+mediumint ... 2 =
> tinyint+tinyint)
>
> By inspecting the start of the .MYD file you should be able to see the
> record length... look for repeating byte sequences and known values...
could
> be tricky, but I don't know another way. If the third column is a varchar,
> you should see the string values, and you will have a variable record
> length. If it is a enum there will be binary values, 1, 2, 4 or 8 bytes
> could be used, depending on the number of values in the enum. Note that
the
> string values of enum columns are _only_ stored in the .frm file, the data
> file only contains an integer poining to the correct string. In other
words,
> you have to reconstruct these strings somehow, if it is an enum.
>
> > I know I used a combination of different integer types to conserve space
> > (some of the numbers will never be higher than 100K or so). However, I
> > cannot determine *what* integer types I've used. I always use unsigned,
> but
> > I cannot recall if I used NOT NULL with a default value.
>
> When there are only three columns, the NULL flags will not take any space,
> i.e. the same byte as is used for the deletion flag is also used for the
> NULL flags. In other words, it does not change the physical record length.
>
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
