| Subject | Re: [firebird-support] Repeated database corruption |
|---|---|
| Author | Gustavo |
| Post date | 2009-10-24T00:00:50Z |
If my previous mail was surprising, this one is even better. Read...
Since I send you my previous e-mail, nobodoy worked in this enterprise because they are not there. They went home (I suppose) to enjoy their weekend.
After sending my previous mail, I connected again to this enterprise via terminal server, I run my application, I enter the option to make backup and I started a backup. The only thing this option makes is to execute gbak (using CreateProcess). After a few seconds I got an error. I close the application, tried again to do the backup and again an error. I tried a third time and again an error. In firebird.log I saw the following:
internal gds software consistency check (page in use during flush (210), file: cch.cpp line: 2965)
So I copied the database to another folder, I tried to make the backup running gbak in a DOS window and I got the same error.
I did gfix -v -full and I got the same error.
So I renamed the database and put in his place the copy I used in my previous e-mail, which was exactly the same because nobody used the application since I made the copy. I did backup again using my application, and everything was good.
After this, I renamed again the copies of the database so the application uses again the original one (the one who failed doing backup a few minutes before) and tried again to do a backup with my application. My surprise was very big because I got NO ERRORS!
So... the same database (the same file!) gives error five times with gbak and gfix, and a few minutes later, without doing nothing, the file is magically good!
Am I crazy? Perhaps this is true also ;-) but... does anyone have an idea of what may be happening?
Since I send you my previous e-mail, nobodoy worked in this enterprise because they are not there. They went home (I suppose) to enjoy their weekend.
After sending my previous mail, I connected again to this enterprise via terminal server, I run my application, I enter the option to make backup and I started a backup. The only thing this option makes is to execute gbak (using CreateProcess). After a few seconds I got an error. I close the application, tried again to do the backup and again an error. I tried a third time and again an error. In firebird.log I saw the following:
internal gds software consistency check (page in use during flush (210), file: cch.cpp line: 2965)
So I copied the database to another folder, I tried to make the backup running gbak in a DOS window and I got the same error.
I did gfix -v -full and I got the same error.
So I renamed the database and put in his place the copy I used in my previous e-mail, which was exactly the same because nobody used the application since I made the copy. I did backup again using my application, and everything was good.
After this, I renamed again the copies of the database so the application uses again the original one (the one who failed doing backup a few minutes before) and tried again to do a backup with my application. My surprise was very big because I got NO ERRORS!
So... the same database (the same file!) gives error five times with gbak and gfix, and a few minutes later, without doing nothing, the file is magically good!
Am I crazy? Perhaps this is true also ;-) but... does anyone have an idea of what may be happening?
----- Original Message -----
From: Gustavo
To: firebird-support@yahoogroups.com
Sent: Friday, October 23, 2009 7:47 PM
Subject: Re: [firebird-support] Repeated database corruption
I have just connected to this enterprise via terminal server to uninstall FB 2.1 CS and install FB 2.1 SS again. Before doing that I copied the database and checked it doing gfix -v -full and... I had the surprise that it was perfect. No errors! I repeated it many times and did it with different copies of the database. I also made a backup doing gbak -v -ignore -garbage -limbo and it did without any problem.
So I didn?t change FB and I left CS.
But, as you can see in the firebird.log of today at the end of this message, today they had many errors. Most of them were "INET/inet_error: read errno = 10054" and many were "internal gds software consistency check (wrong record length (183), file: vio.cpp line: 1121)".
At approx. 10:30hs they had to restart the server to can access the database.
How can it be possible that firebird.log has this errors and now the database is good?
-----------------------
firebird.log 23/10/2009
-----------------------
SERVIDOR Fri Oct 23 10:02:37 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:02:37 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:02:37 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:02:37 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:08:35 2009
Database: MMGESCOMEMPRESA
internal gds software consistency check (wrong record length (183), file: vio.cpp line: 1121)
SERVIDOR Fri Oct 23 10:08:35 2009
Database: MMGESCOMEMPRESA
internal gds software consistency check (wrong record length (183), file: vio.cpp line: 1121)
SERVIDOR Fri Oct 23 10:09:33 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:09:33 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:09:33 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:09:33 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:11:28 2009
Database: MMGESCOMEMPRESA
internal gds software consistency check (wrong record length (183), file: vio.cpp line: 1121)
SERVIDOR Fri Oct 23 10:11:28 2009
Database: MMGESCOMEMPRESA
internal gds software consistency check (wrong record length (183), file: vio.cpp line: 1121)
SERVIDOR Fri Oct 23 10:11:39 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:11:39 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:11:39 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:11:39 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:14:36 2009
Database: MMGESCOMEMPRESA
internal gds software consistency check (wrong record length (183), file: vio.cpp line: 1121)
SERVIDOR Fri Oct 23 10:14:36 2009
Database: MMGESCOMEMPRESA
internal gds software consistency check (wrong record length (183), file: vio.cpp line: 1121)
SERVIDOR Fri Oct 23 10:14:47 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:14:47 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:14:47 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:14:47 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:16:41 2009
Database: MMGESCOMEMPRESA
internal gds software consistency check (wrong record length (183), file: vio.cpp line: 1121)
SERVIDOR Fri Oct 23 10:16:41 2009
Database: MMGESCOMEMPRESA
internal gds software consistency check (wrong record length (183), file: vio.cpp line: 1121)
SERVIDOR Fri Oct 23 10:17:44 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:17:44 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:17:44 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:17:44 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:18:10 2009
Database: MMGESCOMEMPRESA
internal gds software consistency check (wrong record length (183), file: vio.cpp line: 1121)
SERVIDOR Fri Oct 23 10:18:10 2009
Database: MMGESCOMEMPRESA
internal gds software consistency check (wrong record length (183), file: vio.cpp line: 1121)
SERVIDOR Fri Oct 23 10:18:37 2009
Database: MMGESCOMEMPRESA
internal gds software consistency check (wrong record length (183), file: vio.cpp line: 1121)
SERVIDOR Fri Oct 23 10:18:37 2009
Database: MMGESCOMEMPRESA
internal gds software consistency check (wrong record length (183), file: vio.cpp line: 1121)
SERVIDOR Fri Oct 23 10:19:54 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:19:54 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:19:54 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 10:19:54 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 13:13:49 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 13:13:49 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 13:13:49 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 13:13:49 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 15:47:45 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 15:47:45 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 15:47:45 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 15:47:45 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 15:49:00 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 15:49:00 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 15:49:00 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 15:56:16 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 15:56:16 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 15:56:16 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 17:51:40 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 17:51:48 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 17:51:48 2009
INET/inet_error: read errno = 10054
SERVIDOR Fri Oct 23 17:51:48 2009
INET/inet_error: read errno = 10054
[Non-text portions of this message have been removed]
__________ InformaciĆ³n de NOD32, revisiĆ³n 4534 (20091022) __________
Este mensaje ha sido analizado con NOD32 antivirus system
http://www.nod32.com
[Non-text portions of this message have been removed]