Where is my content stored?

January 24, 2007 at 10:25 am | Posted in Architecture, Troubleshooting | 5 Comments

There have been a number of threads on the Documentum Support Forum recently regarding content and where it is stored. I thought it would be useful to put all the ideas together in one place. I’ll only deal with the standard filestore setup here which covers the majority of systems.

Documentum stores your content files in one or more file storage areas, typically with a structure like:

<root of the storage area>/18/ff/0f/44.xls

Usually it is not necessary to know what this storage path is. Standard DMCL and DFC apis allow you to retrieve and store content for an object without having to know the exact location of the storage. However, especially for troubleshooting purposes, it is useful to be able to see where content has been stored.

To retrieve the storage location given the r_object_id of a dm_sysobject use the getpath API method. For example in IAPI:

API> getpath,c,090000038006a902
...
C:\Documentum\data\dm3\content_storage_01\
0000003\80\2f\8e\22.txt

If you already have the dmr_content object id then you can use the GET_PATH method in dql:

1> execute GET_PATH for '0600000380056500'
2> go
result
C:\Documentum\data\dm3\content_storage_01\
0000003\80\2f\8e\22.txt


Finally if you really want to locate a dmr_content object based on the path to a particular piece of content object (reverse lookup) then you can follow this rather convoluted procedure:

1) Turn the filepath into an 8 digit Hex data ticket (i.e. using the file path after the root of the storage path), so for the example above this would be 802f8e22
2) Start Windows calculator (or any other hex to decimal converter)
3) Subtract 0x80000000 from your hex data ticket.
4) Now subtract the result from 0x80000000
3) Convert to decimal and put a minus sign in front.

This gives you the data_ticket value and you can now find the dmr_content object using the DQL:

select r_object_id from dmr_content where data_ticket = <value>

The reason for this is that Documentum turns the hex number (802f8e22) into a signed 32-bit integer. All numbers over 0x80000000 turn into negative numbers, which is why all data_tickets are appear as negative decimal values.

References
Content Server Administration Guide, Path Specifications for Content in File Stores
Content Server API Reference
Content Server DQL Reference, Administrative Methods
Posting on documentum-users, from content storage area to object id – reverse lookup