SQLデータベースのメンテナンス

この情報は、あくまでもガイドとして提供されています。業界標準のベストプラクティスに従い、経験豊かなデータベース管理者のアドバイスを求めることをお勧めします。この情報は、環境全体に対する広範な影響を考慮して使用する必要があります。

次のデータベースはメンテナンスが必要です。

  • InteractDB

  • InteractCacheDB

  • IadaDB

  • AuthenticationServerDB

  • HubDB

  • AuditDB

  • NotificationCenterDB

  • LicenceManagerDB

  • FileServiceDB

  • EmailServiceDB

  • BluePrismDecisionDB

  • ImsDB

  • FileServiceDB

    • CacheDBは、Hub 4.4からFileServiceDBに置き換えられました。

データベースメンテナンスの一般的な推奨事項

以下を行うことをお勧めします。

  • すべてのデータベースに対して自動拡張を正しく設定します。推奨値は、データファイルの場合は1024MB、トランザクションログの場合は2048MBです。
  • 自動拡張イベントの頻度を最小限に抑えるため、データベースのサイズの増加に合わせて自動拡張の値を再確立します。

    • ファイルの拡張率は使用せず、一定の容量を増やします。

  • 過剰なトランザクションログの断片化ファイルを削除します。詳しくは、Microsoftオンラインヘルプを参照してください。
  • インスタントファイルの初期化をオンにします。詳しくは、Microsoftオンラインヘルプを参照してください。
  • 自動圧縮操作をオフにし、すべてのデータベースのページ検証をチェックサムに設定し、AUTO_CREATE_STATISTICSおよびAUTO_UPDATE_STATISTICSをオンにします。統計を更新するための定期的なプロセスを設けます。

    • この目的のために、HubおよびInteractによってインストールされた各データベースに対して、次のT-SQLを設定できます。

    ALTER DATABASE [ここにデータベース名] SET AUTO_CLOSE OFF

    ALTER DATABASE [ここにデータベース名] SET AUTO_SHRINK OFF

    ALTER DATABASE [ここにデータベース名] SET AUTO_UPDATE_STATISTICS ON

    ALTER DATABASE [ここにデータベース名] SET AUTO_CREATE_STATISTICS ON

    ALTER DATABASE [ここにデータベース名] SET PAGE_VERIFY CHECKSUM

  • DBCC CHECKDBを実行する定期的なプロセスを用意します。 – SQLエージェントのジョブは、システム使用率がほとんどまたは全くない時間帯に、少なくとも1日1回実行することをお勧めします。結果は、破損がないかチェックする必要があります。SQLエージェントアラートを作成して、オペレーターグループに以下のエラーを通知すると便利です。

    • 823 - ハードI/Oの破損

    • 824 - ソフトI/Oの破損

    • 825 - 読み取り/再試行の破損

    • 9100 - インデックスの破損

    • 重大度19～25のエラー

  • アドホックワークロードの最適化 = オン

  • バックアップ圧縮のデフォルト = オン

  • バックアップチェックサムのデフォルト = オン

  • 並列処理のコストしきい値 – 50から始めるといいでしょう。

  • 並列化の最大レベル - SQL ServerのNUMA構成に依存しますが、単一のNUMAノードに対するコア数未満です。

  • 自動終了の設定 = オン

  • 最小サーバーメモリ - SQL Serverごとに異なりますが、設定する必要があります。

  • 最大サーバーメモリ - SQL Serverごとに異なりますが、設定する必要があります。

ディスクレイアウトに関する推奨事項

データとトランザクションログファイル、一時データベース、バックアップには、別々のドライブを使用することをお勧めします。

メンテナンス計画を作成する

定期的なバックアップを行うためのメンテナンス計画が整っていることを確認します。SQLデータベースのバックアップには、組織が推奨するメンテナンス計画を使用します。組織にメンテナンス計画がない場合は、業界のベストプラクティスを調査し、組織のニーズに適したメンテナンス計画を選ぶことが推奨されます。

バックアップを取る

バックアップは、組織のリカバリポイント目標（RPO）とリカバリ時間目標（RTO）に基づいて設計する必要があります。

  • RPO - 障害発生後にデータをリカバリできる時点。これにより、データ消失量が決定します。
  • RTO - 障害発生後、データのリカバリにかかる時間。これにより、プラットフォームを使用できない時間の長さが決定します。

Blue Prismデータベースのバックアップおよびリカバリ計画を作成する際は、以下の点を考慮して実装することが重要です。

  • RPOとRTOの両方を定義します。
  • フルリカバリモデルを使用すると、定義したRPOとRTOに合わせて、フルバックアップ、差分バックアップ、トランザクションログバックアップを実行できます。
  • すべてのバックアップの［WITH CHECKSUM］および［VERIFYONLY］オプションを使用し、バックアップが有効であり、必要に応じて復元できることを確認します。
  • ［WITH COMPRESSION］オプションを使用してディスク領域を節約し、データベースのバックアップとオプションの復元にかかる時間を削減します。
  • バックアップおよびリカバリプロセスを文書化します。
  • 定期的に復元して、バックアップの信頼性を確認してください。

これらのバックアップを実行する頻度は、組織の規模、データリスクの量や価値によって異なります。

フルバックアップは、絶対的なダウンタイム時に実行することをお勧めします。増分バックアップは、一部のデータが失われるリスクを伴うサービスを停止することなく実行できます。

インデックスの断片化を解決する

データベースインデックスの断片化により、クエリのパフォーマンスが時間の経過とともに低下します。これを防ぐには、データベースのダウンタイムが許す限り頻繁にインデックスを再構築します。また、バックアップ取得後や大量のデータ削除後にもインデックスを再構築することをお勧めします。フルバックアップを復元する必要がある場合のインデックスの断片化を最小限に抑えるために、フルデータベースバックアップを実行する前にもインデックスを再構築することをお勧めします。

インデックスの再構築や再編成のメンテナンスに推奨されるしきい値は、再編成が30％未満、再構築が30％超です。

データベースインデックスの再構築は、データベースサーバー内のジョブとして実行するようにスケジュールしたり、データベースのメンテナンス計画に追加したりできます。システムのアクティビティが低い時間帯に実行し、バックアップおよびDBCC CHECKDBメンテナンスとの重複を避けるようにスケジュールすることをお勧めします。