How about a faster install?

July 16, 2010 at 2:19 pm | Posted in Performance | 4 Comments
Tags: , , ,

Over the years I have, like many of you, spent quite a lot of time installing Documentum Content Server and creating a repository. Quite a lot of that ‘installation’ time is spent waiting for various scripts to run.

In fact I’m creating a new 6.6 repository right now. It’s taking quite a while to run (the documentation claims it could be 50% slower than a 5.3 installation). So naturally when making coffee, checking email and making a few important calls is done my mind turns to how it could be faster. Here are my thoughts.

The install/repository creation splits into 2 phases, first you install the content server software (if this is the first repository you are creating on the box) and then you create 1 or more repositories. Usually the install is fairly quick as it’s a case of specifying a few parameters and then the install copies some files and possibly starts some services.

The repository creation is where the time seems to get longer and longer. Again the process seems to split into the following:

1. Define a few parameters, user accounts and passwords
2. Create the database schema and start up relevant services
3. Run the Headstart and other scripts including the DAR installations

Again it’s this 3rd step that really takes the time. In essence by the time you’ve finished step 2 you have a working repository. It just doesn’t have a schema or in fact any type of support for things you will need to do via DFC, DFS or any of the other client APIs. The scripts in step 3 just use the API or DFC to create all of that starting with the basic schema and format objects right up to creating all the necessary application objects via the DARs. Since more and more functionality is being packed into a basic content server this is the part that just keeps getting longer and longer to complete – the number of scripts that are now run compared to say 4i is just one indication of that.

I wonder if EMC have considered a better way of doing things. All those API/DFC calls being made in the step 3 scripts simply result in Database rows being created or updated and occasionally files being written to the content store. I would suggest that overwhelmingly the same row values are being created and a quicker approach would be to pre-create a standard set of database files via much faster database-specific data input facilities (how about using imp for oracle databases) and then changing any of the values that need to be specific to the installation (this is somewhat similar in principle to how I believe sysprep works for creating multiple Microsoft Windows installations)

To do this sucessfully EMC would need to have some sort of tool that could quickly identify differences in the basic database from version to version, but it could mean a large number of customer/partner/EMC consulting hours saved. If EMC every change the database backend to xDB maybe this would be naturally easier – they already have XML differencing tools. Just a thought.



RSS feed for comments on this post. TrackBack URI

  1. Maybe the installation time is not so important on the greater scheme of commercial revenue. As a vendor I guess EMC is not interested to show how easy is to install it / or mto make it easier (it would commoditize the expensive services).
    Why not capitalize, instead, on the “Oh, gee.. how long it took to install it… how complex this thing is… i never could have done it without these expensive consulting support…”
    We are not talking of consumer products (which must be “easy”) we’re talking of enterprise products which should be complex and hard to mantain to justify all these people around 🙂

    • As a person who runs one of the IIG Consulting organisations (Australia & NZ) I can confirm that as a vendor EMC is interested in anything that makes our products easier to install.

      The real IP is in defining an information strategy, understanding requirements, developing the solution design and then managing the organisational change. This is how an organisation gets to a point of true benefits realisation – the few hours standing up the environment is the easy stuff.

      I’m sure my Consultants would love to see a faster installer, just as you would…

      Lawrence Maynard

  2. One easy way to cut down on install time is to have separate installers for new installs versus upgrades.

  3. One client site I have worked with has repositories 15 years old, and they have been upgraded multiple times. When a Documentum repository grows to millions upon millions of rows of data and content, the time to upgrade grows from mildly irritating to horrific, with collateral operational impact, due to downtime, costing the business hundreds of thousands of dollars.

    Database tuning and cleaning the repository of unused content is critical. Disposing of old content helps shorten the upgrade process. When it is coupled to a strong records management process, it also helps reduce your business’ liability when exposed to searches and audits.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

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

Google photo

You are commenting using your Google 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 )

Connecting to %s

Create a free website or blog at
Entries and comments feeds.

%d bloggers like this: