data page type = 1. Slot Offset is read wrong #29
Comments
|
You mention that when you read the physical file, the slot offset starts at 478. But what physical file are you reading? Are you reading the backup file itself (.bak)? If so - how are you doing that? OrcaMDF is only made to work on MDF files. What are you using to read the data file, |
|
Both backup file and mdf file restored from the backup reads 478 instead of 222. MDF file attached to MSSQL with DBCC PAGE([database], 1, 1560, 3) reads 222 in the output of the command even though a direct physical read of the same MDF reads 478. From: Mark S. Rasmussen [mailto:notifications@github.com] You mention that when you read the physical file, the slot offset starts at 478. But what physical file are you reading? Are you reading the backup file itself (.bak)? If so - how are you doing that? OrcaMDF is only made to work on MDF files. What are you using to read the data file, Database or RawDatabase? — |
|
does it matter? You read offsets of any king of page for any moethod from the end by 2 bytes as many times as slots count in the header and the method is private void parseSlotArray(){ for (int i = 0; i < Header.SlotCnt; i++) and |
|
I would think it is a partial write during backup. So there suppose to be uncommited kind of transaction sopmewhere in the bakup file that generated MDF in a log or in the page itself and i am not sure where to look for it |
|
I have seen similar stuff happen when I took at 2008 database and restored it in a 2008 R2 server. One bit in the slot array flipped when I looked at DBCC PAGE, but the on-disk structure had the opposite bit. I never found out why, but all data was still there so I didn't have much incentive to really look into it. Let me ask another question - are you missing data or is this more of an academical adventure? Is the database a 2008 R2 version? The OrcaMDF Database class (which I can see you're using) only supports straight 2008 R2 databases, whereas RawDatabase will work on 2005-2012, but only parses the physical structures and nothing more. |
|
Yes i do miss data not physicly but I can not map it. Say if slot number is wrong then I start reading record at slot 0 at address 478 instead of 222. So record is wrong and I have a lot of thouse. Also say you have 2 fields Name and Last Name, varchar and they are written at the end of record in this way: MarkRasmussen. If your last name adddress is shifted by one bit say instead of reading stars at index 5 it would say 4 or 6 you would get your last name to be either kRasmussen or asmussen. So it is a big problem. Another case: if bit is missplaced in your name you might get instead of Mark, Lark or Nark, basicly + - 1 on your next letters. The only positive thing I see that missplaced bit happens only once on the page. I know that this is for databases that have havy multiuser use so they do lots of IO operations. I looked into Tornbit in the header trying to see if info how to fix it there but could not make anything of it. No Torn Page error is raised and db reads data clean so the info how to fix thew page is there either in mdf or in log file but I am not sure. COuld be ven in the page itself. |
|
the database is 2005 |
|
Hi Mark, I simplified the database removed all client sensitive data so many errors got fixed when I shrunk the database. But I am lucky there is still one there that shows the problematic behavior. Here are the cords: ObjectId = 245575913 When attached to SQL server data displayed correctly with no errors: DBCC TRACEON(3604) Shows: Row - Offset |
|
thoose are coords of: |
|
so now what I found is that if you update that record any field you wil lget it fixed in the mdf file. Slot will become 834. So it is there pending somewhere in the db files the question is where and how to read it. |
|
322 -> 0100001010000000 |
|
basicly that makes yours and mine approach of reading direct data useless in a real enviroment. That is why i am thinking it is important to fix it and find out what is going on. I had same thing i saw it once in a test file and thought it will never happen enogth to make it uselees. But now I have a datbase on my hands that has over 1K of errors of this type and even htough I read 99.9 % of the data enability of reading 100% makes all 99.9% effort useless :( |
|
it is like one would charge a client $5 for cup of coffee and everything works OK but once a day one would charge 1mil dollars accidentely on their credit card even though one put $5 in for the price, that makes operations impossible :( |
Hi Mark,
I have a question regarding ORCAMDF project and particularly about reading simple records data page pagetype = 1.
I have a full backup file for mssql database.
There is a page index 1560 in the file and it has 50 slot offsets (50 records in it).
When I read physical page from the file first slot offset reads as 478. When I restore the backup and run:
DBCC PAGE([database], 1, 1560, 3) it reads first slot offset as 222. MDF file in restored database still reads first slot as 478 even though server somehow knows it is 222. I only get to see 222 on the page if I do an update to that page:
UPDATE Vehicle SET VIN = ‘test’ WHERE Vehicle ID = 1433
Now I do see 222 in mdf file.
I have a lot of fields like that with just 1 bit difference in them:
478 -> 0111101110000000
222 -> 0111101100000000
Only 1 bit difference. I understand it is because that bit did not get updated during the backup time but was logged somehow in the backup file. Would you help me to find where I can get the differential info in the backup? In other words how can I fix my data page with the info included in the backup.
I can send you the full backup file if you need it too.
Thank you very much,
The text was updated successfully, but these errors were encountered: