事象
Build Agent でカスタムテーブルを作成し、その際に自動採番される Number フィールドを作らせました。
一通り検証を終えた後で採番をリセットしたいと思い、[System Definition] > [Number Maintenance] を開いてみたのですが、関連リンクの「Show Counter」が見当たりません。
「Show Counter」 のリンク先にあたる Number Counter [sys_number_counter] テーブルも確認しましたが、該当するレコードが存在しませんでした。
にもかかわらず Number フィールドは問題なくカウントアップされているため、採番カウンタの管理方法が変更されているのではないかと考えました。
調査
[System Definition] > [UI Actions] で検索したところ関連リンク「Show Counter」のレコードは存在していたので、Condition の値を確認します。
current.canRead() && new NumberManager(current.category).usingCounterTable()
Number [sys_number] テーブルの該当レコードが参照できることの他に、「NumberManager スクリプトインクルードの usingCounterTable() の戻り値が true であること」が表示条件となっています。
NumberManager の定義を確認すると、システムプロパティ glide.db.atomic_counter_all と glide.db.atomic_counter_included が「Show Counter」の表示条件に使われていることが分かりました。
原因
大量のレコードを同時に作成する際の性能問題により、採番の仕組みに変更があったようです。
BugZeroの説明1によると、複数ノードから同じテーブルへ大量のレコードを作成する際に採番競合が発生し、この事象は MariaDB よりも RaptorDB で多く観測されたとの情報がありました。
ServiceNow の Zurich リリースにおける Known Error 一覧2にも、
[ATT] OM Performance: sys_number_counter impacting overall performance of order creation and fulfillment during 50K customer orders 1hr load testing on RaptorDB Pro
と、Number Counter が大量レコード作成時のパフォーマンスに影響を及ぼす旨の記載があります。
Number Counter のロック→読み取り→加算→保存という処理が直列処理となっていて、それがボトルネックとなるのではないかという趣旨の情報3も見つかりました。
この性能問題への対応として、複数の処理が同時にアクセスしても競合せずに値を増やせる Atomic Counter を使用する方式へ切り替える設定が案内されています。
| リリース | 対応 | 説明 |
|---|---|---|
| Zurich |
glide.db.atomic_counter_included でテーブルの物理名を指定する |
指定されたテーブルの採番方式を Atomic Counter に変更する |
| Australia |
glide.db.atomic_counter_all を true にする（Australia以降のzboot環境では有効化済み） |
採番カウンタを利用するすべてのテーブルにおいて、採番方式を Atomic Counter に変更する |
今回私が使用したのは新規に払い出した PDI 環境（Brazil リリース）でしたが、glide.db.atomic_counter_all の初期値は true となっており、デフォルトで Atomic Counter を使用する状態になっていました。
検証
Number Counter が無くても採番が進む理由については分かったので、当初の疑問に立ち返り、採番のリセット方法について検証してみました。
Atomic Counter のリセットを試す
まず公式ドキュメントを参照しましたが、Atomic Counter のリセットに関する記述は見つかりませんでした。
そのため思いつく範囲で以下の方法を試してみましたが、今回試した操作では Atomic Counter の採番をリセットすることはできませんでした。
-
glide.db.atomic_counter_allの値をtrue→false→trueと変更してみる→✗ - ServiceNow Studio で
Starting numberの値を書き換えてみる→✗ - Number レコードの
Number of digitsを書き換えてみる→✗
以下は推測ですが、Atomic Counter は DB 内部の SEQUENCE で採番管理しているのではないかと考えています。
仮にそうだった場合、ServiceNow 側にリセット用の操作が提供されていないのであれば、今までのように画面から値を書き換えることは難しそうです。
従来の採番方式に変更する
どうしてもカウンタをリセットしたい場合は glide.db.atomic_counter_all を false にして Number Counter を使用した採番方式に戻せば、カウンタの値を書き換えることが可能です。
ちなみに実機での検証では、Atomic Counter 方式と Number Counter 方式は別々に値を管理しているようで、Atomic Counter を有効にすると Number Counter の値は更新されず、無効化・再有効化するとそれぞれが保持している値の続きから採番されました。
基本的には従来の採番方式とし、一部のテーブルのみ Atomic Counter を使いたいという場合は、glide.db.atomic_counter_all が false の状態で glide.db.atomic_counter_included を新規作成し、対象のテーブルの物理名をカンマ区切りで指定することにより対応可能です。
ちなみに task テーブルを指定しても、incident などの子テーブルには Atomic Counter は適用されませんでした。
まとめ
自動採番の仕組みが Atomic Counter に変更されており、その背景には大量レコードを同時に作成する際の性能問題があったということが分かりました。
Atomic Counter のリセット方法については今回確認できませんでしたが、今回はテストで進んだ番号を戻したかっただけなので、そのためだけに従来の採番方式に戻すよりは、Atomic Counter 方式を維持する（カウンタのリセットについては割り切る）方が個人的にはよさそうだと思いました。
