Limit on repeating attributes

Hi All,

We are using D 6.5 SP1 running on AIX 6.1 and Oracle 11g.

We have DFC batch imports which imports files from file system into Documentum... some images contain more than 5000 repeating attributes...it is taking really long time when we call save() method, it is taking hours.

I am not sure if some thing going wrong in Database or if there is any restriction on Documentum that object meta data size shouldn't exceed certain size. I have read some where in support forum that object size can not more than 256K(not sure).

Any suggestions and inputs are really appreciated.

Thanks,

Raju

Find more posts tagged with

Documentum

Comments

mfernandezv

Hi,

for each custom type, DCTM creates 2 tables in Oracle

Eg:

Custom type type1 has two tables:

dm_type1_s

dm_type1_r

The _r table stores the repeating attributes values while the _s table stores the single attributes.

That means you're storing 5000 records in _r table for each record in _s table.

Not sure if it's a good practice to store that huge amount of repeating attributes per object.

Anyway i guess you may want to tune your Oracle DB to improve repository performance.

ldallas

The performance is definitely related to the database but before going there you should consider doing a little cleanup first. Make sure all of the unneeded versions of the object(s) in question are cleaned up. Leaving incremental versions of objects with excessively long lists like this will trick out the query plans in the database. You may be able to return to usability without making DB changes. Make sure you clean up across the type not just the ones that are having issues.

appalaraju.balabhadruni@ge.com

Thanks to all for your inputs... we are storing all repeating attributes in csv file and importing it into Documentum. SCS publishes CSV file along with image and in post sync script we loading data from csv file to target database.

DCTM_Guru

"some images contain more than 5000 repeating attributes...it is taking really long time when we call save() method, it is taking hours."

FYI - I do recall reading somewhere (eg Content Server Fundamentals) that even though there is no limit for number of repeating values, the number of values stored in the attribute should be relatively small (<100s) for the exact reason you mentioned. The only other thing I would suggest is to have a DBA take a look at the repeating attribute table for you custom type and see if he/she can optimize it by adding appropriate indices.

ldallas

Tell the DBA to drop statistics on the *_r table for the type that defines the repeating attribute in question. Then try your queries.

BTW - based on the description of what you are doing the problem may be better addressed in the code.An update DQL statement as opposed to using DFC for example. Although - with 5000 attribute values it may not be the best solution.Transactions will also make this less efficient. I assume you are versioning the object in the target docbase as well. Depending on the rules - it may be more efficient to create a new obejct and delete or subordinate the original target object in some other way.

mfernandezv

I think the behaviour replacing DFC call with DQL call will be very similar.

As Lee commented in the previous post, DB transactions could be the key...

Due to the number of repeating attributes you are working with it would be difficult to improve process performance unless DBAs can do some truly magic

Regards

JohnFWebber

You might be better off keeping most of the repeating attributes out of Documentum altogether and hooking them back in post Site Cache Services.

Begin T

This is an old thread..but for whatever is worth...we had a scenario where we had several thousand repeating values per object. So we decided to store them in an external table in stead of in Documentum as JohnFWebber suggested. The performance is much better. However, there may be more work. You may end up creating views of combining both sides etc..