I think FBFirstAId will not help in this case. If you still have backup, you can try to save data from it with IBBackupSurgeon - look with trial first.
Regards, Alexey Kovyazin ----- Reply message ----- From: "Leonardo Carneiro" <chesterma...@gmail.com> To: <firebird-support@yahoogroups.com> Subject: [firebird-support] gfix mend full deadlock Date: Thu, Nov 24, 2011 23:10 Tried IB-FirstAid+ trial, but gives me this messagem: 18:08:33 INFO: Open database files: C:\Arquivos de programas\DDD_SYSTEM\Servidor\BD_COPY.FDB 18:08:33 Unrecognized database found. On Thu, Nov 24, 2011 at 4:44 PM, Leonardo Carneiro <chesterma...@gmail.com>wrote: > Wow, last error crashed the firebird process =P. Could not connect to > others database in the same server. Had to kill the process =( > > > On Thu, Nov 24, 2011 at 4:19 PM, Leonardo Carneiro <chesterma...@gmail.com > > wrote: > >> Yep. When i first saw the mess, i deeply regreted the use of the -r >> switch =( >> >> Tried a -mend again: >> >> C:\Arquivos de programas\Firebird\Firebird_2_1\bin>gfix -mend -full -user >> SYSDBA -pas masterkey "c:\Arquivos de >> programas\DDD_SYSTEM\Servidor\BD_COPY.FDB" >> unable to allocate memory from operating system >> >> and in log: >> >> VGLDAS2K346 (Server) Thu Nov 24 14:43:17 2011 >> Database: ThreadData::start() failed: >> operating system directive _beginthreadex failed >> Espaço insuficiente de armazenamento para processar este comando. >> *(Insuficient storage space to process this comand). >> >> VGLDAS2K346 (Server) Thu Nov 24 15:33:24 2011 >> bugcheck during scan of table 132 (COMUNICACAO) >> >> >> VGLDAS2K346 (Server) Thu Nov 24 15:59:05 2011 >> Database: C:\ARQUIVOS DE >> PROGRAMAS\VELTRAC_CLIENTE_SERVIDOR\SERVIDOR\CÓPIA DE BD_CLIENTE.FDB >> internal gds software consistency check (page in use during flush (210), >> file: cch.cpp line: 2968) >> >> >> Which is very odd, since there is planty of free memory and disk space =( >> >> On Thu, Nov 24, 2011 at 5:11 PM, a...@ib-aid.com <a...@ib-aid.com> wrote: >> >>> That's why I always insist to do not use -r switch. >>> I'll create ticket to exclude it completely from gbak, even if we will >>> loose some money from such unlucky guys :) >>> >>> Regards, >>> Alexey Kovyazin >>> IBSurgeon Ltd (www.ib-aid.com) >>> >>> ----- Reply message ----- >>> From: "Leonardo Carneiro" <chesterma...@gmail.com> >>> To: <firebird-support@yahoogroups.com> >>> Subject: [firebird-support] gfix mend full deadlock >>> Date: Thu, Nov 24, 2011 20:08 >>> >>> >>> Hi everyone, >>> >>> I'm having a quite bad time with one database. The firebird version is >>> 2.1.4, running on a windows server 2003 r2 enterprise. For some weird >>> reason, the previous administrator thought that would be fun to disable >>> forced writes while in production, so the database was running this way >>> for >>> quite some time. Oddly, at that point, it was running fine. >>> >>> Last week I did some huge deletes, so i though it would be a good idea to >>> do backup/restore. I did the backup and the restore, overwriting the old >>> database, but now i'm having some troubles. Many indexes wasn't enabled >>> during the restore because a huge number of dup rows appeared in various >>> tables. I tried very hard to remove these dup rows, but without success. >>> In >>> one big table, i found more than 17.000 dup rows! >>> >>> Here is what i did: >>> >>> Created a non-unique index so i can search the table faster. >>> Found the dup IDs with: SELECT id FROM table GROUP BY id HAVING count(*) >>> > >>> 1; --> took about 40 minutos. brought about 1200 IDs that have 2 or more >>> duplicates >>> Made a copy of these dup rows in a file: SELECT * FROM table WHERE id IN >>> (IDs from the first command); --> almost instantly, using the new created >>> index >>> Tried to delete the dup rows: DELETE FROM table WHERE id IN (IDs from the >>> first command); runned for more that 10 hours and nothing!!!! >>> >>> Also tried the following: >>> EXECUTE BLOCK >>> AS >>> DECLARE id INT; >>> DECLARE tuple_id char(8); >>> BEGIN >>> FOR >>> SELECT id >>> FROM table >>> GROUP BY id >>> HAVING count(*) > 1 >>> INTO :id >>> DO >>> FOR >>> SELECT min(RDB$DB_KEY) >>> FROM table >>> WHERE id = :id >>> INTO :tuple_id >>> DO >>> DELETE FROM table where id = :id AND RDB$DB_KEY > :tuple_id; >>> END >>> >>> But after 40 minutos it ended up with an generic error (sorry, don't >>> remenber exactly). Looking at firebird.log, i did found the following: >>> internal gds software consistency check (Attempt to call >>> GlobalRWLock::unlock() while not holding a valid lock for logical owner) >>> >>> Finally, tried to execute a gfix mend full in a copy of the database, but >>> after a couple of hours, it simply returned the word "deadlock": >>> >>> C:\Arquivos de programas\Firebird\Firebird_2_1\bin>gfix -mend -full -user >>> SYSDBA -pas masterkey "c:\Arquivos de >>> programas\DDD_SYSTEM\Servidor\BD_COPY.FDB" >>> deadlock >>> >>> >>> Now i did a full validate. It took about 4 hours, but did gave any >>> output. >>> Any word on what i can do? >>> >>> Tks in advance. >>> >>> >>> [Non-text portions of this message have been removed] >>> >>> >>> >>> [Non-text portions of this message have been removed] >>> >>> >>> >>> ------------------------------------ >>> >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >>> Visit http://www.firebirdsql.org and click the Resources item >>> on the main (top) menu. Try Knowledgebase and FAQ links ! >>> >>> Also search the knowledgebases at http://www.ibphoenix.com >>> >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Yahoo! Groups Links >>> >>> >>> >>> >> > [Non-text portions of this message have been removed] [Non-text portions of this message have been removed]
