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]