クローンに関する FAQ - よくある質問

この記事では、ソースインスタンスからターゲットインスタンスへのクローンに関して、ServiceNow テクニカルサポートから受けるクローニングに関する最もよく寄せられる質問を一覧表示します。バックアップ、クローン作成後、除外、プリザーバー、クリーンアップスクリプトの詳細をご確認ください。

この記事は、クローンに関する3部構成のシリーズの一部です。

• • クローンの基本情報
  • クローンのヒントとテクニック

3 つのよくある質問

特定の日付からクローンを作成できますか?

クローン実行前にバックアップを取ることを要求できますか？

バックアップ関連の質問

クローンを作成するとき、どのバックアップファイルが使用されますか? 

• クローンでは、クローンターゲットインスタンスのデータセンターに関連する最新のバックアップファイルが常に使用されます。 
• たとえば、本番インスタンスの LHR データセンターに 2 つのノードと AMS データセンターに 2 つのノードがある場合、これら 2 つのデータセンターの日次バックアップファイルが作成されます。AMS データセンターに開発インスタンスがあり、LHR にテストインスタンスがある場合、開発のクローンは最新の AMS バックアップを使用し、テストのクローンは最新の LHR バックアップを使用します。 

オンデマンドバックアップからのクローン作成について聞いたことがありますが、どのように機能しますか?

オンデマンド バックアップを作成するには、次の 2 つの方法があります。

オプション1:クローン管理コンソール内のオンデマンドバックアップオプション:

新しい Clone Admin Console (2023 年 11 月リリースのストアアプリ) には、オンデマンドバックアップオプションがあります。新しいアプリを使用してクローンを作成する場合は、オプション設定でオンデマンドバックアップを選択できます。アプリでこのオプションを選択すると、指定したクローン開始時刻に新しいバックアップが開始されます。
この機能を利用するには オンデマンドバックアップリストにも登録する必要はありません ことに注意してください。 

オプション 2:Now Support からケースを作成して、「オンデマンドバックアップリスト」への追加を要求できます。インスタンスがこのリストに登録されると、クローンごとに新しいバックアップが作成されます。
オンデマンドバックアップリストからインスタンスを削除するには、テクニカルサポートのケースを再度作成する必要があります。[オンデマンドバックアップ]の下–前の質問。

本番インスタンスを「オンデマンドバックアップ」リストに追加した場合、バックアップ作成中の本番環境のパフォーマンスに影響しますか?

いいえ、オンデマンドバックアップの生成中にパフォーマンスが低下することはありません。 

ソース・インスタンスのデータベースが断片化されている場合、ターゲット・インスタンスも断片化されますか。

いいえ、クローンは選択したバックアップから新しいデータベースを構築するため、クローンされたインスタンスに断片化はほとんどまたはまったくありません。

クローン後の質問

クローン作成後、コメント/更新がすべて異なるユーザーと時間として表示されるのはなぜですか?

これは設計どおりです。sys_audit テーブルはそれぞれのコメントや更新を行ったユーザーおよび日時を保持するために使用されます。sys_audit テーブルを除外する除外機能を使用してクローンを作成した場合、sys_audit がないため、レコード上のすべてのコメントに sys_created_by フィールドと sys_created_at フィールドが使用されます。

レコードの履歴を表示すると、すべての更新が「update 0」として表示されます。

詳細については、「KB0690828:クローン - アクティビティフォーマッターと監査に正しいユーザーと時刻が表示されない」を参照してください。

クローンのMFAをリセットするにはどうすればよいですか?

このビデオ は、クローンされたインスタンスで MFA をリセットする方法を示しています。

クローン実行後にログインできないのはなぜですか？

この問題は頻繁に発生します。

インスタンスに対してクローンを作成すると、本番環境の設定が取り込まれます。これには、SSO およびログイン機能が含まれ、アップグレード後に準本番インスタンスにログインできなくなる可能性があります。

この記事では、クローンのために限らず、常にログインできるローカルアカウントを持つことのメリットについて説明しています。

クローンでこの問題が発生しないようにするには、次の操作を実行します。

方法 1：ソースインスタンスでローカル管理者ユーザーを作成します。

1. 1. ソースインスタンスでローカルパスワードを使用してローカル管理者ユーザーを作成します
   2. 準本番インスタンスでクローンを作成します。
   3. side_door.do を使用してインスタンスにログインしますが、その際、ステップ 1 のユーザー名とパスワードを使用します。

方法 2：ターゲットインスタンスでローカル管理者ユーザーを作成し、プリザーバーを含めます。

1. 1. ターゲットインスタンスでローカルパスワードを使用してローカル管理者ユーザーを作成します
   2. ユーザー (sys_user)、ユーザーロール (sys_user_has_roles)、およびユーザーグループ (sys_user_grmember) のクローンプリザーバーを作成します。
   3. 準本番インスタンスでクローンを作成します。
   4. side_door.do を使用してインスタンスにログインしますが、その際、ステップ 1 のユーザー名とパスワードを使用します。

デモまたはpovインスタンスにターゲットとしてクローン作成すると、「有効なキャパシティマッピングのクローンプリフライトチェックが失敗しました」というメッセージが表示されてクローンが失敗しました。

このエラーメッセージは、小さすぎてサイズが大きくなるように設定されていないインスタンスをクローンしようとしたときに表示されます。

デモおよびPOVインスタンスは特定のサイズまでのみ拡張するように構築されているため、ソース・インスタンスも小さい場合はクローニングできますが、特定のサイズに成長すると、デモまたはPOVインスタンスをクローニングに使用できなくなります。その後、準本番インスタンス (サイズが大きくなる可能性がある) をクローンする必要があります

また、デモまたはPOVインスタンスのサイズを増やすことはできません。常に準本番インスタンスのクローンを要求します。

クローンの後にテキスト検索が実行されないのはなぜですか?

インスタンスでクローンを作成すると、テキスト検索が機能しないという問題が発生する可能性があります。

これは、クローン作成後に実行されるクローンクリーンアップスクリプトの 1 つが、このインスタンスを検索用に再インデックス化していて、このスクリプトの実行中は検索が機能しないことが原因です。

実行中のジョブを見ると、 text index events process が表示され、stats.do を見ると、次のように表示されます。

このジョブが完了するのを見守ります。完了したら、検索機能を使用できます。 

特定のテーブルを除外しましたが、クローン作成後もデータがまだ残っていますか?

これはサポートに寄せられることが非常に多い質問です。エクスクルーダーに入力しても、クローン作成後にデータが残っているという問題です。

これにはさまざまな原因が考えられます。

1. 1. クローンで除外するテーブルのチェックボックスをオフにした。
   2. 除外対象からブラックリストに登録されているテーブルを選択しました。 

タスクテーブルの子テーブルを除外すると、子テーブルが除外されます。親タスクテーブルを子テーブルと一緒に除外する必要はありません。これは TPH または TPC 拡張モデルに対して機能します。

エクスクルーダーとプリザーバー

エクスクルーダーはどのように機能しますか？ 

• すべての除外設定をソースインスタンスで設定する必要があります。
• テーブルごとに作成され、条件ベースのエクスクルーダーは使用できません。
• ソースデータに対してのみアクションが実行されます。
• テーブルを除外すると、テーブルが切り捨てられるため、ソースインスタンスのデータは保持されません。
• テーブルフラット化を使用するタスクテーブルの子テーブルを除外すると、 階層拡張モデル別テーブル、子テーブルは除外されます。親タスクテーブルを子テーブルと一緒に除外する必要はありません。
• デフォルトでは、除外オプションがクローン作成用に選択されています
• クローンを作成する前に除外オプションを削除すると、どのデータも除外されません。
• 同じテーブルを除外および保持することができます。

プリザーバーはどのように機能しますか？ 

• すべてのプリザーバー設定をソースインスタンスで設定する必要があります。
• 保持できるのはデータのみで、テーブルや列は保持できません。
• テーブルごとに作成され、条件を使用して特定のデータのみを保持できます。
• ターゲットデータに対してのみアクションが実行されます。
• データは、除外が実行された後にインポートされます。
• これらは常にすべてのクローンで実行されます。
• 同じテーブルを除外および保持することができます。
• ターゲットインスタンスからテーブルを保持できるのは、そのテーブルがソースインスタンスにも存在する場合のみです。 (テーブル構造は保持できず、データのみが保持されるため)
• また、プリザーバーは重要なデータを保持するためのものであり、大量のデータを保持するものではありません。大量のデータを保持すると、クローンが壊れたり、実行に非常に長い時間がかかったりすることがあります。大量のデータを保持しないことをお勧めします。

詳細についてはKB0717012 - 除外およびプリザーバーの構成に基づくクローン結果を参照してください。

除外リストとプリザーバーリストの両方にテーブルを追加するとどうなるか?

その結果、テーブルは、クローン作成後も、ターゲットインスタンスでのクローン作成前とまったく同じになります。クローンの前にテーブルに 5 つのレコードがあった場合、その後も同じ 5 つのレコードが存在することになります。

ターゲットインスタンスのプラグインを保持できますか？

場合によっては、ターゲットインスタンスでプラグインをテストした際に、それらのプラグインを保持して、引き続きテストして作業できるようにしたいと思われるかもしれません。 

当社では新しいデータベースに対してソースインスタンスを復元する方法でクローンを作成します。そのため、残念ながら、クローン作成後にプラグインを再度有効にするか、必要に応じて HI 経由でプラグインを要求する必要があります。

レコードを保持する場合、添付ファイルも保持する必要がありますか？

クローン作成時に、ターゲットインスタンスの特定のレコード (一部のインシデントなど) を保持することができます。また、クローン作成後に、これらのインシデントにリンクされている添付ファイルも確実に保持されるようにする必要があります。

現在、当社の自動化では、添付ファイルのあるレコードを保持した場合、添付ファイルテーブル専用の別のプリザーバーを作成しなくても、その添付ファイルが自動的に保持されます。 

プリザーバーとエクスクルーダーを変更した場合、次回のクローン作成で変更がすぐに機能しますか？

エクスクルーダーまたはプリザーバーを調整したばかりで、クローンを実行する前にしばらく待機する必要があるかどうかを知りたいと、よく質問されます。この場合、待機する必要はありません。エクスクルーダーとプリザーバーを変更すると、それらの変更は次回のクローンの要求で適用されます。

除外オプションのチェックを外しましたが、クローン作成後も除外オプションが実行されました。

最近、この問題が増加しています。クローンを要求し、クローンの作成後に除外オプションのチェックを外した後も、エクスクルーダーが実行されているようです。

これは要求フォームの UI 変更に関係しています。一部のお客様がフォームをカスタマイズし、そのため変更を取得できませんでした。

UI に変更が加えられた結果、オプションタブで除外するオプションが非表示になり、開いて表示するにはクリックしなければならなくなりました。この変更以降、一部のお客様がフォームをカスタマイズしたか、非表示セクションのオプションを表示する代わりにこれらの値を表示するようにフォームを既にカスタマイズしたために、フィールドが 2 回表示されている可能性があります。

ここでの問題は、値は常に最後に検出された値から取得されるので、メインフォームのオプションをオフにすると、そのフィールドで検出された最後の値であるため、そのオプションの値が取得されることです。

これを修正するには、フォームを更新して、フィールドがすべてのセクションで 1 回だけフォームに表示されるようにする必要があります。一旦修正すれば、再発することはありません。

既存のテーブルをプリザーバーに追加できません。

特定のテーブルのデータプリザーバーを追加しようとしているときに、リストにそのテーブルが見つからず、不思議に思うことがあります。これはおそらくテーブルのスコープが原因です。

特定のスコープの一部であるテーブルを保持する場合は、次の操作を行う必要があります。

1. 1. 右上の歯車アイコンをクリックしてテーブルのスコープに切り替え、[開発者] に移動し、テーブルのスコープを選択します。
   2. 次に、データプリザーバーテーブルに移動します。
   3. データプリザーバーを作成しているので、その特定のテーブルを選択して保存できます。
   4. クローン作成後に添付ファイルが見つからないのはなぜですか？FAQに移動
   5. 最近、クローンが完了した後、ターゲットインスタンスに添付ファイルがなく、問題を引き起こしていることに気付いたかもしれません。 
   6. これは実際には設計どおりに機能しているのですが、この除外は、2018 年 12 月以降にクローン作成の自動化によって内部の問題が修正された後に正しく機能し始めました。これは ServiceNow のリリースの範囲外であるため、それ以降のすべてのリリースとすべてのクローンに影響しています。[大きな添付データを除外 (Exclude large attachment data)] クローンオプションに対して修正が行われました。 
   7. 前の質問で説明したように、クローンのすべてのオプションにはどのような機能がありますか？
   8. 基準を満たさない sys_attachment レコードは削除されると記載されています。名前からすると、基準はサイズに基づくように思われますが、そうではありません。
   9. つまりこれは設計どおりに、またマニュアルに記載されているとおりに機能しています。添付ファイルを保持したい場合は、クローン作成時に [大きな添付データを除外 (Exclude large attachment data)] チェックボックスをオフにする必要があります。   

クリーンアップスクリプト

クローンクリーンアップスクリプトはどのように機能しますか？ 

• クローンが完了すると、すべてのクリーンアップ スクリプトが「クローン クリーンアップ スクリプトの実行:クリーンアップ スクリプトを順次実行」という名前のスケジュール設定済みジョブとして結合され、グローバル スコープで完了するまで実行されます。
• クリーンアップスクリプトは、順序フィールドに基づいて順序付けされます。
• ソースインスタンスで定義する必要があります。

特定のスコープでクリーンアップスクリプトを実行できますか? 

すべてのクリーンアップ スクリプトは、クリーンアップ スクリプトを構成したスコープに関係なく、グローバル スコープで実行されます。したがって、スコープ付きスクリプトを実行する場合は、次の方法を使用するのが最善の方法です。

1.クリーンアップロジックを含むスクリプトインクルードを目的のスコープに作成します。

2.次の設定でスコープ対象のスクリプトにアクセスできるように、制限付きの発信者アクセス設定を用意します (RCA を作成するには、スクリプトインクルードのスコープ内にいる必要があります)。

ソーススコープ：グローバル
ソースタイプ：スコープ
ステータス：許可
ターゲットスコープ:<スクリプトインクルードのスコープ>
ターゲットタイプ：スクリプトインクルード
ターゲット: <script>
操作: API

3. クローンクリーンアップスクリプトからスクリプトインクルードを呼び出します。

クリーンアップスクリプトをテストするには、バックグラウンドスクリプトのグローバルスコープから実行し、期待どおりに機能していることを確認します。

どのクリーンアップスクリプトが実行されたかを確認するにはどうすればよいですか?

次の URL を使用して、トリガーされたクリーンアップスクリプトのリストを取得します。クローン作成が今日行われていない場合は、作成日フィルターの変更が必要になることがあります。

<INSTANCE_URL>/syslog_list.do?sysparm_query=sys_created_onONToday%40javascript%3Ags.beginningOfToday()%40javascript%3Ags.endOfToday()%5EmessageSTARTSWITHExecuting%3A%5Esource%3DNew%20Clone%20Engine

インスタンスごとにクリーンアップスクリプトを設定できますか？ 

• 特定のインスタンス専用のクリーンアップスクリプトはありません。
• ただし、インスタンス名のシステムプロパティを確認し、その結果に応じて特定のジョブを実行するようにクリーンアップスクリプトで定義することはできます。
• 例：

var instanceName = gs.getProperty('instance_name');
if (instanceName == 'testdev')
{
// Do specific jobs for dev instance
}
else if (instanceName == 'testsandbox')
{
// Do specific jobs for sandbox instance
}

更新セットとクローン作成

アップグレードと更新セットの展開後にクローンを作成した後、更新セットが見つからないのはなぜですか?

アップグレードが完了すると、新しいバックアップが作成されます。状況は次のようになります。システムはアップグレード直後に新しいバックアップを作成し、アップグレード直後に更新セットもプッシュします。すぐにクローン作成することを選択しますが、適用したばかりの更新セットはアップグレード後のバックアップで失われます。クローン作成すると、バックアップ内の項目のみが取得されます

アップグレードとアプリへの更新のプッシュ後は、毎日のバックアップが実行され、適用したすべての更新がキャプチャされる時間を確保するために、少なくとも 24 時間待つことをお勧めします。

大量の進行中の更新セットを処理するためのヒント

1. 進行中の作業 (WIP) の更新セットがあるターゲット インスタンスで、フィルター処理してすべての WIP 更新セットを含むリスト ビューを取得します。
2. 別のウィンドウ/タブで、新しい更新セットを作成します。
3. ステップ 1 のすべての未完了の更新セットをバッチ処理します。 (つまり、WIP 更新セットのリストの親フィールドを新しいバッチ更新セットに設定します)
   1. 一括更新の方法: Shift キーを押しながらマウスの左クリックを押したまま、マウスで列全体を選択することで、リストを一括更新できます。次に、選択した列のいずれかのフィールドをダブルクリックし、必要な値を入力して、すべてをその値に更新します。
4. 親更新セットを「完了」に設定し、「CLNREQ_DATE」という名前を付けます (識別しやすくするための命名提案)
5. 親更新セットをエクスポートします。
6. ソース インスタンスに戻り、更新セットを取得します (重要: コミットしないでください)
   親更新セットが、ソース インスタンスで取得した更新セットに追加されました。
7. 更新セットが毎日のバックアップでキャプチャされるまで 24 時間待つようにしてください (または、クローン管理コンソールでオンデマンド バックアップを選択することもできます)。
8. ソース インスタンス > ターゲット インスタンスから通常どおりクローンを実行します。
9. 親更新セットがバックアップで取得されているため、ターゲット インスタンスには親更新セットと、クローン後に実行中の開発作業が含まれます。
10. ターゲット インスタンスに戻って、親更新セットを進行中の作業に設定し直し、親を解除できます。
11. ソース インスタンス: 取得した親更新セットをクリーンアップ (削除) できるようになりました。

その他のFAQ

ドラフトとは何ですか? なぜこれらを削除できないのですか?

UI をクリックしてクローンを送信すると、クローンテーブルにレコードが作成されます。クローンを続行しないか、ポップアップウィンドウの外をクリックすると、レコードは「ドラフト」としてシステムに残りますが、これは無視しても問題ありません。これらを削除できない理由は、クローン要求を管理する ServiceNow の内部インスタンスへのリンクがあるためです。

クローンが「保留中」なのはなぜですか?

クローンのステータスが [保留] に設定されている場合、サーバーがクローン要求を却下したことを意味します。最も一般的な理由は次のとおりです。

• スケジュールされた時間までにクローンを続行する準備ができなかった。
• ターゲットインスタンスはダウングレードされません。
• クローンに使用されたバックアップに問題がある。

詳細については、「KB0694499 - 「保留」状態の複数のクローン」を参照してください。

別のインスタンスにクローンした場合、リリースは変更されますか?

はい。クローンを作成すると、ソースインスタンスのレプリカが作成されるため、テーブル構造とバージョンは一致することになります。

したがって、Tokyo で San Diego インスタンスをクローンする場合、ターゲットインスタンスは San Diego リリースになります。

逆に、San Diego で Tokyo インスタンスをクローンすると、ターゲットインスタンスは Tokyo リリースになります。

スタンバイ・データベースとソース・インスタンスの違いは何ですか。 

クローンを作成すると、スタンバイデータベースとソースインスタンスのいずれかを選択するオプションが表示されます。

これは古いオプションであり、クローンの作成を要求するときには不要になりました。新しいリリースでは削除され、表示されないはずですが、表示されている場合は、このオプションをそのままにして無視してかまいません。 

[クローン元:] フィールドとは何ですか。これにより、クローンがライブデータベースとバックアップのどちらを使用するかが決まりますか?  

クローンをスケジュールするときに、このフィールドを使用して、バックアップファイルとライブデータベースのどちらからクローンを作成するかを決定できるというのは、よくある誤解です。このフィールドは、実際には以前のアプリ内クローン エンジンに関連する従来のフィールドであり、バックアップ機能からの新しいクローンでは目的がありません。

認証ステップでクローンを要求したり、クローンターゲットを作成したりすると、「無効なユーザー名またはパスワード」というプロンプトが表示されますか?

この問題は、以下の 2 つの原因のいずれかが原因で発生します。

(I) ターゲットインスタンスで複数勢力認証が有効になっているか確認してください。これを確認するには、

1. [sys_properties] テーブルに移動し、プロパティ [glide.authenticate.multifactor] を検索します。
2. このプロパティの値が true の場合、インスタンスでマルチファクター認証が有効になっています。

(II) ターゲットインスタンスの BasicAuth スクリプトインクルードがカスタマイズされているか確認します。 

どちらの場合も、クローンターゲットを作成しようとすると、次のようなログが見つかります。

Script: InstanceRetrieverAjax: Sending request to /HAGetParams.do?SOAP
WARNING *** WARNING *** OUTBOUND USAGE ANALYTICS - OutboundUsageAnalytics : OutboundUsageAnalytics: Usage analytics send failed
Operation against file 'instance' was aborted by Business Rule 'Target Instance Validate^c16a7406db00c890cd7efafc0f9619dd'. Business Rule Stack:Target Instance Validate
Slow business rule 'Target Instance Validate' on instance: time was: 0:00:00.506
Error in user input caused action to be cancelled

クローンターゲットの作成を認証する場合、またはクローンをスケジュール設定する場合は、ローカル管理者ユーザーを使用することをお勧めします。

使用されているローカル管理者ユーザー ID で「Web サービスへのアクセスのみ」がチェックされていない場合、認証に失敗し、「無効なユーザー名またはパスワード」というエラーメッセージが表示されます。これは、ビジネスルール「ターゲットインスタンスの検証」が、スクリプトインクルード「InstanceRetrieverAjax」から送信された SOAP 呼び出しを介してターゲットインスタンスを検証できないためです。

その他の情報：

クローンターゲットの作成中に「無効な挿入」や「無効なユーザー名とパスワード」などのエラーメッセージが表示される

ターゲットインスタンスへのクローン認証が「無効なユーザー名またはパスワード」で失敗する

データを除外している場合でも、メールアカウントがターゲットにクローンされたのはなぜですか？

クローンを作成してメールをオンにすると、本番メールアカウントが準本番インスタンスにコピーされていることがあります。それで、テーブルを除外するオプションがオンになっていることを確認しても、問題が解消されないように思えました。

この問題が発生するのは、通常は以下のことが原因です。あるとき準本番環境でテーブルを除外せずにクローンを作成したため、sys_email_account がターゲットインスタンスにコピーされました。その場合 sys_email_account のプリザーバーが存在するため、その後のすべてのクローンでメールアカウントが保持されます。

回避策：クローンクリーンアップスクリプト

1. 本番インスタンスにログインします。
2. 準本番環境で不要なメールアカウントのすべての sys_id を確認します。
3. これらの sys_id を持つすべてのメールアカウントを削除するクローンクリーンアップスクリプトを本番環境で作成します。

スクリプトの例：

// Add sys_ids to the encoded query (queryString)

// Like queryString = "sys_idIN206594e8db9eb3002e14c6fc34961998,6ab25213db003300eaf8e64305961927"

var queryString = "sys_idIN";

var emailclean = new GlideRecord('sys_email_account');

emailclean.addEncodedQuery(queryString);

emailclean.deleteMultiple();

これは、すべてのクローン作成後に、これらの sys_email_accounts がクローンされたかどうかに関係なく削除されることを意味します。新しいメールアカウントを追加する場合は、このスクリプトに追加する必要がありますが、これによりソースインスタンスからのメールアカウントが取得されなくなります。