7 日以上経過した「.7z」タイプのファイルを削除する SQL を作成しようとしています。
これが私が持っているもので、機能していません：
DECLARE @DateString CHAR(8)
SET @DateString = CONVERT(CHAR(8), DATEADD(d, -7, GETDATE()), 1)
EXECUTE master.dbo.xp_delete_file 0,
N'e:\Database Backups',N'7z', @DateString, 1
また、末尾の「1」を「0」に変更してみました。
これは「成功」を返しますが、ファイルは削除されません。
SQL Server 2005、標準、SP2 を使用しています
同様の問題があり、さまざまな答えが見つかりました。これが私が見つけたものです。
xp_delete_fileを使用して7zファイルを削除することはできません。これは、SQL 2000から引き継がれた、文書化されていない拡張ストアドプロシージャです。削除するファイルの最初の行をチェックして、SQLバックアップファイルまたはSQLレポートファイルのいずれかであることを確認します。ファイル拡張子に基づいてチェックしません。私が収集したものから、その使用目的は、古いバックアップと計画レポートをクリーンアップするための保守計画にあります。
これは、7日より古いバックアップファイルを削除するためのTomalakのリンクに基づくサンプルです。人々をつまずかせるのは、「sys」スキーマ、フォルダーパスの末尾のスラッシュ、およびファイル拡張子にドットがないことです。SQL Serverを実行するユーザーも、フォルダーに対する削除権限を持っている必要があります。
DECLARE @DeleteDate datetime
SET @DeleteDate = DateAdd(day, -7, GetDate())
EXECUTE master.sys.xp_delete_file
0, -- FileTypeSelected (0 = FileBackup, 1 = FileReport)
N'D:\SQLbackups\', -- folder path (trailing slash)
N'bak', -- file extension which needs to be deleted (no dot)
@DeleteDate, -- date prior which to delete
1 -- subfolder flag (1 = include files in first subfolder level, 0 = not)
xp_delete_fileはSP2で壊れており、レポートファイルでは機能しないことに注意してください。[ http://support.microsoft.com/kb/938085]に修正プログラムがあります。SP3ではテストしていません。
文書化されていないため、xp_delete_fileは、SQLServerの将来のバージョンでなくなるか変更される可能性があります。多くのサイトでは、代わりにシェルスクリプトを使用して削除を行うことを推奨しています。
私の知るxp_delete_file限り、SQL Server 2005 によって認識されるファイル (バックアップ ファイル、トランザクション ログなど) のみが削除されます。おそらく、次のようなことを試すことができます。
xp_cmdshell 'del <ファイル名>'
このspは、ネイティブSQLサーバーのバックアップファイルまたはネイティブメンテナンスレポートファイルのみを削除します（セキュリティ上の目的で）
スミンクが提案したように、あなたは使用することができます
xp_cmdshell 'del <filename>'
フォルダに対する適切な権限が必要です。
私はこの質問を見つけましたが、解決策は私には当てはまりませんでした (メンテナンス プランの一環として、SQL Server 自体が作成した .bak ファイルだったため)。
私の場合の問題はセキュリティでした。スクリプトは、SQL Server (MSSQL) (私の場合、おそらくほとんどの場合「ネットワーク サービス」) を起動するユーザーとして実行され、ファイルを削除しようとしていたフォルダーにアクセスできませんでした。
したがって、「ネットワークサービス」を追加して「変更」を許可すると役立ちました。
拡張ストアド プロシージャ xp_delete を使用して問題を解決しようとしたときに、複数の個人が追求したさまざまなアプローチとソリューションを読んだことがあります。解決策は次のとおりです。
私のシナリオでは、上記のすべてが正しかった。ルーチン xp_delete にバグがあると言うコメントがウェブ上にほとんどありません。
バックアップ ファイルが削除されていないときに、メンテナンス用の SQL を抽出し、SSMS から実行しました。結果のメッセージは、ファイルが SQL Server バックアップ ファイルではなかったというものでした。このメッセージは、バックアップが正常に復元され、操作可能なデータベースになったため、誤りでした。
データベースの検証に使用されたデータベース コマンドは次のとおりです。
RESTORE HEADERONLY FROM DISK = N'<file path\filename>.Bak'
RESTORE VERIFYONLY FROM DISK = N'<file path\filename>.bak'
上記のコマンドはどちらも、バックアップ ファイルが有効であることを示しています。
次に、イベント ビューアーを開き、接続マネージャーのログイン エラーがあったことを示すメッセージを見つけました。テスト接続ボタンで接続を検証していたので、これは奇妙でした。エラーは、私が作成したアカウントとは関係ありませんでした。
イベント ビューア メッセージ:
*ソース MS SQL SERVER からのイベント ID 17052 の説明が見つかりません。このイベントを発生させるコンポーネントがローカル コンピューターにインストールされていないか、インストールが破損しています。コンポーネントをローカル コンピューターにインストールまたは修復できます。イベントが別のコンピューターで発生した場合、表示情報をイベントと共に保存する必要がありました。
イベントには次の情報が含まれていました。
重大度: 16 エラー: 18456、OS: 18456 [Microsoft][SQL Server Native Client 11.0][SQL Server] ユーザー 'domain\servername$' のログインに失敗しました。*
次に、xp_delete が正しく機能しているマシンにログオンしました。Active Directory を調べたところ、システム アカウントが見つからなかったので、イベント ビューアーに進み、同様のメッセージを見つけました。ここで、domain\server$ のアカウントがシステム セキュリティにマップされていることが明らかになりました。
次のステップは、xp_delete が機能するデータベース セキュリティと機能しないデータベースを比較することでした。xp_delete が機能しなかったデータベースで、セキュリティの下に 2 つのログインがありませんでした。不足している 2 つのログインは次のとおりです。 NT AUTHORITY\SYSTEM NT Service\MSSQLSERVER
NT service\MSSQLSERVER を追加すると、xp_delete が正常に機能しました。
テストの 1 つの方法は、メンテナンス タスクを使用して個々のファイルを削除することです。
最初のパラメータを 0 から 1 に変更してみてください。
ここに私が見つけた小さな要約がxp_delete_fileあります。この手順では運が悪いように思えます。
これが少し古いことは承知していますが、私のフラストレーションを皆さんと共有したかったのです。私はこれらの投稿の多くと同じ問題を抱えていましたが、何もうまくいかないようでした. そのとき、NetLib というデータベースに暗号化レイヤーがあることを思い出しました。これは、バックアップが暗号化されているため、xp_delete_file がヘッダーを読み取ることができないことを意味します。OS でバッチ ファイルを使用し、エージェント ジョブから呼び出すようになりました。これが誰かに役立つことを願っています。
通常、データベースを別のサーバーに移動した場合、または SQL インスタンスを同じサーバーに再インストールしたが、バックアップが古いディレクトリに残っている場合に、このような状況に陥ります。例: データベースをサーバー 1 からサーバー 2 に移動しましたが、サーバーには定期的なバックアップを実行するメンテナンス プランがあるか、サーバー 1 に SQL インスタンスを再インストールしてデータベースを復元しました。
バックアップの場合、msdb に情報として保持されているセットはもう存在しないため、バックアップ セットを含むテーブルから派生した失敗から情報がチェックされないため、作成された古いバックアップはすべて削除されません。
EXECUTE master.sys.xp_delete_file 0, -- FileTypeSelected (0 = FileBackup, 1 = FileReport)
最初の引数は、msdb のテーブルが使用されていることを示しています。
これが誰かに役立つことを願っています。