web-dev-qa-db-fra.com

Autorisations du débogueur SQL Server sans accorder sysadmin aux développeurs

La documentation BOL indique que l'autorisation sysadmin est requise pour exécuter le débogueur.

Je suis certain à 90% qu'il n'y a pas de solution à cette exigence, mais j'ai pensé demander au cas où quelqu'un trouverait un moyen d'accorder l'autorisation du débogueur sans accorder l'autorisation sysadmin.

Que font les gens quand une équipe de développeurs a besoin de parcourir une boucle de curseur compliquée avec des variables, etc. pour déboguer un aspect de cela?

La plupart des boutiques n'autorisent pas les développeurs à avoir une autorisation sysadmin même sur les serveurs de développement, et beaucoup ne permettraient pas aux développeurs de conserver une copie des données d'entreprise sur leur machine locale avec leur propre édition de serveur SQL développeur, par exemple pour des raisons PII et de sécurité des données.

Je ne sais pas pourquoi le débogueur serait configuré de cette façon.

Donc, je suis curieux de voir comment d'autres personnes gèrent les demandes d'autorisation du débogueur dans un scénario similaire.

Que faites-vous dans votre environnement?

sql-serversql-server-2014permissionsdebugging
5
GWR

Vous pouvez ajouter une variable declare @idebug int À vos procédures stockées, puis coder autour des bits importants lorsque vous avez besoin d'informations pertinentes.

Votre procédure stockée ressemblerait alors un peu à ceci:

CREATE PROCEDURE [dbo].[uspDoSomething]
...
@iiDebug int = 0
...
AS
...
BEGIN
    /* debugging configuration */   
    declare @debug int

    /* debug settings
    1 = turn on debug information
    2 = turn on all possible outputs
    4 = turn on transaction handling

    e.g.: Adding an @iDebug paramter of 6 will turn on transaction handling 
    and turn on all possible output information

    e.g.: Adding an @iDebug value of 1 will turn on debugging information
    */ 

    set @debug = @iiDebug
    ....
    if @debug & 1 = 1  print 'Checking variables...'

                    /* If general output has been turned on print output*/ 
                    if @debug & 2 = 2 
                        BEGIN
                            PRINT 'Debug comment here' + convert(varchar(100), @iRetVal) + 'Debug comment here' + convert(varchar(20),getdate())
                        end

                    close <cursor_name>
                    deallocate <cursor_name>

                    RETURN(@iRetVal)
    ...
    END
    ...
END

Ceci est juste un exemple de la façon dont cela peut être fait.

Vous appelleriez alors le sproc avec:

execute uspDoSomething @iiDebug = 3

... qui fournirait des informations de base (au niveau du bit 1) et détaillées (au niveau du bit 2), selon l'endroit où vous avez inséré le code correspondant.

J'ai eu des problèmes une fois lors de l'exécution d'une procédure stockée qui ne produisait pas les bons résultats et j'ai dû déboguer les instructions individuelles, j'ai donc simplement entré les différents niveaux de débogage dans la procédure stockée et, lorsque cela était nécessaire, j'ai exécuté le sproc avec le @iiDebug Valeurs selon le niveau d'information dont j'ai besoin.

Exemples de valeurs d'entrée:

@iiDebug = 1 -- > Basic "where am I in the sproc" information
@iiDebug = 2 -- > Print of @nvSQL values
@iiDebug = 4 -- > Run individual execution of statements in BEGIN and COMMIT transactions

Exemples de code (la variable d'entrée @iiDebug Est stockée dans @debug Dans le code sproc):

set @debug = @iiDebug
...
...
if @debug & 4 = 4
BEGIN
    begin tran mojo
END
if @debug & 2 = 2 then print @nvSQL

exec @iRetVal = sp_executesql @nvSQL
if @iRetVal <> 0 
BEGIN
    /* If transactions have been turned on then rollback if failed */
    if @debug & 4 = 4
    BEGIN
        rollback tran mojo
    END

/* If transactions have been turned on then commit on success */
if @debug & 4 = 4
BEGIN
    commit tran mojo
END

Ce ne sont que des exemples rapides de la façon dont vous pouvez introduire le débogage sans avoir accès au débogueur SQL Server ou aux privilèges requis.

Attention:
Il peut s'agir d'un porc de performance et il vaut mieux le retirer de la production.

4
John aka hot2use

Je ne sais pas pourquoi le débogueur serait configuré de cette façon.

Très probablement en raison de la nature invasive/non sécurisée du débogage: le débogueur s'attache au processus SQL Server lui-même afin qu'il puisse voir à l'intérieur de ce processus et même apporter des modifications à la volée. C'est prendre le contrôle du serveur. Et affecte considérablement la sécurité ainsi que la stabilité.

C'est aussi pourquoi vous devriez pas faire cela en Production. Du tout.

Que font les gens quand une équipe de développeurs a besoin de parcourir une boucle de curseur compliquée avec des variables, etc. pour déboguer un aspect de cela?

Obtenez de nouveaux/meilleurs développeurs ;-)

et beaucoup ne permettraient pas aux développeurs de conserver une copie des données d'entreprise sur leur machine locale avec leur propre édition de serveur SQL développeur, par exemple pour des raisons PII et de sécurité des données.

Vrai. C'est pourquoi j'ai toujours trouvé utile de mettre en place une machine de test isolée. Quelles que soient les données de Production qui peuvent y être chargées, elles ne doivent contenir que suffisamment de données pour parcourir le code débogué. Il peut même être isolé de sorte que celui qui l'utilise ne puisse pas transférer les données vers sa machine de développement. Mais le code peut être modifié sur place sans avoir besoin de passer en revue le code car il s'agit simplement de tester/déboguer. Et vous n'avez pas à vous soucier de la modification des données, comme s'ils avaient restauré ces données sur la station de travail du développeur.

Une fois le problème identifié et un correctif testé, la ou les bases de données ainsi que les fichiers de données et journaux peuvent être supprimés. S'il y a des PII à nettoyer (en supposant que cela n'interfère pas avec les tests/débogages), cela peut être fait avant de donner accès à n'importe quel développeur.

1
Solomon Rutzky

Si vous n'êtes pas totalement opposé à donner à chaque développeur une copie de la base de données pour jouer localement, envisagez de prendre le temps de configurer un script dans votre environnement de test/développement qui réduira la base de données à une taille de jouet. Conservez les n derniers mois de données, nettoyez/anonymisez vos données PII, et autant que cela me fait mal de le dire, si nécessaire, configurez les données nécessaires pour tester les scénarios (les DBA, enfin, au moins moi, ne le font pas comme configurer des données de test pour d'autres développeurs, mais si vous êtes le seul à y avoir accès, je suppose que vous devez). Chaque développeur peut ensuite prendre cette base de données et la restaurer localement.

Là où je travaille, nous avons un serveur sandbox où tout se passe, il est donc facultatif pour le développeur de restaurer localement ou de jouer dans le sandbox. Mais le même concept que ci-dessus s'applique.

1
mathewb

J'utilise SQL Builder de CAST (ver 7.0.11, build 4230). Cela me permet de déboguer des procédures stockées SANS ces autorisations spéciales requises par SQL Server Management Studio. J'ai dû créer une procédure stockée factice dans sa propre base de données pour que SQL Builder fonctionne:

Create Proc sp_dboption (
      @dbname varchar(30) = NULL,
      @optname varchar(20) = NULL,
      @optvalue varchar(10) = NULL,
      @dockpt tinyint = 1)
As
Begin
    return(0)
end

Le seul problème est que les outils CAST ne sont pas gratuits.

0
Lane