Comment puis-je dire * SI * ET * De quelles partitions * sont accessibles - sql server 2008 moteur db

Question

Setup

• Coût du Seuil Parallélisme: 5
• Max Degré de Parallélisme: 4
• Nombre de processeurs: 8
• SQL Server 2008 10.0.2.2757
• J'ai une requête avec plusieurs jointures, plusieurs enregistrements.
• Le motif est une étoile. (Table centrale avec fks dans les tables de référence)
• La table centrale est partitionnée dans la colonne de date correspondante.
• Le schéma de partition est divisée par jours
• Les données sont très bien réparti sur le schéma de partition - à en juger en comparant les tailles des fichiers dans les groupes de fichiers affectés au schéma de partition
• requêtes impliquées ont l'ensemble des prédicats sur la colonne partitionnée. tels que (cs.dte> = @min_date et cs.dte < @max_date)
• Les valeurs des paramètres de date sont un jour d'intervalle @ minuit donc, 2010-02-01, 2010-02-02
• Le plan de requête estimé ne montre aucun parallélisme

a) Cette question concerne le moteur de base de données Sql Server 2008. Quand une requête dans le moteur OLTP est en cours d'exécution, je voudrais voir/avoir le genre d'aperçu que l'on obtient lors du profilage d'une requête SSAS en utilisant l'événement Progress End - où l'on voit quelque chose comme "Terminé en lecture PartititionXYZ". B) si le plan de requête estimé ou le plan de requête réel ne montre aucun traitement parallèle, cela signifie-t-il que toutes les partitions seront/ont été vérifiées/lues? * Ce que j'essayais de dire ici était - juste b/c je ne vois pas de parallélisme dans un plan de requête, cela ne garantit pas que la requête ne frappe pas plusieurs partitions - non? Ou - existe-t-il une relation solide entre le parallélisme et # partitions accédées?

c) suggestions? Y a-t-il plus d'informations que je dois fournir? D) comment puis-je savoir si une requête est en cours de traitement en parallèle sans chercher @ le plan de requête réel? * Je ne m'intéresse vraiment à cela que si cela aide à déterminer quelles partitions sont utilisées.

---

Ajoutée Nov 10

Essayez ceci:

• Créer querys que devrait frapper 1, 3, et toutes vos partitions
• Ouvrez une fenêtre de requête SSMS et exécutez SET SHOWPLAN_XML ON
• Exécutez chaque requête une par une dans cette fenêtre
• Chaque course donnera le coup d'un morceau de XML
• Comparer ces résultats XML (j'utiliser un outil de comparaison de texte, « CompareIt », mais un outil similaire serait faire)

Vous devriez voir que les plans d'exécution sont significativement différent. Dans mes requêtes "3" et "All", il y a un morceau de texte étiqueté "ConstantScan" qui a une entrée pour (respectivement) 3 et Toutes les partitions dans la table, et cette section n'est pas présente pour la requête "1 partition" . J'utilise ceci pour déduire que oui en effet, SQL fait ce qu'il dit qu'il va faire, à savoir: ne lire que le maximum de la table comme il le croit nécessaire afin de resovle la requête.

Answer 1

Vous avez une assez bonne réponse ici: http://www.sqlservercentral.com/Forums/Topic1064946-391-1.aspx#bm1065048

Answer 2

a) Je ne connais aucun moyen de déterminer comment une requête a progressé alors que la requête est toujours en cours d'exécution. Peut-être quelque chose de finicky avec les vues du système de verrouillage et de verrouillage, mais j'en doute. (Je ne suis hélas pas assez familier avec SSAS pour établir des parallèles entre les deux.)

b) SQL utilisera probablement le parallélisme lorsque vous travaillez avec plusieurs partitions au sein d'une même table, auquel cas vous verrez le traitement parallèle des "jetons" "dans votre plan de requête. Cependant, si, pour une raison quelconque, le parallélisme n'est pas invoqué et que plusieurs partitions doivent être lues, elles seront lues sans l'utilisation du parallélisme.

d) Une autre chose que l'on ne peut peut-être pas faire. Sous des conditions très contrôlées, vous pouvez utiliser System Monitor (Perfmon) pour suivre l'utilisation du processeur ou peut-être lire des disques pendant l'exécution de la requête. Cela n'aidera pas si le serveur effectue un autre travail, ou si les données résident en mémoire (le cache du tampon), et peuvent donc être d'une utilisation limitée.

c) Qu'est-ce que vous tentez réellement de comprendre? Quelles partitions (le cas échéant) sont accédées par les utilisateurs sur une période de temps? SQL génère-t-il un plan de requête "intelligent"? Sans les détails des données, de la structure et de la requête, il est difficile d'obtenir des conseils.