Discussion :

[Luc1an0]

Bonjour,

j'ai un fait un développement permettant de faire des synchronisations de bases de données.

J'utilise en fait deux datatables et la fonction "select(maCondition)" pour déterminer les bons traitements à faire.

J'ai été d'une part un peu gourmand sur les ressources car je ne faisais pas de "Dispose" ou "Clear" quand il le fallait. Du coup mon programme levait l'exception System.OutOfMemoryException

Mais la réelle question est :
Est ce que le fait d'utiliser la fonction "Select()" sur une datatable a une quelconque intéraction sur la base de donnée ou la table ?

J'ai constaté que notre serveur SQL devenait extremement lent durant mes tests ... A vrai dire ça ralentissait tous les utilisateurs.

Merci d'avance de vos réponses.

[Rami]

je ne pense pas que ca viennent du .Select()

le dataset est un object deconnecté a priori.

Par contre, pour remplir tes dataset, tu fais un select de combien de table/lignes/a quelle frequence...

J'ai constaté que notre serveur SQL devenait extremement lent durant mes tests ... A vrai dire ça ralentissait tous les utilisateurs.

Quels utilisateurs? de la même application/des meme bases de données/ du meme serveur SQL?

tes tests ne couvrent que cette partie select? ou il y a des requetes insert/update/delete ?

[Luc1an0]

En fait le process de comparaison se décline en 3*2 instructions

- 1 partie Insert (Comparaison + Traitement )
- 1 partie Update (idem)
- 1 partie Delete (idem)

Je commence par récupérer les tables à comparer, définies dans un fichier de config.

Pour chaque table j'effectue le traitement décrit ci-dessus.

Pour la comparaison : 1 select sur la table "source" / 1 select sur la table de destination qui me valorise mes deux datatables.

Je garde les lignes "sources" qui me permettront par la suite de faire les traitements d'insertion/modification/suppression dans la base de destination.

Une fois ma datatable "source" valorisée, comme tu dis, je n'utilise à priori plus de liens vers ce serveur.

Par contre, pour remplir tes dataset, tu fais un select de combien de table/lignes/a quelle frequence...

Donc : 1 select sur l'ensemble des lignes de la table. Fréquence : Je suis en phase de dev', donc pas de production. La fréquence correspond à celle où je lance mon prog' pour mes tests

Quels utilisateurs? de la même application/des meme bases de données/ du meme serveur SQL?

On utilise un serveur SQL 2005. Les utilisateurs utilisent cette base via deux applicatifs access. Ces applicatifs utilisent des tables liées sur ce serveur SQL.

tes tests ne couvrent que cette partie select? ou il y a des requetes insert/update/delete ?

J'ai déjà commencé par allégé la charge mémoire en vidant plus régulièrement des objets servant à stocker des informations.
Les requêtes de modifications de données (Insert/Delete/update) ne vont qu'à destination d'une base située sur mon poste. A terme, sur une autre machine. Mais le principe reste le meme.

Pour résumer, le serveur SQL ne subit que 3 requêtes "select" par tables traitées. Je ne sais plus combien de tables je traite, mais on va dire entre 10 et 15.

Merci en tout cas.

[Luc1an0]

le dataset est un object deconnecté a priori.

Juste pour précision : je confirme.

Je viens de désactiver ma carte réseau après avoir récupérer mes données et avant d'effectuer mes traitements.

Mon traitement de vérification fonctionne. Ce n'est donc pas l'instruction "Select()" qui pose souci.

Mais du coup c'est encore plus flou pour comprendre d'où ce ralentissement réseau provient :s

[Rami]

Si j'ai bien compris ce que tu fais:

Pour résumer, le serveur SQL ne subit que 3 requêtes "select" par tables traitées.

Je ne suis pas sur de comprendre pourquoi tu fais 3 select (au sens SQL).
Une fois ton dataset rempli, tu peux faire plusieurs .Select() (au sens .Net) consecutifs dessus il me semble...

Je ne sais plus combien de tables je traite, mais on va dire entre 10 et 15.

il n'y a pas de grosses tables (du type avec des champs binaires/images et beaucoup d'enregistrements)?


Dernier point a regarder a priori :
verifies tes fermetures de connections

[Luc1an0]

tu peux faire plusieurs .Select() (au sens .Net) consecutifs dessus il me semble...

Oui effectivement. Je fais un "Select" / ligne en fait : Pour vérifier la correspondance entre une entrée de la table source avec une entrée de la table de destination.

verifies tes fermetures de connections

Le Connect() / Disconnect() à mes sources de données sont encapsulés dans mes fonctions d'exécution de insert / delete / update / select (SQL)

il n'y a pas de grosses tables (du type avec des champs binaires/images et beaucoup d'enregistrements)?

Si ... la taille des tables varie, mais on peut atteindre 150 000 lignes sur une (voir plusieurs tables)

Mais dans le sens où le DataTable marche en mode déconnecté... Cela fait juste une bonne charge mémoire & processeur. Chose à laquelle j'ai à peu près remédié le souci en faisant
- des Dispose() de mémoire plus souvent,
- des écritures de plusieurs fichiers logs temporaires (libérant ainsi l'espace mémoire qu'ils occupaient avant la fin du programme), avant d'être réécris dans un seul et même fichier

Le souci principal c'est que je m'efforce de coder en utilisant le moins de mémoire possible, et en mettant des sleep de 1 voir 2 Ms dans mes boucles afin de ne pas alourdir le proc' : mais qu'au final je peux difficilement testé car je ne veux pas gêner tous les autres utilisateurs.

Je pourrais faire cela sur une base de test ? : Oui.

Mais je ne pourrai pas faire rapprocher ma base de test avec les mêmes réactions que la base de production.

[Rami]

Le souci principal c'est que je m'efforce de coder en utilisant le moins de mémoire possible, et en mettant des sleep de 1 voir 2 Ms dans mes boucles afin de ne pas alourdir le proc' : mais qu'au final je peux difficilement testé car je ne veux pas gêner tous les autres utilisateurs.

C'est pas clair toute cette histoire pour moi...
en quoi la memoire sur ton poste et le proc sur ton poste ont une influence?
a moins que tu comptes deployer sur le serveur hostant SQL Server?

tes interaction avec le serveur doivent etre:
- je rempli mon dataset (et ca peut etre effectivement lourd).
- finito (puisque l'autre base est ailleurs si j'ai bien suivi)
d'ou mon "doutage"..


Pour ce qui est de la base de test, si ta base de prod est backuppé de maniere journalière, un admin SQL devrait pouvoir te mettre en place une base de test J-1 ou J-2 assez simplement.

[Luc1an0]

C'est pas clair toute cette histoire pour moi...

Désolé

en quoi la memoire sur ton poste et le proc sur ton poste ont une influence?
a moins que tu comptes deployer sur le serveur hostant SQL Server?

Tout juste.

tes interaction avec le serveur doivent etre:
- je rempli mon dataset (et ca peut etre effectivement lourd).
- finito (puisque l'autre base est ailleurs si j'ai bien suivi)
d'ou mon "doutage"..

C'est tout à fait ça. Et crois moi que le remplissage des dataset sont assez rapides.

Pour ce qui est de la base de test, si ta base de prod est backuppé de maniere journalière, un admin SQL devrait pouvoir te mettre en place une base de test J-1 ou J-2 assez simplement.

En outre c'est moi l'admin SQL... D'où le dev

Quand je parlais d'une base de test, c'était plutôt : une base de test sur mon PC, et non une base sur le Serveur. En fait je craignais un ralentissement Serveur, et non sur une base à proprement dit.

[Rami]

Tout juste.

OK ^^ maintenant je comprends...

Une question qui arrive un peu tard pour toi mais, vu le contexte tu as regardé du coté SSIS? (SQL Server Integration Services) en terme de performance sur le traitement data c'est assez adapté.
De même, si ton appli ne fait de la synchronisation de deux base "identique",
tu dois pouvoir trouver un moyen "tout pret" dans SQL 2005 (depend de l'edition je te dirais) et dans ce cas demande sur les forum SQL Server.

Dans les autres cas:

* Pour le testing, prepare le en 2 phase:
un environment de test "aussi proche que possible" de celui de prod pour identifier les "bottleneck" (tu fais des mesures relatives, elles devraient etre ordonées pareil sur la prod) ...
une fois une bonne vision de comment tourne l'appli en "relatif" et certains "bottleneck" enlevés, test de perf reel en prod.
tu seras bcp plus a l'aise pour cette seconde phase si tu passes par la phase 1.

** il y a peut etre un algo plus optimisé que de faire un .select() pour chaque ligne...
Si tu dispose d'un bon ordonencement des records et une identification adequat, un parcours des 2 tables "en même temps" (un coup j'avance sur la table A, un coup j'avance sur la table mirroir de A) en comparant a chaque increment est peut etre possible... mais la faudrait rentrer un peu dans le detail de ton projet.

*** enfin si aucun de ces aspect ne t'apporte qqchose de satisfisant envisage quand meme de deployer ton applicatif sur une autre machine (plutot que de faire des sleep dans tes boucles, c'est pas beau ca ^^)

[Luc1an0]

Une question qui arrive un peu tard pour toi mais, vu le contexte tu as regardé du coté SSIS? (SQL Server Integration Services) en terme de performance sur le traitement data c'est assez adapté.
De même, si ton appli ne fait de la synchronisation de deux base "identique",
tu dois pouvoir trouver un moyen "tout pret" dans SQL 2005 (depend de l'edition je te dirais) et dans ce cas demande sur les forum SQL Server.

http://social.msdn.microsoft.com/For...5-578913dc4f42

Je suis pas dans le cas d'un SQL Server 64 bits, mais la situation s'en rapproche grandement

** il y a peut etre un algo plus optimisé que de faire un .select() pour chaque ligne...
Si tu dispose d'un bon ordonencement des records et une identification adequat, un parcours des 2 tables "en même temps" (un coup j'avance sur la table A, un coup j'avance sur la table mirroir de A) en comparant a chaque increment est peut etre possible... mais la faudrait rentrer un peu dans le detail de ton projet.

A vrai dire j'ai privilégié le traitement de donnée en mode déconnecté plutôt que la sélection massive de requêtes ...Disons que si la machine travaille dans son coin, c'est déjà plus rapide car on évite les "ouvertures/fermetures" de connexion.

J'avais pensé à faire des blocs de requetes, du genre récupérer le nombre de lignes, et le diviser de façon à avoir des blocs de ligne relativement plus petit à traiter. Mais je ne sais pas ce que peux donner des requetes avec des conditions du genre

Code :

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

"select meschamps from matable where ma cleprimaire in (suite,de,cle,primaire)"

J'ai "à peu de chose" près implémenté ton idée au début. C'est à dire que je faisais une sorte d'indexation des clé primaires avec un "Dictionnary (of String, Integer).
Je récupère mes données. Je parcours ma table source, je stocke dans un nouvel item de mon dictionnaire le couple "cléprimaire"/index de la ligne où est contenu cette clé dans le datatable.

Ensuite je fais un parcours de ma table de destination en utilisant pour chaque ligne la fonction "Contains()" de Dictionnary.

Le souci c'est qu'en terme de mémoire ça monte vite derrière....

[Rami]

* Si je resume:
- tu es admin d'un SQL Server 2005
- tu dois accomplir des manipulations de données de diverses sources.
- tu veux executer cette action sur le serveur SQL

SSIS est tout designé (peut etre pour la suite)
Certes il y a de l'apprentissage, mais tu vas pas mal y gagner au final:
- Plannification dans le SQL Agent tres simple
- performance sur Bulk Insert
- Log d'erreur facile a mettre en place
- operation de maintenance disponible au passage
etc...

** Sinon a regarder aussi:
http://www.dbconvert.com/convert-mss...mysql-sync.php

*** Derniere question, tu comptes executer (une fois finaliser) une synchro de type J-1 aux "heures creuses"?

**** pour l'algo ce n'est pas exactement ce que j'avais en tête, mais c'est pas evident sans se plonger vraiment dedans...

[Luc1an0]

* Si je resume:
- tu es admin d'un SQL Server 2005
- tu dois accomplir des manipulations de données de diverses sources.
- tu veux executer cette action sur le serveur SQL

SSIS est tout designé (peut etre pour la suite)
Certes il y a de l'apprentissage, mais tu vas pas mal y gagner au final:
- Plannification dans le SQL Agent tres simple
- performance sur Bulk Insert
- Log d'erreur facile a mettre en place
- operation de maintenance disponible au passage
etc...

Certainement. Le souci c'est que nous n'avons pas les outils. Peut être présents sur les CD de réinstall' Dell... Je comptais regarder. Je te tiendrai au courant.

A vrai dire je comptais implémenter la solution finalisée en tant que Service Windows...

** Sinon a regarder aussi:
http://www.dbconvert.com/convert-mss...mysql-sync.php

J'aime beaucoup... A voir si ma direction m'accorde l'achat de licence, mais pour l'instant je pars du principe que non ............

*** Derniere question, tu comptes executer (une fois finaliser) une synchro de type J-1 aux "heures creuses"?

Actuellement on a une synchro (mais très peu performante, et très instable). Cette solution marche dans l'absolu, mais ne répond plus aux critères d'expansion de la base. Il y a beaucoup trop de données et la solution n'est plus fiable à 100% et pose d'une part, trop de problèmes de sécurité et d'autres part trop de problème de validité des données.

L'idéal : 2 synchros par jour aux heures creuses sans critères.

**** pour l'algo ce n'est pas exactement ce que j'avais en tête, mais c'est pas evident sans se plonger vraiment dedans...

Actuellement on a, dans chaque table "miroir" des champs d'indication pour l'insertion et la modification des données.
Notre synchro actuelle se base là dessus. J'ai pas forcément souhaité m'en servir mais peut être ça serait judicieux... L'élément principal qui m'a fait oublié ces indicateurs c'est la généricité de code. (pouvoir me resservir par exemple de cet outil pour la migration de base de donnée par exemple, ou pour de la copie)


En tout cas, je vais regarder dès aujourd'hui si je peux trouver SSIS et étudier cela.

Merci beaucoup en tout cas pour ton aide

[Rami]

Bon courage.

n'hesite pas a demarcher les forumeurs SQL Server, je pense que les specialiste SSIS (je suis plutot un neophite ) se trouvent la-bas.

Pour le cout de license, dis leur que ca ne reprensente qu'e x journées de travail de ton salaire (c'est souvant l'argument qui fait mouche) mais c'est vrai que c'est une periode compliquer pour le moindre achat ^^

pour la copie et la migration, SSIS devrait te combler.
Sinon un petit outil tout simlpe qui genere tout les scripts qui vont bien:
SQL Publishing Wizard.
ca peut etre bien pratique parfois.