Polyspace Access データベースのクリーンアップ
Polyspace®Access™ データベースのパフォーマンスを最適化するために、古いプロジェクトや不要になったプロジェクトの削除や、データベースのバキューム処理など、データベース クリーンアップ操作を定期的に実行します。クリーンアップ操作を実行する前に、データベースをバックアップすることをお勧めします。データベースのバックアップの作成を参照してください。
プロジェクト実行またはプロジェクト全体の削除
Polyspace Access Web インターフェイスで、[プロジェクト エクスプローラー] のプロジェクトの右クリック メニューで [プロジェクトの削除] をクリックしてプロジェクトを削除するか、またはコマンド ラインで polyspace-access -delete-project
コマンドを使用してプロジェクトを削除すると、削除されたプロジェクトが [ProjectsWaitingForDeletion] フォルダーに移動されます。このプロジェクトは、このプロジェクトにアップロードされたすべての実行を含め、明示的に削除するまでデータベース内に残ります。データベースからのプロジェクトの削除を参照してください。
[ProjectsWaitingForDeletion] フォルダーは、[管理者] の役割をもつ Polyspace Access ユーザーにのみ表示されます。
データベースのサイズを適切に管理できるように、古くなったプロジェクト実行をデータベースから削除する頻度に関するポリシーを定義してください。プロジェクトごとに削除ポリシーを定義し、以下の値に基づいてPolyspace で古い実行が削除される頻度を指定できます。
プロジェクト実行の経過日数 — プロジェクトで実行を保持する最大日数 (
MAX_DAYS
) を指定します。実行のアップロード時点からの経過日数がMAX_DAYS
の値を超えると、Polyspace によりその実行がデータベースから削除されます。プロジェクト内の実行の数 — プロジェクトで保持する実行の最大数 (
MAX_RUNS
) を指定します。プロジェクトにMAX_RUNS
個の実行が既に含まれている場合に、新しい実行をアップロードすると、Polyspace によりそのプロジェクトの最も古い実行がデータベースから削除されます。
Polyspace により削除ポリシーが適用されるのは、プロジェクトに新しい実行がアップロードされたときのみです。プロジェクト実行 olderThanMaxDays
の経過日数が MAX_DAYS
の値を超えていても、新しい実行がそのプロジェクトにアップロードされなければ、実行 olderThanMaxDays
は削除されません。
[管理者] または [オーナー] の Polyspace Access 役割をもつユーザーのみが、削除ポリシーを設定できます。
注意
データベースから削除したデータは、そのデータのバックアップ コピーがない限り、復元できません。
ユーザー インターフェイスでの削除ポリシーの管理
PolyspaceAccess インターフェイスで削除ポリシーを設定、設定解除、または管理するには、[プロジェクト エクスプローラー] でプロジェクトを選択してから、[プロジェクトの詳細] ペインの [削除ポリシー] リンクをクリックします。
[実行の削除] ウィンドウでは次の操作を実行できます。
[カスタム] を選択して削除ポリシーを設定するか、[なし] を選択してポリシーを設定解除します。
Polyspace がプロジェクト実行を削除する際のしきい値として使用する実行の最大経過日数および実行の最大数を指定することで、削除ポリシーを管理します。これらのしきい値のいずれかまたは両方を指定できます。
両方のしきい値を指定すると、実行がいずれかのしきい値を満たした場合に Polyspace はプロジェクト実行を削除します。
手動で削除するプロジェクト実行を個別に選択します。実行を選択して をクリックすると、選択した実行がデータベースから削除されます。
削除ポリシーから除外する実行を、永続として設定します。このプロパティを使用すると、特定の実行が削除されないようにすることができます。たとえば、プロジェクトにアップロードした最初の実行はベースラインとして保持して、そのプロジェクトにアップロードするその他のすべての実行には削除ポリシーを適用するような場合です。Polyspace は、実行の最大数に関する削除ポリシーを適用する際、ユーザーが永続として設定した実行は数に含めません。
実行を永続として設定するには、その実行に対応する [永続] 列のセルをダブルクリックして、
[はい]
を選択します。実行をアップロードするときに、コマンド ラインでその実行を永続として設定することもできます。コマンド ラインでの削除ポリシーの管理を参照してください。削除ポリシーの対象から除外された実行は、ユーザーが明示的に削除するまでデータベース内に残ります。手動削除する実行を選択する前に、永続プロパティの設定を解除してください。
削除ポリシーでデータベースから自動的に削除されるのは、プロジェクト実行のみです。プロジェクトとそのすべての実行をデータベースから削除するには、データベースからのプロジェクトの削除を参照してください。
コマンド ラインでの削除ポリシーの管理
コマンド ラインで削除ポリシーを管理するには、以下のコマンドに polyspace-access
バイナリを使用します。
コマンド | アクション |
---|---|
-get-deletion-policy projectPath | プロジェクト パス たとえば、プロジェクト
|
| プロジェクト パス 削除ポリシーを設定すると、それ以降のすべてのアップロードでそのポリシーが適用されます。追加の実行をプロジェクトにアップロードしなければ、実行が削除のポリシー条件に一致しても Polyspace はどの実行も削除しません。 たとえば、経過日数が 30 日を超えているすべての実行を Polyspace がプロジェクト
MAX_RUNS ) が設定されているプロジェクトに対して上記のコマンドを適用すると、MAX_RUNS 条件が上書きされ、Polyspace では MAX_DAYS 条件のみが使用されます。 |
-unset-deletion-policy projectPath | プロジェクト パス たとえば、プロジェクト
|
-upload resultPath -exclude-from-deletion | 削除ポリシーからアップロードを除外します。このオプションを使用すると、特定のプロジェクト実行が削除されないようにすることができます。たとえば、プロジェクトにアップロードした最初の実行はベースラインとして保持して、そのプロジェクトにアップロードするその他のすべての実行には削除ポリシーを適用するような場合です。Polyspace は、最大数に関する実行の削除ポリシーを適用する際、ユーザーが削除対象から除外した実行は数に含めません。 削除ポリシーの対象から除外された実行は、ユーザーが明示的に削除するまでデータベース内に残ります。この実行は、Polyspace Access インターフェイスの [実行の削除] ウィンドウで [永続] として表示されます。個々の実行をコマンド ラインで手動で削除することはできません。 |
削除ポリシーで自動的に削除されるのは、プロジェクト実行のみです。プロジェクトとそのすべての実行をデータベースから削除するには、データベースからのプロジェクトの削除を参照してください。
データベースからのプロジェクトの削除
[オーナー] または [管理者] の役割をもつ Polyspace Access ユーザーは、データベースから完全に削除することなく、プロジェクトを削除できます。
ユーザー インターフェイスの [プロジェクト エクスプローラー] でプロジェクトを右クリックし、[プロジェクトの削除] を選択します。
コマンド ラインで、コマンド
-delete-project
または-move-project
を使用して、そのプロジェクトを [ProjectsWaitingForDeletion] フォルダーに移動します。
Polyspace では、[管理者] の役割をもつ Polyspace Access ユーザーのみが表示できる [ProjectsWaitingForDeletion] フォルダーに、プロジェクトとそのすべての実行を移動します。
プロジェクトとそのすべての実行をデータベースから完全に削除するには、次のようにします。
ユーザー インターフェイスの [ProjectsWaitingForDeletion] フォルダーでプロジェクトを右クリックし、[空のフォルダー] を選択します。
コマンド ラインで
polyspace-access -delete-project
コマンドを使用し、[ProjectsWaitingForDeletion] フォルダーのプロジェクトを指定します。たとえば、次のコマンドを使用すると、プロジェクト
myProj
がデータベースから削除されます。polyspace-access -delete-project ProjectsWaitingForDeletion/myProj -host example-access-server:9443 login: jsmith password: Connecting to https://example-access-server:9443 Connecting as jsmith Deletion requested for project "ProjectsWaitingForDeletion/example_project" PROJECT_DELETED ProjectsWaitingForDeletion/example_project Command Completed
[管理者] の役割をもつ Polyspace Access ユーザーのみが、このアクションを実行できます。
削除したプロジェクトの復元
[管理者] の役割をもつ Polyspace Access ユーザーは、[ProjectsWaitingForDeletion] フォルダーにある削除されたプロジェクトを復元できます。復元するには、[プロジェクト エクスプローラー] でプロジェクトを別のフォルダーに移動するか、または polyspace-access -move-project
コマンドを使用します。
データベースから削除したプロジェクトは、そのデータベースのバックアップ コピーがない限り、復元できません。
削除ポリシーへの PSCAUTO スクリプトの移行
PSCAUTO スクリプトを使用してデータベースのクリーンアップを管理している場合に、Polyspace Access R2023b 以降に更新すると、特定のプロジェクトに割り当てられていたこれらのスクリプトが、同じプロジェクトの削除ポリシーに移行されます。
たとえば、プロジェクト public/Bug_Finder_Example (Bug Finder)
に割り当てられており、プロジェクト内の実行の最大数を 10 に設定する次のような PSCAUTO スクリプトがあるとします。
assign_to_project "public/Bug_Finder_Example (Bug Finder)" AFTER_STATISTICS myScript
clean_project "public/Bug_Finder_Example (Bug Finder)" MAXRUNS 10
polyspace-access -get-deletion-policy
を使用してプロジェクト public/Bug_Finder_Example (Bug Finder)
の削除ポリシーを表示すると、プロジェクトの削除ポリシーが、スクリプトのコマンドに一致していることがわかります (MAX_RUNS
=10)。assign_to_project
コマンドを使用していない PSCAUTO スクリプトは移行されません。一般的にそのようなスクリプトは、Polyspace Access に結果をアップロードするたびに実行されるものではなく、1 回だけ実行したスクリプトです。
Polyspace Access バージョン R2023b 以降では、データベースのクリーンアップを管理する目的で PSCAUTO スクリプトを使用することはできません。
データべースのバキューム処理の実施
データベース テーブルの行を更新または削除するコマンドを実行しても、その行はテーブルからは削除されません。これは、他のデータベース トランザクションでその行の古いバージョンがまだ使用されている可能性があるためです。データベース トランザクションで使用されなくなった古い行のディスク容量を再利用するには、PostgreSQL の vacuumdb
コマンドを使用します。データベースのバキューム処理を定期的に行うことで、データベースのディスク容量が大きくなりすぎたり、断片化したりすることを防止できます。
バキューム処理を行う前に、Polyspace Access に接続しているユーザーがいないことを確認してから、Polyspace Access Web Server サービスと Polyspace Access ETL サービスを停止します。これらのサービスを停止するには、サービスをホストしているサーバー上のターミナルから、次のコマンドを入力します。
docker stop polyspace-access-etl-0-main polyspace-access-web-server-0-main
メモ
Polyspace Access バージョン R2021b 以前を実行している場合は、Docker コンテナー名が異なる可能性があります。現在実行中のコンテナーの名前を表示するには、docker ps --format '{{.Names}}'
コマンドを使用してください。
Polyspace Access データベースの定期的なバキューム処理を行うには、データベースをホストしているサーバー上のターミナルを開き、次のように入力します。
docker exec polyspace-access-db-0-main vacuumdb -U postgres prs_data
vacuumdb
コマンドを実行するときに、--analyze
オプションを使用して、PostgreSQL サーバー統計を更新することもできます。正確なサーバー統計は、データベースのパフォーマンス低下を防ぐのに役立ちます。データベースをホストしているサーバー上のターミナルを開き、次のように入力します。
docker exec polyspace-access-db-0-main vacuumdb -U postgres --analyze prs_data
データベース テーブルのサイズを最小化し、使用されていない容量をオペレーティング システムに戻すには、--full
オプションを使用して vacuumdb
を実行することで、フル バキューム処理を実行します。データベースをホストしているサーバー上のターミナルを開き、次のように入力します。
docker exec polyspace-access-db-0-main vacuumdb -U postgres --full prs_data
定期的なフル バキューム処理の実行頻度に関するポリシーを設定してください。たとえば、週に 1 回、定期的なバキューム処理を行います。
バキューム処理が完了したら、Polyspace Access Web Server サービスと Polyspace Access ETL サービスを再起動します。次のコマンドを実行します。
docker start polyspace-access-etl-0-main polyspace-access-web-server-0-main