We got many errors during installation for triggers/indexes/special chars in OBS etc. Now the error is about audits.
SQL error code: 4098
Error message: [CA Clarity][Oracle JDBC Driver][Oracle]ORA-04098: trigger 'AUDIT_OBS_ATTRIBUTES' is invalid and failed re-validation
Is there a simple way to turn off audits? Set a flag in the table or something?
I have a seen a few success stories with 14.2 upgrade. Could you please share your experience and tricks you used?
Can you see the below thread, myself and Nika_Hadzhikidi had suggested few workarounds. Do let us know how it goes.
That thread is very helpful. You suggested DB update solution, did you try that?
Do you strongly recommend turning off audits for each object in the UI or is Db update good enough?
Yes the database solution is tried across many upgrades and that does work, however he recommendations is to do it via UI. Let me know how the upgrade progress.
We moved a bit further with the upgrade, now the error is CODE not found in odf_view_sections. We are not sure which version added the code attribute 13.1?
I would need the install log to suggest further.
odf_view_sections.code was added in Clarity 13.1. There is a way to workaround an issue with the column if it's missing, but it's best if it happens through a Support issue, and providing all the logs and details.
So, since you seem to be hitting few subsequent issues, please feel free to open a Support issue so we can help with your upgrade.
Looking forward to hearing from you.
Principal Support Engineer
We overcome that issue. Upgrade skipped a 13.1 for some reason and we started fresh and we are able to upgrade to 13.2. Thank you!
We are able to upgrade to 13.3 now. Checkinstall for 14.2 detected a conflict with object code portfolio.
Please take the above object definitions along with instances backed up through XOG, and delete those objects from the system. Then manually update the Xogged out definitions to rename the object codes to non-conflicting codes, then Xog them back in.
DId you face this issue? If you did, how did you handle it?
If this checkinstall script: check-seeded-object-name-conflicts.xml failed, this is because there is a conflict in the object names. Basically this script checks for any custom objects with same names as seeded objects, since they can get completely overwritten during upgrades.
Now, the script runs this statement and it shows that there is result returned:
SELECT CODE objectcode FROM ODF_OBJECTS WHERE IS_CUSTOM = 1 AND CODE IN ( 'portfolio' )
This means that you have an object in Studio - Objects, named portfolio and marked as custom. If customers have truly custom objects with one of the reserved OOTB object code, they would have, as requested, to back it up with XOG, and rename it by deleting and XOGging back since it will get overwritten during the 14.2 upgrade.
However, since you are upgrading from 13.1, portfolio is an OOTB name of the object back then. If this is the case, something might have gone wrong with your upgrade so far: because the OOTB portfolio object gets completely deprecated during the install to 13.2, and replaced with pfm_portfolio instead. This doesn't seem to have happened. Did you encounter any errors during your 13.2 upgrade in install.log and admin.log?
To proceed further, I recommend you to raise a Support ticket, so you can provide all the logs and we ensure the objects are correctly upgraded. Trying to reset the object with a manual query can only be done after we at Support review it and approve as a solution for your exact situation; else it's unsupported.Also I am concerned this may have been caused by another prior upgrade issue so checking this together is the best way to proceed in my opinion.
Looking forward to your feedback.
that helped. We are moving forward with 14.2 install now ended up in a new error.
Our DBA checked and found view DWH_ESTIMATE_SIZE_V does not exists.
6/30/15 1:19 PM (Target) Target "perform-check" started.
6/30/15 1:19 PM (SQLTask) Failed to execute: SELECT ( SELECT SUM (s.BYTES) / (1024 * 1024 * 1024) FROM user_segments s) clarity_schemasize, (SELECT ESTIMATED_DWH_SIZE_IN_GB FROM DWH_ESTIMATE_SIZE_V) estimated_dwhsize FROM DUAL
6/30/15 1:19 PM (UnknownElement) Task "nsql" finished with error.
/cappm/install/checkinstall/scripts/check-estimated-dwh-schema-size.xml:28: java.sql.SQLSyntaxErrorException: [CA Clarity][Oracle JDBC Driver][Oracle]ORA-00942: table or view does not exist
DWH_ESTIMATE_SIZE_V is a view that gets introduced with Clarity 14.2 release, it was not existing in prior releases. The checkinstall script will check the size of DWH at the end of the upgrade during postcheck script. At this stage the view should already be in the database. Have you had any errors during the upgrade to 14.2? Please attach your full install.log for review or raise a Support ticket with the attachment and let me know.
Nika HadzhikidiCA TechnologiesPrincipal Support Engineer
Attached please find the install.log.
As I thought, your upgrade actually failed earlier that the error you indicated above. Here is the error message:
6/30/15 1:07 PM (ExecTask) Error Applying XOG: Failure occurred while applying JOB_ENABLE_CAPEX.xml6/30/15 1:07 PM (ExecTask) Check /cappm/clarity/logs/xog-seeddata/out/revmgr/JOB_ENABLE_CAPEX_out.xml for errors6/30/15 1:07 PM (ExecTask) ERROR: Upgrade failed for tenant 6/30/15 1:07 PM (ExecTask) /cappm/clarity/.setup/scripts/db.xml:2101: The following error occurred while executing this line:6/30/15 1:07 PM (ExecTask) /cappm/clarity/.setup/scripts/db.xml:2317: The following error occurred while executing this line:6/30/15 1:07 PM (ExecTask) /cappm/clarity/.setup/scripts/db.macros.xml:93: Java returned: 26/30/15 1:07 PM (ExecTask) at org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelper.java:551)6/30/15 1:07 PM (ExecTask) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:444)6/30/15 1:07 PM (ExecTask) at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)6/30/15 1:07 PM (ExecTask) at com.niku.tools.taskdefs.xpath.Iter.executeTarget(Iter.java:294)6/30/15 1:07 PM (ExecTask) at com.niku.tools.taskdefs.xpath.Iter.execute(Iter.java:189)
We will have to redo the upgrade so you can go ahead and order the rollback to 13.3. for now. Before running another upgrade, we have to see what we have to correct, please provide the file cappm/clarity/logs/xog-seeddata/out/revmgr/JOB_ENABLE_CAPEX_out.xml for review and I'll advise.
Nika HadzhikidiCA TechnologiesPrincipal Support Engineer
I have attached the file.
Please can you check with your DBA what happens if you run this statement:
select INVESTMENT_ID, STATUS from TEMP_CAPEX_ENABLED_INVESTMENTS
Is the table in the database?
The table is there but very different from other 13.3 db.
This is what we have
Name Null Type
------------------- -------- --------------
BP_MIGRATION_STATUS NOT NULL VARCHAR2(1)
This is from another 13.3 instance not part of 14.2 upgrade
INVESTMENT_ID NOT NULL NUMBER
INVESTMENT_CODE NOT NULL VARCHAR2(60)
STATUS NOT NULL VARCHAR2(1)
CP_MIGRATION_STATUS NOT NULL VARCHAR2(1)
Can you rollback to 13.3 since we have to do it anyways, and see if the table is having the issue there? Post all the columns from the table here once done.
Also, can you upload your other install logs prior to 13.3 for review?
OK, we will revert to 13.3 and start over.
Sounds good : before starting the upgrade can you please check the table and let me know the output of describe as above? Thanks Rajani.
We reverted back to 13.3 and ran checkinstall. We see a discrepancy with the table structure TEMP_CAPEX_ENABLED_INVESTMENTS. This is supposed to have 22 columns and we have only 15. Checkinstall is complaining about a column in this table.
ERROR from Checkinstall ....
We are not sure how bad is our 13.3 install. There were compile errors and we dropped the following. These are system stuff and we were not sure how to fix the compile errors. We had a ticket with CA and CA Support Darryl Reed could not provide us an answer to this. Now we are wondering deletion of this table and indexes might have caused the issue with TEMP_CAPEX_ENABLED_INVESTMENTS table.
Drop table ODF_CA_PROJFINPROPERTIES;
Drop index ODF_CA_PROJFINPROPERTIES_GN2;
Drop index ODF_CA_FINANCIALS_GN1;
Drop index ODF_CA_INV_GN1;
Drop index ODF_CA_PROJECT_GN1;
Drop index ODF_CA_PROJFINPROPERTIES_GN1;
13.3 is running OK but we are not sure how bad it is with incorrect system tables.
Please advice next steps.
You definitely shouldn't have dropped any OOTB tables or indexes without our approval. I would suggest you revert all the way to initial environment, and we will guide you to finish you upgrade.
I could see you opened a support case : I'll review and advise.
Ok Thank you, we reverted back to 13.0 and waiting on CA’s response before we proceed.
We were working with CA on the upgrade and asked the same question on how to deal with this issue and did not get a response. We just gave it a short taking the risk in dev.
Sure Rajani : I just sent you the solution on your case. We'll keep working with you on your CA Support case.
When 14.2 failed with this error, we reverted back to 13.0 and tried the install to 13.3 fresh and it resulted in the index error.
When we encountered the error on indexes, we contacted you.
Clarity status is failed to upgrade from 13.0 to 13.3.
Our question is, can we deal with the indexes per your instructions and proceed to 13.3 or do we need to go back to 13.0?
The reason for asking this question is we thought the install was skipping 13.1 and going to 13.2.
Technology Tools and Services
Clarity Links: SharePoint site<http://cto.mckesson.com/tools/clarity/default.aspx>; Support tickets<http://remedyweb.mckesson.com/ppm>
Rally Links: SharePoint site<http://cto.mckesson.com/tools/rally/default.aspx>; Support tickets<http://remedyweb.mckesson.com/rally>
Please revert back to 13.0, since this error failed your current upgrade to 13.3, and there is no way to resume the install from this point. Then apply the instructions on workarounding the Indexes error, also the audit workaround, and portfolio workaround that we discussed above, and run the upgrade again.
Please let me know how it goes.
Hi - just a comment ; doesn't this conversation all really belong in the support-call rather than a community discussion?
I do recognise the benefit of "problems in my upgrade" discussion threads, but once the specific issues with an upgrade are being handled by a support call, then surely seemingly duplicating those support-call discussions in the community could easily lead to confusion (in the support call) as the discussion appears to be currently happening in 2 places - I would suggest that important information in resolving the problem could be overlooked/lost ?
Please don't take this comment as me having a moan about this ; I'm quite happy for you (both the customer and CA support) to carry on discussing this on the community ; I am just suggesting that the better option for resolving this problem would be just in the support-call - perhaps updating this community discussion when the call is resolved saying "CA Support fixed my problem ; it was nasty!"
Good luck anyway!
Agreed, we will keep the work on this on the Support case. Rajani : please let's work on the Support case only from now on.
Principal Support Engineer