We are planning to upgrade from CA Clarity 13.1 to Clarity 14.3.
Prior performing the upgrade we want to upgrade our existing DB from 22.214.171.124.0 to 126.96.36.199.0 which is a prerequisite for the Upgrade.
Our Infrastructure Team has got into a situation where we cannot do a direct DB upgrade as the server is being shared by several other applications.
We are planning to have a fresh DB server (different server) with 12 C installed and have data migrated from 188.8.131.52 to 184.108.40.206.0 prior performing the upgrade.
Could anyone share some document /reference link on these topic which we can use to do the data migration?
Is there any other approach which we can follow? I am willing to explore other options as well.
I was checking the installation guide but was not able to collect any information.
Looking forward for the response.
You are on the right path, you can set up a database with the parameters mentioned in the install guide, take the dump of PPM and import the dump into the new system. Its like refreshing the test to dev.
I should install on the new server the exact same db version.
Make a full db backup of the current system.
Restore the backup on the new server.
Redefine the db connection in CSA.
When everything is verified to be OK upgrade the db.
Then proceed with the CA PPM upgrade.
Thanks for the response .
In continuation to these .
We have upgraded our database from oracle 220.127.116.11.0 to 12C.
This is a new DB server .
And cloned the existing 13.1 Application to another which has Red Hat 7.2 due to the same concern .
I tried to change DB connection in NSA to map the new DB in defined syntax and restarted the server .
I am getting the below error when I try the Clarity URL .
HTTP Status 500 -
The server encountered an internal error () that prevented it from fulfilling this request.
CA Clarity PPM
While checking NSA log I found the below error .
Clarity 13.1.0.0248 re-initializing...
2016/08/11 14:29:39.793 | Aug 11, 2016 2:29:39 PM org.apache.catalina.core.ApplicationDispatcher invoke
2016/08/11 14:29:39.793 | SEVERE: Allocate exception for servlet Clarity Web Control
2016/08/11 14:29:39.793 | com.niku.union.config.ConfigurationException: At least one validated Database must exist in Multitenant mode.
I am not sure what is going wrong I have provided the correct user name and other details .
I have already check with the DBA for TNS Entry in the Aplication server ,yet to receive an update.
Any pointers to these issue would be of great help .
Are you able to connect to database via any client tools like oracle SQL developer. Also PPM 13.1 was never tested to work with Oracle 12. Please perform the test below to see the exact reason
1. Go to the CSA > Properties > Application tab
2. At the end of the JVM Parameters for the CSA service (not the App service), add a space (' ') and then these values:
-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
3. Click Save.
4. Stop, deploy, and start the CSA service.
5. Navigate to the DWH properties page in the CSA.
6. At the putty terminal in the production server where the CSA was restarted, type:
jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=5005
7. The following should probably appear with a prompt awaiting more information:
Initializing jdb ...
8. Type in the following command, making sure that the case sensitivity is precise:
stop at com.niku.nsa.util.NsaUtil:43
9. Go back to the CSA and click Save. This will likely not complete, you have to go back to the jdb program in putty now.
10. If at this point you see a message saying Breakpoint hit on com.niku.nsa.util.NsaUtil.getConnectionStatus(), line=43, perform the next two steps otherwise skip them.
11. Type in the following commands:
12. You should now see an Exception message displayed that either refers to a database or network issue to be addressed. It will also include the JDBC url being used, the credentials, and also whether the database ID is correctly Datawarehouse or null or niku or something else.
13. Type in the commands:
14. If no longer needed, you can now remove the JVM parameters that were added in the CSA and then stop/deploy/start the CSA services again
Not sure if this helps, but a while ago (when 12C was new-ish) I was playing around with seeing if the application would work against it (before CA supported it) - ( this was to prove a point for some DBAs in the organisation, not for any real reason )
anyway; hit lots of problems but ;
Dave wrote: we got a sandpit instance running on 12c OK when the DBA set the 12c database up in "old-style" management, when we set the database up in new "12c style" (described to me as "containers") then we could not connect to it in the CSA. We suspected that the Clarity software/db-drivers just did not expect that "12c style" setup. (the details of the above mean very little to me, might make sense to an Oracle DBA person)
we got a sandpit instance running on 12c OK when the DBA set the 12c database up in "old-style" management, when we set the database up in new "12c style" (described to me as "containers") then we could not connect to it in the CSA. We suspected that the Clarity software/db-drivers just did not expect that "12c style" setup.
(the details of the above mean very little to me, might make sense to an Oracle DBA person)
This is most likely due to the fact the database version 12c is not supported to work with 13.1. This is why it throws this error message.
Do you need to bring the application up at all? Since you want to simply upgrade, just ignore this message.
Do the following:1. Ensure all details in properties.xml are correct.2. Bring the services down, remove them3. Follow all prerequisites, take backups4. Start your upgrade to 14.3.
You should not have any issue once you upgrade to 14.3.
Hope this helps -Nika
Hi Supriya.Chakraborty1 - Did any of the responses help answer your question? If so please mark as Correct Answer. Thanks!