Issue with HQ server after upgrade

[vodyanoi]

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

[jvalkeal_hyperi]

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

[vodyanoi]

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

[jvalkeal_hyperi]

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...

[admin]

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]

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

[admin]

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

[vodyanoi]

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