Tags: oracle, startup, troubleshooting
This is a very windows specific solution however similar things could occur on *nix
This is a problem I ran into while investigating an oracle problem. I had a VMWare image that I used to run Oracle and Content Server. Content Server had always run fine on it whenever I switched the VM on. Then this morning it didn’t. Coincidentally I had just installed a new Oracle home (ie installation) to test out some issues to do with a particular Oracle patch version. Too much of a coincidence? Of course.
The problem actually arose when I subsequently tried to create a new docbase for an entirely different investigation. I started the docbase config program entered all the information until I got to the bit where it takes the database password and tests the database connection – FAILURE.
I did a couple of tests, first of all start up SQL Plus and try and connect to the database, in this case the database connect identifier is DB1:
SQL> connect system/@DB1
ORA-12154: TNS: could not resolve the connect identifier specified
OK so SQL Plus seems to have a similar problem to the Content Server config program. So What happens when you type connect …/…@DB1? Well assuming you are using the standard TNSNAMES name resolution it looks for the file tnsnames.ora in the %ORACLE_HOME%\network\admin folder and uses that to convert DB1 into a request to the TNSListener.
The problem was I hadn’t defined ORACLE_HOME – never needed to – so presumably it was using a default value that had now changed after the new oracle home installation.
So I set an explicit oracle home environment variable:
and that fixed SQL Plus. By opening up the control panel System app I set the environment variable for the dmadmin user so now the configuration program , and all the docbases could start.
Update: every Documentum on Oracle installation I have seen has used TNSNAMES, using something like Oracle Internet Directory (OID) is not a good idea according to support note esg97155.
Tags: content server, documentum, troubleshooting
This question comes up so many times on the forums it’s time to add it to the blog. It probably helps to understand the role of the Documentum Docbroker (or Connection Broker isn’t it amusing how the marketing people insist on changing the names for these things but the old names live on in the code!).
Most of this information is in the Content Server manuals but a few definitions:
Docbase/Repository. A collection of content files and metadata that is managed as a single entity. Usually consists of one or more files systems and a RDBMS. Can also include an XML Store (from D6.5) and other more esoteric options like Centera. Some people include the Full-text index as part of the docbase.
Content Server. A server-based process (or set of processes is you are on *nix) that provides an API for clients to access and control the underlying docbase. Each server will access exactly one docbase, but each docbase could have multiple servers possibly distributed to different machines and maybe other parts of the world.
Docbroker/Connection Broker. Each content server will be configured to project connection information (what IP address and port the server is on, which docbase it serves). When client applications want to connect to a server to access a docbase they first ask a docbroker for the connection details. If they receive connections details they then connect to the correct server. The details of this are all contained within the DMCL connect or DFC IDfSession. Note that clients are configured with which docbroker(s) to connect to not which servers to connect to.
In a simple out-of-the-box implementation you usually have 1 docbase, served by 1 content server projecting to 1 docbroker all on the same server, so I’ll continue this discussion on that basis although it is easily extensible to more complicated deployments.
If you get the above error message then you can conclude that the client application sucessfully connected to a docbroker and asked for the connection details for a docbase. The docbroker however did not know about any servers that served the docbase.
A couple of questions to ask yourself are as follows. First, is the content server for the docbase running? Use Task Manager or ps to check that there is a process running. Usually the process is called documentum.exe (or just documentum) but earlier versions of the windows software used dm_serverv4.exe. If you have a machine with multiple content servers possibly serving different docbases then you have a slight problem as you want to check if the content server for one particular docbase is running. In Unix this is easy as the full command line is available in ps, but in Windows it’s more difficult. Process Explorer, formerly from SysInternals but now owned by Microsoft, gives this information.
If you know the server is running then you need to find out why the docbroker doesn’t know about it. First of all check the server log especially the startup section – there is a DM_DOCBROKER_I_PROJECTING message that tells you which docbroker(s) the server is projecting to. Is it the docbroker your client is configured for?
It maybe that the server has tried to connect but has been unsuccessful e.g. due to firewall problems. There will be an error message in the log stating the problem. You then need to work out what configuration must be changed to allow the projection.
The content server is unnecessarily picky about which IP addresses it binds to and I have seen issues with docbroker and content server on a machine with multiple network adapters where the content server is binding to one adapter and the docbroker is binding to another. Even though they are on the same machine they are trying to communicate on different IP addresses.
By working your way through this troubleshooting process you should be able to resolve 9 out of 10 (or maybe 99 out of 100) examples of this problem