je recherche des tests, charges...bench, des expériences, white
papers....enfin peu importe, entre les performances de sql server et la
volumétrie des bases.
- Les performances baissent elles de facon significatives en fonction de
l'augmentation du volume de la base ?
- Peut on compenser efficacement par une augmentation du hardware.
- Ce ratio performance/volume est il dépendant d'autres
critères....(normalisation des bases, gestion des index...)
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
AB
Bonjour, Utilisez le profiler de Sql Server. Dans un premier temps choisi, dans la classe événements disponible pour une trace, RCP:Completed pour les procedures stockées et SQL:batchCompleted pour T-SQL. au niveau colonne de données prendre la 'duration'. le resultat est à stockées dans un fichier de trace ou dans une table sql. Optez pour une table SQL c'est plus facile pour faire des requêtes sur les colonnes duration. Prendre toutes les duration importantes. Ce qui en ressortira, c'est la procedure stockée ou la requête qui pose problème.
Pour une procedure stockée revoir la logique technique (cursor doit être en open fast_forward et read_only si le cursor n'a pas besoin d'être modifié). Pour tout ce qui est du 'Select avec un clause where + jointure, travailler sur les index. Toutes les colonnes du where et ceux utiliser dans la jointure doivent être indexées.
Sinon rajouter de la ram pour le cache sql server ainsi qu'un bon matériel. Il faut travailler sur les 4 points suivants si on veut gagner en performance. 1 - Cofiguration memoire sql server 2 - Index 3 - Archivage 4 - Matériel.
Plus la bd prend du volume plus il faut agir sur ces 4 points pour améliorer les performances.
Un conseil: suivez régulièrement les performances. n'attendez pas la dernière minute pour le faire.
Cordialement AB
Cordialement AB
"Lac" a écrit :
Bonjour,
je recherche des tests, charges...bench, des expériences, white papers....enfin peu importe, entre les performances de sql server et la volumétrie des bases. - Les performances baissent elles de facon significatives en fonction de l'augmentation du volume de la base ? - Peut on compenser efficacement par une augmentation du hardware. - Ce ratio performance/volume est il dépendant d'autres critères....(normalisation des bases, gestion des index...)
merci pour vos infos...
Bonjour,
Utilisez le profiler de Sql Server.
Dans un premier temps choisi, dans la classe événements disponible pour une
trace, RCP:Completed pour les procedures stockées et SQL:batchCompleted pour
T-SQL. au niveau colonne de données prendre la 'duration'. le resultat est à
stockées dans un fichier de trace ou dans une table sql. Optez pour une table
SQL c'est plus facile pour faire des requêtes sur les colonnes duration.
Prendre toutes les duration importantes. Ce qui en ressortira, c'est la
procedure stockée ou la requête qui pose problème.
Pour une procedure stockée revoir la logique technique (cursor doit être en
open fast_forward et read_only si le cursor n'a pas besoin d'être modifié).
Pour tout ce qui est du 'Select avec un clause where + jointure, travailler
sur les index. Toutes les colonnes du where et ceux utiliser dans la jointure
doivent être indexées.
Sinon rajouter de la ram pour le cache sql server ainsi qu'un bon matériel.
Il faut travailler sur les 4 points suivants si on veut gagner en performance.
1 - Cofiguration memoire sql server
2 - Index
3 - Archivage
4 - Matériel.
Plus la bd prend du volume plus il faut agir sur ces 4 points pour améliorer
les performances.
Un conseil: suivez régulièrement les performances. n'attendez pas la
dernière minute pour le faire.
Cordialement
AB
Cordialement
AB
"Lac" a écrit :
Bonjour,
je recherche des tests, charges...bench, des expériences, white
papers....enfin peu importe, entre les performances de sql server et la
volumétrie des bases.
- Les performances baissent elles de facon significatives en fonction de
l'augmentation du volume de la base ?
- Peut on compenser efficacement par une augmentation du hardware.
- Ce ratio performance/volume est il dépendant d'autres
critères....(normalisation des bases, gestion des index...)
Bonjour, Utilisez le profiler de Sql Server. Dans un premier temps choisi, dans la classe événements disponible pour une trace, RCP:Completed pour les procedures stockées et SQL:batchCompleted pour T-SQL. au niveau colonne de données prendre la 'duration'. le resultat est à stockées dans un fichier de trace ou dans une table sql. Optez pour une table SQL c'est plus facile pour faire des requêtes sur les colonnes duration. Prendre toutes les duration importantes. Ce qui en ressortira, c'est la procedure stockée ou la requête qui pose problème.
Pour une procedure stockée revoir la logique technique (cursor doit être en open fast_forward et read_only si le cursor n'a pas besoin d'être modifié). Pour tout ce qui est du 'Select avec un clause where + jointure, travailler sur les index. Toutes les colonnes du where et ceux utiliser dans la jointure doivent être indexées.
Sinon rajouter de la ram pour le cache sql server ainsi qu'un bon matériel. Il faut travailler sur les 4 points suivants si on veut gagner en performance. 1 - Cofiguration memoire sql server 2 - Index 3 - Archivage 4 - Matériel.
Plus la bd prend du volume plus il faut agir sur ces 4 points pour améliorer les performances.
Un conseil: suivez régulièrement les performances. n'attendez pas la dernière minute pour le faire.
Cordialement AB
Cordialement AB
"Lac" a écrit :
Bonjour,
je recherche des tests, charges...bench, des expériences, white papers....enfin peu importe, entre les performances de sql server et la volumétrie des bases. - Les performances baissent elles de facon significatives en fonction de l'augmentation du volume de la base ? - Peut on compenser efficacement par une augmentation du hardware. - Ce ratio performance/volume est il dépendant d'autres critères....(normalisation des bases, gestion des index...)
merci pour vos infos...
Sébastien GROSBOIS \(Microsoft France\)
Bonjour,
Malheureusement c'est très difficile de répondre à une question aussi ouverte !
Sachez cependant que la taille de la base n'est pas toujours facteur principal en ce qui concerne les performances d'un moteur relationnel.
Le premier facteur de performance est applicatif et notamment degré de normalisation en fonction de l'activité (OLTP,DW), les index, la qualité d'écriture des requêtes. Après seulement intervient le hardware (disques, mémoire, CPU) mais en aucun cas la surenchèrede harware ne pourra compenser une application mal écrite. Ensuite, la limitation en performance dépend de votre budget hardware (les plus gros systèmes actuels peuvent atteindre plusieurs millions de dollars)
Mais grosso modo sur une application de type tansactionnelle bien designé et correctement indexé la dégradation de performance devrait être faiblement corrélée avec l'augmentation des volumes. Pour une base de type datawarehouse, dans la mesure où on accède souvent à l'ensemble des lignes des différentes tables pour calculer des aggrégats, les performances devraient décroitre doucement avec l'augmentation du volume. Dans ce cas on précalcule généralement les aggrégats dans une structure multidimensionnelle de type MOLAP (Analysis Services)
Cordialement
"Lac" wrote in message news:
Bonjour,
je recherche des tests, charges...bench, des expériences, white papers....enfin peu importe, entre les performances de sql server et la volumétrie des bases. - Les performances baissent elles de facon significatives en fonction de l'augmentation du volume de la base ? - Peut on compenser efficacement par une augmentation du hardware. - Ce ratio performance/volume est il dépendant d'autres critères....(normalisation des bases, gestion des index...)
merci pour vos infos...
Bonjour,
Malheureusement c'est très difficile de répondre à une question aussi
ouverte !
Sachez cependant que la taille de la base n'est pas toujours facteur
principal en ce qui concerne les performances d'un moteur relationnel.
Le premier facteur de performance est applicatif et notamment degré de
normalisation en fonction de l'activité (OLTP,DW), les index, la qualité
d'écriture des requêtes.
Après seulement intervient le hardware (disques, mémoire, CPU) mais en aucun
cas la surenchèrede harware ne pourra compenser une application mal écrite.
Ensuite, la limitation en performance dépend de votre budget hardware (les
plus gros systèmes actuels peuvent atteindre plusieurs millions de dollars)
Mais grosso modo sur une application de type tansactionnelle bien designé et
correctement indexé la dégradation de performance devrait être faiblement
corrélée avec l'augmentation des volumes.
Pour une base de type datawarehouse, dans la mesure où on accède souvent à
l'ensemble des lignes des différentes tables pour calculer des aggrégats,
les performances devraient décroitre doucement avec l'augmentation du
volume.
Dans ce cas on précalcule généralement les aggrégats dans une structure
multidimensionnelle de type MOLAP (Analysis Services)
Cordialement
"Lac" <laurent.coupez@irec.fr> wrote in message
news:OfxhtBUgFHA.3940@tk2msftngp13.phx.gbl...
Bonjour,
je recherche des tests, charges...bench, des expériences, white
papers....enfin peu importe, entre les performances de sql server et la
volumétrie des bases.
- Les performances baissent elles de facon significatives en fonction de
l'augmentation du volume de la base ?
- Peut on compenser efficacement par une augmentation du hardware.
- Ce ratio performance/volume est il dépendant d'autres
critères....(normalisation des bases, gestion des index...)
Malheureusement c'est très difficile de répondre à une question aussi ouverte !
Sachez cependant que la taille de la base n'est pas toujours facteur principal en ce qui concerne les performances d'un moteur relationnel.
Le premier facteur de performance est applicatif et notamment degré de normalisation en fonction de l'activité (OLTP,DW), les index, la qualité d'écriture des requêtes. Après seulement intervient le hardware (disques, mémoire, CPU) mais en aucun cas la surenchèrede harware ne pourra compenser une application mal écrite. Ensuite, la limitation en performance dépend de votre budget hardware (les plus gros systèmes actuels peuvent atteindre plusieurs millions de dollars)
Mais grosso modo sur une application de type tansactionnelle bien designé et correctement indexé la dégradation de performance devrait être faiblement corrélée avec l'augmentation des volumes. Pour une base de type datawarehouse, dans la mesure où on accède souvent à l'ensemble des lignes des différentes tables pour calculer des aggrégats, les performances devraient décroitre doucement avec l'augmentation du volume. Dans ce cas on précalcule généralement les aggrégats dans une structure multidimensionnelle de type MOLAP (Analysis Services)
Cordialement
"Lac" wrote in message news:
Bonjour,
je recherche des tests, charges...bench, des expériences, white papers....enfin peu importe, entre les performances de sql server et la volumétrie des bases. - Les performances baissent elles de facon significatives en fonction de l'augmentation du volume de la base ? - Peut on compenser efficacement par une augmentation du hardware. - Ce ratio performance/volume est il dépendant d'autres critères....(normalisation des bases, gestion des index...)
merci pour vos infos...
Fred BROUARD
Lac a écrit:
Bonjour,
je recherche des tests, charges...bench, des expériences, white papers....enfin peu importe, entre les performances de sql server et la volumétrie des bases. - Les performances baissent elles de facon significatives en fonction de l'augmentation du volume de la base ?
Absolument pas. En revanche les perfs sont fonction de la "fenêtre de données" et du nombre de demandes simultanées (requêtes).
- Peut on compenser efficacement par une augmentation du hardware.
Oui, mais dans une certaine limite. Encore faut-il estimer le volume de la base et celle de la fenêtre et choisir le bon OS. A postériori une opération de changement d'OS est délicate sur une volumétrie importante.
- Ce ratio performance/volume est il dépendant d'autres critères....(normalisation des bases, gestion des index...)
Dans le cadre des audits de bases de données que je fais régulièrement, les point de gain de temps/perf dans l'ordre d'importance sont les suivants (en dehors du hardware qui doit être pensé au démarrage) : 1) modèle de données : 60% du gain de perf. 2) écriture du code serveur (requêtes, proc stock, trigger, UDF, vues...) 20% 3) indexation : 15% 4) paramétrage Base de données / SQL Server / OS système 5%
Ces pourcentages sont des moyennes, mais peuvent varier de manière très importante. Par exemple la répartition de la base sur différents fichiers de différentes grappes RAID de différents niveau RAID permet de doubler, voire tripler les perfs dans certaines conditions.
La plupart du temps le modèle de données est fortement en cause du fait de détails subtils tels que l'utilisation des collations, le choix des types de colonnes, la taille des lignes... De même en matière d'écriture du code serveur on peut multiplier les perf de manière très significative par une ré écriture (indépendamment du plan de requête). Par exemple entre une procédure de 100 lignes avec utilisation d'un curseur et le même traitement sous la forme d'une requête très complexe avec une dizaine de sous requête, le gain peut être énorme. Encore faut-il savoir écrire proprement le code et penser de manière ensembliste ce qui est rarement le cas des développeurs. Mon expérience à montré que 80% des curseurs écrit peuvent être transformé en requête... Enfin, avec la version 2005 il est encore plus facile de se passer des curseurs du fait de l'utilisation du concept de CTE et de la récursivité des requêtes. (la v 2005 annonce des gains de temps sec de 40% en moyenne)
A +
merci pour vos infos...
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Lac a écrit:
Bonjour,
je recherche des tests, charges...bench, des expériences, white
papers....enfin peu importe, entre les performances de sql server et la
volumétrie des bases.
- Les performances baissent elles de facon significatives en fonction de
l'augmentation du volume de la base ?
Absolument pas. En revanche les perfs sont fonction de la "fenêtre de données"
et du nombre de demandes simultanées (requêtes).
- Peut on compenser efficacement par une augmentation du hardware.
Oui, mais dans une certaine limite. Encore faut-il estimer le volume de la base
et celle de la fenêtre et choisir le bon OS. A postériori une opération de
changement d'OS est délicate sur une volumétrie importante.
- Ce ratio performance/volume est il dépendant d'autres
critères....(normalisation des bases, gestion des index...)
Dans le cadre des audits de bases de données que je fais régulièrement, les
point de gain de temps/perf dans l'ordre d'importance sont les suivants (en
dehors du hardware qui doit être pensé au démarrage) :
1) modèle de données : 60% du gain de perf.
2) écriture du code serveur (requêtes, proc stock, trigger, UDF, vues...)
20%
3) indexation : 15%
4) paramétrage Base de données / SQL Server / OS système 5%
Ces pourcentages sont des moyennes, mais peuvent varier de manière très
importante. Par exemple la répartition de la base sur différents fichiers de
différentes grappes RAID de différents niveau RAID permet de doubler, voire
tripler les perfs dans certaines conditions.
La plupart du temps le modèle de données est fortement en cause du fait de
détails subtils tels que l'utilisation des collations, le choix des types de
colonnes, la taille des lignes...
De même en matière d'écriture du code serveur on peut multiplier les perf de
manière très significative par une ré écriture (indépendamment du plan de
requête). Par exemple entre une procédure de 100 lignes avec utilisation d'un
curseur et le même traitement sous la forme d'une requête très complexe avec une
dizaine de sous requête, le gain peut être énorme. Encore faut-il savoir écrire
proprement le code et penser de manière ensembliste ce qui est rarement le cas
des développeurs.
Mon expérience à montré que 80% des curseurs écrit peuvent être transformé en
requête...
Enfin, avec la version 2005 il est encore plus facile de se passer des curseurs
du fait de l'utilisation du concept de CTE et de la récursivité des requêtes.
(la v 2005 annonce des gains de temps sec de 40% en moyenne)
A +
merci pour vos infos...
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
je recherche des tests, charges...bench, des expériences, white papers....enfin peu importe, entre les performances de sql server et la volumétrie des bases. - Les performances baissent elles de facon significatives en fonction de l'augmentation du volume de la base ?
Absolument pas. En revanche les perfs sont fonction de la "fenêtre de données" et du nombre de demandes simultanées (requêtes).
- Peut on compenser efficacement par une augmentation du hardware.
Oui, mais dans une certaine limite. Encore faut-il estimer le volume de la base et celle de la fenêtre et choisir le bon OS. A postériori une opération de changement d'OS est délicate sur une volumétrie importante.
- Ce ratio performance/volume est il dépendant d'autres critères....(normalisation des bases, gestion des index...)
Dans le cadre des audits de bases de données que je fais régulièrement, les point de gain de temps/perf dans l'ordre d'importance sont les suivants (en dehors du hardware qui doit être pensé au démarrage) : 1) modèle de données : 60% du gain de perf. 2) écriture du code serveur (requêtes, proc stock, trigger, UDF, vues...) 20% 3) indexation : 15% 4) paramétrage Base de données / SQL Server / OS système 5%
Ces pourcentages sont des moyennes, mais peuvent varier de manière très importante. Par exemple la répartition de la base sur différents fichiers de différentes grappes RAID de différents niveau RAID permet de doubler, voire tripler les perfs dans certaines conditions.
La plupart du temps le modèle de données est fortement en cause du fait de détails subtils tels que l'utilisation des collations, le choix des types de colonnes, la taille des lignes... De même en matière d'écriture du code serveur on peut multiplier les perf de manière très significative par une ré écriture (indépendamment du plan de requête). Par exemple entre une procédure de 100 lignes avec utilisation d'un curseur et le même traitement sous la forme d'une requête très complexe avec une dizaine de sous requête, le gain peut être énorme. Encore faut-il savoir écrire proprement le code et penser de manière ensembliste ce qui est rarement le cas des développeurs. Mon expérience à montré que 80% des curseurs écrit peuvent être transformé en requête... Enfin, avec la version 2005 il est encore plus facile de se passer des curseurs du fait de l'utilisation du concept de CTE et de la récursivité des requêtes. (la v 2005 annonce des gains de temps sec de 40% en moyenne)
A +
merci pour vos infos...
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
