SQL Server 2005のメンテナンス計画についてアドバイスが必要です。ここで、いくつか質問があります。
私たちの場合、データは1分ごと（1分あたりわずか200レコード）に24時間年中無休で入力されます。
誰かが私にこのデータベースに適したメンテナンスプランを提案できますか？
ありがとう、
デルス
2つの言葉：ディザスタリカバリ
最良の計画はあなたがテストしたものです。
災害復旧を計画し、この計画から既存のシステムをどれだけ復元できるかを確認します。問題をメモし、それらを解決する方法を見つけてから、障害復旧を再実行します。これは、決定を下し、要件に優先順位を付けるのに役立ちます。
これは、O/S復元とSQLサーバー復元の両方で行うのが最適です。
また、いくつかのアドバイス：マスター、モデル、mssqlsystemresourceデータベースのファイルシステムコピーを実行するためのO/Sスケジュールタスクを設定します。これにより、バックアップからマスターデータベースを復元するために、SQLサーバーをシングルユーザーモードで実行する必要がなくなります。
バックアップがあればそれはすべてうまくいきますが、リカバリをテストしたことがなければ、バックアップは無価値です。
メンテナンス計画は、実際にはデータベースプロセスによって異なります。データは毎分入力されるので、ロールアップおよびetlプロセスを実行していますか？
私が言える最も重要なプロセスは、データとトランザクションログの毎日のバックアップ（テープとディスクの両方）です。
クエリプランアナライザを使用して実行速度の遅いクエリを確認します。必要に応じて、テーブルの一部を毎日または毎週再インデックス付けする必要がある場合があります。SQL Server 2005 Enterprise Editionでオンラインのインデックスの再作成を行うことができます。つまり、オフラインである必要はありません。
メンテナンス計画を作成して適切なプロセスを作成し、スケジュールされたジョブを作成して可能な限り自動化します。
パフォーマンスを維持し、データベースの一貫性を確保するために、私は通常、毎晩次のタスクを実行します。
1）データベースのバックアップ （通常、これは完全バックアップです。ただし、データベースが非常に大きい場合は、完全バックアップが週に1回{週末}に実行され、平日は増分または差分で実行されます）
2）すべてのインデックスを再構築します （これにより、すべてのインデックスも自動的に再編成されるため、再編成の手順は必要ありません。）
3）データベース統計の更新 （他の統計は以前に実行されたインデックス再構築によって自動的に更新されるため、列統計のみが必要です）
4）データベースの整合性の検証 （これは、ほとんどすべてのデータによって破損し、しばらくの間は正常に実行される可能性があるため、最も重要な手順です。その間、すべてのデータはますます破損します。）
5）成功を電子メールでオペレーターに通知します（成功と失敗の両方を送信する必要があります。失敗のみを送信する場合、サーバーが失敗の電子メールの送信を妨げる別の問題を抱えている可能性があり、そうすると彼らは決して知りません。）
6）ファイルのクリーニング （ドライブの容量によっては、古いバックアップを削除する必要があります。空きがあれば少なくとも数週間は保持するようにしていますが、データベースが大きくなるにつれて、これを確認し、場合によっては次のように減らす必要があります。 1つまたは2つの完全バックアップとして低くなります。）
7）クリーンアップ履歴 （メンテナンスプランのログ履歴はそれほど大きくないので、スペースをあまり気にせずに長い履歴を保持できます。長い間表示に失敗しているデータベースに出くわしたときに役立つ場合があります。それが失敗し始めたとき、それを使用して、それを監視している人々に、それが成功のために適切に監視されていないことを指摘します。）
注：バックアップをメインデータベースサーバーからコピーして、オフサイトに保存してください。