Bonjour,
J'ai besoin de mettre régulierement à jour une base de données SQL
Server 2k hébergé sur un bi Xeon 2,4 GHz - 1 Go de RAM
Cette mise à jour s'effectue via un programme (développé en c++ sous
Builder C++) à partir d'un fichier xls via un serveur ole/com.
Cette base de données occupe 1,1 Go (Data+journaux).
Les tables à mettre à jour comportent 300.000 lignes pour l'une et
4.700.000 lignes pour la seconde. (2ieme table: table de liaison (m,n)
entre table 1 et une 3ième table)
Adresse ---(NumAdr)--> AdrPrest <----(NumPrest)---- Prestataire
1 2 3
Le problème est la lenteur de ces mises à jour :
environ 300 lignes par heure....gloups...
le prog de mise à jour s'execute sur un poste client où l'activité proc
est faible. Par contre les proc sur le serveur sont à 95-100 %
continuellement. La mémoire physique est pleine mais pas saturée (pas de
swap)
L'algo général de cette mise à jour est le suivant :
( si l'adresse n'existe pas elle est créée puis la table 2 est mise à
jour, si l'adresse existe seule la table 2 est mise à jour)
Chaque ligne comporte une premiere serie d'infos sur une adresse
(rue,ville...) puis une 2ieme série avec des prestataires par categorie
Pour chaque ligne du fichier Excel :
1 - recherche de l'adresse en prenant en compte env. 10 champs (select
NumAdr where Rue=..., NumAppart=..., CodePostal=...,...soit 10 champs)
-> si elle n'existe pas: requete INSERT puis SELECT IDENT_CURRENT...
2 - mise à jour de la table 2:
- 2a : on efface les enregistrements de la table ayant le NumAdr
- 2b : on crée les enregistrements selon les infos du fichiers
excel ( environ une petite vingtaine de INSERT...)
Eventuellement, un prestataire inexistant est crée dans table 3.
J'ai ajouté 512 Mo de RAM dernièrement sans noter d'amélioration sensible.
Quelles pistes me proposez-vous?
J'ai perso pensé à:
- optimiser les requetes (mais comment : suis preneur de tout lien et
idée sur ce sujet)
- est-ce Ole/DCom qui n'est pas performant? Serait-il possible et
profitable d'utiliser un connecteur ODBC ou autre entre le prog et le
ficher excel ( La connexion SQL Server/programme est faite via ODBC)
- partir sur l'acquisition d'un second serveur et monter les 2 serveurs
en grappe ??? mais au vue de l'investissement, est'se que cela serait
vraiment profitable.
Sachant que je dois mettre en jour plus de 200000 adresses par mois, je
dois vraiment trouver la solution pour une énorme amélioration. Sinon,
je me retrouve avec 27 jours de mise à jour par mois.........
Rem : Une optimisation des index sont effectuées sur cette BDD chaque
semaine et il n'y a pas d'indexation de texte intégral.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
synopsis
Avez-vous regardé du côté de l'ETL Microsoft : DTS ?
"E.Leruste" a écrit dans le message de news: 43e378ce$0$18313$
Bonjour, J'ai besoin de mettre régulierement à jour une base de données SQL Server 2k hébergé sur un bi Xeon 2,4 GHz - 1 Go de RAM Cette mise à jour s'effectue via un programme (développé en c++ sous Builder C++) à partir d'un fichier xls via un serveur ole/com. Cette base de données occupe 1,1 Go (Data+journaux). Les tables à mettre à jour comportent 300.000 lignes pour l'une et 4.700.000 lignes pour la seconde. (2ieme table: table de liaison (m,n) entre table 1 et une 3ième table)
Adresse ---(NumAdr)--> AdrPrest <----(NumPrest)---- Prestataire 1 2 3 Le problème est la lenteur de ces mises à jour : environ 300 lignes par heure....gloups...
le prog de mise à jour s'execute sur un poste client où l'activité proc est faible. Par contre les proc sur le serveur sont à 95-100 % continuellement. La mémoire physique est pleine mais pas saturée (pas de swap)
L'algo général de cette mise à jour est le suivant : ( si l'adresse n'existe pas elle est créée puis la table 2 est mise à jour, si l'adresse existe seule la table 2 est mise à jour) Chaque ligne comporte une premiere serie d'infos sur une adresse (rue,ville...) puis une 2ieme série avec des prestataires par categorie
Pour chaque ligne du fichier Excel : 1 - recherche de l'adresse en prenant en compte env. 10 champs (select NumAdr where Rue=..., NumAppart=..., CodePostal=...,...soit 10 champs) -> si elle n'existe pas: requete INSERT puis SELECT IDENT_CURRENT... 2 - mise à jour de la table 2: - 2a : on efface les enregistrements de la table ayant le NumAdr - 2b : on crée les enregistrements selon les infos du fichiers excel ( environ une petite vingtaine de INSERT...) Eventuellement, un prestataire inexistant est crée dans table 3.
J'ai ajouté 512 Mo de RAM dernièrement sans noter d'amélioration sensible.
Quelles pistes me proposez-vous? J'ai perso pensé à: - optimiser les requetes (mais comment : suis preneur de tout lien et idée sur ce sujet) - est-ce Ole/DCom qui n'est pas performant? Serait-il possible et profitable d'utiliser un connecteur ODBC ou autre entre le prog et le ficher excel ( La connexion SQL Server/programme est faite via ODBC) - partir sur l'acquisition d'un second serveur et monter les 2 serveurs en grappe ??? mais au vue de l'investissement, est'se que cela serait vraiment profitable.
Sachant que je dois mettre en jour plus de 200000 adresses par mois, je dois vraiment trouver la solution pour une énorme amélioration. Sinon, je me retrouve avec 27 jours de mise à jour par mois.........
Rem : Une optimisation des index sont effectuées sur cette BDD chaque semaine et il n'y a pas d'indexation de texte intégral.
Merci d'avance pour votre aide...
Avez-vous regardé du côté de l'ETL Microsoft : DTS ?
"E.Leruste" <sofratel@wanadoo.fr> a écrit dans le message de news:
43e378ce$0$18313$8fcfb975@news.wanadoo.fr...
Bonjour,
J'ai besoin de mettre régulierement à jour une base de données SQL
Server 2k hébergé sur un bi Xeon 2,4 GHz - 1 Go de RAM
Cette mise à jour s'effectue via un programme (développé en c++ sous
Builder C++) à partir d'un fichier xls via un serveur ole/com.
Cette base de données occupe 1,1 Go (Data+journaux).
Les tables à mettre à jour comportent 300.000 lignes pour l'une et
4.700.000 lignes pour la seconde. (2ieme table: table de liaison (m,n)
entre table 1 et une 3ième table)
Adresse ---(NumAdr)--> AdrPrest <----(NumPrest)---- Prestataire
1 2 3
Le problème est la lenteur de ces mises à jour :
environ 300 lignes par heure....gloups...
le prog de mise à jour s'execute sur un poste client où l'activité proc
est faible. Par contre les proc sur le serveur sont à 95-100 %
continuellement. La mémoire physique est pleine mais pas saturée (pas de
swap)
L'algo général de cette mise à jour est le suivant :
( si l'adresse n'existe pas elle est créée puis la table 2 est mise à
jour, si l'adresse existe seule la table 2 est mise à jour)
Chaque ligne comporte une premiere serie d'infos sur une adresse
(rue,ville...) puis une 2ieme série avec des prestataires par categorie
Pour chaque ligne du fichier Excel :
1 - recherche de l'adresse en prenant en compte env. 10 champs (select
NumAdr where Rue=..., NumAppart=..., CodePostal=...,...soit 10 champs)
-> si elle n'existe pas: requete INSERT puis SELECT IDENT_CURRENT...
2 - mise à jour de la table 2:
- 2a : on efface les enregistrements de la table ayant le NumAdr
- 2b : on crée les enregistrements selon les infos du fichiers
excel ( environ une petite vingtaine de INSERT...)
Eventuellement, un prestataire inexistant est crée dans table 3.
J'ai ajouté 512 Mo de RAM dernièrement sans noter d'amélioration sensible.
Quelles pistes me proposez-vous?
J'ai perso pensé à:
- optimiser les requetes (mais comment : suis preneur de tout lien et
idée sur ce sujet)
- est-ce Ole/DCom qui n'est pas performant? Serait-il possible et
profitable d'utiliser un connecteur ODBC ou autre entre le prog et le
ficher excel ( La connexion SQL Server/programme est faite via ODBC)
- partir sur l'acquisition d'un second serveur et monter les 2 serveurs
en grappe ??? mais au vue de l'investissement, est'se que cela serait
vraiment profitable.
Sachant que je dois mettre en jour plus de 200000 adresses par mois, je
dois vraiment trouver la solution pour une énorme amélioration. Sinon,
je me retrouve avec 27 jours de mise à jour par mois.........
Rem : Une optimisation des index sont effectuées sur cette BDD chaque
semaine et il n'y a pas d'indexation de texte intégral.
Avez-vous regardé du côté de l'ETL Microsoft : DTS ?
"E.Leruste" a écrit dans le message de news: 43e378ce$0$18313$
Bonjour, J'ai besoin de mettre régulierement à jour une base de données SQL Server 2k hébergé sur un bi Xeon 2,4 GHz - 1 Go de RAM Cette mise à jour s'effectue via un programme (développé en c++ sous Builder C++) à partir d'un fichier xls via un serveur ole/com. Cette base de données occupe 1,1 Go (Data+journaux). Les tables à mettre à jour comportent 300.000 lignes pour l'une et 4.700.000 lignes pour la seconde. (2ieme table: table de liaison (m,n) entre table 1 et une 3ième table)
Adresse ---(NumAdr)--> AdrPrest <----(NumPrest)---- Prestataire 1 2 3 Le problème est la lenteur de ces mises à jour : environ 300 lignes par heure....gloups...
le prog de mise à jour s'execute sur un poste client où l'activité proc est faible. Par contre les proc sur le serveur sont à 95-100 % continuellement. La mémoire physique est pleine mais pas saturée (pas de swap)
L'algo général de cette mise à jour est le suivant : ( si l'adresse n'existe pas elle est créée puis la table 2 est mise à jour, si l'adresse existe seule la table 2 est mise à jour) Chaque ligne comporte une premiere serie d'infos sur une adresse (rue,ville...) puis une 2ieme série avec des prestataires par categorie
Pour chaque ligne du fichier Excel : 1 - recherche de l'adresse en prenant en compte env. 10 champs (select NumAdr where Rue=..., NumAppart=..., CodePostal=...,...soit 10 champs) -> si elle n'existe pas: requete INSERT puis SELECT IDENT_CURRENT... 2 - mise à jour de la table 2: - 2a : on efface les enregistrements de la table ayant le NumAdr - 2b : on crée les enregistrements selon les infos du fichiers excel ( environ une petite vingtaine de INSERT...) Eventuellement, un prestataire inexistant est crée dans table 3.
J'ai ajouté 512 Mo de RAM dernièrement sans noter d'amélioration sensible.
Quelles pistes me proposez-vous? J'ai perso pensé à: - optimiser les requetes (mais comment : suis preneur de tout lien et idée sur ce sujet) - est-ce Ole/DCom qui n'est pas performant? Serait-il possible et profitable d'utiliser un connecteur ODBC ou autre entre le prog et le ficher excel ( La connexion SQL Server/programme est faite via ODBC) - partir sur l'acquisition d'un second serveur et monter les 2 serveurs en grappe ??? mais au vue de l'investissement, est'se que cela serait vraiment profitable.
Sachant que je dois mettre en jour plus de 200000 adresses par mois, je dois vraiment trouver la solution pour une énorme amélioration. Sinon, je me retrouve avec 27 jours de mise à jour par mois.........
Rem : Une optimisation des index sont effectuées sur cette BDD chaque semaine et il n'y a pas d'indexation de texte intégral.
Merci d'avance pour votre aide...
Sylvain Lafontaine
Oubliez votre recherche du côté de COM/DCOM, OLEDB et ODBC; comme votre serveur travaille à 95-100% de sa capacité, votre problème se situe à ce niveau là et non pas au niveau du client ou du protocol de communication intermédiaire.
Votre problème est probablement dû à une recherche inefficace: la recherche de chaque adresse individuelle implique possiblement une « table scan » de la table #1 à chaque fois. Regardez les plans d'exécution et modifier le design de vos requêtes/table/indexes afin de faire disparaître ce « table scan » ; fort possiblement que votre problème sera alors résolu.
Comme SQL-Server n'utilise qu'un index à la fois, il est important que cet index couvre tous les champs requis pour la recherche et qu'il ait aussi un faible pourcentage d'occupation (50% ou moins?) puisque vous faîtes énormément de mise-à-jour de la table. À cause de ces mise-à-jours aussi, ne le mettez pas en mode cluster.
Votre table de liaison intermédiaire m'a également l'air suspect. On utilise généralement ce genre de table lorsqu'une seule addresse peut correspondre à plusieurs prestataires et un même prestataire avoir plusieurs addresses différentes en même temps. La description que vous donnez ne semble pas correspondre à exactement cela; particulièrement lorsque vous dites que vous effacer d'abord tous les enregistrements et que vous faites ensuite une vingtaine d'insertions.
-- Sylvain Lafontaine, ing. MVP - Technologies Virtual-PC E-mail: http://cerbermail.com/?QugbLEWINF
"E.Leruste" wrote in message news:43e378ce$0$18313$
Bonjour, J'ai besoin de mettre régulierement à jour une base de données SQL Server 2k hébergé sur un bi Xeon 2,4 GHz - 1 Go de RAM Cette mise à jour s'effectue via un programme (développé en c++ sous Builder C++) à partir d'un fichier xls via un serveur ole/com. Cette base de données occupe 1,1 Go (Data+journaux). Les tables à mettre à jour comportent 300.000 lignes pour l'une et 4.700.000 lignes pour la seconde. (2ieme table: table de liaison (m,n) entre table 1 et une 3ième table)
Adresse ---(NumAdr)--> AdrPrest <----(NumPrest)---- Prestataire 1 2 3 Le problème est la lenteur de ces mises à jour : environ 300 lignes par heure....gloups...
le prog de mise à jour s'execute sur un poste client où l'activité proc est faible. Par contre les proc sur le serveur sont à 95-100 % continuellement. La mémoire physique est pleine mais pas saturée (pas de swap)
L'algo général de cette mise à jour est le suivant : ( si l'adresse n'existe pas elle est créée puis la table 2 est mise à jour, si l'adresse existe seule la table 2 est mise à jour) Chaque ligne comporte une premiere serie d'infos sur une adresse (rue,ville...) puis une 2ieme série avec des prestataires par categorie
Pour chaque ligne du fichier Excel : 1 - recherche de l'adresse en prenant en compte env. 10 champs (select NumAdr where Rue=..., NumAppart=..., CodePostal=...,...soit 10 champs) -> si elle n'existe pas: requete INSERT puis SELECT IDENT_CURRENT... 2 - mise à jour de la table 2: - 2a : on efface les enregistrements de la table ayant le NumAdr - 2b : on crée les enregistrements selon les infos du fichiers excel ( environ une petite vingtaine de INSERT...) Eventuellement, un prestataire inexistant est crée dans table 3.
J'ai ajouté 512 Mo de RAM dernièrement sans noter d'amélioration sensible.
Quelles pistes me proposez-vous? J'ai perso pensé à: - optimiser les requetes (mais comment : suis preneur de tout lien et idée sur ce sujet) - est-ce Ole/DCom qui n'est pas performant? Serait-il possible et profitable d'utiliser un connecteur ODBC ou autre entre le prog et le ficher excel ( La connexion SQL Server/programme est faite via ODBC) - partir sur l'acquisition d'un second serveur et monter les 2 serveurs en grappe ??? mais au vue de l'investissement, est'se que cela serait vraiment profitable.
Sachant que je dois mettre en jour plus de 200000 adresses par mois, je dois vraiment trouver la solution pour une énorme amélioration. Sinon, je me retrouve avec 27 jours de mise à jour par mois.........
Rem : Une optimisation des index sont effectuées sur cette BDD chaque semaine et il n'y a pas d'indexation de texte intégral.
Merci d'avance pour votre aide...
Oubliez votre recherche du côté de COM/DCOM, OLEDB et ODBC; comme votre
serveur travaille à 95-100% de sa capacité, votre problème se situe à ce
niveau là et non pas au niveau du client ou du protocol de communication
intermédiaire.
Votre problème est probablement dû à une recherche inefficace: la recherche
de chaque adresse individuelle implique possiblement une « table scan » de
la table #1 à chaque fois. Regardez les plans d'exécution et modifier le
design de vos requêtes/table/indexes afin de faire disparaître ce « table
scan » ; fort possiblement que votre problème sera alors résolu.
Comme SQL-Server n'utilise qu'un index à la fois, il est important que cet
index couvre tous les champs requis pour la recherche et qu'il ait aussi un
faible pourcentage d'occupation (50% ou moins?) puisque vous faîtes
énormément de mise-à-jour de la table. À cause de ces mise-à-jours aussi,
ne le mettez pas en mode cluster.
Votre table de liaison intermédiaire m'a également l'air suspect. On
utilise généralement ce genre de table lorsqu'une seule addresse peut
correspondre à plusieurs prestataires et un même prestataire avoir plusieurs
addresses différentes en même temps. La description que vous donnez ne
semble pas correspondre à exactement cela; particulièrement lorsque vous
dites que vous effacer d'abord tous les enregistrements et que vous faites
ensuite une vingtaine d'insertions.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF
"E.Leruste" <sofratel@wanadoo.fr> wrote in message
news:43e378ce$0$18313$8fcfb975@news.wanadoo.fr...
Bonjour,
J'ai besoin de mettre régulierement à jour une base de données SQL
Server 2k hébergé sur un bi Xeon 2,4 GHz - 1 Go de RAM
Cette mise à jour s'effectue via un programme (développé en c++ sous
Builder C++) à partir d'un fichier xls via un serveur ole/com.
Cette base de données occupe 1,1 Go (Data+journaux).
Les tables à mettre à jour comportent 300.000 lignes pour l'une et
4.700.000 lignes pour la seconde. (2ieme table: table de liaison (m,n)
entre table 1 et une 3ième table)
Adresse ---(NumAdr)--> AdrPrest <----(NumPrest)---- Prestataire
1 2 3
Le problème est la lenteur de ces mises à jour :
environ 300 lignes par heure....gloups...
le prog de mise à jour s'execute sur un poste client où l'activité proc
est faible. Par contre les proc sur le serveur sont à 95-100 %
continuellement. La mémoire physique est pleine mais pas saturée (pas de
swap)
L'algo général de cette mise à jour est le suivant :
( si l'adresse n'existe pas elle est créée puis la table 2 est mise à
jour, si l'adresse existe seule la table 2 est mise à jour)
Chaque ligne comporte une premiere serie d'infos sur une adresse
(rue,ville...) puis une 2ieme série avec des prestataires par categorie
Pour chaque ligne du fichier Excel :
1 - recherche de l'adresse en prenant en compte env. 10 champs (select
NumAdr where Rue=..., NumAppart=..., CodePostal=...,...soit 10 champs)
-> si elle n'existe pas: requete INSERT puis SELECT IDENT_CURRENT...
2 - mise à jour de la table 2:
- 2a : on efface les enregistrements de la table ayant le NumAdr
- 2b : on crée les enregistrements selon les infos du fichiers
excel ( environ une petite vingtaine de INSERT...)
Eventuellement, un prestataire inexistant est crée dans table 3.
J'ai ajouté 512 Mo de RAM dernièrement sans noter d'amélioration sensible.
Quelles pistes me proposez-vous?
J'ai perso pensé à:
- optimiser les requetes (mais comment : suis preneur de tout lien et
idée sur ce sujet)
- est-ce Ole/DCom qui n'est pas performant? Serait-il possible et
profitable d'utiliser un connecteur ODBC ou autre entre le prog et le
ficher excel ( La connexion SQL Server/programme est faite via ODBC)
- partir sur l'acquisition d'un second serveur et monter les 2 serveurs
en grappe ??? mais au vue de l'investissement, est'se que cela serait
vraiment profitable.
Sachant que je dois mettre en jour plus de 200000 adresses par mois, je
dois vraiment trouver la solution pour une énorme amélioration. Sinon,
je me retrouve avec 27 jours de mise à jour par mois.........
Rem : Une optimisation des index sont effectuées sur cette BDD chaque
semaine et il n'y a pas d'indexation de texte intégral.
Oubliez votre recherche du côté de COM/DCOM, OLEDB et ODBC; comme votre serveur travaille à 95-100% de sa capacité, votre problème se situe à ce niveau là et non pas au niveau du client ou du protocol de communication intermédiaire.
Votre problème est probablement dû à une recherche inefficace: la recherche de chaque adresse individuelle implique possiblement une « table scan » de la table #1 à chaque fois. Regardez les plans d'exécution et modifier le design de vos requêtes/table/indexes afin de faire disparaître ce « table scan » ; fort possiblement que votre problème sera alors résolu.
Comme SQL-Server n'utilise qu'un index à la fois, il est important que cet index couvre tous les champs requis pour la recherche et qu'il ait aussi un faible pourcentage d'occupation (50% ou moins?) puisque vous faîtes énormément de mise-à-jour de la table. À cause de ces mise-à-jours aussi, ne le mettez pas en mode cluster.
Votre table de liaison intermédiaire m'a également l'air suspect. On utilise généralement ce genre de table lorsqu'une seule addresse peut correspondre à plusieurs prestataires et un même prestataire avoir plusieurs addresses différentes en même temps. La description que vous donnez ne semble pas correspondre à exactement cela; particulièrement lorsque vous dites que vous effacer d'abord tous les enregistrements et que vous faites ensuite une vingtaine d'insertions.
-- Sylvain Lafontaine, ing. MVP - Technologies Virtual-PC E-mail: http://cerbermail.com/?QugbLEWINF
"E.Leruste" wrote in message news:43e378ce$0$18313$
Bonjour, J'ai besoin de mettre régulierement à jour une base de données SQL Server 2k hébergé sur un bi Xeon 2,4 GHz - 1 Go de RAM Cette mise à jour s'effectue via un programme (développé en c++ sous Builder C++) à partir d'un fichier xls via un serveur ole/com. Cette base de données occupe 1,1 Go (Data+journaux). Les tables à mettre à jour comportent 300.000 lignes pour l'une et 4.700.000 lignes pour la seconde. (2ieme table: table de liaison (m,n) entre table 1 et une 3ième table)
Adresse ---(NumAdr)--> AdrPrest <----(NumPrest)---- Prestataire 1 2 3 Le problème est la lenteur de ces mises à jour : environ 300 lignes par heure....gloups...
le prog de mise à jour s'execute sur un poste client où l'activité proc est faible. Par contre les proc sur le serveur sont à 95-100 % continuellement. La mémoire physique est pleine mais pas saturée (pas de swap)
L'algo général de cette mise à jour est le suivant : ( si l'adresse n'existe pas elle est créée puis la table 2 est mise à jour, si l'adresse existe seule la table 2 est mise à jour) Chaque ligne comporte une premiere serie d'infos sur une adresse (rue,ville...) puis une 2ieme série avec des prestataires par categorie
Pour chaque ligne du fichier Excel : 1 - recherche de l'adresse en prenant en compte env. 10 champs (select NumAdr where Rue=..., NumAppart=..., CodePostal=...,...soit 10 champs) -> si elle n'existe pas: requete INSERT puis SELECT IDENT_CURRENT... 2 - mise à jour de la table 2: - 2a : on efface les enregistrements de la table ayant le NumAdr - 2b : on crée les enregistrements selon les infos du fichiers excel ( environ une petite vingtaine de INSERT...) Eventuellement, un prestataire inexistant est crée dans table 3.
J'ai ajouté 512 Mo de RAM dernièrement sans noter d'amélioration sensible.
Quelles pistes me proposez-vous? J'ai perso pensé à: - optimiser les requetes (mais comment : suis preneur de tout lien et idée sur ce sujet) - est-ce Ole/DCom qui n'est pas performant? Serait-il possible et profitable d'utiliser un connecteur ODBC ou autre entre le prog et le ficher excel ( La connexion SQL Server/programme est faite via ODBC) - partir sur l'acquisition d'un second serveur et monter les 2 serveurs en grappe ??? mais au vue de l'investissement, est'se que cela serait vraiment profitable.
Sachant que je dois mettre en jour plus de 200000 adresses par mois, je dois vraiment trouver la solution pour une énorme amélioration. Sinon, je me retrouve avec 27 jours de mise à jour par mois.........
Rem : Une optimisation des index sont effectuées sur cette BDD chaque semaine et il n'y a pas d'indexation de texte intégral.
Merci d'avance pour votre aide...
Michel PRIORI
Bonjour,
Pour optimiser les requetes : 1- lancer le 'profiler' (analyseur de profil) et choisir le modèle tuning pour faire une trace 2- dans entreprise manager, chercher les assistants, lancer 'index tuning wizard' et pointer le ficheir de trace (faire l'analyse table par table sous peine d'attendre 2 heures et voir le process planter - à faire sur le serveur de prod)
Pour les mises à jour : si c'est le client qui génère un ordre de mise à jour ligne après ligne, l'étape de dessus ne sert à rien. Un seul ordre update et insert doit être lancé. Plutôt qu'une logique ligne à ligne il FAUT réfléchir à des actions ensemblistes. C'est le moteur d'optimisation SQL (celui que tu as acheté avec la licence) qui fait le boulot (et plutôt bien d'ailleurs).
En clair y a du boulot.
Bon courage.
cordialement
"E.Leruste" wrote:
Bonjour, J'ai besoin de mettre régulierement à jour une base de données SQL Server 2k hébergé sur un bi Xeon 2,4 GHz - 1 Go de RAM Cette mise à jour s'effectue via un programme (développé en c++ sous Builder C++) à partir d'un fichier xls via un serveur ole/com. Cette base de données occupe 1,1 Go (Data+journaux). Les tables à mettre à jour comportent 300.000 lignes pour l'une et 4.700.000 lignes pour la seconde. (2ieme table: table de liaison (m,n) entre table 1 et une 3ième table)
Adresse ---(NumAdr)--> AdrPrest <----(NumPrest)---- Prestataire 1 2 3 Le problème est la lenteur de ces mises à jour : environ 300 lignes par heure....gloups...
le prog de mise à jour s'execute sur un poste client où l'activité proc est faible. Par contre les proc sur le serveur sont à 95-100 % continuellement. La mémoire physique est pleine mais pas saturée (pas de swap)
L'algo général de cette mise à jour est le suivant : ( si l'adresse n'existe pas elle est créée puis la table 2 est mise à jour, si l'adresse existe seule la table 2 est mise à jour) Chaque ligne comporte une premiere serie d'infos sur une adresse (rue,ville...) puis une 2ieme série avec des prestataires par categorie
Pour chaque ligne du fichier Excel : 1 - recherche de l'adresse en prenant en compte env. 10 champs (select NumAdr where Rue=..., NumAppart=..., CodePostal=...,...soit 10 champs) -> si elle n'existe pas: requete INSERT puis SELECT IDENT_CURRENT... 2 - mise à jour de la table 2: - 2a : on efface les enregistrements de la table ayant le NumAdr - 2b : on crée les enregistrements selon les infos du fichiers excel ( environ une petite vingtaine de INSERT...) Eventuellement, un prestataire inexistant est crée dans table 3.
J'ai ajouté 512 Mo de RAM dernièrement sans noter d'amélioration sensible.
Quelles pistes me proposez-vous? J'ai perso pensé à: - optimiser les requetes (mais comment : suis preneur de tout lien et idée sur ce sujet) - est-ce Ole/DCom qui n'est pas performant? Serait-il possible et profitable d'utiliser un connecteur ODBC ou autre entre le prog et le ficher excel ( La connexion SQL Server/programme est faite via ODBC) - partir sur l'acquisition d'un second serveur et monter les 2 serveurs en grappe ??? mais au vue de l'investissement, est'se que cela serait vraiment profitable.
Sachant que je dois mettre en jour plus de 200000 adresses par mois, je dois vraiment trouver la solution pour une énorme amélioration. Sinon, je me retrouve avec 27 jours de mise à jour par mois.........
Rem : Une optimisation des index sont effectuées sur cette BDD chaque semaine et il n'y a pas d'indexation de texte intégral.
Merci d'avance pour votre aide...
Bonjour,
Pour optimiser les requetes :
1- lancer le 'profiler' (analyseur de profil) et choisir le modèle tuning
pour faire une trace
2- dans entreprise manager, chercher les assistants, lancer 'index tuning
wizard' et pointer le ficheir de trace (faire l'analyse table par table sous
peine d'attendre 2 heures et voir le process planter - à faire sur le serveur
de prod)
Pour les mises à jour :
si c'est le client qui génère un ordre de mise à jour ligne après ligne,
l'étape de dessus ne sert à rien. Un seul ordre update et insert doit être
lancé.
Plutôt qu'une logique ligne à ligne il FAUT réfléchir à des actions
ensemblistes.
C'est le moteur d'optimisation SQL (celui que tu as acheté avec la licence)
qui fait le boulot (et plutôt bien d'ailleurs).
En clair y a du boulot.
Bon courage.
cordialement
"E.Leruste" wrote:
Bonjour,
J'ai besoin de mettre régulierement à jour une base de données SQL
Server 2k hébergé sur un bi Xeon 2,4 GHz - 1 Go de RAM
Cette mise à jour s'effectue via un programme (développé en c++ sous
Builder C++) à partir d'un fichier xls via un serveur ole/com.
Cette base de données occupe 1,1 Go (Data+journaux).
Les tables à mettre à jour comportent 300.000 lignes pour l'une et
4.700.000 lignes pour la seconde. (2ieme table: table de liaison (m,n)
entre table 1 et une 3ième table)
Adresse ---(NumAdr)--> AdrPrest <----(NumPrest)---- Prestataire
1 2 3
Le problème est la lenteur de ces mises à jour :
environ 300 lignes par heure....gloups...
le prog de mise à jour s'execute sur un poste client où l'activité proc
est faible. Par contre les proc sur le serveur sont à 95-100 %
continuellement. La mémoire physique est pleine mais pas saturée (pas de
swap)
L'algo général de cette mise à jour est le suivant :
( si l'adresse n'existe pas elle est créée puis la table 2 est mise à
jour, si l'adresse existe seule la table 2 est mise à jour)
Chaque ligne comporte une premiere serie d'infos sur une adresse
(rue,ville...) puis une 2ieme série avec des prestataires par categorie
Pour chaque ligne du fichier Excel :
1 - recherche de l'adresse en prenant en compte env. 10 champs (select
NumAdr where Rue=..., NumAppart=..., CodePostal=...,...soit 10 champs)
-> si elle n'existe pas: requete INSERT puis SELECT IDENT_CURRENT...
2 - mise à jour de la table 2:
- 2a : on efface les enregistrements de la table ayant le NumAdr
- 2b : on crée les enregistrements selon les infos du fichiers
excel ( environ une petite vingtaine de INSERT...)
Eventuellement, un prestataire inexistant est crée dans table 3.
J'ai ajouté 512 Mo de RAM dernièrement sans noter d'amélioration sensible.
Quelles pistes me proposez-vous?
J'ai perso pensé à:
- optimiser les requetes (mais comment : suis preneur de tout lien et
idée sur ce sujet)
- est-ce Ole/DCom qui n'est pas performant? Serait-il possible et
profitable d'utiliser un connecteur ODBC ou autre entre le prog et le
ficher excel ( La connexion SQL Server/programme est faite via ODBC)
- partir sur l'acquisition d'un second serveur et monter les 2 serveurs
en grappe ??? mais au vue de l'investissement, est'se que cela serait
vraiment profitable.
Sachant que je dois mettre en jour plus de 200000 adresses par mois, je
dois vraiment trouver la solution pour une énorme amélioration. Sinon,
je me retrouve avec 27 jours de mise à jour par mois.........
Rem : Une optimisation des index sont effectuées sur cette BDD chaque
semaine et il n'y a pas d'indexation de texte intégral.
Pour optimiser les requetes : 1- lancer le 'profiler' (analyseur de profil) et choisir le modèle tuning pour faire une trace 2- dans entreprise manager, chercher les assistants, lancer 'index tuning wizard' et pointer le ficheir de trace (faire l'analyse table par table sous peine d'attendre 2 heures et voir le process planter - à faire sur le serveur de prod)
Pour les mises à jour : si c'est le client qui génère un ordre de mise à jour ligne après ligne, l'étape de dessus ne sert à rien. Un seul ordre update et insert doit être lancé. Plutôt qu'une logique ligne à ligne il FAUT réfléchir à des actions ensemblistes. C'est le moteur d'optimisation SQL (celui que tu as acheté avec la licence) qui fait le boulot (et plutôt bien d'ailleurs).
En clair y a du boulot.
Bon courage.
cordialement
"E.Leruste" wrote:
Bonjour, J'ai besoin de mettre régulierement à jour une base de données SQL Server 2k hébergé sur un bi Xeon 2,4 GHz - 1 Go de RAM Cette mise à jour s'effectue via un programme (développé en c++ sous Builder C++) à partir d'un fichier xls via un serveur ole/com. Cette base de données occupe 1,1 Go (Data+journaux). Les tables à mettre à jour comportent 300.000 lignes pour l'une et 4.700.000 lignes pour la seconde. (2ieme table: table de liaison (m,n) entre table 1 et une 3ième table)
Adresse ---(NumAdr)--> AdrPrest <----(NumPrest)---- Prestataire 1 2 3 Le problème est la lenteur de ces mises à jour : environ 300 lignes par heure....gloups...
le prog de mise à jour s'execute sur un poste client où l'activité proc est faible. Par contre les proc sur le serveur sont à 95-100 % continuellement. La mémoire physique est pleine mais pas saturée (pas de swap)
L'algo général de cette mise à jour est le suivant : ( si l'adresse n'existe pas elle est créée puis la table 2 est mise à jour, si l'adresse existe seule la table 2 est mise à jour) Chaque ligne comporte une premiere serie d'infos sur une adresse (rue,ville...) puis une 2ieme série avec des prestataires par categorie
Pour chaque ligne du fichier Excel : 1 - recherche de l'adresse en prenant en compte env. 10 champs (select NumAdr where Rue=..., NumAppart=..., CodePostal=...,...soit 10 champs) -> si elle n'existe pas: requete INSERT puis SELECT IDENT_CURRENT... 2 - mise à jour de la table 2: - 2a : on efface les enregistrements de la table ayant le NumAdr - 2b : on crée les enregistrements selon les infos du fichiers excel ( environ une petite vingtaine de INSERT...) Eventuellement, un prestataire inexistant est crée dans table 3.
J'ai ajouté 512 Mo de RAM dernièrement sans noter d'amélioration sensible.
Quelles pistes me proposez-vous? J'ai perso pensé à: - optimiser les requetes (mais comment : suis preneur de tout lien et idée sur ce sujet) - est-ce Ole/DCom qui n'est pas performant? Serait-il possible et profitable d'utiliser un connecteur ODBC ou autre entre le prog et le ficher excel ( La connexion SQL Server/programme est faite via ODBC) - partir sur l'acquisition d'un second serveur et monter les 2 serveurs en grappe ??? mais au vue de l'investissement, est'se que cela serait vraiment profitable.
Sachant que je dois mettre en jour plus de 200000 adresses par mois, je dois vraiment trouver la solution pour une énorme amélioration. Sinon, je me retrouve avec 27 jours de mise à jour par mois.........
Rem : Une optimisation des index sont effectuées sur cette BDD chaque semaine et il n'y a pas d'indexation de texte intégral.
