Violation Primary Key incohérente

Bonjour,

J'utilise l'ETL Genio pour réaliser l'alimentation d'une table sur SQL Server 2008.
Cette table possède une PK sur 5 colonnes.

Avant de réaliser une insertion de données, cette table est vidée par une instruction DELETE.
Les lignes à insérer, au nombre de 5 000 000, sont uniques (vérification faite maintes et maintes fois) mais leur insertion provoque un nombre incalculable d'erreur de violation de PK, malgré la suppression des données avant traitement.

Si je remplace ma purge DELETE par une instruction TRUNCATE, l'insertion des données se passe sans problème. (mais je ne peux garder cette solution, car j'ai absolument besoin de pouvoir faire un ROLLBACK)

Ma question donc : est-il possible qu'au niveau des index il y ait une persistance de mes PKs, et si oui comment faire pour s'en affranchir ?
Ou si vous avez toute autre proposition concernant ce problème, je suis preneur.

Merci d'avance pour votre aide.

Quels sont les messages d'erreur ?

Avant d'avoir cette on va se perdre en conjecture....

A +

Le fonctionnement des logs dans l'ETL Genio est un peu particulier car il traite les lignes par packet...

Toujours est il qu'il me renvoie cette erreur pour énormément de lignes :

Citation:

---

[Microsoft][SQL Server Native Client 10.0][SQL Server]Violation of PRIMARY KEY constraint 'PK_FAITS_TESTS_PK'. Cannot insert duplicate key in object 'dbo.FAITS_TESTS_PK'. The duplicate key value is (4, 2009, 6, SU641, N.1123.S).
01000
[Microsoft][SQL Server Native Client 10.0][SQL Server]The statement has been terminated.
23000

---

Jusquà ce qu'a priori, ces erreurs bloquent les logs de la base, car l'erreur suivante est renvoyée :

Citation:

---

37000
[Microsoft][SQL Server Native Client 10.0][SQL Server]The transaction log for database 'MSTR_REP_FCE' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

---

A noter que le traitement commence à planter lorsqu'il atteint les 4 500 000 lignes environ...

je pense que c'est plutôt du à une mauvaise utilisation de l'ETL qu'autre chose....
je pense à une mauvaise parallélisation.
Faite en sorte de vérouiller la table le temps de cette insertion et agir en mono thread (MAXDOP = 1)

A +

Merci pour votre réponse.

En fait, sur cet ETL, il n'est pas possible de préciser l'utilisation d'un mono thread. En l'occurrence, cela ne posait pas de problème car les traitements de purge et d'alimentation était effectués séquentiellement.

Après diverses investigations, nous avons finalement pu déterminer que le problème venait de la taille allouée au fichier de log. Celui-ci ne pouvait plus s'étendre et donc ne prenait pas toutes les informations de suppression. Il en résulté les problème de violation de clés.

Il ne faut pas accuser un des meilleurs (mais mourant) ETL du marché à tort et à travers !

De mémoire le (MAXDOP = 1) se précise en fin de requête dans les options, c'est dès lors tout à faire possible de le rajouter via un dataset (dans les zones d'éditions sans toucher à la requête).

Au passage, il est renommé en OTIC (OpenText Integration Center) à partir de la version 7.1.

Et enfin, avec SQL-Server l'opération TRUNCATE est annulable, à voir comment ça se goupille dans OTIC, j'avoue n'avoir jamais essayé.

Bonjour,

Je n'accuse personne et certainement pas Genio (ou OTIC plutôt c'est vrai) car je l'utilise tous les jours et en suis très content.

Néanmoins, je ne trouvais pas et ne trouve toujours pas comment paramétrer le MAXDOP = 1. Si tu as plus d'éléments là-dessus, ça m'intéresse. Qu'entends-tu par "fin de requête, dans les options" ? J'ai regardé côté Connexions, Datasets, et Modules et je n'ai rien vu de tel. Ou alors faut-il forcer le SQL pour le préciser quelquepart ?

Et de toute évidence je ne suis pas venu pour rien car un TRUNCATE annulable ? J'apprends encore quelquechose de très intéressant. Bien que je ne vois pas non plus comment le mettre en place.

Je ne l'ai pas tout de suite sous la main, mais dans le dataset sur l'onglet où il y a le SQL, on peut éditer des bouts de requête en bas sans forcément toucher à toute la requête. Ça permet de limiter les impacts des éditions.

Pour le truncate annulable :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

create table dbo.Test_truncate ( id int);   insert into dbo.Test_truncate (id) values (1);   begin transaction   select 'PRE-TRUNCATE' as ope, id from dbo.Test_truncate;   truncate table dbo.Test_truncate;   select 'POST-TRUNCATE' as ope, id from dbo.Test_truncate;   rollback transaction   select 'ROLLBACK' as ope, id from dbo.Test_truncate;       ope id ------------ ----------- PRE-TRUNCATE 1   (1 row(s) affected)   ope id ------------- -----------   (0 row(s) affected)   ope id -------- ----------- ROLLBACK 1   (1 row(s) affected)

---