DCTM Admin ‘Best Practices’

Posted by Sumeet on Oct 1, 2007 in Documentum |

1. API collections are used to loop through a set of object instances. While the collections are open, database cursors are open and thus locks are held in the database. Therefore, do not keep the collections open longer than necessary so that the cursors and locks will be released. Do not perform any extraneous operations within a collection that could be performed after or before the collection is opened. Consider retrieving and storing attributes being returned in a collection in local variables or an array first, and then processing them later in order to close the collection earlier. For example, an application may retrieve attributes within a collection and perform a “getfile” API (which could have a sizeable impact on elapsed time due to the transfer of the content) within the collection. It is best to store the attributes necessary to do the “getfile” in a local array, close the collection and then perform the “getfiles” afterwards, releasing the locks on the database.

2. With “begintran” statements do not make any extraneous API calls or other programming logic within the transaction loop if at all possible. Assuming that API collections, and hence database cursors are opened with the transaction, then locks are held in the database.

3. The combination of “begintran,” “commit” and “abort” API calls are used to open a explicit database transaction in order to commit or abort a set of transactions as one. If no saves or changes are done within the confines of a transaction, then there is no reason to use these APIs. Keep the duration of the transaction short, as all locks acquired during the transaction will be held until the transaction has either explicitly committed or aborted the transaction. The “assemble” method also establishes an explicit transaction. This transaction is open the locks held until the collection created by the “assemble” method is closed.

4. Documentum provides a system administration tool, “Queue Management,” to delete “dequeued” Inbox items. By default, when an item is removed from an Inbox, the item is marked as “dequeued” but it is not physically removed from the underlying “dmi_queue_item” object in the Docbase. If these items are not removed the “dmi_queue_item” object and the underlying database tables continue to grow and may cause performance degradations. For applications with heavy use of routers, notifications, and events, it is advisable to execute this tool on an automated, scheduled basis. The tool will remove “dequeued” items from the “dmi_queue_item” object to prevent the tables from growing with a number of parameters to configure how and what gets deleted. If a large number of deletes are performed, then running Sybase statistics on the underlying “dmi_queue_item” tables is recommended.

5. Repeating attributes have their own set of APIs to handle the specific definition and characteristics of repeating attributes. Using the APIs; “append, count, locate, insert, remove, repeating, truncate and values” will simplify the code and possibly improve performance.

6. There are some APIs and attributes to aid the programmer when working with routers. The “anyevents” method checks the current user’s Inbox to see if any new items have been placed in the Inbox and the “getevents” method returns a collection of all items contained within the Inbox of the current user. It may prevent having to formulate otherwise complex queries. These methods and more information about managing an Inbox are described in more detail in Chapter 9 of the Documentum’s “Server User’s Guide.”

7. With a router, the “package_id” attribute contains the object ID of the document that is being routed. While the document is being routed, it may be versioned. When the user forwards the router to the next user, the next user receives the old version of the document unless the “package_id” has been updated explicitly by the application or unless the “package_label” attribute has been defined. If the “package_label” is defined, when the user checks out the document, the server will search the version tree of the document for a version matching the version label specified in the “package_label,” such as “CURRENT.” Using this feature will ensure that users always get the most current version of a document being routed. This is described in Chapter 8 of the Documentum Server User’s Guide. Once again, it is encouraged to explore this feature to maintain simplicity, manage the routers via the attributes and possibly improve performance. Depending on how your application is used, it may eliminate the need for queries to determine if a particular object is the most current version.

8. While on the subject of determining the most current version. Rather than have one complex query, it may be more beneficial to simply retrieve the most current object ID first with the API call, “id,c,dm_document where I_chronicle_id_I = ID(”).” This will return the current version for the object id passed in the where clause. If the object ID is different, perform a “fetch” command, such as “fetch,c,(”)” to return the attributes. If they are the same, the ID is the most current version and the application may already have the attributes it needs to continue processing. These are two simple queries with a predictable response in terms of performance and network trips.

9. The “dm_sysobject” attribute, “i_latest_flag” indicates whether a version is the most recent version of the object on a particular branch in a version tree. While this can be used to determine if an object is the most recent version, it comes with one caveat. If the application uses branching version trees, as opposed to linear which is the default, then the “i_latest_flag” will not necessarily represent the most current version as denoted by the version label of “CURRENT.” If branching is not used, then this attribute can be used in confidence.

10. The use of the “id_i” integer attribute, which is indexed, in “where” clauses should be used in all instances of the application. This will have a significant effect on database performance.

11. For DQL “selects,” where the objects are not being updated, use the “readquery” API or the “execquery” API with the “read_only” flag set to “true.” For DML statements, where the objects are being updated, use the “query” or “execquery” API with the “read_only” flag set to the value of “false.”

12. Do not use the “order by” clause in “select” statements unless it is necessary to have the returned collection sorted.

13. For custom sub types, strongly consider indexing some of the custom attributes based on how the objects are queried in the “where” clause. This is not as important during the pilot phase when not many instances are created. But, as the Docbase grows in size, creating an index on the appropriate attribute will spawn significant performance gains.

14. Utilize the “ALL” key word in “select” statements wisely. For DQL “selects,” the “ALL” key word directs the server to search all versions of each object. For example, if the current version of a document is desired in a query, the statement, “select r_object_id from dm_document(all) where any r_version_label = ‘CURRENT’” can be more efficiently written as “select r_ r_object_id from dm_document,” which will return only the current version.

15. Sybase uses a statistical-based optimizer, which incorporates statistics of the record distribution in the database. These statistics are not dynamically updated. Keep the Sybase statistics updated. Assuming that the database will be very dynamic in the beginning (as far as record distribution is concerned) and the time to run statistics will therefore not be long, run them frequently. This will improve the Sybase optimizer.

16. Take advantage of the “run_as_server” argument when running external, custom procedures using the “DO_METHOD”. This directs the server to run the method under its own account (the installation account which is typically “dmadmin”). This eliminates the need for password validation logic in the code.

1 Comment

Ken Domen
Jan 25, 2010 at 9:42 pm

Great stuff!


 

Reply

 


Copyright © 2017 dm_maniacs All rights reserved. Theme by Laptop Geek.

wordpress stats