OnDemand 8.5.0.5 to 9.0.0.0 Upgrade

[johnnoel]

Has anyone done this upgrade yet?

I let the 9.0 install, uninstall the 8.5.0.5 but left the Instance intact.

The Readme is a little confusing to me.....

I have tried several times and for some reason, when I get to this step to update the system tables, there is one table missing..... "<OD_INSTANCE>.ARSFTIWORK" And so it fails for each of the steps below.

  1.4) Update the OnDemand System tables indexes
    - Customers should run the arsdb commands to drop and recreate the
      indexes for these tables

      Drop the indexes:
        arsdb -I <OD_INSTANCE> -efv
      Create the indexes:
        arsdb -I <OD_INSTANCE> -rv

      Then you will need update the statistics on all the OnDemand System
      tables

        arsdb -I <OD_INSTANCE> -mv


Has anyone encountered this issue and ow did you resolve it?

Thanks,
John

[GlendaRegpala]

Hi John,

We are currently in 8.5.0.5 and planning to upgrade - still deciding whether to go to 8.5.0.7 (latest Fix Pack) or 9.0.0.1 (latest release).  I'm curious if you resolved your issues in 9.0.

Is there anyone else who performed upgrade to 9.0?  Are there any issues you encountered or any negative impact?     

Any feedback would be appreciated.

Thanks.
Glenda

[Justin Derrick]

For the record, ARSFTIWORK is related to the full-text indexer.  The table may or may not be needed, depending on if you're running with the new full text indexing feature.

It sounds like you may need to export the tables (arsdb -xlvf) then drop the tables, then create the tables (arsdb -crtv) then re-import the tables (arsdb -ilvf).

Notice that I've left out the potentially destructive command to drop the tables.  I'm leaving that one for you to look up. 

Of course, you'll want to open a PMR and confirm that this method will do what you want it to, and resolve the problem you're experiencing.

-JD.

[GlendaRegpala]

Thanks Justin for your reply, fortunately we are not using full text indexer.   

My main dilemma is whether to upgrade from 8.5.0.5 to 8.5.0.7 or go to 9.0.0.1.   We are experiencing issues with 8.5.0.5 (slow response/queueing effect with TSM) and I saw one of your posts regarding this version as well... so we'd like to get out of the version 8.5.0.5.   But the question is where to go    On the PMR I opened, IBM recommended going to 8.5.0.7, so I asked the question why not 9.0 and they said, they normally recommend the latest Fix Pack, but would encourage getting to the latest version, which is 9.0.

Does anyone have opinions on going one way or another (basically 8.5.0.7 or 9.0.0.1..... currently 8.5.0.5)?  We're ok on the requirements for both and don't need the new features of 9.0.   I'm more inclined to going to 8.5.0.7 but if the effort is the same, it might be better to go to latest version... but not sure if it might introduce more issues.   
 
Thank you!

[Alessandro Perucchi]

Hello Glenda,

I've performed on Tuesday an upgrade from CMOD V8.3 (7.1.2.2) to CMOD 9.0.0.2. without problems.

Meaning that you can without trouble go from 8.5.0.5 to 9.0.0.2 directly.

Of course, you need to test it, etc... but you shouldn't find any problems.

And concerning your missing table, my only advice would be to do a "arsdb -uv", if the tables are already there, then it does nothing, if they are missing, then it will add them.
If you have any doubt about the output (which can be scary :-D), you can send me or us, the output, and I will tell you if it is ok or not... After seeing more than 20-30 upgrades of CMOD 8.3/8-4/8.5 -> 8.5/9.0... I'm seen many strange things sometimes!! :-)

Sincerely yours,
Alessandro

[GlendaRegpala]

Thanks Alessandro for the feedback... it's good to know that you didn't have issues with 9.0!   

[johnnoel]

Hi Glenda,

I apologize. I am only now seeing your question. I have to check my settings because I didn't get a notification (I thought I remembered somewhere such a setting.)

Anyway..... we are upgraded to 9.0.0.1 in DEV and INT, but not PROD yet. We are still working through several challenges with our large PROD database and moving to a new server since this version requires 2008 64 bit server and previous version was on 2003 Server.

My main issue now is that the ARSLOAD command seems to have changed from the previous 8.4 version we are on. It doesn't work as is and I am still trying to figure it out.

[GlendaRegpala]

Thanks John for the feedback.   Our management decided to only install the fix pack for now - 8.5.0.5 to 8.5.0.7 - to fix the queueing effect that we get on 8.5.0.5.    We will hold off on the upgrade to V9....glad you mentioned the ARSLOAD issue, we need to make sure we look at this when we start analysis for V9 upgrade.

Just want to clarify - you said that you are having issue with the ARSLOAD command which was from 8.4 version.   I thought you were upgrading from 8.5 to 9.0.       

[Alessandro Perucchi]

Well I have found one thing with ARSLOAD and CMOD V9.

For what I discovered, the famous way to store password with the arsload.cfg file does not work anymore.
And I had some customer that was using it quite extensively, so they changed everything to stash password, and it was resolved.

Well as John said in another post, the order of the arsload parameter might have some importance...

One big thing, that I've discovered with some pain...

You have in nearly all CMOD 9.0 commands the option -1 and -2 for tracing purposes...
They tell you that you can use -2 to set the level of tracing that you want... but maybe I was blind, but no explanation on how to choose the level.

So if you need to follow the same logic as trace.settings... with ALL=<number>

Code: [Select]

Trace Levels (add together to form level)

ERROR     1
WARNING   2
INFO      4
FLOW      8         

example:   arsload .... -1 mylog.log -2 ALL=15


Sincerely yours,
Alessandro