BOLのドキュメントには、デバッガーを実行するにはsysadmin権限が必要であると記載されています。
私はこの要件に回避策がないことを90%確信していますが、誰かがsysadmin権限を付与せずにDebugger権限を付与する方法を見つけた場合に備えて尋ねると思いました。
変数などを使用して複雑なカーソルループをステップスルーする必要がある開発者のチームがある場合、人々は何をしますか?
ほとんどのショップでは、開発サーバーに対しても開発者がsysadmin権限を持つことを許可していません。また、多くのショップでは、開発者が独自の開発者sqlサーバーエディションを使用してローカルマシンにエンタープライズデータのコピーを保持することを許可していません。 PIIとデータのセキュリティ上の理由による。
デバッガがこのように設定される理由がわかりません。
だから、私は他の人が同様のシナリオでデバッガー許可の要求をどのように処理するのか興味があります。
あなたの環境では何をしていますか?
declare @idebug int
変数をストアドプロシージャに追加し、関連情報が必要なときに重要なビットをコード化することができます。
ストアドプロシージャは、次のようになります。
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
これは、それを行う方法の単なる例です。
次に、次を使用してsprocを呼び出します。
execute uspDoSomething @iiDebug = 3
...関連するコードを挿入した場所に応じて、基本的な(ビットごとの1
)および詳細な(ビットごとの2
)情報を提供します。
正しい結果が得られないストアドプロシージャの実行中に問題が発生し、個々のステートメントをデバッグする必要があったため、ストアドプロシージャにさまざまなデバッグレベルを入力し、必要に応じて、関連する@iiDebug
値を使用してsprocを実行しました必要な情報のレベルで。
入力値の例:
@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
コードの例(入力変数@iiDebug
は、sprocコードの@debug
に格納されます):
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
これらは、SQL Serverデバッガーまたは必要な権限にアクセスせずにデバッグを導入する方法の簡単な例にすぎません。
注意:
少しパフォーマンスが独占している可能性があり、本番環境から削除することをお勧めします。
デバッガがこのように設定される理由がわかりません。
最も可能性が高いのは、デバッグの侵襲的/安全でない性質によるものです。デバッガーはSQL Serverプロセス自体にアタッチされるため、そのプロセスの内部を確認し、その場で変更を加えることもできます。それがサーバーを制御しています。セキュリティと安定性に大きな影響を与えます。
これが、プロダクションでnotを実行する必要がある理由でもあります。全然。
変数などを使用して複雑なカーソルループをステップスルーする必要がある開発者のチームがある場合、人々は何をしますか?
新しい/より良い開発者を獲得する;-)
そして多くは、開発者が独自の開発者SQLサーバーエディションを使用してローカルマシンにエンタープライズデータのコピーを保持することを許可しません。 PIIとデータのセキュリティ上の理由による。
本当です。これが、隔離された試験機を設置することが常に役立つと私がいつも思っている理由です。 Productionからのデータはどれでもロードできますが、デバッグするコードをステップ実行するのに十分なデータが含まれていれば十分です。それを分離して、それを使用している誰もが開発マシンにデータを転送できないようにすることもできます。ただし、コードは単なるテスト/デバッグであるため、コードレビューを行わなくても、その場で変更できます。また、開発者のワークステーションにこのデータを復元した場合と同様に、データの変更について心配する必要はありません。
問題が特定されて修正がテストされたら、データベースとデータおよびログファイルを削除できます。スクラブする必要があるPIIがある場合(そうすることでテストやデバッグの妨げにならないと想定)、開発者にアクセス権を与える前に行うことができます。
各開発者にローカルで操作するデータベースのコピーを提供することに全面的に反対しない場合は、テスト/開発環境でスクリプトをセットアップして、データベースをおもちゃのサイズにまで縮小することを検討してください。過去nか月のデータを保持し、PIIデータをスクラブ/匿名化し、必要に応じて、シナリオのテストに必要なデータを設定します(DBA、まあ、少なくとも私はしないでください)。他の開発者のためにテストデータを設定するようなものですが、あなたがそれにアクセスできる唯一の人なら、私はあなたがしなければならないと思います)。その後、各開発者はそのデータベースを取得してローカルに復元できます。
私が作業している場所にはサンドボックスサーバーがあり、開発者がローカルで復元したり、サンドボックスで再生したりすることは任意です。ただし、上記と同じ概念が適用されます。
CASTのSQLビルダーを使用しています(バージョン7.0.11、ビルド4230)。 SQL Server Management Studioが必要とするこれらの特別な権限なしで、ストアドプロシージャをデバッグできます。 SQL Builderを機能させるには、自分のデータベース内にダミーのストアドプロシージャを作成する必要がありました。
Create Proc sp_dboption (
@dbname varchar(30) = NULL,
@optname varchar(20) = NULL,
@optvalue varchar(10) = NULL,
@dockpt tinyint = 1)
As
Begin
return(0)
end
唯一の問題は、CASTツールが無料ではないことです。