Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Double index problem [CORE4078] #4406

Open
firebird-automations opened this issue Apr 9, 2013 · 7 comments
Open

Double index problem [CORE4078] #4406

firebird-automations opened this issue Apr 9, 2013 · 7 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Marcin Olejarczyk (tomas_1)

Is related to CORE3610

During restoring my database I received such error:

gbak:cannot commit index DRC_DOC_PK
gbak: ERROR:attempt to store duplicate value (visible to active transactions) in unique index "DRC_DOC_PK"
gbak: ERROR:action cancelled by trigger (3) to preserve data integrity
gbak: ERROR: Cannot deactivate index used by a PRIMARY/UNIQUE constraint
gbak:Exiting before completion due to errors

I have checked my DRT_DOCUMENTS table definition:

CREATE TABLE DRT_DOCUMENTS
(
DOC_ID INTEGER NOT NULL,
DOC_CREATION_TIME TIMESTAMP NOT NULL,
DOC_PAT_ID INTEGER,
DOC_PRINT_TIME TIMESTAMP,
DOC_STATUS SMALLINT NOT NULL,
DOC_TEMPLATE VARCHAR( 300) NOT NULL COLLATE PXW_PLK,
DOC_TYPE INTEGER NOT NULL,
DOC_USR_ID INTEGER NOT NULL,
DOC_AUDIT_CB VARCHAR( 50) DEFAULT user NOT NULL COLLATE PXW_PLK,
DOC_AUDIT_CT TIMESTAMP DEFAULT current_timestamp NOT NULL,
DOC_AUDIT_MT TIMESTAMP,
DOC_AUDIT_CNT INTEGER DEFAULT 0 NOT NULL,
DOC_C_USR_ID INTEGER,
DOC_M_USR_ID INTEGER,
DOC_PRODUCT_VERSION VARCHAR( 20) COLLATE WIN1250,
CONSTRAINT DRC_DOC_PK PRIMARY KEY (DOC_ID)
);

And this is a result of select 'SELECT * FROM DRT_DOCUMENTS WHERE DOC_ID = 91570' command:

DOC_ID DOC_CREATION_TIME DOC_PAT_ID DOC_PRINT_TIME DOC_STATUS DOC_TEMPLATE DOC_TYPE DOC_USR_ID DOC_AUDIT_CB DOC_AUDIT_CT DOC_AUDIT_MT DOC_AUDIT_CNT DOC_C_USR_ID DOC_M_USR_ID DOC_PRODUCT_VERSION
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
91570 2013-02-22 14:41:41 3672 2013-02-22 14:42:18 2 A4_FO_FI_REHAB.fr3 10 11 CLIENT 2013-02-22 14:42:18 0 11 3.40.0.0
91570 2013-02-22 14:51:26 3672 2013-02-22 14:51:47 2 A4_FO_FI_REHAB.fr3 10 11 CLIENT 2013-02-22 14:51:47 0 11 3.40.0.0

How is it possible that there are two instances of the the same indexe '91570' on the same table?

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

The index could get corrupted before you perform a backup. Did you run validation against the original database? Any suspicious records in firebird.log?

And it would be better to move to the firebird-support mailing list, as the tracker is a wrong place for asking and answering questions.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

priority: Critical [ 2 ] => Major [ 3 ]

security: Developers [ 10012 ] =>

@firebird-automations
Copy link
Collaborator Author

Commented by: Marcin Olejarczyk (tomas_1)

Of course, index get corrupted before backup and this is a fault in my opinion.
We use all the time 2.5.2 version of Firebird, so maybe issue Core-3610 has not been fixed correctly on 2.5.2.

firebird-support mailing list is for question/answer about Firebird functionality, but in my opinion this is a fault which caused our system crash.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue is related to CORE3610 [ CORE3610 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

You're correct, but unfortunately we can do almost nothing without a reproducible test case. For the time being, I'm linking this ticket to CORE3610 in a hope that some insight will happen.

@firebird-automations
Copy link
Collaborator Author

Commented by: Marcin Olejarczyk (tomas_1)

I checked client side and unfortunatelly there is no requirement to run validation against the original databas :(
About firebird.log - client has uninstall Firebird with removing all log files.

@firebird-automations
Copy link
Collaborator Author

Commented by: Marcin Olejarczyk (tomas_1)

Please close it - We will register new issue with necessary log files in case of the same problem in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant