Undeleting Objects

It is possible to “undelete” objects from the Documentum repository under certain conditions, but it requires some detective work.  If the object you are trying to undelete is one which you know some details, the process shouldn’t be that bad.  If you are trying to undelete a set of objects (e.g., the contents of an entire folder) you might want to consider a system restore instead.

Under most conditions, when an object is deleted from Documentum, only the metadata is deleted from the database.  The content file will remain in the storage area until the dmClean job runs and actually deletes the file from the file system.  As long as the dmClean job has not run, it is possible to undelete objects in the repository.  Following is a simple procedure to locate and undelete an object you have accidentally deleted.

  1. Gather as much information as you can about the deleted object.  A file format or object name would be very helpful.
  2. Query the dmr_content objects using the information you gathered in step #1.  For example:

    select * from  dmr_content where any parent_id is null and and full_format = 'msw8'  and  set_file like '2010%Report'.

    dmr_content objects with no parent IDs represent deleted content.  This query assumes the set_file name is the same as the object_name, which is often the case.  You may need to adjust this query to expand or limit your result set as appropriate.  You can view the available attributes for the dmr_content object in the EMC Documentum System Object Reference Manual to fine tune this query.

  3. For each candidate dmr_content object in your result set, get the path to the content it represents using the API editor like this:
    • API> apply,c,0600...0100,GET_PATH
    • q0
    • API> next,c,q0
    • true
    • API> get,c,q0,result
    • C:\Documentum\data\repo1\content_storage_010000001\80002.doc

    For each path the API returns, open the file to determine if it is the one you are looking for.

  4. Once you have found your deleted content in step #3, create a new object in the repository to hold it.  Use the setfile API to connect the newly created object to the content already in the filestore.  Remember, the object must be linked to a folder before it can be saved.  In this example, I link it to the /Temp cabinet.
  • API> create,c,dm_document
  • 0900...0000
  • API> set,c,l,object_name,Restored Document
  • OK
  • API> setfile,c,l,C:\Documentum\data\repo1\content_storage_010000001\80002.doc,msw8
  • OK
  • API> link,c,l,/Temp
  • OK
  • API> save,c,l
  • OK

You have now recovered your deleted content.  It’s not perfect — all of the original metadata and versions have been lost, but it is back in the repository. With some clever manipulation I’m sure you can reintegrate it into your application in a suitable manner.

I mentioned above that under most conditions when a object is deleted from a Documentum repository, the metadata is destroyed.  The exception to this occurs if the root of the version tree is deleted while versions remain.  For example, if you delete version 1.0 of an object, but versions 1.1, 1.2 and 2.0 still remain in the repository, the version 1.0 object is flagged for deletion and the connection to the content is severed, but the metadata remains.  To undelete objects in this state, try these steps:

  1. Find the deleted object with a query like this:

    select * from dm_sysobject (DELETED) where  i_is_deleted = true order by r_object_id asc

  2. Once the correct object is found, set the i_is_deleted flag to false and set the root folder ID to a known folder. You can do this in DQL like this:

    update dm_document (deleted) object set i_is_deleted = false, set i_folder_id[0] = '0c00...0107' where r_object_id = '0900...2108'

  3. Use the same setfile and save API commands as above to reattach the content to the object and save it.
  • API> setfile,c,0900...2108,C:\Documentum\data\repo1\content_storage_010000001\80002.doc,msw8
  • OK
  • API> save,c,0900...2108
  • OK

Now you have recovered the version tree root object with all of its original metadata.  You can now link it to the proper folder if necessary.

The most important thing to remember when undeleting objects is that it has to be done before the dmClean job runs.  Otherwise, all the orphaned dmr_content objects are deleted along with the content they point to and the content will truly be gone.

Advertisements

About Scott
I have been implementing Documentum solutions since 1997. In 2005, I published a book about developing Documentum solutions for the Documentum Desktop Client (ISBN 0595339689). In 2010, I began this blog as a record of interesting and (hopefully) helpful bits of information related to Documentum, and as a creative outlet.

5 Responses to Undeleting Objects

  1. doquent says:

    Good and useful tip, thanks for sharing.

    I would have named the post something like “Undeleting content and root objects” since objects (metadata), in general (root object is an exception), cannot be restored (as you also mention above) without using a backup of the DB. As objects can be contentless, I tend to make the distinction between object and the associated content.

    Like

  2. prabhu says:

    Very helpful …. thanks

    Like

  3. Pingback: Documentum Housekeeping Jobs « dm_misc: Miscellaneous Documentum Tidbits and Information

  4. Subodh says:

    Hi, Very helpful post.

    Need clarification on below 2 things:
    1) How can I find out if versions other than the ROOT are still existing in the docbase? What is the DQL for this?
    2) If the object (dm_document) is deleted and having some references to VD, is it possible to get the r_object_id of document for below scenarios?
    i) dmClean job is run
    ii) dmClean job is not run

    Thanks!
    Subodh

    Like

    • Scott says:

      If the dmClean job runs, nothing is recoverable because the database will have effectively committed the deletes. You cannot recover metadata info from any other version of a document except the root, and only if later versions in the version tree still exist. That is because in this case, the database only does a “soft delete” that is reversible. For any other version of an object deleted, all metadata is lost, including version and virtual document information.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: