des chevauchements de partitions.

Concernant les requêtes telles que celle du listing 3, qui accède uniquement à des pré-agrégations :

• Aucun partitionnement n’est nécessaire car son incidence est négligeable, voire négative.
• Appliquez la fonctionnalité d’optimisation en fonction de l’utilisation fournie par Analysis Services.

Concernant les requêtes telles que celle du listing 2, qui calcule de nombreuses agrégations à la volée :

• Partitionnez en fonction des tranches de données interrogées – par exemple, ([Partition Year].[2]. [1997], [Fatal]).
• Aucune optimisation en fonction de l’utilisation n’est nécessaire car cette approche ne produit aucun effet.
• Un niveau d’agrégation de 5 pour cent constitue le seuil maximum pour lequel une amélioration des performances est constatée.

Si vous avez de nombreuses requêtes lentes présentant des besoins de partitionnement différents, envisagez de créer des cubes distincts pour chacune d’elles. Concernant les utilisateurs ad hoc d’ordinateurs de bureau qui ne peuvent récupérer qu’un écran de résultats à la fois, le recours à plusieurs cubes peut être problématique. En revanche, pour les applications personnalisées (telles que les applications Web et de reporting) nécessitant des résultats complets, vous pouvez au choix accéder à plusieurs cubes, voire à plusieurs bases de données en arrière-plan pour des performances optimales.

Le terme « tuning » signifie que vous devez expérimenter différentes approches afin d’atteindre les performances optimales pour votre système. Les techniques et recommandations exposées dans cet article n’aboutiront pas forcément immédiatement à des performances optimales, mais si vous prenez le temps d’examiner l’utilisation de vos requêtes et d’identifier celles dont l’exécution est lente, d’évaluer les partitions susceptibles d’éviter les analyses séquentielles et de tester les partitions en question, nul doute que vous vous rapprocherez des niveaux de performances recherchés.