Comment augmenter les performances d'une base de données?

J'ai conçu des bases de données à plusieurs reprises dans mon entreprise. Pour augmenter les performances de la base de données, je regarde pour la Normalisation et l'Indexation.

Si on vous a demandé d'augmenter les performances d'une base de données qui a environ 250 tableaux et des tables avec des millions de documents, quelles sont les différentes choses que vous recherchez?

Merci d'avance.

source d'informationauteur Vaibhav Jain | 2010-01-05

  1. 10

    Optimiser la conception logique

    Le niveau logique est à propos de la structure de la requête et les tableaux eux-mêmes. Essayez de maximiser cette première. L'objectif est d'accès, peu de données que possible au niveau logique.

    • Sont plus efficaces que les requêtes SQL
    • La conception d'un schéma logique de soutien à la candidature de besoin (par exemple, le type des colonnes, etc.)
    • Conception du commerce, afin de soutenir certains cas d'utilisation, mieux que d'autres
    • Relationnel contraintes
    • Normalisation

    Optimiser la conception physique

    Le niveau physique traite de la non-logique considération, tels que le type d'index, les paramètres des tables, etc. L'objectif est d'optimiser les IO qui est toujours le goulot d'étranglement. Accordez chaque table pour l'adapter à ce besoin. Petite table peut être chargé de façon permanente chargée dans le système de gestion de cache, d'une table avec une faible vitesse d'écriture peut avoir des paramètres différents de table avec une haute fréquence de mise à jour pour prendre moins d'espace disque, etc. En fonction des requêtes, différents index peut être utilisé, etc. Vous pouvez dénormalisée les données de manière transparente avec les vues matérialisées, etc.

    • Tables de paramètres à utiliser (taille d'allocation, etc.)
    • Index (combiné, types, etc.)
    • À l'échelle du système les paramètres (taille de la mémoire cache, etc.)
    • Partitionnement
    • Dénormalisation

    Essayez d'abord d'améliorer la logique de conception, la conception physique. (La limite entre les deux est cependant vague, donc on peut dire à propos de mon catégorisation).

    Optimiser l'entretien

    Base de données doit être utilisé correctement pour rester aussi efficace que possible. Cela inclut un peu de mainteanance taks qui peuvent avoir un impact sur la perofrmance, par exemple

    • Tenir des statistiques à jour
    • Re-séquence tables critiques périodiquement
    • De maintenance de disque
    • Tout le système des trucs pour avoir un serveur qui les roches
  2. 4

    Compression. Pour la grande majorité des charges, j'ai essayé, à l'aide de la compression a été un immense plaisir. Réduit la taille des données permet de réduire l'I/O signifie un meilleur débit. Dans SQL Server 2005, les options de compression sont limitées (vardecimal). Mais je voudrais sérieusement envisager de passer à 2008 pour la compression de page seul. Ou 2008 R2 si vous utilisez nvarchar fréquemment pour obtenir de compression Unicode.

    De Conservation Des Données. L'établissement de politiques de conservation et de supprimer les anciennes données de manière agressive. Moins de données signifie moins d'I/O, signifie un meilleur débit. Ceci est généralement considéré comme opérationnel, pas de design, mais j'aime à penser à ce problème comme une application de la conception.

    Bien sûr, je suppose que vous avez déjà surveiller chaque requête pour s'assurer qu'aucun n'est stupide de bout en bout, les analyses de la table.

    Beaucoup plus de performance boosters sont pour la plupart opérationnelles ou de déploiement, pas de design: l'entretien (défragmentation, de reconstruction d'index, etc), I/O et la conception du stockage etc.

    Et dernier mais pas moins de comprendre les coûts cachés de diverses solutions clés en main. Comme, par exemple, la Réplication ou la mise en Miroir de Base de données.

  3. 3

    C'est une très vague question.

    Vous dites que vous regardez pour l'indexation, mais vous ne pouvez pas regarder l'indexation dans l'isolement. Vous avez à regarder les requêtes en cours d'exécution, les plans d'exécution, les index sont utilisés et comment ils sont utilisés. Le Profileur outil peut aider beaucoup dans la détermination des requêtes sont inefficaces.

    Côté de celle - assurez-vous d'un plan de maintenance est mis en place. Vous devriez être en mettre à jour les statistiques et la défragmentation/reconstruction d'index au moins une fois par semaine au lieu d'une grosse base de données transactionnelle.

    Si vous avez de l'infrastructure, regardez vos fichiers et paramètres. Vous devriez essayer de mettre des tables et/ou les indices qui sont grandes et souvent utilisé sur différents disques physiques, si possible. Si vous avez des très grandes tables, vous pourriez penser de partitionnement.

    Si vous rencontrez toujours des problèmes de performances, dénormalisation peut parfois aider, mais tout dépend de la situation.

    Je vais arrêter là - ne veulent pas de cette réponse pour devenir la plus aléatoire de la liste de performances SQL conseils. Je vous recommande d'être plus précis sur l'endroit où vous pensez que les problèmes de performances, et de nous en dire un peu plus sur la base de données (taille, actuel d'indexation de la stratégie, de la fréquence des transactions, tout grand les rapports dont vous avez besoin pour générer, etc.)

  4. 2

    À votre trousse à outils de normalisation et d'indexation, avec de très grandes tables vous pouvez également envisager les avantages et les inconvénients de partioning les tables. Mais vous avez les clés, il y en a déjà.

  5. 2

    Il y a beaucoup de choses que vous pourriez faire, beaucoup d'entre eux l'a déjà suggéré ci-dessus. Certains que je regarde (dans cet ordre):

    • Erreurs/journaux - plusieurs moteurs de base de données ont des outils de reporting qui fait ressortir les problèmes dans une base de données. Commencez ici pour voir si il n'y a rien que vous puissiez vous concentrer sur.
    • De conservation des données - vérifiez les spécifications de combien de temps les données doivent être conservées pour, assurez-vous que toutes les anciennes données sont transférées à un entrepôt de données pour garder la table de petite taille. (Pourquoi garder 5 ans de données en cas de besoin seulement 3 derniers mois?)
    • Look pour les analyses de la table, l'index, les données si cela peut aider (vous avez de la jauge de celui-ci contre la table de l'écrit). Vos journaux de serveur peut probablement vous aider à trouver les analyses de la table.
    • Atomique des éléments de travail, sont quelques-uns écrit en gardant des verrous sur les différents tableaux avant de commettre un point est atteint? Ces éléments de travail simplifié ou de commettre des points déplacé à la vitesse d'exécution? C'est là que vous aurez besoin d'un développeur à regarder le code.
    • Chercher longtemps l'exécution des instructions SQL, peut-elle être plus efficace? Parfois, mal structuré de requêtes peuvent vraiment de la tourbière d'une application vers le bas. Vous devrez peut-être suggérer un changement dans les codes afin d'améliorer les performances.
    • dba domaine: regardez comment les tables sont attribuées: taille de la page, plusieurs segments, etc. C'est là que les outils de diagnostic de la part du vendeur sont pratiques, car ils peuvent souvent suggérer comment vous pouvez la structure d'une table basée sur l'utilisation de l'histoire. Un dba expérimenté serait utile ici.
    • look pour le matériel/goulots d'étranglement du réseau. C'est là où vous auriez besoin d'un gars du matériel. 🙂

    Ce sont vraiment de haut niveau, je voudrais aussi prendre un coup d'oeil à ce que le fournisseur de votre moteur db suggère que des améliorations de performances.

    Aussi, je voudrais jauge de la liste comme cela à l'encontre de ce que mon patron est prêt à payer et la façon dont beaucoup de temps que j'ai. 😉

    Espère que cette aide.

  6. 2

    Mon rouleau à MySpace était "l'Amélioration de la Performance DBA/Développeur". Je dirais que la Normalisation et les Index sont une exigence de haute performance des bases de données, mais vous devez vraiment analyser vos structures de tables et les index pour vraiment débloquer les pouvoirs de conception de base de données.

    Ici sont quelques suggestions que j'aurais pour vous;

    1. Apprendre à connaître le Moteur de base de données. Une connaissance de la mise en évidence de l'I/O de la structure va un long chemin dans la conception d'un bon index ou d'une table. À l'aide de l'analyseur de performances et de Profiler, à côté de votre connaissance de ce que Lire/Écrire des e/s sont, vous pouvez mettre des chiffres derrière votre théorie de ce qui est bien formée table /index solution.

    2. Comprendre la différence entre le Cluster et les index Non Cluster et à utiliser.

    3. Utiliser sys.dm_os_waiting_tasks et le sys.dm_os_wait_stats Dmv. Ils vous diront où vous devez mettre vos efforts dans la réduction des temps d'attente.

    4. Utilisez DBCC ENSEMBLE des STATISTIQUES IO/TEMPS, et d'évaluer vos plans d'exécution pour voir si une requête réduit ou augmente le nombre de lectures de page ou la durée.

    5. DBCC SHOWCONTIG vous dira si vos tables sont fortement fragmenté. Ceci est souvent négligé par les développeurs et Jr Administrateurs de base de données à partir d'un point de vue des performances - toutefois, cela peut avoir un très GRAND effet sur le nombre de page-les lectures que vous avez. Si une table a 20% de l'étendue de la page de densité, ce qui signifie que vous êtes en train de lire de près de 5 fois les données que vous ne le serait autrement si la table et les index ont été défragmenté.

    6. Évaluer sale-lit ( nolock, read uncommited ). Si vous pouviez faire disparaître ordre de la milliseconde de précision sur le lit, enregistrer les serrures!

    7. Envisager de prendre inutilement les Clés Étrangères. Ils sont utiles dans les environnements de Dev, pas sur la haute performance des systèmes transactionnels.

    8. Partitions dans les grandes tables de faire une grande différence - le seulement si elle est bien conçue.

    9. Modification de l'Application - Si vous pouviez calendrier de mises à jour par lot pour les transactions asynchrones, les mettre dans un index-libre du tas et de les traiter sur la planification de sorte que vous n'avez pas constently mettre à jour les tables dont vous interrogez fortement.

    10. Toujours Toujours Toujours!!! utiliser le même type de données de la variable de requête de la cible colonnes; Par exemple, l'instruction suivante utilise une variable de type bigint pour une colonne de type smallint:

    declare @je bigint
    set @i = 0

    select * from MyTable where Col01SmallInt >= @i

    Dans le processus de l'évaluation de l'index /la table des pages, le moteur de requête peut choisir de convertir votre smallint de données de la colonne de type de données bigint. Considérer la place, de changer votre varialbe type, ou au moins de le convertir à smallint dans votre condition de recherche.

    1. SQL 2005/08 vous donne "Rapports" dans la Gestion de la Demande, jetez un oeil à des rapports sur la façon dont votre index. Sont-ils en cours de numérisation, tant Recherchée? lors de votre dernière Analyse de la Table? Si c'était récent, il existe des indices de non respect de toutes les requêtes nécessaires. Si vous avez un indice qui n'est guère utilisé (seeked ou scanné), mais est constamment mis à jour, pensez à supprimer.. il peut vous faire économiser beaucoup d'inutiles de la ligne de verrous et de serrures.
      ..

    C'est tout ce que je peux penser à du haut de ma tête. Si vous rencontrez des problèmes plus spécifiques, j'aurais plus de réponse spécifique pour vous..

  7. 1

    Si une requête est extrêmement mission-critique, vous pourriez envisager de de-normalisation, afin de réduire le nombre de table-recherches par requête.
    A côté de cela, si vous avez besoin de plus de performance au-delà de l'indexation et de normaliser peut effectuer, vous voudrez peut-être regarder du programme-côté: la mise en cache, optimisation des requêtes/stockage-procédures, etc.

  8. 1

    Afin d'accroître les performances, vous aurez besoin de surveiller votre première base de données. Vous pouvez suivre le avant de le charger dans sql server profiler pour savoir qui sont les plus lentes des requêtes. Après cela, vous pouvez vous concentrer sur eux.

    Vous pouvez également utiliser les vues dynamiques et de gestion de la fonction pour trouver les index manquants. Vous serez également en mesure de récupérer des statistiques sur les indices tels que l'indice d'utilisation et de manquer d'index.

  9. 0

    Optimiser les requêtes qui sont utilisés pour accéder à cette base de données qui est le plus important. Juste en ajoutant des index vous n'avez pas de garantie que les requêtes de les utiliser.

  10. 0

    Nous n'avons pas écrit sur une performance peu:

    Matériel.

    Les bases de données sont intensément I/S en. Le déplacement d'un disque dur plus rapide devrait augmenter la vitesse de requêtes de base de données. Le fractionnement de la base de données entre plusieurs rapide des disques durs pourrait l'améliorer encore plus.