[UCM] What Happened to the Content IDs in UCM 11g?

UCM10gでコンテンツIDの自動採番を有効（IsAutoNumber=true）にしていた場合、新規コンテンツをチェックインすると、コンテンツIDは1ずつインクリメントされていました。UCM11gではこうしたことは起こらないので、コンテンツIDが飛んでいても驚かないでください。

新しいUCM11gインスタンスにコンテンツをチェックインして数日経ってから、コンテンツIDが次のようになっていることがわかりました。

UCM_000001
UCM_000002
UCM_000003
UCM_000004
UCM_000005
UCM_000006
UCM_000201
UCM_000202
UCM_000203
UCM_000204
UCM_000205
UCM_000206
UCM_000207
UCM_001001
UCM_001201
UCM_001202
UCM_001203
UCM_001203
UCM_001204
UCM_001401
UCM_001402
UCM_001601

コンテンツIDが飛んでいますが、その理由がわからず、コンテンツIDと他のIDをUCMで生成する方法に変化があったのだろう、と推察しました。

少なくともOracle Database上で動作している場合には、UCM11gはカウンタ表のかわりにデータベースの順序(Sequence)を使ってIDを生成します。大量のコンテンツを登録しようとしている場合、カウンタ表でグローバルロックを使うと大きな問題を引き起こしたので、これは非常に大きな進歩です。

Oracle Databaseに詳しい人なら、ICDSEQDOCIDという順序 (Sequence) のキャッシュサイズが200であることが原因で、番号が飛ぶのだと教えてくれるでしょう。UCM起動時に毎回200個の値をデータベースから取得してメモリ上に保存しますが、キャッシュした200個の値を使い切る前にUCMもしくはデータベースを停止した場合、使われなかったキャッシュ上の値を捨てることになります。

もし番号が飛ばないようにする必要があるならば、順序の定義でNOCACHEを指定して再定義する必要があります。NOCACHEを指定した場合、性能に影響があります（RAC環境ならより影響が大きくなります）。それゆえ、これはあまりお勧めできません。コンテンツIDは本当に無意味なIDは本当もしくはコンテンツのキー値と見なすべきで、1ずつインクリメントしていないことに目くじらを立てるべきではないと考えます。


原文はこちら。
http://blogs.oracle.com/ecmarch/2011/03/what_happened_to_the_content_i.html