Bug 1067330

The installation log linked seems to demonstrate a successful installation, with SRAMP seeding and SQL table creation both succeeding. Is that the correct InstallationLog?

Created attachment 867575 [details]
installation log

I'm sorry, accidentaly attached bad log file. Now there should be one with the problem.

Hmm, the fact that the SQL table creation succeeded seems to me to mean that the problem lies somewhere within the SRAMP configuration (no problem with the database itself, and there are no problems with the JDBC driver jar). Thus, I would hesitate to say that this problem is caused by the installer. Ideas for where the problem lies are 
a) SRAMP modeshape configuration.
Modeshape configuration for this specific DB version may require tweaking (see jboss-eap-6.1/cli-scripts/s-ramp-add-sramp-conf.db2.cli)

b) The table creation step is not creating all of the required tables.
Looking into the SQLCODE=-204 it may be that there some missing SQL statments from the sql scripts that currently exist.

Some useful links:
http://www-01.ibm.com/support/docview.wss?uid=swg21613531 - this document contains an error message that looks nearly identical to the one we receive, may be helpful to diganose the issue. 
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=%2Fcom.ibm.db2z9.doc.codes%2Fsrc%2Ftpc%2Fn204.htm - description of what the -204 SQLCODE means. 

I will investigate more tomorrow.

I attempted to reproduce this locally with the following db2-97 jar here with this md5 sum: 
efb5dd5fdfc07ddb86fe232345a22a2d  db2jcc4.jar

and the installation succeeds. I would now also suspect that the dballo database may have been previously used by some other installation and contains some tables that are making installation fail (this has happened before.) 

Thanks,
Tom

Tom, it worked for me localy too, on jenkins it fails sometimes, we always clean db before our tests, so db didn't contain other tables.

It doesn't fail consistently, so maybe some timing issue? I tried now and it passed for me on jenkins too. Will see with future runs how it behaves and let you know.

Let's try to identify a pattern of when this fails - is this OS or JDK dependent? Thanks!

I am trying to find out the pattern of when the installation fails with DB2-97 database. It seems the problem is not connected with OS or JDK. On the same environment some installations fail and some not. I use databases from our Red Hat dballocator and the same database user accounts produce the same results.

accounts-OK: dballo01,dballo04,..
accounts-ERROR: dballo02,dballo03,dballo05,..

It is hard to say if this pattern is correct but up to now the results are constant. I am still waiting for some other results from one jenkins job..

Before every installation I cleaned the database and I used JDBC driver with following md5 hash.

efb5dd5fdfc07ddb86fe232345a22a2d  db2jcc4.jar

Does anybody know if it is possible that some DB accounts (od the same database) can produce this problem?

Hello Martin,

I am able to confirm that I see the same errors with the accounts you listed in error.

Not sure if this helps too much, I am using the same jar as well 

efb5dd5fdfc07ddb86fe232345a22a2d  db2jcc4.jar

Hi,
I've asked for the page size associated with the tablespaces these dballocator accounts are on.  It may be that the failing accounts are not sized sufficiently for sramp data.

https://engineering.redhat.com/rt/Ticket/Display.html?id=297634

If not then it rules out this as a problem.  I had seen some page size problems on other issues that related to data size.   (In reply to Martin Basovník from comment #7)

Hi,
I just tried to install to install FSW on some DB2 databases now. I used dballo01-04 from DBAllocator tool. Every installation failed while trying to install FSW during the step "Creating database tables". I tried to erase database from web GUI, databases became broken and must be repaired manually. I am not able to effectively investigate this problem until the databases from DBAllocator will be repaired.

According to ticket 297634 above, it seems that tablespace page size does not cause our problem because database dballo04 (mentioned in the list in ticket) has also reduced tablespace page size and installation of FSW worked on it.

(In reply to Jiri Sedlacek from comment #2)
> Created attachment 867575 [details]
> installation log
> 
> I'm sorry, accidentaly attached bad log file. Now there should be one with
> the problem.

On further investigation have noticed in the logs we have two database schemas that are referenced dballo03 and dballo01 in the attached log.  We should only be configured for one schema (in this install - dballo03) which is confuising.  Its suspicious that dballo01 is referenced for non sramp tables which makes me also suspicious that ispn_bucket table was created in dballo01 and the ontology fails as it tries to access it in dballo03. Secondly, all tables should not be referenced in dballo01 as the datasources are configured with dballo03 username and password.  The matter is further complicated by the fact that we may have been masking an issue due to existence of the tables in other schemas on dballocator servers that have been left behind from other installations which could maybe explain the intermitent nature of the problem.

[12:36] <stejohns> jdc: I wonder whether during installation somehow the ispn_bucket table got created in dballo01 and the ontology load is trying against dballo03
[12:38] <stejohns> jdc: concerned also that non sramp tables should have been validated in dballo03 according to the datasource username & password also
[12:39] <jdc> stejohns: It looks like the tables were found on dballo01 too?
[12:39] <jdc> stejohns: I don't understand the mismatch between 01 and 03 though.
[12:39] <stejohns> jdc: yes i think all tables should have been in dball03
[12:40] <stejohns> jdc: yes i think there is two issues at play here
[12:40] <stejohns> jdc: the validations should have shown dball03 
[12:40] <jdc> stejohns: Could it be that some of the tables exist in both databases?
[12:40] <stejohns> jdc: +1 thats what i was thinking ... that could explain intermitent issue
[12:40] <jdc> stejohns: Yes - I'd expect that from the connection URL.
[12:40] <stejohns> jdc: when dballocator clears stuff you get a failure
[12:41] <jdc> stejohns: Makes sense.  (You need to run the schema creation either manually or via the installer before running anything.)
[12:41] <stejohns> jdc:  the second issue maybe that sramp did actually get created in dballo01 for some reason
[12:42] <stejohns> jdc:  then ontology upload correctly worked against dballo03
[12:43] <stejohns> jdc: i cannot see in logs where sramp table gets created as its done via cli command
[12:44] <jdc> stejohns: Same here.  It still seems very strange that the username is dballo03 and the tables are prefixed with user "dballo01".
[12:44] <stejohns> jdc: that is very confusing because if you look at the datasource config cli ... they are set to dballo03
[12:45] <stejohns> jdc: so i would have expected validation in dballo03
[12:45] <stejohns> jdc: i just dont see where its picking up dballo01
[12:45] <jdc> stejohns: Same here.
[12:46] <stejohns> jdc: but that also makes me suspicious that sramp table got created in dballo01 and thwn at ontology load time it correctly tries to access dball03 where the tables does not exist
[12:46] <jdc> stejohns: I wonder if the sqlresults.log file would help.
[12:46] <jdc> stejohns: Yes.
[12:46] <stejohns> jdc: and on some runs we just got lucky that tables existed in other schemas on the dballocator server
[12:46] <stejohns> jdc: it may be best to get a zip up of the directory and have a good look through it 
[12:47] <jdc> stejohns: Something broken with the database/dballocator setup, or with our code?  (I suspect the database/dballocator.)
[12:47] <stejohns> jdc: as there a temp files genrated for sramp stuff too that could harbour wrong username & passwords
[12:47] <jdc> stejohns: After the job has run, the workspace should be visible for a while.
[12:47] <jdc> stejohns: Ah.  That would be useful to know.
[12:48] <stejohns> jdc: hmm i wonder if we created one run, then created the text only installer and we have cached some tmp files settings
[12:48] <stejohns> jdc: then modified this to work on other db setups etc
[12:48] <jdc> stejohns: I'm not sure how the QE Jenkins jobs are set up.
[12:48] <stejohns> jdc: but not quite got it right
[12:49] <jdc> stejohns: That's possible.
[12:49] <stejohns> jdc: me neither... 
[12:49] <jdc> stejohns: Need more information from the files in the workspace though.
[12:49] <stejohns> jdc: the error after further investigations suggest the sramp table does not exist at ontology load time
[12:49] <jdc> stejohns: Ask QE to re-run the job and then the workspace will reappear?
[12:50] <jdc> stejohns: Which supports the theory that the create and use are on different databases or users.
[12:50] <stejohns> jdc: the dballo01 and dballo03 raises my suspiciions that it got created in wrong account and also that for some reason we are also ignoring the datasource dballo03 correct settings for the rest of the tables
[12:50] <jdc> stejohns: Yes.  It's not obvious why though.

Resetting the flags back to the state it was before Oct-24- 2PM. There was an incorrect bulk update that I'm trying to fix.

Hey guys,

did you make any progress with this? I'm getting the same error with our tests and would like to at least find some workaround.

Is there a bug here or not?

Is there any progress with this issue? We cannot easily check the database compatibility with DB-2 because of this issue, hence here I'm asking :)

This product has been discontinued or is no longer tracked in Red Hat Bugzilla.