メンテナンスに関する考慮事項

Orchestrator のデータベースをすっきり整理された状態に保ち、日々の運用時にもアップグレード時もスムーズに使用できるようにすることが重要です。

それには、以下で概説するスクリプトのいずれかを使用して、古いデータを定期的にクリーンアップすることをお勧めします。その際、他のデータベース操作で許可されていれば、都合の良い時間にクリーンアップの実行をスケジュールするオプションを使用できます。

重要:

Orchestrator データベースのメンテナンス スクリプトは、Customer Portal からダウンロードできます。

データベースをバックアップする

SQL サーバーのデータベースは、週 1 回の完全バックアップや毎日の差分バックアップなど、定期的にバックアップすることを推奨します。

さらに、この場所でスクリプトを使用して作成した DatabaseBackup 保存プロシージャを利用することを推奨します。

データベースのクリーンアップ

次のスクリプトは、以前のすべてのデータベース クリーンアップ スクリプトを置換します。これらによって必要なメンテナンス タスクがすべてカバーされます。設定は必要に応じて変更できます。

SQL スクリプト

前提条件

スクリプト CreateOrchestratorCleanupObjects.sql を実行するには次の条件を満たす必要があります。

• Orchestrator データベースのコンテキスト内からアーカイブ データベースにアクセスできる必要があります。

• アーカイブには、Archive.dbo.QueueItemsTableArchive などの、3 つの構成要素から成る名前を使用してアクセスできる必要があります。

使用方法

1. SQL スクリプト CreateOrchestratorCleanupObjects.sql を実行して、以下のオブジェクトを作成します。

• 実行ログを格納する dbo.__CleanupLog テーブル。
• アーカイブ テーブルを作成または返す dbo.GetOrCreateArchiveTable プロシージャ。
• dbo.RunOrchestratorCleanup プロシージャ。古いデータを削除し、必要に応じてアーカイブします。

2. スケジューリング XML 設定ファイルを使用してdbo.RunOrchestratorCleanup を実行し、クリーンアップします。

注:

SQL Server エージェントを使用してクリーンアップを実行することもできます。

スクリプトのサンプル

DECLARE @cleanupConfigXml XML = 
'<CleanupConfig totalRunMaxMinutes="180">
	<Table name="QueueItems" runMaxMinutes="-1" idColumn="Id" dateTimeColumn="CreationTime" additionalFilter="Status IN (2, 3, 4, 5, 6)" daysOld="180" batchSize="50" forceCascade="1" shouldArchive="1" />
</CleanupConfig>';

EXEC dbo.RunOrchestratorCleanup 
@cleanupConfigXml = @cleanupConfigXml,
@archiveDatabaseName = 'OrchestratorArchive';

PowerShell スクリプト

これは、SQL スクリプトを使用できない場合に適しています。

注:

PowerShell スクリプトは PowerShell 5.1 に対応しており、Azure Automation Runbook で使用できます。

前提条件

スクリプト RunOrchestratorCleanup.ps1 は、以下の両方の接続文字列と通信できる必要があります。

• SourceConnectionString - Orchestrator データベースの接続文字列です。
• DestinationConnectionString - アーカイブ データベースの接続文字列です。アーカイブ データベースは、事前に作成して設定しておく必要があることに注意してください。

作成するオブジェクト

• 実行ログを格納する dbo.__CleanupLog テーブル。
• dbo.__CleanupIds テーブル。クリーンアップする必要がある ID の一時的なバッチを格納します。

制限事項

このスクリプトは 2 つの接続を開きます。1 つは Orchestrator データベースへの接続 (SourceConnectionString 経由)、もう 1 つはアーカイブ データベースへの接続 (DestinationConnectionString 経由) です。したがって、データは Orchestrator からアーカイブにコピーされた後、Orchestrator から削除されるため、実際のトランザクションは関与しません。

つまり、2 つのアクションの間のどこかで例外がスローされ、スクリプトが再実行されると、同じデータが再度コピーされ、アーカイブ データベースに重複が発生する可能性があります。

ただし、アーカイブ データベースでは一意であることが強制されないため、問題は発生しません。

スクリプトのサンプル

.\RunOrchestratorCleanup 
-SourceConnectionString "Data Source=.;Initial Catalog=UiPath;User ID=sa;Password=******" 
-DestinationConnectionString "Data Source=.;Initial Catalog=<OrchestratorArchive>;User ID=sa;Password=******" 
-CleanupConfigXml '<CleanupConfig totalRunMaxMinutes="180"><Table name="QueueItems" runMaxMinutes="-1" idColumn="Id" dateTimeColumn="CreationTime" additionalFilter="Status IN (2, 3, 4, 5, 6)" daysOld="180" batchSize="50" forceCascade="1" shouldArchive="1" /></CleanupConfig>'

クリーンアップのスケジュールを設定する

データベースからクリーンアップするデータと、各実行でクリーンアップ アクティビティをいつ、どれくらいの時間実行するかを選択できます。

それには、SQL または PowerShell スクリプトが記述された以下の XML ファイルを使用します。このスクリプトは、推奨パラメーターで事前設定されていますが、より高度な機能が必要な場合は編集できます。スクリプトを編集する前に、各パラメーターの機能を理解しておいてください。そうしないと、重大な結果を招く可能性があります。

<CleanupConfig totalRunMaxMinutes="180">
    <Table name="QueueItems" runMaxMinutes="-1" idColumn="Id" dateTimeColumn="CreationTime" additionalFilter="Status IN (2, 3, 4, 5, 6)" daysOld="180" batchSize="50" forceCascade="1" shouldArchive="1" />
    <Table name="Jobs" runMaxMinutes="-1" idColumn="Id" dateTimeColumn="CreationTime" additionalFilter="State IN (4, 5, 6)" daysOld="180" batchSize="50" forceCascade="1" shouldArchive="1" />        
    <Table name="Logs" runMaxMinutes="-1" idColumn="Id" dateTimeColumn="TimeStamp" additionalFilter="" daysOld="90" batchSize="1000" forceCascade="0" shouldArchive="1" />
    <Table name="AuditLogs" runMaxMinutes="-1" idColumn="Id" dateTimeColumn="ExecutionTime" additionalFilter="" daysOld="365" batchSize="25" forceCascade="1" shouldArchive="1" />
    
    <Table name="Tasks" runMaxMinutes="-1" idColumn="Id" dateTimeColumn="DeletionTime" additionalFilter="IsDeleted = 1" daysOld="180" batchSize="10" forceCascade="0" shouldArchive="1" />
    <Table name="QueueProcessingRecords" runMaxMinutes="-1" idColumn="Id" dateTimeColumn="ProcessingTime" additionalFilter="ReportType != -1" daysOld="30" batchSize="1000" forceCascade="0" shouldArchive="0" />
    <Table name="Sessions" runMaxMinutes="-1" idColumn="Id" dateTimeColumn="ReportingTime" additionalFilter="" daysOld="180" batchSize="50" forceCascade="1" shouldArchive="0" />    
    
    <Table name="RobotLicenseLogs" runMaxMinutes="-1" idColumn="Id" dateTimeColumn="StartDate" additionalFilter="" daysOld="180" batchSize="1000" forceCascade="0" shouldArchive="0" />    
    <Table name="UserNotifications" runMaxMinutes="-1" idColumn="Id" dateTimeColumn="CreationTime" additionalFilter="" daysOld="90" batchSize="1000" forceCascade="0" shouldArchive="0" />
    <Table name="TenantNotifications" runMaxMinutes="-1" idColumn="Id" dateTimeColumn="CreationTime" additionalFilter="" daysOld="90" batchSize="1000" forceCascade="0" shouldArchive="0" />    
    <Table name="Ledger" runMaxMinutes="-1" idColumn="LedgerId" dateTimeColumn="CreationTime" additionalFilter="" daysOld="7" batchSize="1000" forceCascade="0" shouldArchive="0" />
    <Table name="LedgerDeliveries" runMaxMinutes="-1" idColumn="Id" dateTimeColumn="LastUpdatedTime" additionalFilter="" daysOld="7" batchSize="1000" forceCascade="0" shouldArchive="0" />
    <Table name="__CleanupLog" runMaxMinutes="-1" idColumn="Id" dateTimeColumn="ExecutionTimeUtc" additionalFilter="" daysOld="7" batchSize="1000" forceCascade="0" shouldArchive="0" />
</CleanupConfig>

1 回の実行で 1 つまたはいくつかのテーブルを部分的にしかクリーンアップできない場合でも、すべてのバックログをクリーンアップするまでスクリプトが続けて実行されます。したがって、スクリプトで処理しきれないほど大きなバックログを蓄積しないことが重要です。蓄積されてしまう場合は、スクリプトをより頻繁に実行するようスケジュールすることを検討してください。

クリーンアップ XML のパラメーター

パラメーター	説明	予想される値
totalRunMaxMinutes	1 回の実行時にすべてのテーブルに対してスクリプトを実行できる最大時間 (分)。	1 より大きい値である必要があります。
name	削除するデータを含むテーブルの名前。	例: QueueItems
runMaxMinutes	1 回の実行時に特定のテーブルに対してスクリプトを実行できる最大時間 (分)。 重要: ここで設定する時間は、数分ほど超過することがあります。 また、このパラメーターを -1 に設定したとしても、totalRunMaxMinutes が優先され、常に適用されます。	-1: スクリプトは時間 (分) の制限なく実行されます。 0: スクリプトはその特定のテーブルに対して実行されません。 >0 (すなわち、ユーザーが選択した数値): スクリプトが実行される最大時間 (分)。
idColumn	削除するデータを含む列の ID。	例: QueueItems テーブルの Id
dateTimeColumn	これはデータ型によって異なります。 daysOld と組み合わせて使用されます。	例: QueueItems の CreationTime
additionalFilter	フィルターの有効な SQL ステートメント。 これは空のままにしておくことができます。	例: Status IN (2, 3, 4, 5, 6)。これは、UiPath が推奨する XML ファイルに含まれています。
daysOld	一定日数分のデータを保持できます。 dateTimeColumn と組み合わせて使用されます。	この値は、2 以上に設定する必要があります。 例: このパラメーターを 5 に設定すると、5 日前までのすべてのデータが保持されます。
batchSize	1 回の反復処理で削除されるテーブル行の数。 重要: これは、外部キーが定義されているテーブルには使用されません。	例: QueueItems テーブルに対してこのパラメーターを 50 に設定すると、その特定のテーブルから 50 項目が削除されます。
forceCascade	外部キーが定義されているテーブルに対してスクリプトを実行できます。 重要: このサンプルでは、テーブルで必要とされる箇所に、既に forceCascade を使用しています。したがって、変更する必要はありません。	0: カスケードしません。 1: カスケード。たとえば、QueueItems テーブルにこのオプションを設定すると、QueueItemEvents テーブルと QueueItemComments テーブルの両方が処理されます。
shouldArchive	データをアーカイブするかどうかを選択できます。	0: アーカイブしないでください。 1: アーカイブ。

SQL スクリプトと PowerShell スクリプトの比較

機能	SQL スクリプト	PowerShell スクリプト
クリーンアップ XML	どちらも、「クリーンアップのスケジュールを設定する」セクションで説明しているロジックを使用します。
実行ログ	どちらも、実行のログを格納する dbo.__CleanupLogs テーブルを作成します。 SELECT * FROM dbo.__CleanupLog WHERE ExecutionId = '<execution_id>' ORDER BY Id を使用して、実行のログを照会できます。 実行時にエラーが発生していたかどうかを確認するには、SELECT * FROM dbo.__CleanupLog WHERE ExecutionId = '<execution_id>' AND IsError = 1 を使用します。 ExecutionId パラメーターは、これらのスクリプトのいずれかを実行するたびに生成されます。
アーカイブ テーブル	アーカイブ テーブルには、インデックス、外部キー、または ID 列は含まれません。 TimeStamp 型の列はアーカイブされません。
アーカイブ テーブル名	名前は同じロジックに従い、テーブル スキーマに基づく文字列を含みます。
アーカイブ/削除する ID のバッチ	一時テーブルに格納されます。	dbo.__CleanupIds テーブルに格納されます。
トランザクション	バッチごとに 1 つのトランザクションが実行され、その間にデータがアーカイブおよび削除されます。 バッチ サイズ、つまり処理するテーブルの行数は、XML ファイルで batchSize パラメーターを使用して定義されます。	SqlBulkCopy を使用してデータをコピーします。 アーカイブと削除を目的として実行される単一のトランザクションはありません。

Elasticsearch

Orchestrator は、毎月各テナントについて 1 つのインデックスを保存します。Elasticsearch で古いインデックスを保存すると、検索やレポートで使用されていなくても、パフォーマンスに影響 (メモリ破損) を与える 場合があります。このため、古いインデックスは削除することを推奨します。