Discussion :

[kssillati]

Salut a tous,
j'ai une table que je met à jour en utilisant une table intermidiaire(que je vais appeler Cache). sur ma table cache je n'ai aucune clé aucun index de sorte que la copie y est plus rapide ensuite je update ma table principale avec les donnees contenu dans le cache. A la fin de la mise a jour je vide mon cache, et la table cache libère également l'espace disque quelle utilisait, pas la toitalité mais une grande partie(80 a 95%).
Cela marchais tres bien jusqu'a aujourd'hui ou je constate que la table cache ne libère plus Lespace disque et je rencontre dans l'exécution de mon packet(visualstudio) qu'il ya un bloquage.Grace a la procedure

Code :

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

1
2
3
4
SELECT W.session_id, S.login_name, S.host_name, S.program_name , W.wait_duration_ms, W.wait_type, W.blocking_session_id, W.resource_description
FROM sys.dm_os_waiting_tasks W
INNER JOIN sys.dm_exec_sessions S ON S.session_id = W.session_id
WHERE blocking_session_id IS NOT NULL

je peux voir que mon packet est bloque. Mais quand je Kill le processus et que je relance il y'a a nouveau un bloquage.
J'ai recréé ma table Cache, mai apres une premiere execution sans probleme,le probleme survient encor a la deuxieme execution.

merci de votre aide

[SQLpro]

Salut a tous,
j'ai une table que je met à jour en utilisant une table intermidiaire(que je vais appeler Cache). sur ma table cache je n'ai aucune clé aucun index de sorte que la copie y est plus rapide

Vous commettez d'emblée deux erreurs : faire du cache manuellement, alors que le SGBDR le fait de manière optimisé et ne pas mettre de clef ou d'index dans une table.
Pour ce dernier cas, quelque soit votre but, il faut toujours avoir une clef dans une table par définition, sinon vous irez TOUJOURS PLUS LENTEMENT !
En effet n'importe quel ordre SQL de mise à jour (INSERT, UPDATE, DELETE) commence par effectuer un SELECT positionnel. Sans index, c'est un parcours de toute la table (SCAN). Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p7...d-index-ni-de/

Commencez par nous décrire votre traitement, car à mon avis vous êtes à côté de la plaque en matière de traitement SGBDR ce qui provoque ces problème. En effet, vous utilisez visiblement l'outil à contresens ce qui est généralement totalement anti-performant.
Imaginez combien c'est dur de couper un steak avec un couteau mais pas du le coté lame !

A +

[kssillati]

Merci pour toute ces observation , elles sont tres pertinante,
le but de mon traitement est mettre ma base de données a partir d'un fichier csv. Dans le fichier csv il n'esiste pas de clés, une meme information peut aparaitre plusieurs fois. Je faisai l'importation directement sur ma table principale (qui contient clé et index) mais j'avais des resultat pas tres rapide a mon gout.d'ou l'utilisation de ce cache qui a augmenter la rapidité.
et j'utilise ce proceder depuis un bon moment sans probleme. mais maintenan j'ai un probleme de blockage au niveau de ma table cache. ok merci de l'aide et comment faire pour utiliser le cache du SQL a chaque update en gardant la structure de la table (le update se fait a partir de plusieur fichier different.)
merci.

[SQLpro]

1) créez une table d'import contenant les même colonnes que la table cible ou le fichier mais avec toutes les colonnes de type VARCHAR...
Cette table doit avoir une clef primaire de type autoincrément et pour la remplir faites la chose suivante :

Code :

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

1
2
3
4
TRUNCATE MaTable;
BULK INSERT MaTable
FROM 'mon_fichier' 
WITH ( BATCHSIZE = 64);

2) nettoyez les données de cette table par des requêtes SQL

3) indexez cette table sur la/les colonne(s) servant de lien avec la table cible

4) mettez à jour la table cible avec MERGE qui permet en une seule passe de faire INSERT, UPDATE ou DELETE selon le cas.

5) après insertion, supprimez l'index et videz éventuellement cette table avec un TRUNCATE.

A +