Pourquoi est-il important d'utiliser des vues SQL Server prises en charge avec la création de rapports SCCM ?

Alors que j'étais au Midwest Management Summit au Mall of America (MMSMOA) en mai, le sujet des vues SQL Server prises en charge a été abordé. Quelqu'un a mentionné un moyen simple de convertir des requêtes WQL en requêtes SQL. Cette « astuce », cependant, n'a pas créé de vues SQL Server prises en charge et tout le monde ne semblait pas se rendre compte que c'était une mauvaise idée. Afin de faire la lumière sur ce sujet, je vous explique dans cet article pourquoi vous ne devez utiliser que les vues SQL Server prises en charge et, plus important encore, ce qui se passe lorsque vous ne les utilisez pas.

Si vous voulez voir quelles vues et fonctions SQL Server sont prises en charge par l'équipe produit SCCM, jetez un œil à cet article de blog que j'ai publié peu de temps après MMSMOA, «Quelles sont les vues SQL Server prises en charge à utiliser avec la création de rapports SCCM ?"

Pourquoi les vues SQL Server prises en charge sont-elles importantes ?

Il y a trois raisons principales pour lesquelles vous souhaitez toujours utiliser les vues et fonctions SQL Server prises en charge, et vous devez éviter celles qui ne sont pas prises en charge avec les rapports System Center Configuration Manager (SCCM).

Ils sont:

1. Verrouillage des transactions

2. Accorder des autorisations dbo aux utilisateurs

3. Modification des autorisations sur une table/vue/etc.

Verrouillage des transactions

SCCM stocke les données dans la base de données SQL Server et un problème pouvant survenir lors de l'accès aux données à partir de la base de données SQL Server est appelé « Verrouillage des transactions ». Pourquoi est-ce important pour un administrateur SCCM et en particulier pour les rapports SCCM ? Voici la réponse simple : lorsqu'une requête SQL Server non prise en charge est exécutée pour un rapport, elle crée un verrou sur la table interrogée. Ce verrou PEUT empêcher SCCM lui-même de mettre à jour ou d'insérer des données dans la base de données, ou il peut même bloquer d'autres requêtes.

Pour plus d'informations, voir ceci Débordement de pile Publier, Comprendre SQL Server LOCKS sur les requêtes SELECT.

Les docs Microsoft (voir lien ci-dessous) sont également bonnes pour expliquer ce problème :

Dans n'importe quelle base de données, une mauvaise gestion des transactions entraîne souvent des conflits et des problèmes de performances dans les systèmes qui ont de nombreux utilisateurs. À mesure que le nombre d'utilisateurs qui accèdent aux données augmente, il devient important de disposer d'applications qui utilisent efficacement les transactions.

Plus tard, sous Notions de base sur le verrouillage et la gestion des versions de lignes, les docs disent :

Chaque transaction demande des verrous de différents types sur les ressources, telles que des lignes, des pages ou des tables, dont dépend la transaction. Les verrous empêchent d'autres transactions de modifier les ressources d'une manière qui poserait des problèmes à la transaction demandant le verrou. Chaque transaction libère ses verrous lorsqu'elle n'a plus de dépendance vis-à-vis des ressources verrouillées.

En résumé, tout cela signifie qu'aucune requête ne peut utiliser le même objet en même temps. Pour plus de détails, veuillez consulter la documentation Microsoft SQL Server : Guide de verrouillage des transactions et de gestion des versions de ligne.

Solution de verrouillage des transactions

Afin de résoudre ce problème (verrouillage des transactions), l'équipe SCCM utilise l'indice de requête (Nolock) dans les vues SQL Server prises en charge. L'indicateur de requête (Nolock) empêche ce problème de se produire.

Autorisations

Cela vous est-il déjà arrivé auparavant ? Vous créez un rapport avec des vues SQL Server non prises en charge, le testez, puis le téléchargez sur votre site SSRS. Cela fonctionne bien pour vous, donc vous donnez le rapport à quelqu'un d'autre et, « uh-oh », il l'exécute et obtient le message suivant :

  • Une erreur s'est produite lors du traitement du rapport. (rsProcessingAborted)
    • L'exécution de la requête a échoué pour l'ensemble de données 'DataSet1'. (rsErrorExecutingCommand)
      • L'autorisation SELECT a été refusée sur l'objet 'vSMS_Advertisement', base de données 'CM_CB1', schéma 'dbo'.

Une fois que vous avez déterminé qu'il s'agit d'un problème d'autorisation, vous effectuez l'une des deux mauvaises idées. Toi non plus accorder des autorisations dbo à un utilisateur ou alors modifier les autorisations sur une table/vue/etc.

Octroi d'autorisations DBO à un utilisateur

Par défaut, seuls les comptes du propriétaire de la base de données (DBO) ou de l'administrateur système (SA) dans SQL Server ont accès à tous les objets de la base de données. Étant donné que les vues, fonctions, etc. de SQL Server non prises en charge ne disposent d'aucune autorisation, seuls les comptes désignés comme DBO ou SA peuvent accéder aux données de ces vues, tables, etc. données au sein des vues, tables, etc. une de vos options est de leur accorder des droits SA ou DBO sur la base de données.

De toute évidence, c'est une mauvaise idée en raison des risques de sécurité inhérents. Le seul "avantage" est que cette méthode n'a aucun effet lorsque SCCM est mis à niveau vers une version supérieure à une date ultérieure.

Vues SQL Server prises en charge - Autorisations

Modification des autorisations sur une table, une vue, etc.

Votre autre option est moins risquée, mais comporte toujours des problèmes de sécurité. Vous pouvez simplement ajuster les autorisations « sélectionner » ou « exécuter » sur les vues, les tables, etc. Bien que cette méthode présente moins de risques pour la sécurité, elle peut vous empêcher de passer ultérieurement à une version plus récente de SCCM. Pourquoi? L'édition de la base de données SCCM n'est pas prise en charge. De plus, voulez-vous vraiment modifier les autorisations sur toutes les vues, tables, etc., que vous souhaitez utiliser ?

Vues SQL Server prises en charge

Quels sont les avantages de l'utilisation des vues et fonctions SQL Server prises en charge avec la création de rapports SCCM ? En plus d'éviter les problèmes de verrouillage et d'autorisation des transactions susmentionnés, voici quelques autres raisons :

· Administration basée sur les rôles (RBA). Vous pouvez utiliser RBA pour les requêtes. Cela signifie que si quelqu'un ne doit pas voir les données, avec un rapport RBA, il ne les verra pas !

· Ajustements des performances. Microsoft fait beaucoup d'efforts ces jours-ci pour peaufiner SQL Server, donc les performances sont plus rapides et meilleures ! À cet égard, ils mettent uniquement à jour les vues SQL Server prises en charge. D'ailleurs, les fonctions RBA sont là où elles mettent la plupart de leurs efforts. Vous pouvez voir ce que je veux dire dans ce post, "Requêtes RBA et non-RBA : quand est-ce que plus lent est réellement plus rapide ?"

Quelles vues et fonctions SQL Server sont prises en charge par Microsoft ? La réponse courte est n'importe quel objet SQL Server avec des autorisations « sélectionner » ou « exécuter » attribuées au rôle smsschm_users. Pour la liste complète, voir mon article de blog, "Quelles sont les vues SQL Server prises en charge à utiliser avec la création de rapports SCCM?"

Si vous avez des questions sur les vues et fonctions SQL Server prises en charge, n'hésitez pas à me contacter à l'adresse @GarthMJ.

Découvrez comment Right Click Tools change la façon dont les systèmes sont gérés.

Augmentez immédiatement votre productivité grâce à notre version Community Edition limitée et gratuite.

Commencez dès aujourd'hui avec Right Click Tools :

Assistance

  • Ce champ n’est utilisé qu’à des fins de validation et devrait rester inchangé.

Contact

  • Ce champ n’est utilisé qu’à des fins de validation et devrait rester inchangé.

En soumettant ce formulaire, vous comprenez que Recast Software peut traiter vos données comme décrit dans le Recast Software Politique de confidentialité.

fr_FRFrench