We’re trying to install a new environnement for CA 14 Sp2 via an Oracle DB.
I’m on the enterprise manager name EM-H01.intranet.mrn.gouXX
My DBA send me those information for the MDB creation:
Compatibility : OracleServer: chiefs.intranet.mrn.gouXXX
DB : d0511,
Service: DGA_D (Service)
BD Administrator : CA_ITRM
Password : ********
I’ve gave the information on Page 1 and 2 of the install shield wizard:
Here, I’m missing something, what is ORACLE_HOME? I kind of not understand the documentation...
Whatever I type in it, I got an error.
ORACLE_HOME refers to a directory where the Oracle software is installed
Check the documentation:
Preparing to Work with an Oracle MDB - CA Client Automation - 14.0 - CA Technologies Documentation
A Oracle client should installed on the computer where you are planning to install the Domain Manager.
Also be advised ITCM is a 32-bit application, and therefore requires a 32-bit oracle client application to be installed. The remote database can be 64-bit though.
After two weeks of work, we're now stuck while installing DSM Manager... with an error code 110.
The log show that MDBAdmin is unable to connect to Oracle... but if I try to connect with SQLPLUS it work...
Have you verified the Oracle client is 32-bit?
Has the tnsnames.ora file on the client side been configured for a connection to the remote database? You can use the NetCA tool (network configuration tool) from Oracle to manage or add this connection to the tnsnames.ora file.
Sample location for the tnsnames.ora file:
Does the sqlnet.ora file specify the EZConnect method as being available?
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
Sample location for the sqlnet.ora file:
Alternatively, you can try running the standalone mdb installer:
<ITCM DVD Media) --> WindowsProductFiles_x86 --> mdb --> setup.bat
It's the same mdb database, just wrapped in a java based installer. You can try it as an alternative, to see if it will get you further along. If it succeeds, then you can run the normal installer, and the result should be different now that the database and user accounts exist, versus having to create them in the first place.
IT was the Oracle Client that had problem , we reinstalled it and everything kinda work...
We had to do many installation test.
now we have this little problem I can't seem to find the solution...
We installed the DM then the EM
When I go in the EM to add the new Domain:
Does anyone know of a simple command to release the DM from an inexistant Enterprise???
Open DSM Explorer on the DM and see if this option exists:
Nope I don't have that option:
maybe a command to force reregistreing a domain to enterprise...
If that's the case, and you are sure the DM does not belong to some non-existent Enterprise, then you can follow the steps on this document:
Obviously you can ignore the steps for cleaning up the Enterprise database, since it does not exist.
A note to anyone reviewing this posting:
I DO NOT recommend using this procedure to unlink a DM from an EM, in substitution for using the normal DSM Explorer method to unlink a DM from an EM. The reason being that this document does not drop the triggers on the individual replicated tables that keep track of records deleted from the DM database tables. These triggers are added when a DM is linked to an EM, and they feed deleted data into the ca_replication_history table on the DM. Thus if you used these steps to permanently unlink a DM from the EM, months from now (depending on the size of your environment) you would be calling for an issue where either your database is running out of disk space or performing poorly, because the ca_replication_history table will slowly be growing without an upper limit in the background.
Does those SQL query work under Oracle?
if so, can I do them in SQLPLUS?
Isn't there a simple CMD command like de cserver to register on another Enterprise...
Unfortunately there is no command and it's not that simple! The "cserver" commands are for changing registrations of scalability servers to DMs. When it comes to Enterprise and Domains that are linked together, there is much more complexity involved, as both managers replicate data to each others databases.
I believe a colleague of mine (Mr. Joe Puccio) had to translate that technical document to Oracle, for another customer. Let me contact him and see if we have this on-hand...
Well, I'm kind of lost...
I've asked our DBA to reset both MDB and I've uninstalled and delete all of CA on both manager and reinstalled :
1- DM --> Standalone
2- SS --> To DM
3 - EM --> To SS
then done the same thing with order:
1 EM --> To SS
2 DM --> Pointing directly to EM
3 SS --> To DM
There's something I don't understand...
Run these two queries on the DM database and let us know the output:
select domain_uuid, label, domain_type from ca_n_tierselect domain_uuid, label from ca_manager
Also, put the DSM Explorer in which you are attempting the link, into detail mode:
cftrace -c set -l detail -s 20000 -ln 4
Reproduce the error message, and attach the TRC_GUI* log files...
I've join the Log.
here are the queries result:
on the DM MDB:
I don't know if it can help but the same queries on the EM MDB:
So the results of the query do not show the DM is linked to any EM. So we need to see the TRC_GUI log, to understand why it's giving an error that the DM is still linked to an EM.
If the DM was still linked to an EM, we would see it listed in the ca_n_tier and ca_manager tables.
I've add the log in the attached files a the top...
but for what I can see:
300418-14:14:45.7981640L|003832|000017b8|GUI |cmObjectManager |dataaccess.cpp |003273|DETAIL | COAPI_CDataAccess::GetLinkEnterpriseDomainStatusCb entered300418-14:14:45.7982310L|003832|000017b8|GUI |cmObjectManager |dataaccess.cpp |003292|DETAIL | COAPI_CDataAccess::GetLinkEnterpriseDomainStatusCb link handle 4300418-14:14:45.7982555L|003832|000017b8|GUI |cmObjectManager |dataaccess.cpp |003309|DETAIL | COAPI_CDataAccess::GetLinkEnterpriseDomainStatusCb status 235, curr=0, total=0300418-14:14:45.7982812L|003832|000017b8|GUI |cmObjectManager |dataaccess.cpp |003321|ERROR | COAPI_CDataAccess::GetLinkEnterpriseDomainStatusCb operation has errored300418-14:14:45.7983074L|003832|000017b8|GUI |cmObjectManager |dataaccess.cpp |003835|ERROR | COAPI_CDataAccess::HandleError rc=CMM000235, component=cmnObjectDAI, errorInfo=300418-14:14:45.7983315L|003832|000017b8|GUI |co_mapi |co_mapi.cpp |002624|ERROR | LinkEnterpriseDomainCb error trying to get status of operation300418-14:14:45.7983506L|003832|000017b8|GUI |cmObjectManager |dataaccess.cpp |001435|DETAIL | COAPI_CDataAccess::~COAPI_CDataAccess no database connection to close300418-14:14:45.8078239L|003832|000017b8|GUI |GUI_CM |messagebox.cpp |000207|INFO | MessageBox (Single item) - Item: ? (?) Message: "The Domain being linked is already member of an Enterprise [CMM000235]"
I see what the problem is...
From your earlier screenshots... both EM and DM have the same domain_uuid !!! One must be a copy of the other. Hence it fools the DSM Explorer link process into thinking the two managers are already linked, since that domain_uuid, already exists in the Enterprise manager's database.
You need to do a fresh install for one of the managers, and allow the installer to create a new database, which will generate a new domain_uuid.
I'm guessing you attempted to shortcut the process, by copying the database from one of the existing managers, and then tried to install a new manager, to a copy of an existing database. This would not be allowed.
Thank you so much...
that was exactly the problem...