dm_notes: Documentum Notes

August 14, 2008

How many objects your docbase can accomodate?

Filed under: documentum — Tags: , — Raj V @ 5:33 pm

In Documentum every object has a unique identifier (r_object_id) in the repository for accessing it and this unique identifier is composed of a 16 digit hexadecimal(4-bits) value (8 bytes). The structure of the object id is composed of 2-digit hexadecimal id (object type – not the same as r_object_type attribute of an object), a 6 digit hexadecimal docbase id and a 8 digit unique identifier for the corresponding object.

  • Each Object Type is defined by a 2 digit hexadecimal identifier by Documentum Server internally
    • Like ’09’ for dm_document type
    • ‘0b’ for dm_folder type etc.
  • Each Object has the next 6 digits as the docbase id to which it belongs to. The docbase id is theoretically unique globally.
  • The rest of the 8 digit hexadecimal identifier defines a unique identifier to the object in the repository.

So for a given object type (including the its sub types) in a repository we can accommodate a maximum of ‘ffffffff’ (hexadecimal) no. of objects. This translates to ‘4,294,967,295’ no. of objects (in decimal). This comes to roughly 4 billion objects. This is good enough for a single repository at any point.

How ever over the course of time (may be in decades) this no. could reach its limit with the increasing no. of documents being placed over and over again (including multiple versions).

Think of a case of the ACLs being defined (dm_acl type; type id : 45) in the repository, The ACL type also can outgrow to a max limit of 4,294,967,295 in a docbase. However even under any exceptional scenario, I don’t see these no. of ACLs being defined in a single repository. Here many of the identifiers are being unused in the repository.

Taking a note of the hierarchy of the “dm_document” type, there are many internally defined subtypes of “dm_document” that would occupy further more space with in the limit set for dm_document type stored in the repository.

\ dm_document
\ dm_staged
\ dm_plugin
\ dm_java
\ dm_email_message
\ dm_format_preferences
\ dm_menu_system
\ dm_docset
\ dm_docset_run
\ dm_esign_template
\ dm_xml_config
\ dm_xml_style_sheet
\ dm_xml_zone
\ dm_xml_custom_code
\ dm_message_archive
\ dmc_notepage
\ dmc_jar
\ dmc_tcf_activity_template
\ dmc_tcf_activity
This clearly points out that in some cases its possible to hit the limit for a object type(including sub types)  where as in other cases we would never fill even 10th of the space allocated for these types.

The way Documentum has categorized/structured the object ids is designed to its best, but how to overcome these limitations.

One possible way is to increase length of the object id from 8 bytes to 24/32/64 bytes. Again the OS limitations and the Database limits may apply here. Quite possible that it was designed keeping in view of the 16/32-bit OS available at that time.

I recall at some discussion that Documentum is planning to support 32 bytes in future. If this is the case they would probably provide a utility during upgrade where the object ids should be converted to accommodate the 32bytes like converting the object identifiers from 8 bytes to 24 bytes.

Migrating these object ids may create issues in the environments using CIS filers who refer to the older object ids and these ids can’t be changed due to the filers locking the content/metadata.


Blog at