Author: Syed Saad Ali
What’s the E-Business Suite Roadmap for Java?
Oracle E-Business Suite uses Java. When discussing EBS’s use of Java, it is important to distinguish between server-side vs. client-side certifications.
EBS+Java Combinations certified today
E-Business Suite 12.1 and 12.2 both require Java at the server tier as well as Java on the desktop client tier to run Forms-based content. As of today, we have certified:
- EBS 12.1 & 12.2 server tier: Java 6 and 7
- EBS 12.1 & 12.2 desktop client tier: Java 6, 7, 8
There are no plans to certify Java 8 with EBS 12.1 and 12.2 server-side components. Those EBS releases include Fusion Middleware components (e.g. Forms, Oracle HTTP) that are only compatible with Java 6 and 7, not Java 8. There are no plans to update those Fusion Middleware server-side components to be compatible with Java 8.
EBS+Java Certification Roadmap
Future releases of E-Business Suite are expected to continue to need Java on the server tier as well as Java on the client tier.
What is the outlook for desktop client browser support for Java?
Until recently, E-Business Suite’s Java-based content required a browser that supports Netscape Plug-in Application Programming Interface (NPAPI) plug-ins.
Some browsers are phasing out NPAPI plug-in support. Some browsers were released without NPAPI plug-in support. This prevents the Java plug-in from working.
E-Business Suite 12.1 and 12.2 now support Java Web Start (JWS), which launches Java-based content (e.g. Oracle Forms) from browsers that do not support Java plug-ins via NPAPI. Java Web Start in EBS works with:
- Microsoft Internet Explorer
- Microsoft Edge
- Firefox Rapid Release (32-bit and 64-bit)
- Firefox Extended Support Release (32-bit and 64-bit)
- Google Chrome
For more details about using JWS for EBS 12.1 and 12.2, see:
EBS+Java on the Desktop tier
We expect EBS 12.1 and 12.2 to be certified with desktop clients running Java 9 for Forms-based content. We expect that we will offer Java Web Start and Java Plug-in support with Java 9 for EBS 12.1 and 12.2. We have been testing EBS with Java 9 desktop client betas for years now and do not expect any compatibility issues when Java 9 is eventually released.
EBS+Java on the Server tier
We expect that a later version of Java (i.e. something higher than Java 7) will require a major new E-Business Suite release. This major new E-Business Suite release is expected to include later Fusion Middleware components that are compatible with later Java releases.
We are working on that major new EBS release right now. Since our R&D is still underway, it is a bit early to make any commitments about specific Java releases or specific Fusion Middleware components to be included in that EBS release.
When will the next major EBS release be available?
Oracle’s Revenue Recognition rules prohibit us from discussing certification and release dates, but you’re welcome to monitor or subscribe to this blog. I’ll post updates here as soon as soon as they’re available.
Disclaimer
The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decision. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.
Source: https://blogs.oracle.com/stevenchan/whats-the-e-business-suite-roadmap-for-java
Multi-tenant container database architecture in Oracle Database 12cr1
The Oracle Database 12c Release1 introduced the Oracle Multi-tenant architecture, which allowed consolidation of multiple pluggable databases (PDBs) together in a multi-tenant container database (CDB). Various PDBs store data in objects independently of other PDBs and are maintained separately. Because PDBs isolate data and operations, each PDB is a self-contained, fully functional traditional Oracle Database from an application point of view. However, from an operational point of view, a CDB is a database having a single set of background processes and a shared memory area (SGA); these are shared by all the PDBs in the CDB. This architecture eliminates replication overheads, making the most efficient use of available resources. Any existing pre-Oracle Database 12c database (non-CDB) can be simply adopted as a PDB without having to make any changes to the database or application. Consequently, by consolidating multiple non-CDBs as PDBs, administrators can manage many databases as one.
Containers in a CDB (Pre 12.2)
A container is a collection of schemas, objects, and related structures in a multitenant container database (CDB). Every CDB has the following containers:
- Root
Every CDB has one and only one CDB root container, also called the “CDB root” or simply “root”. The root container is named CDB$ROOT. While the root stores Oracle-supplied metadata and common users, it does not store user data. . All PDBs belong to the root.
- Seed PDB
Every CDB has one and only one seed PDB, named PDB$SEED, which is a system-supplied template for the creation of PDBs that support applications. Since the Seed PDB itself is not intended to support an application, objects cannot be added to or modified in it.
- User-created PDBs
Every CDB can have zero or more user-created PDBs. A user-created PDB, or simply “PDB”, is a user-created entity that contains the data and code specific to a particular application. Each PDB’s data is isolated in its own container. For example, sales and human resources applications can have their own dedicated PDBs.
The following figure shows a CDB CDB1 with four containers:
- The root (CDB$ROOT)
- The seed (PDB$SEED)
- User-created PDB PDB1 having its own dedicated application APP1
- User-created PDB PDB2 having its own dedicated application SALES
Limitations in Oracle 12cR1
Although Oracle 12cR1 Multi-tenant allowed database administrators to manage many databases as one by consolidating them as PDBs in a multi-tenant CDB, the same did not hold true for application administrators. In Oracle 12cR1, common objects exist in Oracle-supplied schemas in the CDB root only. If multiple PDBs shared an application, there was no provision for a single master definition of the application on top of PDBs. For example, let us say there are four user-created PDBs (PDB_North, PDB_South, PDB_East, and PDB_West) representing databases of regional offices of the same organization, each using the same application SALES.
In such a case, a full copy of the database components of the application must be stored individually in each PDB. Also, an application upgrade script must be run on each tenant PDB individually. Hence, the need to extend the benefits of managing many as one to the application administrator.
Application containers
Oracle Database 12.2 introduces the concept of Multi-tenant Application Containers that enable many PDBs to share application objects such as code, metadata, and data. As a result, application administrators can now efficiently manage many application PDBs as one in a single Application Container while securely isolating their individual customer-specific data. This capability is ideally suited for SaaS, franchise, and other applications that are typically shared across different constituents, but require secure isolation of each constituent’s data.
An application container is a special type of PDB that stores data for one or more user-created applications and shares application metadata and common data among various application PDBs contained within it. An application container has the following containers:
- Application root: Every application container has exactly one application-specific root container which is a hybrid between the CDB root and a PDB. Like a PDB, it belongs to the CDB root and shares descriptions of Oracle-supplied common objects in the CDB root. At the same time, it acts like a mini CDB root container that houses a master application definition containing common objects for one or more applications that are shared by application PDBs belonging to it. Such objects are not visible to the CDB root, other application roots, or PDBs that do not belong to the application root.
- Application PDBs: Every application container can have zero or more user-created application PDBs plugged into the application root. The master application definition stored in the application root is visible to all application PDBs within the application container. Local objects can be created in application PDBs outside of the application definition if needed. When changes are made to the application in the application root, individual tenant PDBs can synchronize with the new version on their own schedule.
- An application seed PDB: Every application container can have an optional application PDB tied to the application root that serves as a user-created template to create new application PDBs rapidly. Once an application definition has been installed in the Application Root, the Application Seed can be created, and thereafter new Application PDBs can be provisioned simply by cloning the Application Seed.
Containers in a CDB with Application Container(s) (12.2.0.1)
With the introduction of Application Containers, multi-tenant architecture has been revised as follows:
- There is only one CDB root (CDB$Root), and one CDB seed PDB (PDB$Seed) in a CDB.
- A CDB can have zero or more application containers.
- For every application container, there is always one application root PDB that serves as a repository for a master definition of an application back end.
- A CDB can have zero or more user created PDBs. A user created PDB can be:
- A Standard or Regular PDB – The same as in Oracle 12cR1 PDB. It belongs to the CDB root container and can support one or more independent applications. It does not belong to an application container and hence cannot use common objects belonging to other applications.
- An Application PDB – Belongs to exactly one application container, wherein it is federated with other application PDBs sharing the same application(s) .
- An application seed PDB: An optional preconfigured user-created PDB template belonging to exactly one application container.
The following figure shows a CDB CDB1 with an Application Container. In this variation, CDB1 has following containers:
- The CDB root (CDB$ROOT)
- The CDB seed (PDB$SEED)
- A user-created regular PDB PDB1 supporting its own dedicated application APP1. It does not belong to an application container.
- An application container for the SALESapplication. It contains:
- An Application Root PDB (APP_ROOT): It stores common objects for the SALES application; e.g., the structure of the table used to store customer information
- Four application PDBs (PDB_North, PDB_South, PDB_East, PDB_West): Databases supporting the SALESapplication for various regional offices of an organization. While sharing the structure of the customers table stored in the Application Root, they can store region specific customer data in the table.
- An Application Seed PDB (APP_ROOT$SEED): A user-created PDB template used to create new application PDBs rapidly.
In the above example, an Application Container has been used for a company that builds and maintains a sales application that is used by its various regional offices. The structure of the information about its customers is consistent across all regions and hence is stored in the Application Root. Since each office has different customers and therefore different customer data, there is a separate application PDB for each regional office. A metadata-linked table is used to store customer information so that structure of the table is the same in each application PDB, but the customer data is different.
Application Containers: Other Features
- Application Master: With the introduction of application containers, a master application definition can be installed just once in the Application Root in an Application Container. It is visible to all application PDBs within the application container.
- Application Maintenance: Since there is only one master copy of the application, maintenance operations (such as applying an application patch) need to be performed in the Application Root once only and a new master definition will propagate to individual tenant PDBs after they have synchronized with the new version. Since individual Application PDBs can choose to synchronize on their own schedule, the impact of application upgrade is restricted merely to the tenants being upgraded and a business-wide upgrade can be performed in a phased manner, leading to a much more agile application development process .
- Rapid Provisioning: An application PDB can be provisioned instantly by several methods:
- By cloning a CDB Seed
- By cloning an Application seed PDB defined in the application container
- By cloning an Application PDB defined in the application container
- By unplugging/plugging, or cloning local and remote regular PDBs to join an application container
- Application Root Replica: A particular application can be installed in several application containers by creating copies of the master application root, called application root replicas, in the same or different (even remote) CDBs. Using proxy-PDB, changes in the master application root can be propagated to its replicas in different CDBs.
- Reporting: Queries can be executed across the application PDBs
- Within a CDB
- Across CDBs.
- Application Versions: Different applications tagged with distinct application names and application versions can be installed in an application container.
Use Cases for Application Containers
- Applications with a high density of customers: Similar types of customers using the same application can be are grouped within an application container.
- Logical Data Warehouse: Dimension tables can be created in the application root while the fact table is logically partitioned across multiple application PDBs based on some partitioning key (e.g. region). As a result, ETLs can be efficiently performed for every region without any impact on one another. Moreover, a query executed across the application PDBs can effectively prune the partitions, and therefore the application PDBs, based on the key that is passed to it.
Application Container Views
The following views give information about applications. They can be queried from the application root container and in some cases the application container PDBs.
- DBA_APPLICATIONS – Provides information about the applications in the current application container.
- DBA_APP_PDB_STATUS – Provides information about applications in all the application PDBs in the current application container. This view can be used to show which version of an application has been synced to which application PDBs.
- DBA_APP_VERSIONS – Displays information about all application versions installed in an application container.
- DBA_APP_ERRORS – Describes all application error messages in the application container.
- DBA_APP_PATCHES – Describes all the application patches in the Application Container.
- DBA_APP_STATEMENTS – Describes all statements from all the applications in the Application Container.
Best Practices For Migrating Oracle Database To Oracle’s Database Cloud Service
By: Edgar Haren
When Oracle set out to create our PaaS cloud, more specifically the Database Cloud Service, a particular element was at the forefront. The software in the cloud had to be the same software that our customers are using on premises. There had to be no difference whatsoever. The same tools, skills and software you use to manage, monitor and tune your on-premises databases had to seamlessly and transparently move between platforms. A DBA should be able to monitor a cloud database just as they would with an on premises database with no exceptions. Oracle’s database cloud enables you to create an enterprise class, highly available database in less than an hour, and manage this database just as you would on premises.
With this same software in the cloud as on premises paradigm, Oracle’s Database cloud allows migration and data loading with the ease you are familiar with. To start, all Oracle Database Enterprise Cloud Service instances give you access to the operating system as well as SQL*Net access. This enables users and systems with the correct access to stage and load data into the database using multiple methods. SQL*Loader is the most basic, allowing data loading from a local file or via SQL*Net.
The original database export and import utility can be used today to move on-premises databases into the cloud
Superseding import/export in Oracle 10gR1 was data pump. Oracle Data Pump enables very high-speed movement of data and metadata from one database to another, much faster than the original import/export tools. As for data pump, features such as exporting and importing over a network and the ability to restart jobs help to make this a perfect fit for moving data to the Oracle Cloud. Other features such as the ability to estimate how much space an export job would consume without actually performing the export will help on cost estimates for purchasing cloud storage.
If the source database is an 8i or greater database, then transportable tablespaces give you a very fast method for moving your database to the cloud, all you need to do is move the metadata and the datafile. Also Starting with Oracle9i, the transported tablespaces are not required to be of the same block size as the destination database, helping with the migration process.
Another important aspect of transportable tablespaces is that you can migrate across OS platforms. To check on what platforms you can migrate to, in your database check the V$TRANSPORTABLE_PLATFORM table. The V$TRANSPORTABLE_PLATFORM view lets you see the platforms that are supported and to determine each platform’s endian format. What is endianness? It’s the way computers store multibyte data-types. Think of it this way; If the platform is Big endian, it will store the number 2134 as 2134. On a little endian platform, it will store it as 4312. This is simplifying it a bit, but you can see the basic issue we have. If the source and cloud database endianness match, then you can move the tablespaces to the cloud platform with no conversion necessary. If the endianness does not match, then an additional step is required. You can perform this step on the source or cloud database to convert the tablespace being transported to the target endian format. Doc ID 371556.1 on support.oracle.com will guide you through this process. Also remember, when using transportable tablespaces, the source and the target databases must use compatible database character sets and source and the target databases must use compatible national character sets.
With the latest cloud release, we can now create databases from a customers’ on premises backup with a single click. The Oracle Database cloud now includes a feature to create or replace an existing database with a backup from our database backup service. Just tell the UI where the backup lives and the cloud takes care of the rest. The database will be created, then replaced with that backup from the cloud. This jumpstarts many use cases such as disaster recovery in the cloud using Data Guard as well as a test/development environment from a backup of production which is on premises.
The last method of migrating to the cloud we will discuss in this article is moving PDBs. With 12c, Oracle introduced the concept of a multitenant architecture allowing database to function as a multitenant container database (CDB). Within this CDB, we can have one, zero, or multiple pluggable databases (PDBs). The multitenant feature represents one of the biggest architectural changes in the Oracle Database. This grouping of multiple PDBs into a single CDB allows us to manage, patch, upgrade and backup all of our databases as a single unit allowing us to consolidate multiple databases into one.
So how does the Oracle Cloud utilize the multitenant feature? To start, built right into Oracle SQL Developer is the ability to move local PDBs straight into the Oracle Cloud. As long as that PDB is on the same instance as SQL Developer, we can unplug, copy and plug that PDB into a cloud 12c database with a single click of a button. This is a great way to move development and test instances into the cloud quickly and easily.
With Enterprise Manager 12cR5 and 13c, we can do even more with PDBs and the Oracle Cloud. Enterprise Manager (EM) has the facilities to remotely move any 12c PDB in your monitored fleet to the Oracle Cloud. Not only can we move these PDBs to the cloud, but we can also move from the cloud back to an on premises 12c database. Using the data masking and subsetting pack, EM will mask or scramble sensitive data as it is moved from an on premises PDB to the oracle cloud. Want an even quicker way to migrate PDBs? Use the PDB remote cloning feature to clone a PDB instantly over a database link.
Back to the original thought, seeing the software in the Oracle Database Cloud is the same as on premises, all the tools and features that existed in previous versions as well as current versions of the database will continue to work, no need to purchase anything extra or retrain on a cloud specific variant. And this this familiarity, we can leverage your existing skills and knowledge to make this migration to the Oracle Database Cloud even easier. For more information please take a look at the resources provided below.
Brian Spendolini
Senior Principal Product Manager
Resources:
- Oracle Database 12c Release 2 For The Cloud Topic Page – https://www.oracle.com/database/oracle-database-cloud/index.html
- Quick Q&A On Why You Should Move To Oracle Database Cloud – www.oracle.com/us/products/database/answer-to-database-cloud-questions-3304671.pdf.
- Infographic: Oracle Database In-Memory (DBIM) https://www.oracle.com/webfolder/s/delivery_production/docs/FY16h1/doc5/baORCL1503-Infographic-v14.pdf
- Oracle SQL Developer – http://www.oracle.com/technetwork/developer-tools/sql-developer/overview/index.html
- Oracle Database Cloud 30 Days Trial – http://www.oracle.com/webfolder/technetwork/tutorials/infographics/dbcs_trial_quickview/index.html
- Oracle Newsletters – http://www.oracle.com/us/syndication/subscribe/index.html
Check BI Publisher’s Health with BIP Analyzer for E-Business Suite
In addition to helping customers resolve issues via Service Requests, Oracle Support also builds over 60 free diagnostic tools for Oracle E-Business Suite 12.2, 12.0, 12.1, and 11i. These Support Analyzers are non-invasive scripts that run health-checks on your EBS environments. They look for common issues and generate standardized reports summarizing that provide solutions for known issues and recommendations on best practices.
Here’s an index to these tools:
Spotlight on BIP Analyzer
BI Publisher for EBS (BIP, previously called XML Publisher) is integrated into the E-Business Suite technology stack. The BIP Analyzer is available here:
- EBS BI Publisher (BIP) Analyzer (Note 2032715.1)
The BI Publisher Analyzer reviews BIP configurations and compares them against Oracle’s best practices. It provides troubleshooting advice for common issues, such as:
- Java Heap sizing
- OPP memory optimization
- Issues with threads and processes
- Out of Memory issues
This tool can be run manually or configured to run as a concurrent request, so it can be scheduled to be run periodically and included in regular Workflow Maintenance cycles.
Can this script be run against Production?
Yes. There is no DML in the Analyzer Script, so it is safe to run against Production instances to get an analysis of the environment for a specific instance. As always it is recommended to test all suggestions against a TEST instance before applying to Production.
Related Articles