Discussion :

[splinternabs]

Bonjour,

Voila mon souci : J'effectue tous les jours des insertions dans une table sur SQL SERVER. Ces insertions sont relativement nombreuses (30000/j) avec un nombre de champs relativement important, donc pas mal de données en gros.
seulement avant de faire une insertion je controle que la données n'existe pas au sein de la table (pour éviter les doublons).
en résumé je fais :
un select
un insert
le tout 30000 fois en moyenne par jour.
le pb c'est que je risque de mettre le serveur a genoux, vu que cette méthode brutale est très consommatrice. Et les insertions prennent pas mal de temps.
N'étant pas expert BDD, et étant persuadé que ma méthode est loin d'etre la plus efficace, je sollicite votre savoir faire en la matière.
merci de bien vouloir m'indiquer des pistes ou des solutions pour ce pb.

[ylarvor]

Voila mon souci : J'effectue tous les jours des insertions dans une table sur SQL SERVER. Ces insertions sont relativement nombreuses (30000/j) avec un nombre de champs relativement important, donc pas mal de données en gros.
seulement avant de faire une insertion je controle que la données n'existe pas au sein de la table (pour éviter les doublons).
en résumé je fais :
un select
un insert
le tout 30000 fois en moyenne par jour.
le pb c'est que je risque de mettre le serveur a genoux, vu que cette méthode brutale est très consommatrice. Et les insertions prennent pas mal de temps.
N'étant pas expert BDD, et étant persuadé que ma méthode est loin d'etre la plus efficace, je sollicite votre savoir faire en la matière.
merci de bien vouloir m'indiquer des pistes ou des solutions pour ce pb.

Deux choses à regarder en priorité :

1 Le log : mode simple ou sauvegarde régulière pour éviter une taille qui gonfle...
2 La fragmentation : toutes les nuits, tu dois defragmenter ta base.

Ensuite :

tes opérations de mise à jour ont lieu toute à la meme heure ou repartie dans la journee ?

si il s'agit d'un batch, traitement massif, il peut être interessant ( a etudier par un test ) de supprimer les index avant et de les recreer apres pour réduire le temps du batch.

pour améliorer les opérations de mise à jour :

log sur un disque à part.
index sur un disque à part.

fichier mdf dimensionné à 3 ans.

enfin,

un serveur sql serveur peut supporter des frequences de mises à jour extremement importantes, il suffit de le dimensionner ( processeur, mémoire, disque ).

pour en savoir plus sur les perf de sql serveur : http://www.tpc.org/

[splinternabs]

Bonjour et merci pour ces éléments de réponses.

je vais analyser tout ca de plus près et je reviendrai donner plus de détails quant à la suite des énèments.
Par contre pour info, ce n'est pas un batch mais une petite appli développée en VB qui insert les données a partir d'un fichier texte.
On m'avait parlé de bulk insert, mais a priori cette méthode fait des insertions rapides mais en brut sans controles, ce qui ne m'arrange pas tellement (a moins qu'il y aie un moyen d'inserer des controles ce qui peut devenir intéressant).
merci encore pour ces réponses

[SQLpro]

évidemment si vous utilisez une procédure ligne à ligne cela ne peut en aucun cas aller vite !

Un SGBDR est fait pour traiter des données ensembliste et non ligne par ligne. Chaque fois que vous vous détournerez de cette fonctionnalité alors ce sera lent.
Imaginez que vous utilisez une formule 1 pour aller faire vos courses au tabac du coin. Je pense que vous mettrez plus de temps à faire votre créneau avec une formule 1 que vous n'en aurez dépensé en un aller retour si vous aviez utilisé un véhicule approprié.

Insérez vos données à l'aide de BULK INSERT dans une table temporaire dont la structure est proche de la table cible.
Rectifiez ensuite les données à l'aide de requêtes SQL UPDATE.
Au final lorsque toutes vos données sont acceptables, alors faites un INSERT INTO ... SELECT * FROM #...

A +