We've got CS/SCS 5.2.5 on Sun/Oracle.
We use the out-of-the-box db_updateStats job, and don't have the Oracle DBA do anything special, because that's what the admin manual suggests, and a separate CS 5.2.5 system on Windows had horrible Desktop Client performance unless we ran db_updatestats.
One fairly large SCS publish set involves 51,000 documents. It takes about 30 minutes to run an incremental publish job, even when no new or updated documents need to be published. (I'm not sure what you mean by "export base query" and "Contentless export query".) If a small number of documents are published in that set, the job takes only another minute or so.
Smaller document sets (e.g. 1,000 docs) take only a minute or so when doing incremental publishes.
So I wouldn't be complaining if I had a set of 250,000 documents publishing in 2 hours.
It was a while ago, but I think the initial publish of about 45,000 documents took a couple of hours to collect, compress, and push the content files, even though the documents were small, 1- or 2-page text files.
Are your 16 hour, incomplete jobs doing the initial publish?
If that is the problem, have you tried to break the data into smaller sets to get the first publish done?
Or, is SCS trying to compress TIFF or PDF image files that SCS can't efficiently compress? If so, turn off the SCS compression.
Andrew
--- In documentum-users <at> yahoogroups.com, "Sushant" <s_sushant <at> ...> wrote:
>
> Our experience with db_updateStats on oracle platform has not been very good, especially with SCS in picture. Our DBA team run their own updatestats script (I don't have the details of that script). We also had some carefully defined indexes for both Export base and delete sync queries. The other tuning that helped speed up publishing process was the extensions_to_compress, though it did not matter for queries. The biggest benefit we derived at the database level was when we increased the SGA memory. Not sure what it translates to for the SQL database. The second benefit was cleanup of the redundant dm_relation objects. The setting for exclude_formats also helped to a certain extent.
>
> --- In documentum-users <at> yahoogroups.com, "fpaivacanada" <fjpaiva <at> > wrote:
> >
> > We have been having a lot of problems with extremely long running SCS queries, that are taking so long to return results that the process essentially hangs (e.g 16-18 hours and incomplete)
> >
> > In the investigations we conducted, we tried creating additional indexes, augmenting the SCS heap and increasing the error threshold. The one step that seemed to make the most difference, as expected, was the careful addition of indexes. However, the relative benefits of indexing and then generating stats via the RDBMS vs db_UpdateStats is unclear, although it tends to suggest that db_UpdateStats has some additional benefits compared to Stats Generation at the RDBMS level, i.e the perormance gains and resulting stability are much higher using db_UpdateStats.
> >
> > We're using CS/SCS 5.3, running on a SQLServer 2005 DB, publishing about 250k objects in a single publish. The export base query and Contentless export query take about 2 and 1 hours respectively to complete.
> >
> > Any thoughts on the relative benefits of db_UpdateStats vs RDBMS stats generation ?
> >
> > THanks
> >
>
RSS Feed