Utilisation de l'index spatial et du processeur SQL Server 2008 avec MapGuide Open Source 2.1

Question

J'ai une table SQL Server avec des centaines de milliers de parcelles de type géométrie. J'ai fait des index sur eux en essayant différentes combinaisons de densité et d'objets par paramètres de cellule. Jusqu'à présent, je suis en train de définir pour les objets FAIBLE, FAIBLE, MOYEN, MOYEN et 16 par cellule et j'ai créé un SP qui définit le cadre de délimitation en fonction de l'étendue des entités de la table.

Il y a une incroyable amélioration des performances des requêtes qui prennent presque des minutes sans index à moins de secondes, cela devient plus rapide lorsque le zoom est plus proche, donc moins d'objets sont affichés.

Pourtant, l'utilisation du processeur atteint 100% lors de l'interrogation des fonctionnalités, même lorsque les requêtes elles-mêmes sont rapides. Je crains que cela ne vole pas dans un environnement de production.

J'utilise MapGuide Open Source 2.1 pour ce projet, mais je suis certain que la charge du processeur est due à SQL Server.

Je me demande si mes index sont correctement définis. Je n'ai trouvé aucune documentation claire sur la manière de les configurer correctement. Chaque article que j'ai lu dit essentiellement "ça dépend ..." mais rien de spécifique. Avez-vous des recommandations pour moi, y compris des livres, des articles?

Merci.

Answer 1

L'utilisation de l'unité centrale est-elle utilisée par SQL ou par le démon mapguide? L'un des problèmes que nous avons rencontré est que mapguide n'est pas très intelligent pour écrire des requêtes. Si vous êtes à un zoom maximum et que vous affichez un petit sous-ensemble d'une légende (dites seulement la transmission à ce niveau de zoom), il interrogera tous les objets de la zone de vue sans appliquer d'autre filtre. Il boucle ensuite des milliers d'enregistrements et applique le thème (qui utilise un filtre séparé). Ce que vous pouvez essayer est d'écrire des couches pour différents niveaux de zoom et d'utiliser le filtre de requête pour limiter la quantité de données renvoyées par SQL (ce qui prend probablement beaucoup de temps CPU). Cela a réduit le temps de chargement initial sur nos lignes de transmission et de distribution (le seul élément logique à afficher à ce niveau) jusqu'à quelques millisecondes, comparé à 20+ secondes.

-

Ce que je parlais est en vous assurant que vous ne les données que les besoins demandez de la couche. Supposons que vous affichiez les identifiants 1, 2, 3 et 4.

Disons que vous avez les affichages 1 et 2 aux échelles 0 -> infini. Alors que 3 et 4 ne font que 20 000 pieds. Par défaut mapguide fera essentiellement un select * avec une boîte englobante de la fenêtre. Ensuite, il passera en revue toutes les données appliquant le thème. Ainsi, à 30 000 pieds, par exemple, toutes les données seront interrogées, mais elles doivent toujours être parcourues en boucle.

Answer 2

la réponse simple est de généraliser vos données, il est donc optimisé pour l'affichage

-à-dire créer des tables supplémentaires qui ont moins de détails et est moins dense

Answer 3

Chaque fois que vous avez ce genre de question, il est temps pour extraire SQL Profiler et voir quelles requêtes sont en cours d'exécution. Ensuite, exécutez-les via le planificateur de requêtes pour voir où se trouvent les goulots d'étranglement.Vous pouvez également être paresseux (comme moi) et simplement enregistrer une charge typique en utilisant le Tuning Template, et l'exécuter à travers le Database Engine Tuning Advisor pour voir où il pense que vous pourriez ajouter des indices pour améliorer les performances.

Normalement, vous seriez également en mesure d'optimiser les requêtes qui sont exécutées sur le serveur, mais vous manquez un peu d'options en ce qui concerne MapGuide; Il se peut que MapGuide pose les questions d'une manière difficile à optimiser pour SQL Server. Si vous trouvez que c'est le cas, veuillez enter a ticket in the MapGuide Trac système