Discussion :

[esa]

Bonjour à tous,

j'effectue une backup de ma DB avec un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gbak -v -t -user SYSDBA -password *** C:\....

Mais lors de la restoration avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gbak -c -r -v -p 4096 -user SYSDBA -password *** -no_validity C:\...

j'obtiens une erreur :

gbak: opened file C:\Projets\MyDB-20051011-1809.FBK
gbak: transportable backup -- data in XDR format
gbak: backup file is compressed
gbak: created database C:\Projets\MyDB.GDB, page_size 4096 bytes
gbak: started transaction
gbak: restoring domain RDB$DBKEY_LENGTH
gbak: ERROR: attempt to store duplicate value (visible to active transactions) in unique index "RDB$INDEX_2"
gbak: Exiting before completion due to errors

J'imagine que les index et les triggers y sont pour quelque chose, mais je ne sais pas comment contourner le problème et récupérer mes backups.

Si quelqu'un a déjà été confronté au problème,
merci.

[qi130]

C'est du interbase/FireBird ça, non ?

=> 1 petit tour sur le forum dédié......

Et puis j'ai l'impression que tu cherches à créer une DB interbase (GDB) à partir d'un backup Firebird (FBK)?

[esa]

C'est tout du FireBird, même si IB et FB sont compatibles.
Sur le forum, je n'ai trouvé que des questions, et les réponses ne concernaient que les switchs. Certaines parlent d'utilitaires, mais aucune solution ne fonctionne pour moi.

J'en suis à chercher comment désactiver/activer mes triggers manuellement pour faire un restore entre, et ensuite remettre les numéros à la bonne valeur. C'est coton

[qi130]

Est-ce qu'avec l'option

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

-i

lors de la restauration, elle aboutit ?

[EDIT]

En fait, dans ta commande de backup, il manquerait le -B indiquant le backup.

Et pour la restauration, d'après la doc, c'est soit -C soit -R

gbak {-c|-r} [options]......

toi, tu mentionnes les 2

[esa]

Non J'ai essayé tous les switchs.
En fait, c'est bien les triggers qui m'empechent de restorer les fiches...

[jean-jacques varvenne]

le problème provient d'une base "cassé"...

j'explique, le message

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gbak: ERROR: attempt to store duplicate value (visible to active transactions) in unique index "RDB$INDEX_2""

indique le la restauration essai de faire "entrer" une valeur qui est déjà présente dans la table, alors que tu as un index unique, ce qui est impossible!

il faut donc "voir" à trouver cette table avant le backup et y faire une commande du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
select <le champ en question>, count(1) from <ta table>
group by <le champ en question>
having count(1) > 1

pour chaque réponse, c'est une erreur...

il te faudra alors voir le pourquoi et supprimer tous les doublons!

à ton clavier...

[esa]

Lors du restore, il crée une base vierge dans laquelle il essaie d'importer des datas. Le problème est que le trigger qui fournit les IDU (numeros uniques) interdit l'ajout d'enregistrements dont l'IDU < au NextNumber.
Enfin, je crois...

Et c'est ce que j'essaies de contourner.


[EDIT]

J'ai même essayé avec une base vierge, le restore donne la même erreur.
Donc c'est le domain RDB$DBKEY_LENGTH qui le fait planter...

[lio33]

C'est vraiment problématique si la défaillance est due aux générateurs qui interdisent la restauration pour la cause que tu mentionnes. J'avoue que cela m'étonne un peu, car cela ne doit pas être une situation trés rare!

Je suis intéressé pour connaitre la solution à ce problème, s'il est réellement du à ce point là, car je vais y être confronté trés prochainement

[jean-jacques varvenne]

quand tu parle de générateur, tu pense à un trigger "before" avec à l'intérieur quelque chose du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

new.id = gen_id( mongenerateur, 1 );

est-ce à cela que tu fais référence?

si oui, la réponse et alors:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if( new.id is null )then
  new.id = gen_id( mongenerateur, 1 );

auquel cas, le générateur ne fonctionnera pas pendant la restauration, puisque "new.id" recevra une valeur provenant du backup.

note que "id" et un nom de champ comme cela, c'est à remplacer par le nom de ton champ.

cela dit, il est étrange qu'il y a un problème sur ce champ, car les champs et index rdb$... sont des éléments des tables systèmes et il est extrêmement rare d'avoir des problèmes de la sorte sur ces tables, sauf à faire du "hotfixe" directement dans ces tables... ou alors un mauvais backup (fichier endommagé) ou une base "cassé" suite à un problème disque.

autre chose, je trouve curieux que tu n'indique pas le nom de la base à restaurer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

,gbak -c -r -v -p 4096 -user SYSDBA -password *** -no_validity C:\...

je vois le nom de ce qui pourrait être le nom du backup, mais pas du nom de la base? mais je peux me tromper.

essai alors ceci...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gbak -c c:\mabase.fdb c:\lebackup.fbk -user sysdba -password ***

histoire de "voir"
cette commande minimaliste permet de restaurer une base de données.

mais je n'y crois pas trop... je reste persuadé que le problème provient d'une donnée qui est un "double" dans une colonne à index (contrainte) unique, ce qui est tout à fait anormale, mais possible lors de manipulation de la base de données.

[esa]

Effectivement, je n'ai pas mentionné les 2 noms de DB dans mon code GBAK, mais ils y figurent bien.

Oui, je parlais du générateur before et le test null est peut-être la solution, j'essaierai demain matin au bureau.

Qu'entends-tu par "hotfixe" directement sur la table ? Si tu penses à la mise à jour de l'id en dur, non, je ne le fais jamais.
Quant à la base cassée, même celle qui tourne déjà avec des enregistrements ne remonte aucune erreur de doublons, les triggers étant en place depuis le début, mais on ne sait jamais

J'insiste sur le fait que j'ai effectué le backup et le restore avec une base vide pour l'instant et j'obtiens la même erreur lors du restore:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gbak: ERROR: attempt to store duplicate value (visible to active transactions) in unique index "RDB$INDEX_2"

Merci de vos réponses et encore désolé d'avoir posté dans le mauvais forum.

[jean-jacques varvenne]

c'est franchement étrange ton problème... si la base et vide, il est impossible d'avoir cela, ta base d'origine et forcément endommagée d'une manière ou d'une autre.

ou alors ta base et loin d'être vide comme tu le pense!

mais je suis sûr que le problème et lié à un doublon dans une colonne avec une contrainte unique, le message et des plus clair à ce sujet.

un "hotfixe" consiste à faire des inserts/updates directement dans les tables systèmes, or le message référence une des tables systèmes (mais j'ignore laquelle), donc deux possibilité, ta base est endommagée, ou quelqu'un à bricolé cette table systeme, aux choix...

essai donc de trouver la table en question et passe dessus le "select...having" tu aura certainement des surprises!

[TMuet]

Problème déjà constaté également sous Firebird.
Il accepte dans certains cas (que je n'ai pas encore précisemment établis) d'insérer des doublons sur la clé primaire

Or, lors de la restauration, l'application des contraintes d'intégrité détecte le problème et échoue.
Le backup n'a rien détecté.

Il suffit de restaurer sans les constraintes d'intégrité.

[esa]

J'ai déjà testé avec -no_validity et c'est pareil
C'est une base FireBird.

[esa]

Je viens de créer une autre base en partant de zero et là tout fonctionne correctement.
J'avais donc un problème dans la structure (identique pourtant) de l'autre base, surement corrompue, même après avoir supprimé tous les enregistrements de toutes les tables.

Merci à tous pour vos réponses.