Clarity 15.6.1 Install w/SQL Server

[Derrick Tetlow]

This is on-prem.

I am doing an install of Clarity 15.6.1 with SQL Server. I've followed all the instructions per the guide. I installed sql server, restored from the image provided in the install. Installed Tomcat. Installed the CSA. Deployed services. Started services. 

A couple of issues. 

1. The app is not coming up. I checked at localhost/niku/nu and the application is down even though the services have been started. 
2. Under Installation Overview in the CSA, the Database says Not Installed. I have verified all settings in the application and database configuration pages for the single app server and everything is up and available. 

What am I missing? 

Thanks.

------------------------------
Derrick
------------------------------

[Deactivated User]

Not installed basically means CSA does not see the DB where it is told and expected to see it.
There is something not right in your set up.

[Derrick Tetlow]

How does CSA see the db?

The Application server database section sees it. Where would the CSA be configured to see the db?

------------------------------
Derrick
------------------------------

[Deactivated User]

These are from my 15.3
db client protocols

databases in Management Studio


Notice how the server and db name are displayed at the top
CSA

db in CSA, notice that in the URL I am accessing localhost (I am on the server)
The default is Oracle and the port is something else (maybe Oracle default) so they have to be set up.
Even if the values are correct I usually have to save more than once and wait between to get my db available.


If you have those set up correctly start looking at the db login, user name, schema name and user set up

There are plenty of threads about getting the db connection in fresh installs  and upgrade. Use search.

[Derrick Tetlow]

So like this?:



TCP/IP settings for MSSQLSERVER01 are set to 1433 for default port. Username niku is created in the database with default schema of niku and role of db_owner. Restore of the schema from the db file was successful and I was able to query inv_investments and plenty of other tables successfully. 

The log files keep referring to failure to initialize:
The application failed to start because of a database configuration problem. 
Derived invalid tenant clarity from http request

The warmup commands failed as well. 

I am searching, but the new Broadcom site is not easy to search. 

Thanks for the help.

------------------------------
Derrick
------------------------------

[Deactivated User]

If I see it correctly it says Database is available - that means the connection is OK
Does is still say in the installation that it is not installed?
If you go to the Windows  services are beacon and app services running? Or issue on command prompt service status all

An old thread about install problems
https://community.broadcom.com/enterprisesoftware/communities/community-home/digestviewer/viewthread?MessageKey=55fabd21-e908-47d8-8eca-4fcf3934c81a&CommunityKey=7f0cbca3-5f93-4d44-a369-1a8ce98f5578&tab=digestviewer#bm55fabd21-e908-47d8-8eca-4fcf3934c81a
even older
https://community.broadcom.com/enterprisesoftware/communities/community-home/digestviewer/viewthread?MessageKey=b4f5f79f-85fe-4e2b-8429-ce443f719005&CommunityKey=7f0cbca3-5f93-4d44-a369-1a8ce98f5578&tab=digestviewer#bmb4f5f79f-85fe-4e2b-8429-ce443f719005

More recent related to another problem  which tells how I set up the db
https://community.broadcom.com/enterprisesoftware/communities/community-home/digestviewer/viewthread?GroupId=1747&MID=795739&CommunityKey=7f0cbca3-5f93-4d44-a369-1a8ce98f5578&tab=digestviewer

[Nika Hadzhikidi]

This usually happens when you have not upgraded the database and inadvertently have done a new install.

Then the application sees the database, but detects it's a different version and this is why you see "The application failed to start because of a database configuration problem"

To prove this please check your database level with query:

select * from cmn_install_history order by installed_date desc

You will see the current version on top. See if it's 15.6.1. If it's not, you will have to rollback all Clarity files and do the upgrade again, paying attention to the folder you specify. If you specify a directory that does not have Clarity install, the installer will do a new install and will not upgrade the database. 

Hope this helps -Nika

[Nika Hadzhikidi]

This usually happens when you have not upgraded the database and inadvertently have done a new install.

Then the application sees the database, but detects it's a different version and this is why you see "The application failed to start because of a database configuration problem"

To prove this please check your database level with query:

select * from cmn_install_history order by installed_date desc

You will see the current version on top. See if it's 15.6.1. If it's not, you will have to rollback all Clarity files and do the upgrade again, paying attention to the folder you specify. If you specify a directory that does not have Clarity install, the installer will do a new install and will not upgrade the database. 

Hope this helps -Nika

[Derrick Tetlow]

@Deactivated User @Nika Hadzhikidi

It turns out it was an issue with the niku user in the sql server database. I'm not sure exactly what the issue was, but we dropped the user and recreated it and it was fine. Apparently, that status indicator on the database tab of the server in the csa isn't always reliable.

Thanks for all the help!!​​

------------------------------
Derrick
------------------------------

[Deactivated User]

If you mean available then that indicates that there is a database that Clarity can connect to, but as you say it is not detailed enough to tell if everything is OK the way Clarity needs.

What made you decide to drop the user and try that approach?

[Deactivated User]

Just got my installation past that.
No matter how I tried to save the correct settings the ppm and dwh db's were unavailable after the save.
Then I just restarted NSA service and both were available without any further action.
Is that the way it is supposed to go and if yes is it documented?

[Nick Darlington]

If the databases are unavailable it's usually due to some error between Clarity and the database - but the reasons are all suppressed (and usually not even logged) as to why, which aside from trivial 'I got the wrong port number' or 'bad password' or 'I haven't set it up yet' can be caused by a ton of other issues.  Trying to figure them out by trial and error is no picnic.

To try and offset that, although the steps involved are not trivial, I created this article to help show you the direct error messages from the driver at the point the database decides it is going to be showing as 'unavailable':

https://ca-broadcom.wolkenservicedesk.com/external/article?articleId=9580

It may also require some tweaking in my absence for the newer versions of Clarity, so if there are persistent 'unavailable' reasons for a given version not covered I or product support may be able to check and see if this approach can be tweaked to give up the real reason.

I've seen everything from protocol mismatches at a db level causing it, db encryption configurations, db user permissions issues, wrong default schemas, accounts being locked, etc., and usually the errors from this method are very precise at identifying what that is.

It would be good if this could be avoided and the exception/error message just written to the nsa-ca.log file at least, but until then this may help.

Of course, in the event that you weren't already setup for debugging, and then when you restart the services it magically works, that may not be of much help (sorry), but for next time... in your specific case Martti, I could only guess that the database and/or network had 'had enough' of the failures through the db connection pool you had in place, and restarting created a brand new pool and connections that were then able to negotiate it better.  Beyond that I couldn't offer any further reasoning at this time.

[Nick Darlington]

I believe the steps in the article still hold for 15.6.1 inclusive without change by the way.

Note that you may get errors and reasons for dwh and/or the main clarity database schemas from the same steps (e.g. even if on the dwh page it may give errors about an invalid clarity db schema and vice versa), so if using this, pay attention to which one is giving which error to fix it accordingly.

[Deactivated User]

Thanks Nick.
In my last case the db was available after the restart of the nsa service so I would not have got anywhere with the debugging.
I have had this problem before in fresh installs and therefore made screenshots to guide in setting the values.
The db was unavailable after I had set them to what worked before.
What I normally do is test the credentials by creating and ODBC connection, but that is not the same.

I am running a single VMWare box (old version) with both the application and the db. That may contribute to the quality and performance of the connection