So some of you may remember that i attempted to upgrade from 12.1.0.5 to 13cR1 a couple of months back which went pretty badly - see here
I've finally got round to trying this again last night.....
And guess what i had yet more issues - in fact it looked at one point it was a total disaster but i pulled it back from the brink.
Initially things went well and all the issues i covered in my previous post were fine - then on the repository upgrade section i hit this
ORA-39726: unsupported add/drop column operation on compressed tables
ORA-06512: at line 12
File:/oracle/cc13c/sysman/admin/emdrep/sql/core/12.2.0.0/gccompliance/gccompliance_tables.sql
Statement:DECLARE
COLUMN_EXISTS EXCEPTION;
PRAGMA EXCEPTION_INIT(COLUMN_EXISTS, -01430);
BEGIN
EXECUTE IMMEDIATE 'ALTER TABLE EM_RULE_E ADD (' ||
' IS_PATCH_RULE NUMBER(1,0) DEFAULT 0) ';
EXCEPTION
WHEN COLUMN_EXISTS THEN
-- In case if this column has already applied via any patch, then ignore it.
NULL;
WHEN OTHERS THEN
RAISE;
END;
Now this was eerily familiar from when i did the 12.1.0.5 patch previously - the issue there was database compatible was set to 11.2 in a 12.1 database and the feature to allow modifying compressed tables wasn't activated.
In this case though i'm already at 12.1 so why isn't it working?
Well the problem is the default value - that isn't supported when adding columns on compressed tables (and actually why is all this damn stuff compressed - i didn't do that - seems cloud control is using it itself).
So what to do....
well the retry option is there but i'll get the same error again - so i need to do this fix (which will work as i can see the code block has a check that the column isn't already there).
SQL> alter table sysman.em_rule_e nocompress;
SQL> alter table sysman.em_rule_e move;
SQL> alter index sysman.EM_RULE_PK rebuild;
SQL> alter index sysman.SYS_C0057798 rebuild;
SQL> alter index sysman.EM_RULE_U1 rebuild;
Then i try again and get past this and again all is well til my nemesis the BI publisher gets on the scene - this just falls over in a heap with no helpful message at all - however as i don't want it and the only thing after it is to start the OMS i decided to just ignore the failure and carry on.
However when i try and start the OMS it hangs for ages and then fails to start
aaaargh
After some digging (and you don;t want this to happen late in the night let me tell you) i discovered that somehow there was a port conflict and httpd wouldn't start - 7788 was in use. However lsof shows it not in use - so what the hell is going on?
I was rapidly running out of ideas but decided to try and change the http port to something else to see what that would do - to do that i followed this note
https://support.oracle.com/epmos/faces/DocumentDisplay?id=2096928.1
Then i tried to start OMS - crossing all fingers - and to my amazement it actually worked!
After it was up i thought right whats using the 7788 port - a quick check showed it was the httpd daemon from cloud control - wtf!
Digging deeper it seems that somehow the BIP http port is the same as the console http port and that conflict is what has messed up the BI install and the OMS starting up.
At this point i thought i'd just change the BI port config completely somehow - trying to do this however and i fell at the first hurdle - the weblogic admin form would not work so i decided to just leave it alone and release the system to the users - all be it with a new url.
Still don't know how this port conflict came about - it's not something i did as far as i know - perhaps again its some legacy from being 12.1.0.1 originally who knows.
Anyway it's now working - i'll deal with the problem later when i come to do 13cR2 which came up during my upgrade cycle but i didn't want to change half way through.
Comments
Post a Comment