It's all about the answers!

Ask a question

Disparity between an upgraded JAZZ verses new setup - db rights, schema properties

Norman Dignard (356688168) | asked Jan 24 '18, 11:12 a.m.
edited Jan 24 '18, 6:10 p.m. by Muralidhar Rajagopal (10114)

We are currently running 602 CLM, using liberty and Oracle backend. We have a production and  testbed servers

setup since 4.0.3 and have upgraded them a few times to bring us up to 602.  

We had a corruption problem with DNG on our testbed and IBM recommended that we drop and recreate it. Basically unregister dng from jts, drop & recreate db accounts/tablespaces and rerun setup to add DNG. 

Dropping DNG also affects the data warehouse artifacts and with no method to rebuild it, it too needed to be dropped and recreated along with rebuilding jts indexes. and registering the apps with DCC.

After redeployment of DNG and DW (reran jts setup to do so) we had a DNG  registration problem with DCC. We managed to get this resolved however in troubleshooting this problem we noted differences in db account grants, and schema properties (column types, triggers, etc.)

The differences were noted in comparing our production and the "updated" testbed. Prior to this both systems were 
the same.

It appears that there may be a patching/upgrade problem but I am wondering if anyone else has noted this.
The differences can be seen by comparing an instance upgraded from a previous release versing a new deployment for the same version.

This raises concerns on the validity of any tests done on the testbed which should be reflective of the target environment (production).. 


One answer

permanent link
Kenji Sarai (96029) | answered Jan 25 '18, 9:04 p.m.

Hi Norman,

I do not have similar experience as you, but here is the tip. The best way to verify the difference is to compare the database schema creation scripts between 403 and 602. The below explains the DDL files for DW schema creation.

Apart from new schema creation, the upgrade scripts to 602 would change the schema, but it is usually for creating new tables for new features, not modifying existing column types or grants. 

Also there might be a chance of failing to create a schema partially. Verify the logs for schema creation scripts if anything went wrong.

Norman Dignard commented Jan 26 '18, 8:52 a.m.

Thanks for the info/tip.  As for doing a compare, this would have to be done for each app not just for DW or to just do it against live systems.

As for the logs, be it from an upgrade or new setup, no issues are reported. 
Regardless of the methods used to get to the same end state (numberous upgrades, verses new deployment) one would expect that the underlying schemas, etc.. should be the same.

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.