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
TLE91
Bonjour,
Vous donnez peu d'indice pour vous aider !!!
Néanmoins, les points habituels à vérifier : - indexation de la table - si votre base possède beaucoup de tables et si cette table volumineuse est la plus sollicitées, vous pouvez la déplacer sur un disque physique à part - séparer le stockage des data et du log sur deux disques
Vérifier également les requêtes du client et, si possible, utiliser prioritairement des procédures stockées.
Valider la configuration matérielle, tout en sachant que mettre en "bête de course" ne résoudra le problème qu'à court terme si le problème est lié à la conception de la base ou des requêtes du client.
Cordialement.
"Tchot Bleze" a écrit :
Nous avons une base avec une table de 5 millions d'enregistrement. Les temps de réponse sont très longs. Que faire pour améliorer les performances ?
Bonjour,
Vous donnez peu d'indice pour vous aider !!!
Néanmoins, les points habituels à vérifier :
- indexation de la table
- si votre base possède beaucoup de tables et si cette table volumineuse est
la plus sollicitées, vous pouvez la déplacer sur un disque physique à part
- séparer le stockage des data et du log sur deux disques
Vérifier également les requêtes du client et, si possible, utiliser
prioritairement des procédures stockées.
Valider la configuration matérielle, tout en sachant que mettre en "bête de
course" ne résoudra le problème qu'à court terme si le problème est lié à la
conception de la base ou des requêtes du client.
Cordialement.
"Tchot Bleze" a écrit :
Nous avons une base avec une table de 5 millions d'enregistrement.
Les temps de réponse sont très longs.
Que faire pour améliorer les performances ?
Néanmoins, les points habituels à vérifier : - indexation de la table - si votre base possède beaucoup de tables et si cette table volumineuse est la plus sollicitées, vous pouvez la déplacer sur un disque physique à part - séparer le stockage des data et du log sur deux disques
Vérifier également les requêtes du client et, si possible, utiliser prioritairement des procédures stockées.
Valider la configuration matérielle, tout en sachant que mettre en "bête de course" ne résoudra le problème qu'à court terme si le problème est lié à la conception de la base ou des requêtes du client.
Cordialement.
"Tchot Bleze" a écrit :
Nous avons une base avec une table de 5 millions d'enregistrement. Les temps de réponse sont très longs. Que faire pour améliorer les performances ?
Fred BROUARD
Le nombre de ligne d'une table d'une base n'a aucun intérêt dans l'évaluation d'une volumétrie d'une base de données : 5 millions d'entier 32 bits => 5 Mo !
En revanche ce qui est important c'est la fenêtre de données.
Exemple : base de compatbilité recensant 16 Go de données, comprenant 3 années comptable + année en cours Mois en cours exploité à 80 % Trimestre exploité à 10 % Année comptable exploitée à 7 % Autres données exploitées à 3%
Pour servir rapidement 80% des requêtes soit le mois en cours (1 / 42) => 380 Mo de RAM suffisent ! Soit 512 Mo de RAM (exe, OS et data).
Pour servir rapidement 90% des requêtes soit le trimestre en cours (3 / 42) => 1,15 Go de RAM suffisent ! Soit 1,5 Go de RAM (exe, OS et data).
Pour servir rapidement 97% des requêtes soit l'anné comptable en cours (7 / 42) => 2,67 Go de RAM suffisent ! Soit 3 Go de RAM (exe, OS et data).
etc...
Dans l'ordre, les éléments suivants sont primordiaux : 1) RAM 2) disque (RAID 5 voire 10, SCSI impératif, 15 000 rpm) 3) qualité de la modélisation de la base et des fichiers (taille fixe) 4) écriture des requêtes et du code Transact SQL (prioc, UDF, trigger) 5) indexation 6) réglages Serveur
A lire sur l'optimisation en général : http://sqlpro.developpez.com/cours/optimiser/
A +
Tchot Bleze a écrit:
Nous avons une base avec une table de 5 millions d'enregistrement. Les temps de réponse sont très longs. Que faire pour améliorer les performances ?
-- 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 *************************
Le nombre de ligne d'une table d'une base n'a aucun intérêt dans l'évaluation
d'une volumétrie d'une base de données :
5 millions d'entier 32 bits => 5 Mo !
En revanche ce qui est important c'est la fenêtre de données.
Exemple : base de compatbilité recensant 16 Go de données, comprenant 3 années
comptable + année en cours
Mois en cours exploité à 80 %
Trimestre exploité à 10 %
Année comptable exploitée à 7 %
Autres données exploitées à 3%
Pour servir rapidement 80% des requêtes soit le mois en cours (1 / 42) => 380 Mo
de RAM suffisent ! Soit 512 Mo de RAM (exe, OS et data).
Pour servir rapidement 90% des requêtes soit le trimestre en cours (3 / 42) =>
1,15 Go de RAM suffisent ! Soit 1,5 Go de RAM (exe, OS et data).
Pour servir rapidement 97% des requêtes soit l'anné comptable en cours (7 / 42)
=> 2,67 Go de RAM suffisent ! Soit 3 Go de RAM (exe, OS et data).
etc...
Dans l'ordre, les éléments suivants sont primordiaux :
1) RAM
2) disque (RAID 5 voire 10, SCSI impératif, 15 000 rpm)
3) qualité de la modélisation de la base et des fichiers (taille fixe)
4) écriture des requêtes et du code Transact SQL (prioc, UDF, trigger)
5) indexation
6) réglages Serveur
A lire sur l'optimisation en général :
http://sqlpro.developpez.com/cours/optimiser/
A +
Tchot Bleze a écrit:
Nous avons une base avec une table de 5 millions d'enregistrement.
Les temps de réponse sont très longs.
Que faire pour améliorer les performances ?
--
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 *************************
Le nombre de ligne d'une table d'une base n'a aucun intérêt dans l'évaluation d'une volumétrie d'une base de données : 5 millions d'entier 32 bits => 5 Mo !
En revanche ce qui est important c'est la fenêtre de données.
Exemple : base de compatbilité recensant 16 Go de données, comprenant 3 années comptable + année en cours Mois en cours exploité à 80 % Trimestre exploité à 10 % Année comptable exploitée à 7 % Autres données exploitées à 3%
Pour servir rapidement 80% des requêtes soit le mois en cours (1 / 42) => 380 Mo de RAM suffisent ! Soit 512 Mo de RAM (exe, OS et data).
Pour servir rapidement 90% des requêtes soit le trimestre en cours (3 / 42) => 1,15 Go de RAM suffisent ! Soit 1,5 Go de RAM (exe, OS et data).
Pour servir rapidement 97% des requêtes soit l'anné comptable en cours (7 / 42) => 2,67 Go de RAM suffisent ! Soit 3 Go de RAM (exe, OS et data).
etc...
Dans l'ordre, les éléments suivants sont primordiaux : 1) RAM 2) disque (RAID 5 voire 10, SCSI impératif, 15 000 rpm) 3) qualité de la modélisation de la base et des fichiers (taille fixe) 4) écriture des requêtes et du code Transact SQL (prioc, UDF, trigger) 5) indexation 6) réglages Serveur
A lire sur l'optimisation en général : http://sqlpro.developpez.com/cours/optimiser/
A +
Tchot Bleze a écrit:
Nous avons une base avec une table de 5 millions d'enregistrement. Les temps de réponse sont très longs. Que faire pour améliorer les performances ?
-- 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 *************************
