Hi Alessandro
I think you are missing the point
Why should you restore old Ars%-tables? If you cant keep them in synch with your other tables of the loaded data in all your appl.groups?
Who would like to be in a situation where the data you have is not correct?
You could find yourself in a situation where you have data in OAM, indextables where that data is not in the ARS-tables.
I mean...
1) You stop CMOD
2) You do the system table backup + Full Backup of the segment tables
3) You do the upgrade
4) You start CMOD
5) You test if it works
6) It works, then you open for production. Finished.
7) It doesn't work, then stop CMOD
8 ) restore the system tables and possibly the impacted segment tables
9) be sure to use the old SW
10) start CMOD with the old binary version
If you go that way, you won't have any problems. I've done it countless of time with customer where we had some issues.
And depending on the tests, you might need also to restore some segment tables, because of the archived documents that was used during the tests of functionality.
In that case I would advise to do test in a dummy AG, which is not important if the restore makes it not in sync with the restored info from the system tables.
Of course, if after X days you see that it doesn't work... then yeah... both the segment and system table are not in sync anymore and you have a problem. And I agree with you, this is not something that one wants. Not at all.
Downgrading is not a light operation, and during the changes of version with CMOD, there were lot of time that the changes were so profound that a downgrade was simply impossible.
And a restore was the only way. Today the changes are not anymore that deep as in the V7.X and V8.X versions, but still sometimes they are still some modification here and there.
And to be honnest, I know very little product in the market that allow a downgrade without doing some kind of restore.
So I understand your personal thoughts... but I wonder what else could IBM do in that area... because some upgrades are not reversible.
Maybe doing more tests in your test system, to ensure that your prod will be not impacted with some issues?
But that's not IBM work, it is more on your side.
For my part, I am more in the side to do backup and restore. And if after a few days something is really wrong, since I tried to keep all the input data that is archived in CMOD for at least 1 week. If I need to restore something, then I can restore the DB, and reload everything between the moment of the last backup.
Call me paranoid... but I am never expecting a magical solution from vendors in a timely manner. IBM or not IBM.
If I can wait, then ok, but if that is not a possibility, then I have my safety bag.
And of course, then there is a SLA issue, but better that, than keeping with a unsolvable situation that is going worse and worse with time.
What I did many times, was to clone the production database in a test environment, remove the Storage Set/Node dependencies by setting in the local cache, or a test storage which is like Prod. And do my tests there with all the documents type that we load. And since we keep at least 1 week of input files from production, we can test all the possible scenarios.
Especially if we are not sure of the results of the upgrade.
That way we learn if everything is as we expect, and if not, we don't do the upgrade in prod until we have a fix from IBM or internal teams for some custom code.
