いつもお世話になっております。瀬谷です。
堀川様、返信ありがとうございます。


>>複数のファイルグループを作成していて、ファイルの自動拡張は10％、
>>サイズ無制限に設定しています
>
> ファイルの自動拡張の定義は、％ではなく、MB単位の方が良いです
> １割増分の場合、元ファイルの大きさが、数百M,数Gのときは、１割でも
> 大きな容量になり、拡張作業時にパフォーマンスが一時的に落ちます。

今回、拡張に失敗したファイルは約100MBでした
他に複数ファイルがあり、数百M、数Gがあります

過去ログ1756に
ファイル拡張の単位を、「％からMBへ」または「MBから％単位へ」変更すると、
正しく反映されないという問題です。
「Transact-SQL文から実行して下さい」と書かれています。
があったのでこちらでMB単位に指定します

>>領域使用状況の同期とファイルの自動拡張に失敗した事は関係あるのでしょうか?
>
> 関係無いと思います。
> 領域使用計算の元データとなっているsp_spaceusedストアド（その根拠となる
> sysindexesテーブルの値）は、リアルタイムに更新されるものではないため、
> 現在の状況を正確に反映させるためには、DBCC　UPDATEUSAGE命令で
> 更新を掛けないといけません

SQL Server AgentにDBCC　UPDATEUSAGE命令を登録します


>>データ更新処理は最後にバックアップと圧縮を行っていて、
>
> レコードの更新や削除が比較的少ないデータベースであれば、データファイルの
> 圧縮処理は頻繁に行なわなくても良いと思います
>
> 適度に隙間がある方が、挿入や更新処理などのページ分割が抑えられることも
> あります
>
> この辺の対応は難しい要素なので、基本的には、データベースサーバーに
> お任せするのですが。。。

先週データベースサーバーが壊れた為、新しいデータベースサーバーになりました
以前のデータベースサーバーの空き容量が少なかった事と、
データ更新処理はデータ参照に使用する集計データを作成していて、ログが
400MBになるという事で圧縮処理を毎回実行するようにしていました

新サーバーは空き容量は充分なのでSQL Server Agentで検討してみます


>>select @interr=@@error
>>でエラーが発生したらテーブルにエラー番号とエラー行を記録しているのですが
>>今回の「ファイル グループがいっぱいなので」は記録されませんでした
>>エラーの種類によりストアドは強制終了になってしまうのでしょうか？
>
> ファイル拡張に失敗したような致命的エラーは、終了させられます。
>
> アプリケーションでそのエラーを復旧できるようなレベルではありませんが、
> エラーが発生したことを管理者に通知させることはできます。

現在、社内で使用しているメールソフトを使用しています
エラーでストップした時はメール送信されるようになっています