OAUG Upgrade SIG meeting recap
Sunday, October 25, 2016
Business portion of meeting:
- SIG Objective
- Board members
- Open position
Upgrade Panel Q&A:
Introduction of panel members:
Sandra Vucinic - VLAD Group: Moderator, Art Dowd – O2Works, James Morrow – BlueStone Solutions Group, Susan Behn - Infosemantics, Mike Brown – BlueStar, Marvin Sanchez – Pharmavite and Bill Dunham – OATC.
Q&A discussion Recap:
1. A customer with a 21 year old database and is running 12.1.3 but has hard coded foundation schema names. They are adamant that they do not want to re-implement but understand that 12.2.x requires the use of synonyms in online patching.
There was a discussion of the issue, and Oracle representatives revealed that a meeting was set for Tuesday to work with these customers and hopefully provide Oracle with a scrambled copy of the database in order for Oracle to test solutions. Oracle had anticipated this issue while developing 12.2 and may be able to assist with solving it. At present, though, they lack an example to test on.
2. While upgrading from 12.1.3 to 12.2.4, a customer is experiencing problems with custom code and is concerned that they may need to re-name DB tables.
This elicited an extended discussion about 12.2.X customization basics. There should be no need to re-name DB tables. By using the readiness reports mentioned in Oracle E-Business Suite Release 12.2: Online Patching FAQ (Doc ID 1583902.1) customers will be alerted to the non-compliant custom code that will need to be addressed in the upgrade. The three related utilities are:
- Online Patching Enablement Readiness Report checks the system's 12.2.x preparedness. (Doc ID 1531121.1)
- Online Patching Database Compliance Checker (ADZDDBCC.sql), which reports database objects standards violations.
- Global Standards Compliance Checker (gscc.pl), which scans the file system for source files that violate the standards.
3. A customer who is currently on R12.1.3 applications and uses Oracle Internet Directory with Oracle Single Sign-on 10g. They are upgrading to 12.2.4 and Oracle Access Manager and running into issues. The question was whether there were other customers going through this.
The answer from an Oracle representative is that the upgrade from OID with SSO to OAM is necessary and a significant project by itself, and should be accounted for in the planning process.
4. A manufacturing customer who is in the process of upgrading to 12.2.4 asked if they should be testing the interim state of the Run database at the point when the upgrade is triggered. Their concern was that the first step of the 12.2 patch cycle is to create a copy of the Run database and they felt that constituted a change to the database. As such, they felt it should be tested as part of the testing process.
There was a long, multi-faceted discussion about how R12.2 live patching works and it resulted in 2 key take-aways: 1.) Additional test cases should be introduced in order to evaluate the server load and performance while patching is occurring. 2.) There should be no need to test the newly created Patch database at the outset of Prepare step because it is a snapshot copy of the existing Run database and should not change.
A secondary discussion broke out over whether R12.2 live patching was certifiable for FDA purposes for manufacturing organizations that needed FDA certification. Based on the discussion, the assumption was that R12.2 patching could be configured in such a way that it would be acceptable for FDA requirements. That has not been confirmed.
5. A question submitted prior to the panel was addressed. The question was: Is it possible to upgrade from an EBS on-premise instance to an Oracle cloud application.
Because of the architectural differences in the current on-premise applications that have customizations and the Oracle Cloud SaaS offerings, the answer is NO. There is no upgrade path from a current customized on-premise, EBS application to the Oracle Fusion / Cloud applications. It requires a re-implementation. Cloud customers have no direct access to the Software as a Service (SaaS) applications that run on Oracle cloud servers. Customizations must be addressed through the use of the Oracle Platform as a Service (PaaS). This will require a re-implementation for customer looking to move their on-premise ERP applications to the Oracle SaaS cloud.
The EBS case discussed above (moving from on-premise EBS applications to the Oracle Cloud SaaS applications) is different from an organization that is currently hosted by Oracle On-Demand (or another EBS hosting vendor) and wants to upgrade. There is no restriction there.
The key point is that there is no on-premise or hosted EBS environment to Oracle SaaS upgrade path. Movement from on-premise EBS to Cloud Software as a Service (SaaS) will require re-architecting and re-implementing the current EBS environment. While demonstrations showing the relocation of an Oracle database from an “on-premise” database to the Oracle Cloud are relevant in some circumstances, they are not applicable for complex on-premise E-Business Suite (EBS) environments running Oracle applications.