VMware Cloud Community
vodyanoi
Contributor
Contributor
Jump to solution

Issue with HQ server after upgrade

Just going throught the process of upgradeing our current working installation.

We have upgrades HQ server from version 3.1.4 , which was running successfully under windows 2003 server using the inbuilt postgre database, to version 4.1.0 on the same server.

The upgrade process seemed to go without a hitch. We configured the "run as a service " option and then went to windows services and started the service.

We have waited for 2 hours and whenever we try to login to the website we get the message.

The HQ server is still starting. The database is just over 5Gb in size.

Should we have expected the start-up to have completed by now?

Is there something in particular I should be looking for in the logs?

I did note that there was a previous post with a link to ports required for HQserver.
I have checked and as far as I can tell none of the ports are in use by other programs. windows firewall is not turned on on this machine.


regards


Spencer
Reply
0 Kudos
1 Solution

Accepted Solutions
admin
Immortal
Immortal
Jump to solution

This is indeed a redundant index, not sure why it's added here. Look for db-upgrade.xml in the installer and edit it. Look for the following section:

<schemaSpec version="3.82">
<schema-alterColumn table="EAM_CONFIG_RESPONSE" column="VALIDATIONERR"
precision="512" columnType="VARCHAR2"/>

<schema-directSQL>
<statement desc="Creating index on EAM_CONFIG_RESPONSE validationerr"
targetDB="postgresql">
CREATE INDEX cresp_err_idx ON EAM_CONFIG_RESPONSE USING btree (validationerr)
</statement>
</schema-directSQL>
</schemaSpec>


Remove the creation of the index:

<schema-directSQL>
<statement desc="Creating index on EAM_CONFIG_RESPONSE validationerr"
targetDB="postgresql">
CREATE INDEX cresp_err_idx ON EAM_CONFIG_RESPONSE USING btree (validationerr)
</statement>
</schema-directSQL>

Re-run your upgrade. We'll have to investigate why it was put there in the first place.

Charles

View solution in original post

Reply
0 Kudos
7 Replies
jvalkeal_hyperi
Jump to solution

You could post your server logs and upgrade log. Those may tell if there is something wrong.

There is one thread where one user had a problem(turned out to be a bug for upgrade) to upgrade to 4.1.0 with build-in db.
http://communities.vmware.com/thread/353546?tstart=0
Reply
0 Kudos
vodyanoi
Contributor
Contributor
Jump to solution

Okie dokie.

Here are thr three log files I can see

hq-install.log and hq-instal-debug.zip are from the installation directory

The debug log file is about 3250Kb when expanded

server.zip is the log file from the running 4.1.0 installation, it is around 800Kb when expanded.

Hopefully it will make some sense to someone.


regards


spencer
Reply
0 Kudos
jvalkeal_hyperi
Jump to solution

Yeah, it seems that upgrade process failed somehow. At least this is good assumption, since server log is complaining for missing column on db.

So I believe fellows from hyperic should take a quick peek on that install debug file...
Reply
0 Kudos
admin
Immortal
Immortal
Jump to solution

Looking at your hq-install.log.debug, it seems like the database schema upgrade did not complete (it stopped at "Upgrading 3.81 -> 3.82", but the schema changes goes well past 3.140). However, there were no errors. Can you connect with the database and see what the value is for:

SELECT PROPVALUE FROM EAM_CONFIG_PROPS WHERE ID = 2;

If the PROPVALUE is 3.81, then try the statement in 3.82:

begin;
CREATE INDEX cresp_err_idx ON EAM_CONFIG_RESPONSE USING btree (validationerr);
rollback;

See if that index creation fails somehow.

Charles
vodyanoi
Contributor
Contributor
Jump to solution

Hi charles I have carried out the commands you mentioned.

Here is the output from those commands

hqdb=# SELECT PROPVALUE FROM EAM_CONFIG_PROPS WHERE ID = 2;
propvalue
-----------
3.81
(1 row)

hqdb=# begin;
BEGIN
hqdb=# CREATE INDEX cresp_err_idx ON EAM_CONFIG_RESPONSE USING btree (validation err); rollback;
ERROR: relation "cresp_err_idx" already exists
ROLLBACK
hqdb=#

regards


Spencer
Reply
0 Kudos
admin
Immortal
Immortal
Jump to solution

This is indeed a redundant index, not sure why it's added here. Look for db-upgrade.xml in the installer and edit it. Look for the following section:

<schemaSpec version="3.82">
<schema-alterColumn table="EAM_CONFIG_RESPONSE" column="VALIDATIONERR"
precision="512" columnType="VARCHAR2"/>

<schema-directSQL>
<statement desc="Creating index on EAM_CONFIG_RESPONSE validationerr"
targetDB="postgresql">
CREATE INDEX cresp_err_idx ON EAM_CONFIG_RESPONSE USING btree (validationerr)
</statement>
</schema-directSQL>
</schemaSpec>


Remove the creation of the index:

<schema-directSQL>
<statement desc="Creating index on EAM_CONFIG_RESPONSE validationerr"
targetDB="postgresql">
CREATE INDEX cresp_err_idx ON EAM_CONFIG_RESPONSE USING btree (validationerr)
</statement>
</schema-directSQL>

Re-run your upgrade. We'll have to investigate why it was put there in the first place.

Charles
Reply
0 Kudos
vodyanoi
Contributor
Contributor
Jump to solution

Hello Charles,

Thanks for all your help - much appreciated.

The suggestion you made works perfectly.

We are now up and running with version 4.1.0

Again many thanks for your help


Kind regards


Spencer
Reply
0 Kudos