web-dev-qa-db-ja.com

SQLメンテナンスクリーンアップタスクは機能するが削除はしない

BACKUPフォルダーを通過し、5日以上経過したすべての.bakを削除することを想定したメンテナンスプランがあります。ジョブを実行すると、成功メッセージが表示されますが、古い.bakファイルはまだ存在しています。

私は次の質問でステップを試しました： https://serverfault.com/questions/245493/sql-maintenance-cleanup-task-success-but-not-deleting-files

Result is column IsDamaged = 0

私は次の質問で確認しましたが、これは私の問題ではありません： https://serverfault.com/questions/94094/maintenance-cleanup-tasks-running-successfully-but-not-deleting-back-up -files

また、ジョブとメンテナンスプランを削除して再作成しようとしましたが、役に立ちませんでした。

何か案は？

sql-serversql-server-2008maintenance-plan
37
Alex

これらのチェックを試してください：

  1. ファイル拡張子に*。*を使用するか、ドットなしのbakを使用します。どちらも、他の問題が正しければ機能することがわかっています。
  2. パスが単にバックアップがある場所へのパスであるが、最後にバックスラッシュが付いていることを確認してください。
  3. 最初にバックアップを作成するときに、検証がチェックされていることを確認します。
53
sturb

同じ問題があった。 Culpritは.Bak拡張子です。それをBakに変更すれば、うまくいくはずです。

5
jordan koskei

多くの場合、これは許可の問題が原因です。ステップが実行されているアカウントがファイルの削除を許可していない場合、クリーンアップタスクは何も役に立たないようです。

これは次のように確認できます。

  • SQL Server Management Studioで、メンテナンスプランを右クリックし、[変更]を選択します
  • Bakファイルの削除に使用されるメンテナンスクリーンアップタスクを見つけて、[View T-SQL]ボタンをクリックします。スクリプトをクリップボードにコピーします-「EXECUTE master.dbo.xp_delete_file ...」のようなものになります
  • バックアップを含むフォルダーに対して必要な権限を持つWindowsアカウントを使用してサーバーに接続し、SQLを実行します
  • Bakファイルがクリーンアップされる場合、これは、メンテナンスプランタスクが正しく構成されており、アクセス許可の問題があることを示しています。
  • Management Studioで、ジョブのプロパティウィンドウを開き（SQL Serverエージェント>ジョブ）、最初のステップで[編集]ボタンをクリックします。 「実行」セクションは、ジョブを実行しているアカウントを示します。
5
Dan Malcolm

この問題についても同様に、2セントを費やします。SQL2012を使用して新しい展開を行います。バックアップジョブは正常に動作しますが、ログと古いバックアップの両方のクリーンアップタスクは正常に完了しましたが、何もしませんでした。

これらの愚かなことの中で私の意見の問題は、拡張子を.bakと.txtに設定しましたが、.BAKと.TXT（大文字）に変更するとすぐに）動作し始めました。

同様の問題をトラブルシューティングしている人の助けになることを願っています。

2
Rost

適切なSQL Serverでメンテナンスプランを作成してください。もっと詳しく言うと、

SQL Server 2005があり、maintを作成する場合。このSQL Server 2005での計画では、SQL Server 2005 Serverから生成/バックアップされたバックアップ（bak）およびトランザクションログ（trn）を「クリーンアップ」（削除）することしかできません。 2008年、2008年R2、2012年以降のbakまたはtrnをクリーンアップしようとしても、機能しません。 （ファイルヘッダー情報のため）。つまり、2005年は2008年以降の形式のファイルを認識しません！

ただし、maintを作成することにより、これらのファイルをいつでもクリーンアップできます。 SQL Server 2008の下で計画し、2005〜2012年のこれらのファイルを「クリーンアップ」します（テスト済み）。

つまり、1。2005は2005形式のbak/trnのみをクリーンアップできます。2. 2008は2005〜2012形式をクリーンアップできます。

2000（古すぎる）または2014（新しすぎる）をテストする機会がありませんでした。しかし、2014年は2008年から機能するはずです。

2
Chjquest

頻度を1週間から数日に変更する必要があり、古いバックアップが削除されることがわかりました。なぜかわかりませんが、それで問題は解決しました。

1
Cindy

以前にも同様の問題がありました。 GUIを使用したときに場所が明示的に設定されていなかったため、削除せずに遭遇しました。何も変更しなかったとしても、パスの場所が具体的にリストされていなかった場合、削除を処理する場所がわからなかったため、削除は発生しませんでした。それはうまくバックアップされ、すべてが良好でしたが、ウィザード/フォームで指定されているようにクリーンアップしませんでした。

1
Thyamine

私は同じ問題を抱えており、それを解決しようとしました。私はすべての組み合わせを試しましたが、うまくいきませんでした。 xp_delete_fileは文書化されておらず、明らかにバグが多いことに注意してください。

しかし、私がやったことであなたを支援できるのは、ステップをPowerShellステップに変更することです。

以下を使用して、30日より古いファイルを削除できます。

get-childitem c：\ sqlbackup -recurse | where {$ 。lastwritetime -lt（get-date）.adddays（-30）-and -not $。psiscontainer} |％{remove-item $ _。fullname -force -whatif}

テストできるように-whatifが追加されていることに注意してください。

しかし、私の場合、それは十分ではありませんでした。 PowerShellアプローチには権利の問題がありました。 SQLエージェントを実行しているアカウントには、ファイルを削除する権限がありませんでした。権限を正しく設定すると、すべてが魅力のように機能しました。

がんばろう

1
Anders

メンテナンスファイルを削除しようとしたときに、私の2セントを捨てるのは失敗しました。拡張子とファイルの場所は正しく設定されていましたが、バックアップファイルからメンテナンスプランファイルに設定するのを忘れていました。

0
PseudoToad

問題に夢中になりました。回避策がありますが、他のサーバーは問題なしのメンテナンスプランを使用しています。 T-SQLスクリプトをコピーし、dboをsysに変更するspを作成しました。わたしにはできる。読み取り用スクリプト

Create Procedure bk_removeTLogBackupFiles
as
Declare @DeleteDate varchar(50)
Declare @DeleteExecuteSQL varchar(1000)
Set @DeleteDate = cast(DATEADD(day,-7,GetDate()) as varchar(50))
Set   @DeleteExecuteSQL =
'EXECUTE master.sys.xp_delete_file 0,N''\\Backupserver\BackupFolder\' + @@servername + '\User'',N''trn'',N' + quotename(@DeleteDate,'''') +  ',1'


Execute (@DeleteExecuteSQL)

これは、ユーザーシステムなどのフォルダーに分類されたserver\folderのセキュリティを使用して特定のサーバーに向かうすべてのバックアップに使用する汎用スクリプトです。大したことはありませんでしたが、うまくいきました。

0
Harold