Feeds:
Posts
Comments

Posts Tagged ‘Enterprise Content Management’

There are a lot of discussions on various forums/threads regarding the Content Server High Availability Environment. But I have not come across any documentation providing the precise steps to implement it. This is an attempt to list the steps that I have been using for the implementation. It’s basically an integration of bits and pieces from various sources combined along with my experience in order to put a clear picture. These steps may not be exactly as suggested and supported by EMC.
The procedure listed below is specific to the Content Server Linux Oracle 6.5 SP2 version.

Prerequisites:

  • As it’s a HA environment, the content files should be present in a File Store that is shared across the Content Servers.
  • The Installation Owner and the Installation Path should be same on each Content Server.
  • Availability of a Database Server and its connectivity through each Content Server Host using Oracle Client.
  • Update the /etc/hosts file of the Content Server Hosts so that they can resolve their IP addresses and hostnames.

Once the above prerequisites are satisfied, the below steps can be used to establish the HA environment.

  • Install the Primary Content Server as per the standard procedure mentioned in Installation Guide.
  • Install the docbroker on the Secondary CS host.
  • Create a Secondary Server Config object using Documentum Administrator.
  • Copy server.ini, aek.key, dbpasswd.txt, dm_start_docbase and dm_shutdown_docbase from Primary CS Host to Secondary CS Host.
  • Update the server.ini on both the Hosts so that the docbrokers project to each other.
    server.ini on the Primary CS:

    [DOCBROKER_PROJECTION_TARGET]
    host = <primary docbroker>
    port = 1489
    [DOCBROKER_PROJECTION_TARGET_1]
    host = <secondary docbroker>
    port = 1489

    server.ini on the Secondary CS:

    [DOCBROKER_PROJECTION_TARGET]
    host = <secondary docbroker>
    port = 1489
    [DOCBROKER_PROJECTION_TARGET_1]
    host = <primary docbroker>
    port = 1489
  • Update the dm_shutdown_docbase as follows: 
      The line preceding to “shutdown,c,T,T” should be updated as follows:

    • Original:
      ./iapi <docbase> -U$DM_DMADMIN_USER -P -e << EOF 
    • Updated:
      ./iapi <docbase>.<secondary server config object name> -U$DM_DMADMIN_USER  -P -e << EOF
  • Update the dfc.properties of the Web Application as well as both the Content Server Hosts so that they point to both the docbrokers.
  • Create an ACS Config object using the below command:
      dmbasic -f dm_acs_install.ebs -e Install -- <docbase name> <installation owner> <password> <new acs config name> <secondary server config name> <JMS Port> <JMS protocol> <output log location>
  • Update the acs.properties accordingly.
  • Once the above steps are complete, shutdown the Primary CS and test the Secondary CS for expected functionality. There may be minor issues which may need few basic fixes. Such fixes include creation of sysadmin directory at $DOCUMENTUM/dba/logs/<repository id>/ in order to fix issues relating to jobs running on Secondary CS.

Start the Primary CS and now both the CS should be in HA.

Read Full Post »

I came up with this junk when I was trying to clean my repository by finding a DQL that I could use to delete more that 150,000 junk user objects from my repository. Ignore that statement as it is again a junk. What I came up is not very new. It’s just the weirdness in the behavior of the DQLs. Is this weirdness only with the repeating attributes? I would like the DQLs to do much of the talking as I feel they can explain their pain much better. So here it goes:

A1)SELECT COUNT(DISTINCT user_name) FROM dm_user >> 168241

A2)SELECT COUNT(DISTINCT users_names) FROM dm_group >> 2916

A3)SELECT COUNT(DISTINCT user_name) FROM dm_user
WHERE user_name NOT IN
(SELECT DISTINCT users_names from dm_group) >> 0

Isn’t that weird?

B1)SELECT COUNT(DISTINCT user_name) FROM dm_user, dm_group
WHERE ANY dm_group.users_names = dm_user.user_name >> 2915

A2 VS B1: again weird!

C1)SELECT COUNT(DISTINCT user_name) FROM dm_user
WHERE user_name NOT IN
(SELECT DISTINCT user_name FROM dm_user, dm_group
WHERE ANY dm_group.users_names = dm_user.user_name) >> 165326

(A2, A3) VS (B1, C1): any explanation?
But that’s a relief indeed. That’s the result I needed. A1 – B1 = C1. Under the current circumstances, that’s encouraging enough to get into some more meddling.

D1)SELECT COUNT(users_names) FROM dm_group
WHERE ANY users_names NOT IN
(SELECT user_name FROM dm_user) >> 5

What the hell!!!

D2)SELECT users_names FROM dm_group
WHERE ANY users_names NOT IN
(SELECT user_name FROM dm_user)
>> TestUser1 test3 test2 orts test1x

hmmmm…

D3)SELECT COUNT(*) FROM dm_user
WHERE user_name IN
(SELECT users_names FROM dm_group
WHERE ANY users_names NOT IN
(SELECT user_name FROM dm_user))>> 4

This is insane. Isn’t D3 a contradiction in itself? Can I challenge EMC to explain that? Can someone come to my rescue?

D4)SELECT user_name FROM dm_user
WHERE user_name IN
(SELECT users_names FROM dm_group
WHERE ANY users_names NOT IN
(SELECT user_name FROM dm_user))
>> TestUser1 test3 test2 orts

Here is something that helps; but it doesn’t explain the insanity though.

ConsistencyChecker Report:

Checking for users belonging to groups not in dm_user
WARNING CC-0002: User ‘test1x’ is referenced in dm_group with id ‘12000d808004a500’ but does not have a valid dm_user object
Rows Returned: 1

Summery:
Weirdness No. 1:     (A1, A2, A3)
Weirdness No. 2:     A2 VS B1: Explained by the ConsistencyChecker Report.
Weirdness No. 3:     (A2, A3) VS (B1, C1)
Weirdness No. 4:     D3: The Contradiction in itself.

I could get an explanation only for Weirdness No. 2 which I guess is not a weirdness at all. I hope someone reading this post would try explaining the other three. 1 & 2 I guess are contributed by repeating attributes but remains unexplained anyway. 4, the D3 is an absolute marvel. Is there a bug in the way DQL works?
C1 is the undisputed winner as it provides the expected result.

Read Full Post »

Older Posts »