Subject | Re: [firebird-support] gfix mend full deadlock |
---|---|
Author | Leonardo Carneiro |
Post date | 2011-11-24T18:44:40Z |
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:
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[Non-text portions of this message have been removed]
> =(
>
> 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
>>
>>
>>
>>
>