メンテナンスとデータ保持
完全に最適化されたシステムパフォーマンスを維持するために、BriefCamデータベースとストレージの両方からのデータを含めBriefCam、処理されたデータを定期的に自動的にクリアします。
メンテナンスサービスは、複数のマシン間で負荷を分散するために複数のインスタンスにインストールできます。
自動メンテナンスをオフにするには、Maintenance.Enabled環境設定をfalseに設定します。ただし、ストレージがいっぱいになるため、これはお勧めできません。
Maintenance.ExecutionStrategy環境設定で、メンテナンスを毎日または継続的に実行するように設定できます。
設定が継続的（デフォルト）に設定されている場合、メンテナンスは1時間ごとに実行されます。
Dailyに設定した場合、実行する時間はMaintenance.CleanHour環境設定で設定されます。値は時間ベース(hh:mm:ss)で、例えば23:00:00です。
データを事前に消去するには、Maintenance.CleanHour環境設定を現在の時間に設定し、Maintenance.ExecutionStrategyをDailyに設定し、その後にMaintenanceMaintenanceServiceを再起動します。その後、メンテナンスは直ちに実行されます。その後、設定を元の値に戻すことをお勧めします。
メンテナンスの実行に失敗した場合、プロセスが起動すると、システムは自動的に復旧を試みます。復旧の試みは、TaskRecovery.IntervalsMinutes設定で設定された時間間隔で行われます（下の画像を参照）。デフォルトは10分、240分、1440分です。つまり、最初の復旧の試みは10分後、2回目の復旧の試みは4時間後、最後の復旧の試みは12時間後になります。
Maintenance.ServiceInstancesRetentionMinutes環境設定は、オフラインになってからサービスがデータベースから削除されるまでの時間を決定します。この時間はBriefCam、次の時間です。デフォルト値は43,200分（30日）です。
以下のセクションでは、メンテナンスプロセスの動作を制御する追加の環境設定について説明します。
REVIEWモジュール
注記
自動メンテナンス中に削除されたくないREVIEWケースがある場合は、ケースの画面からedit (
) （編集）アイコンをクリックし、Do not delete during maintenance(メンテナンス中に削除しない)チェックボックスを選択します。これらの印付きケースとそのアーティファクトは、他のケースやアラートが削除されても、メンテナンスプロセスでは削除されません。
ベストプラクティスは、以下の2つの設定(CaseRetentionDaysとVideoArchiveExpirationDays)を同じ値に設定することです。
設定： Maintenance.CaseRetentionDays
デフォルト： 30日
ケースの更新日が30日（デフォルト）より古い場合、ケースのすべてのデータはデータベースとディスクから削除されます。この場合、ケースの更新日は30日より前にBriefCam設定されます。ケースの更新日は30日より古くなります。
ケースの名前や説明の編集、ケースの共有、ビデオの追加/削除、ビデオスケジュールの編集、プリセットの編集、ブックマークの追加/削除など、ケースの変更はケースの更新日に影響します。ただし、ケースのウォッチリストに顔やナンバープレートを追加したり、ブックマークの詳細を編集しても、ケースの更新日には影響しません。
同じデータが他のケースで使用されている場合でも、ケースはケース画面から削除され、データはデータベースとディスクに残ります。
ケースにスケジュールが有効化された参照元が含まれている場合、ケースは削除されません。この設定の値より古いスケジュールされた参照元からのリクエストは削除されますが、そのブックマークは、ケース全体が削除されたときにのみ削除されます。ケースにスケジュールが有効化されていない参照元やスケジュールが無効化された参照元が含まれている場合は、それらの参照元も削除されません。
ケースに含まれているのが通常の参照元またはスケジュールが無効化された参照元のみの場合、ケースは通常の参照元として扱われます。つまり、ケースの更新日が30日（デフォルト）より古い場合、30日（デフォルト）より古いケースのすべてのデータがデータベースとディスクから削除されBriefCamます。
REVIEWリクエストの一部がオンデマンド処理に基づき、一部はライブリクエストに基づいている場合（一部のリクエストがすでにアラートに対して処理されているため）、アーティファクトはメンテナンスの設定に従ってREVIEWモジュールとRESPONDモジュールから削除されます。ただし、リクエストは、オンデマンド処理またはライブ処理の2つのうち最後に発生した処理日に従って、インフラストラクチャ（データベースを含む）から完全に削除されます。
ウォッチリストに関しては、ケース内に作成された内部ウォッチリストは、ケースが削除されると（メンテナンスによって、またはユーザーによって）削除されます。
ブックマークに関しては、上記のようにケースが削除されると、ブックマークも削除されます。
設定： Maintenance.VideoArchiveExpirationDays
デフォルト： 30日
この設定は、VMSから取得したビデオファイルを削除する頻度を制御します。この設定は、通常は自動で持ち込まれない（アラートのサムネイルをクリックするときだけ）RESPONDアラートでフェッチされた元のビデオにも影響します。この設定は、アラートのサムネイルをクリックした場合にのみBriefCam適用されます。例えば、RESPONDモジュールでは、各アラートの元の映像は、ユーザーが元の映像を要求するまで取得されません。ユーザーが元の映像を要求するとBriefCam、このパラメータで指定された日数の間、元の映像にすぐにアクセスできるように保持されます。
設定: Maintenance.LocalFilesRetentionInHours
デフォルト：24時間
この設定は、レンダリングされた一時ファイルがデータベースから削除される頻度（時間単位）を制御しBriefCamます。
レンダリングされた一時ファイルは次の場所にあります。..\BriefCam\ServerData\VideoStreamingGateway\VideoService 。
ここに保存されるファイルは、Webクライアントユーザーの操作によって作成されたレンダリングされたアーティファクトです。VIDEO SYNOPSIS、元のビデオなど。
設定: Maintenance.RenderingUploadedFilesRetentionDays
デフォルト： 0.5日
この設定は、アップロードされたファイルがデータベースから削除される頻度を制御しBriefCamます。
アップロードされたファイルは次の場所にあります。..\BriefCam\ServerData\VideoData\WebUpload 。
ここに保存されるファイルは、Webクライアントを介してエンドユーザーがREVIEW処理の目的でアップロードしたビデオファイルです。Investigator 、Investigator for Teams 、Protectおよび設定。
設定: clientMaintenanceCaseMessageInDays
デフォルト：7日
この設定は、ケースの削除通知の表示をいつ開始するかを制御します。ここで設定されている値は、メンテナンスプロセスによってケースが削除されるように設定される前の日数です。
注意
これらの設定はハブには適用されません。これは、サイトおよびスタンドアローンデプロイメントにのみ関連します。
RESPONDモジュール
設定：Maintenance.LiveRetentionDays
デフォルト： 7日
保存期間外のすべてのRESPONDアラートは削除されます（ブックマークが付いているアラートも削除されますが、ブックマーク自体は削除されません）。RESPONDモジュール内のブックマークは、メンテナンスプロセスによって削除されることはありません。
現在実行中のライブタスクのアラートは、保存期間外であれば削除されます。
RESEARCHモジュール
設定： Maintenance.BIAssetsRetentionDays
デフォルト： 30日
この設定は、RESEARCHBIテーブル（メタデータETLから生成される）がストレージから削除される頻度を制御します。BriefCam メタデータは、BriefCamストレージから削除される前に削除されます。これは、Qlikがデータを取得できなかった場合のバックアップです。
設定： Maintenance.BIVisualLayersRetentionDays
デフォルト： 3650日
この設定は、ダッシュボードタブで使用されるビジュアルレイヤーファイルを削除する頻度を制御します。これにより、データベースとBriefCam、画像が保存されているフォルダBriefCamーからファイルが削除されます(C:\BriefCam\ServerData\RenderData )。
これを1日未満に設定すると、ビジュアルレイヤーに影響する場合があります。
設定: Maintenance.BITaskRetentionDays
デフォルト： 3日
この設定は、RESEARCH処理タスクからのメタデータとビジュアルアセットがストレージから削除される頻度を制御しBriefCamます。メタデータは、RESEARCH処理中（継続的またはオンデマンド）に作成されるすべてのアセット/ファイル/レコードです。これは、BIルールエンジンサービスのデータを保存する期間BriefCamです。
設定: RESEARCH.QVDRetentionDays
デフォルト： 30日
この設定は、分割されたQVDを使用するデプロイメントの詳細テーブルを保持する日数を決定します。
この設定は非推奨となっており、この設定を変更してもシステムには影響しません。
QVDファイルはメンテナンスプロセスの一部ではないことに注意してください。ファイルを削除するには、以下の手順を支援するためにBriefCamサポートチームに連絡することをお勧めします。
QMCで次のタスクが実行されていないことを確認してください：
Research_DB、 、ResearchResearch_DB_Agg、Research_Aggおよび。実行中の場合は、実行が終了するまで待ちます。QMCで
Research_DBとタスクを無効にResearch_DB_Aggします。
フォルダ内の
BC_BI_SOURCE_MATCH_1およびフォルダからBC_BI_SOURCE_MATCH2、関連のないファイルを手動で削除しQlikShare\ResearchQvdます。ファイルを削除する場合は、2つのフォルダーが同じ数のファイルとギャップなしで同期されていることを確認してください。両方のフォルダーの日付は同じである必要があります。
フォルダーの更新された内容と同期する
Delete_Research_Data Application Periodic Reload Taskフォルダーを実行します。メンテナンスが完了したら、
Research_DBとResearch_DB_Aggタスクを再度有効にします。
設定： RESEARCH.DetailedLoadDays
デフォルト：30日（v6.4以前から更新された環境の場合、デフォルトは730日）
この設定は、RESEARCHアプリから読み込まれるデータを制御します（VMS時間ではなくタイムスタンプフィールドに基づきます）。この設定は、詳細なアプリの読み込みに必要なRAMに影響し、完全なデータモデルに読み込まれるデータの量を減らします。
集計ダッシュボードはこの設定の影響を受けません。
ウォッチリストのタブ
注意
この機能はハブには適用されません。これは、サイトおよびスタンドアローンデプロイメントにのみ関連します。
外部ウォッチリスト（ウォッチリストタブで管理）はメンテナンスプロセスによって削除されません。ただし、前述の通り、ケース内に作成された内部ウォッチリストは、ケースが削除されると（メンテナンスまたはユーザーによって）削除されます。
メンテナンスの除外
以下のアイテムはメンテナンス中は削除されません。
カメラの背景画像フォルダー – テスト接続を使用する場合、カメラからの画像はそのフォルダーの下に保存されます。このフォルダーには
Camera Background Images、以下の情報が含まれます。各カメラは1つの画像を保持し、接続が再テストされるたびに更新されます。このフォルダーとその内容はメンテナンスの影響を受けません。ブックマーク - RESPONDまたはREVIEWモジュールで作成されたブックマークは、元のアラートまたはオブジェクトが削除されてもシステムに残ります。ユーザーが明示的に削除した場合にのみ削除されます。
Do not delete during maintenance - REVIEWモジュールでは、ケースを編集し、Do not delete during maintenance（メンテナンス中に削除しない） チェックボックスを選択できます。これらのケースとそれに関連するアーティファクトは、メンテナンスサイクルを通じて持続します。
QVDファイル(RESEARCHモジュール)- QVDファイルはメンテナンスプロセスの一部ではなく、必要に応じて手動で削除する必要があります。
メンテナンス監視
メンテナンスを監視および追跡できます。
メンテナンスは、次のような別のサービスによって実行されます。 メンテナンスサービスと独自のログがあります。Event（イベント）画面で、サービスが実行中であるかどうかを確認できます。
メンテナンスに失敗した場合、メンテナンスイベントのしきい値に達すると、メンテナンスイベントがEvents（上記）画面に表示されます。デフォルトでは、メンテナンスの実行が少なくとも1回失敗した場合はWarning（警告）イベントが表示され、直近3回失敗した場合はCritical（重大）イベントが表示されます。
PostgreSQL手動メンテナンス
PostgreSQLデータベースでは、パフォーマンスの問題やテーブルの肥大化を防ぐために手動メンテナンスが不可欠です。VACUUM FULLおよびREINDEX操作を定期的に実行することで、データベースのパフォーマンスと安定性を維持できます。データベースの可用性への影響を回避するには、これらのタスクを、使用率が低い期間または計画されたメンテナンス期間中（理想的には数か月または半年ごと）にスケジュールします。これにより、スムーズで効率的なデータベース操作が保証されます。
最大200GBのPostgreSQL_Dataフォルダサイズのデータベースの場合、6か月に1回、最大6時間のメンテナンスウィンドウが必要です。アクティビティの多いシステムでは、それに応じてメンテナンスの時間枠と間隔が長くなります。