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" <chesterman86@...>
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
<chesterman86@...>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 <chesterman86@...
> > 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, ak@... <ak@...> 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" <chesterman86@...>
>>> 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]