Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 7 of 7 total |
DBISam Data Corruption Questions |
Fri, Feb 16 2007 5:35 AM | Permanent Link |
"Adam H." | Hi Tim,
Our current environment: DBISam 4.25b3, running via 'local' mode with various users. We're running the same app, via the same 'local' mode with various users at other sites. This is the only site that's causing us grief. We keep having corruption issues on a particular table (sometimes two) at this one site only. I'm 99% sure that it's the environment that DBISam is working in, but wanted to run a few things by you, just incase you or someone else may be able to throw me a few ideas. We're getting various kinds of corruptions (from indexes being out of date, to errors about corrupt blobs, and page buffers). Sorry - I've been slack and don't have the exact error messages on me at present, but they seem to vary. One of the interesting things I have noticed, is occasionally, if I do an Optimize table, and then immediately after I do a verify table, it has reported errors on the table I've just Optimized. (Not reproduceable, but happens from time to time). I am running the repair/verify/optimize from a different machine to where the file is located. My first question is - during an optimize, it's my understanding that a brand new file is created - which should ignore (or at least not copy) any corrupt data from the original table, if corrupt data exists (or at least raise an exception). Is this true? If that is true, then my understanding would be that an optimized table should be free from defects, unless the corruption was caused by a fault while writing the 'new' table across the network to the hard drive? If that's the case, I'm going to start my focus at the actual network connection, or the file server where the data resides (being a linux box). I personally don't have much access to this clients system as it's maintained by another IT person who's extremely concerned with security issues which makes it a little hard for me to diagnose myself (as well as me not having a limited understanding as to the setup of the whole system), so I'm thinking of moving the data to a 'less secure' location so I can work with different possibilities there. (And at least have same machine local access to the data without having to go across a network cable to repair or rebuild tables). Another thought - are their any tricks or pot holes that I should watch out for when accessing the data on a linux smb server via a windows machine in 'local' mode? (ie, wierd switches on the linux box that I should be turning off/on) that I may be able to pass on? It's late, and I'm rambling. In short - can anyone comment on the above, or make any other suggestions as to how I could try and diagnose this situation, or reduce the risk? FYI: I've tried forcebufferflush with the session component also to try and increase stability, but has not helped, which has me thinking possible network fault or hardware/software fault at the file server end. Thanks in Advance. Adam. |
Fri, Feb 16 2007 3:16 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Adam,
<< One of the interesting things I have noticed, is occasionally, if I do an Optimize table, and then immediately after I do a verify table, it has reported errors on the table I've just Optimized. (Not reproduceable, but happens from time to time). >> Did you verify the table beforehand to ensure that it wasn't corrupted prior to the Optimize ? << My first question is - during an optimize, it's my understanding that a brand new file is created - which should ignore (or at least not copy) any corrupt data from the original table, if corrupt data exists (or at least raise an exception). Is this true? >> Yes, and no. It does do a copy, but it depends upon what the corruption is in the source as to whether the corruption would carry over or not. << If that is true, then my understanding would be that an optimized table should be free from defects, unless the corruption was caused by a fault while writing the 'new' table across the network to the hard drive? >> I would not assume that an optimized table is 100% free from defects, no. The only way to determine 100% that is not the case is to do a verify or repair. << Another thought - are their any tricks or pot holes that I should watch out for when accessing the data on a linux smb server via a windows machine in 'local' mode? (ie, wierd switches on the linux box that I should be turning off/on) that I may be able to pass on? >> You'll have to check out the Samba support avenues for this, but my understanding is that the latest incarnations work just fine. << FYI: I've tried forcebufferflush with the session component also to try and increase stability, but has not helped, which has me thinking possible network fault or hardware/software fault at the file server end. >> It's possible. It could also just be an improper shutdown issue. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Feb 16 2007 5:12 PM | Permanent Link |
"Adam H." | Hi Tim,
> << One of the interesting things I have noticed, is occasionally, if I do > an Optimize table, and then immediately after I do a verify table, it has > reported errors on the table I've just Optimized. (Not reproduceable, but > happens from time to time). >> > > Did you verify the table beforehand to ensure that it wasn't corrupted > prior to the Optimize ? Yes. I actually repaired the table first, then verified it, and then optimized it. How it came about was that after I verified the table I thought 'maybe their is still a corruption that the verify hasn't picked up on', so chose to do a rebuild (via optimisation instead). > << My first question is - during an optimize, it's my understanding that a > brand new file is created - which should ignore (or at least not copy) any > corrupt data from the original table, if corrupt data exists (or at least > raise an exception). Is this true? >> > > Yes, and no. It does do a copy, but it depends upon what the corruption > is in the source as to whether the corruption would carry over or not. > > I would not assume that an optimized table is 100% free from defects, no. > The only way to determine 100% that is not the case is to do a verify or > repair. So, after doing a repair (including indexes), I should be confident that it is the best way to make sure a table is not corrupt, and if the repair is successful, and subsequent verifies say that the table is OK, then I'm pretty right? (Or is their still a possibility that somewhere, something dark is lurking within a table/index). > << FYI: I've tried forcebufferflush with the session component also to try > and increase stability, but has not helped, which has me thinking possible > network fault or hardware/software fault at the file server end. >> > > It's possible. It could also just be an improper shutdown issue. That is one of the things that we've been looking at. (And I was pretty convinced on, until I did the repair -> verify -> optimize.) I've actually noticed that it's not the 'same' table each time, but happens on various tables. It appears as though it's the same tables because they're the most common. (However, they are also the largest by a significant difference), which makes sence. Thanks for your help Tim! Cheers Adam. |
Mon, Feb 19 2007 6:50 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Adam,
<< Yes. I actually repaired the table first, then verified it, and then optimized it. How it came about was that after I verified the table I thought 'maybe their is still a corruption that the verify hasn't picked up on', so chose to do a rebuild (via optimisation instead). >> If you have a table that reports corruption after an optimization, please send it to me. I haven't seen or heard of any such thing ever with DBISAM. << So, after doing a repair (including indexes), I should be confident that it is the best way to make sure a table is not corrupt, and if the repair is successful, and subsequent verifies say that the table is OK, then I'm pretty right? (Or is their still a possibility that somewhere, something dark is lurking within a table/index). >> No, a repair will ensure that a table and its indexes and BLOB data is 100% free from structural defects. You could still have junk data in some of the columns, however. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Feb 19 2007 5:56 PM | Permanent Link |
"Adam H." | Hi Tim,
> If you have a table that reports corruption after an optimization, please > send it to me. I haven't seen or heard of any such thing ever with > DBISAM. Shall do. (I've just got to get it to replicate the program again first) > << So, after doing a repair (including indexes), I should be confident > that it is the best way to make sure a table is not corrupt, and if the > repair is > successful, and subsequent verifies say that the table is OK, then I'm > pretty right? (Or is their still a possibility that somewhere, something > dark is lurking within a table/index). >> > > No, a repair will ensure that a table and its indexes and BLOB data is > 100% free from structural defects. You could still have junk data in some > of the columns, however. Ah - yep, that's what I was meaning. (What I was wanting to verify was that once a table is repaired, their's no possibility of their still being structual problems within the table, that will cause it to corrupt more easily again). Thanks & Regards Adam. |
Thu, Feb 22 2007 1:04 AM | Permanent Link |
Sam Davis | Adam H. wrote:
>>it's maintained >>by another IT person who's extremely concerned with security issues If he is paranoid as you say does he have Norton AV/Internet Security running? It can sometimes screw up (other 3rd party) database files that are open during a scan. I'm not sure whether DbIsam is affected by Norton or not, but it's worth looking into. Sam |
Thu, Feb 22 2007 4:55 PM | Permanent Link |
"Adam H." | Hi Sam,
> If he is paranoid as you say does he have Norton AV/Internet Security > running? It can sometimes screw up (other 3rd party) database files that > are open during a scan. I'm not sure whether DbIsam is affected by Norton > or not, but it's worth looking into. Good thought. Unfortuantly though, he doesn't. They're using another antivirus software package that I'm familiar with (and use at other site) that causes no problems. Best Regards Adam. |
This web page was last updated on Tuesday, April 30, 2024 at 03:55 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |