Subject | Re: [firebird-support] gfix mend full deadlock |
---|---|
Author | Leonardo Carneiro |
Post date | 2011-11-24T18:19:18Z |
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 =(
=(
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]