J'ai une base de données SQL Server 2008 de taille moyenne qui contient des données actuarielles. Tous les cas d'utilisation pour il sont des requêtes en lecture seule. Existe-t-il des optimisations spéciales que je devrais envisager étant donné ce scénario? Ou devrais-je simplement coller avec les règles normales d'optimisation d'une base de données?
7 Réponses :
Si c'est en lecture seule, une chose que vous pouvez faire est de mettre des index sur tout ce qui pourrait aider (l'espace permettant). L'ajout normalement d'un index est un compromis entre une performance touchée à écrire et un gain de performance pour les lectures. Si vous vous débarrassez des écritures, il n'est plus un compromis.
Lorsque vous chargez la base de données, vous souhaitez supprimer tout / la plupart des index, effectuez la charge, puis mettez les index sur les tables.
Pourquoi voudriez-vous laisser tomber tout / la plupart des index sur charge? Vous pouvez obtenir une légère meilleure performance lors du chargement des données, mais vous risquez de ne pas remettre les indices. Non seulement cela, mais si vous prenez les index offrant et chargez de mauvaises données, vous ne verrez pas le problème avant d'essayer de mettre les index là-bas (si vous vous en souvenez). Chargement de données est une offre unique, ce n'est pas quelque chose qui se passe tout le temps. S'il faut un peu plus longtemps pour insérer, ce n'est pas une grosse affaire. Avoir des données significatives, inestimables.
WLater, prenant les index et les recréer est un moyen courant de faire les charges, il peut extrêmement accélérer les choses. Vous n'avez pas à vous rappeler de les remettre, cela fait partie du paquet SSIS qui fait la charge. Je pense que vous envisagez de laisser tomber les PKS et FKS que vous ne voudrez pas faire habituellement.
Comme Hlgem l'a dit, je ne disais pas que vous devriez supprimer PKS / FKS (bien que dans certains cas, cela puisse être préféré). La différence lors du chargement de nombreuses données où il peut y avoir de nombreux index impliqués peut être beaucoup plus que, "un peu plus longtemps".
La chute d'index non uniques est bonne. Tous les index uniques (non redondants) ou d'autres contraintes doivent rester.
Qu'ils soient ou ne devraient pas rester, c'est un appel de jugement. Si j'ai une source de données précise et que la chute de FKS améliorera considérablement les performances de l'importation, je vais peser cet avantage contre le risque de rétablir une restauration parce que les ajoutez-les échouent en raison de mauvaises données. L'importation de mauvaises données dans votre base de données ne signifie pas que vous devez le garder là-bas. De toute évidence, tout processus ETL devrait inclure des chèques à la fin avec un plan de restauration au cas où il y a un problème.
Je ne suis pas sûr de ce que vous considérez "des règles normales", mais voici quelques suggestions.
Si vous êtes sûr à 100%, c'est en lecture seule, vous pouvez Définissez le niveau d'isolation de la transaction sur READ_UNCOMMITE . Il s'agit du réglage de lecture le plus rapide possible, mais cela conduira à des lectures fantômes et des lectures sales si vous écrivez sur les tables.
Si vous avez des vues, utilisez des vues indexées (créez des index en clustered pour eux). Comme ils ne devront jamais être mis à jour, la pénalité de performance est annulée.
dans la base de données:
dans le programme:
Pour une table en lecture seule, envisagez de modifier les index pour utiliser un facteur de remplissage de 100%.
Cela augmentera la quantité de données sur chaque page de données. Plus de données par page, moins de pages à lire, moins d'E / S, ainsi de meilleures performances.
J'aime cette option car elle améliore les performances sans modifications de code ni changements de table.
Pour le réglage des performances il y a plusieurs choses que vous pouvez faire. fonctionne Denormailzation. index cluster approprié en fonction de la façon dont les données seront interrogé. Je ne recommande pas d'utiliser un soupçon nolock. J'utilise le niveau d'isolement de capture instantanée.
Il est également important sur la façon dont votre base de données est mis sur les disques. Pour obtenir des performances en lecture seule, je vous recommande Raid 10, avec mdf séparé et de LDF de broches à isolés. Normalement, pour une base de données de production, il serait Raid 5 pour les données et RAID 1 pour les journaux. Assurez-vous que vous disposez d'un fichier tempdb pour chaque cpu, utilisé pour le tri, une bonne taille de départ est des données 5Go et 1 Go log pour chaque cpu. Assurez-vous également que vous exécutez vos requêtes ou procs par showplan pour optimiser les aide aussi bien que possible. Assurez-vous que le parallélisme est dans les paramètres du serveur.
Aussi, si vous avez le temps et l'espace pour une performance optimale, je la carte exactement où la vie de données sur les disques, la création de groupes et de les mettre fichiers sur des volumes complètement séparés qui sont des disques isolés dans chaque volume.
Une stratégie consiste à ajouter un groupe de fichiers lisonly à votre DB et mettez vos tables réadonnées là-bas. Un groupe de fichiers Readonly permet à SQL Server de faire un certain nombre d'optimisations, notamment des éléments tels que l'élimination de tous les serrures.
En plus de l'optimisation DB standard:
Éliminer tous les verrous n'est plus le cas dans SQL Server 2012+