web-dev-qa-db-ja.com

ストアドプロシージャがいつ削除され、誰が削除したかを知る方法は？

実際、重要なジョブの1つが実行中に失敗しました。

エラーメッセージで、失敗の原因はストアドプロシージャがないためであることがわかりました。

ストアドプロシージャがユーザーの影響を受けたのはいつですか。どのユーザーがいつそれをしたかを知るにはどうすればよいですか？

sql-serversql-server-2005
6
srihari

あなたは管理トレースを取得します：

select * from fn_trace_getinfo(NULL)
where property=2
and traceid = 1

クラス47のイベントの管理トレースを調べます Object：Deleted Event Class オブジェクトタイプ 8727ストアドプロシージャ ：

select * from fn_trace_gettable('....trc', -1)
where EventClass = 47
and ObjectType=8727

管理トレースは定期的にリサイクルされ、約4〜5個のトレースが保持されます。まだ存在する最も古いtrcファイルの名前を使用する必要があります。

手順が重要な場合、DBAは、許可された担当者のみが変更または削除できることを確認する必要がありました。また、スキーマ変更の監査を実施する必要があります。これは、プロシージャを削除した人のせいではなく、完全にDBAのせいです。

11
Remus Rusanu

SQL Serverはこれをサポートしていないため、デフォルトではこの情報を見つける方法はありません。データベースが完全復旧モードの場合は、トランザクションログを読み取って、DROP PROCEDUREステートメントがいつ実行されたかを確認できます。残念ながら、これを行う簡単な方法はありません。

ApexSQL Log または Quest Toad などのサードパーティツールを使用してみることができますが、これらのツールを使用しても、これをした人のユーザー名。

試すことができる別のオプションは、fn_dblog関数をチェックアウトして、それを使用できるかどうかを確認することです。ここでの問題は、この関数が十分に文書化されていないことです。

7
JdMR

ここで間違った質問をしていると思います。

いったいなぜ、信頼できない人がデータベースで十分な権限を与えられているのですか？ それあなたが尋ねる必要がある質問。

それは、ポーチに鍵を置き忘れた後、誰があなたの家を盗んだかを突き止めるようなものです。

2
Lasse V. Karlsen

SQL Serverの "平均的な"デフォルトのインストールがサーバーに座っているとすると、この情報を特定することはできません。デフォルトでは、SQLはこの種のアクティビティを記録または追跡しません。

（この情報（DDLトリガー）をログに記録する方法はいくつかありますが、これは今のところ役に立たない-将来の活動に役立つだけです。）

Chrisは、トランザクションログを確認し、そこに存在する情報を抽出することについて述べました。これは機能しますが、SQL 2005はトランザクションログをふるいにかけるための「ネイティブ」機能を提供しません。そのためにはサードパーティのツールが必要です。そして、それは、そのデータがトランザクションログにある場合にのみ当てはまります。データベースの回復モードが「シンプル」に設定されている場合、そのデータはログからワイプされます。 （データベースがアクティブに使用されている場合は、すでに使用されていない可能性があります。）

Remus Rusanuは、システムトレースを照会する方法の概要を説明しました。とてもクールです、私はそれを賛成しています！彼が言ったように、これも保存期間が限られています。上書きされる前に、これらのファイルのコピーを作成する必要がありますnow。

上記の方法が不可能な場合、バックアップの復元と確認は、それが発生したときに追跡する可能性があります。これも、リカバリモードと、使用しているバックアップファイルによって異なります。トランザクションログバックアップでポイントインタイムリカバリを実行できる場合は、いつ削除されたかをかなり正確に推定できるはずです。完全バックアップまたは差分バックアップしかない場合は、精度が低くなります（たとえば、午後1時のバックアップにあったか、午後2時のバックアップになかった場合、1と2の間で削除されている必要があります）。

誰がそれをドロップしたか（または、どのSQLログインを介してドロップしたか）については、意図的に構成されたプロセスをインストールして実行していない限り、その情報を抽出できないと思います。開始点は、だれか（むしろ、どのログインか）を特定することですcouldドロップを実行し、そこから進みます。 SQLインストールは、成功したログインをWindowsイベントログに記録するように構成されていますか？ドメインはドメインログインを追跡するように設定されていますか？ ... SQL認証が関係している場合はどちらも役に立ちません。

それは不可能かもしれませんが、いくつかの合理的な推測をすることができるかもしれません。幸運を！

2
Philip Kelley

以下のスクリプトを使用して、疑わしいユーザーを特定できます。

SELECT 
    te.name AS eventtype
    ,t.loginname
    ,t.spid
    ,t.starttime
    ,t.objectname
    ,t.databasename
    ,t.hostname
    ,t.ntusername
    ,t.ntdomainname
    ,t.clientprocessid
    ,t.applicationname  
FROM sys.fn_trace_gettable
(
    CONVERT
    (VARCHAR(150)
    ,(
        SELECT TOP 1 
            value
        FROM sys.fn_trace_getinfo(NULL)  
        WHERE property = 2
    )),DEFAULT
) T 
INNER JOIN sys.trace_events as te 
    ON t.eventclass = te.trace_event_id 
WHERE eventclass=164
0
Anvesh

トランザクションログをさかのぼって、少なくともそのプロシージャがデータベースから削除された時期を知ることができるはずです。ユーザーが誰であるかについては、その時点でシステムにログインしていたユーザーを確認し、それをいくらか絞り込むことができる場合があります。

これが一部に役立つことを願っています。

0
Chris