Database Consultant (Passionate about Database & Cloud Technologies)

Database Architect,Core DBA ,APPSDBA,Mysql DBA,MongoDB,PostgreSQL,MariaDB,Installations,Upgrades on all Flavors of UNIX (LINUX,SOLARIS,HP(AIX)). Oracle E-Business Suite R12 (Upgrades,Patching,Cloning) AWS upgrades and implementation expert. OCI (Oracle Cloud Infrastructure) Architect, Exadata (Oracle Database Exadata Cloud at Customer(Exacc)),Superclusters ,Autonomous Databases, AWS RDS Customs , Sql Tuning Expert. ***Never Stop sharing,Learning and Growing***

Tuesday, December 27, 2022

Migrating Oracle to AWS

Migrating Oracle to AWS

Very good article and Presentation BY Daniel

■ Gather stats

■ Migrate data to RDS

■ Monitoring

Presentation - Migrating Oracle to AWS

Sunday, December 25, 2022

AMAZON WEB SERVICES EC2

Amazon Elastic Compute Cloud (Amazon EC2)

provides secure, resizable compute capacity in the cloud as Amazon EC2 instances.

Imagine you are responsible for the architecture of your company's resources and need to support new websites. With traditional on-premises resources, you have to do the following:

Spend money upfront to purchase hardware.
Wait for the servers to be delivered to you.
Install the servers in your physical data center.
Make all the necessary configurations.

By comparison, with an Amazon EC2 instance you can use a virtual server to run applications in the AWS Cloud.

You can provision and launch an Amazon EC2 instance within minutes.
You can stop using it when you have finished running a workload.
You pay only for the compute time you use when an instance is running, not when it is stopped or terminated.
You can save costs by paying only for server capacity that you need or want.

Types Of EC2 Instances and Their Uses Cases

1. General Purpose Instances:

Balance of Compute, Memory and Networking Resources
and can be used for a variety of workloads.

Series: A (Arm Ecosystem), M & T

USES:
* A- Webserver, Containerized Micro Services, Caching Fleets
* M- Gaming Server
* T- Website and Webapp, Code Repo

2. Compute Optimize Instance:

Ideal for compute bound application (Banking applications) that benefit from high performance processors. (Processing Thousands of requests at a particular point of time)

Series: C (C4, C5)

USES:
* C4- Batch Processing, Video Editing
* C5- High Performance Web Servers, Gaming

3. Memory Optimized Instance:

* High performance relational and NoSQL databases.
* Well suited for Memory Intensive Enterprise Application and SAP HANA (High performance Analytic Appliance)

Series: R, X & Z

USES:

* R- Financial Services, Hadoop
* X and Z- Electronic Design Automation

4. Storage Optimized Instances:

Designed for workloads that require high, sequential read and write access to very large datasets on local storage.

Series: I, D & H

USES:
* I- Data Warehousing Application, OLTP
* D- Massive Parallel Processing Data Warehouse
* H- Data-intensive workloads such as MapReduce and distributed file systems

5. Accelerated Computing Instance:

Uses hardware accelerators and co-processors to perform same functions such as floating-point number calculation, graphic processing or data pattern matching more efficiently than it is possible in software running on CPUs.

Series: P, G & F (FPGA)

USES:
* P- Machine Learning, Seismic analysis
* G- Video Creation Services, 3D Visualization
* F- Genomics Research, Financial Analytics

6. High Memory Instance:

Purpose built to run large - in - memory databases including production developments of SAP HANA in the cloud.

Series: U

USES:
* U- Reducing the management overhead associated with complex networking and ensuring predictable performance.

Wednesday, December 21, 2022

Amazon RDS Reserved Instances

Amazon RDS Reserved Instances give you the option to reserve a DB instance for a one or three year term and in turn receive a significant discount compared to the On-Demand Instance pricing for the DB instance.
You can choose between three payment options when you purchase a Reserved Instance. With the All Upfront option, you pay for the entire Reserved Instance with one upfront payment. This option provides you with the largest discount compared to On-Demand Instance pricing. With the Partial Upfront option, you make a low upfront payment and are then charged a discounted hourly rate for the instance for the duration of the Reserved Instance term. The No Upfront option does not require any upfront payment and provides a discounted hourly rate for the duration of the term.
All Reserved Instance types are available for Aurora, MySQL, MariaDB, PostgreSQL, Oracle and SQL Server database engines.

Features

Reserved Instances provide three payment options: All Upfront, Partial Upfront, and No Upfront.
Reserved Instances can save you up to 69% over On-Demand rates when used in steady state.
Reserved Instances require no change to how you use Amazon RDS. When computing your bill, our system will automatically apply Reserved Instance rates first to minimize your costs. An instance hour will only be charged at the On-Demand rate when the total number of instances you run that hour exceeds the number of applicable Reserved Instances you own.
Reserved Instances for the MySQL, MariaDB, PostgreSQL, and Amazon Aurora database engines as well as the “Bring your own license” (BYOL) edition of the Oracle database engine offer instance size flexibility.
All Upfront and Partial Upfront Reserved Instances can be purchased for one or three year terms, while No Upfront Reserved Instances are only available for one year term.
Reserved Instances are available in all the AWS regions.
Reserved Instances are available for all supported DB Engines.
Pricing for Reserved Instances is available on the Amazon RDS Pricing page.

When Should You Purchase Reserved Instances?

Reserved Instances are a great option for the steady state use case. Most production applications require database servers to be available 24×7. Reserved Instances could provide your business substantial savings if you currently use On-Demand DB instances for your production applications.

Reserved Instances can also provide significant cost savings for mission critical applications that run on Multi-AZ database deployments for higher availability and data durability.

You can determine whether Reserved or On-Demand DB Instances best fit your needs by comparing On-Demand hourly rates and the effective hourly rate of Reserved Instances. In order to calculate an effective hourly rate, amortize the one-time fee over the term and add the hourly usage rate.

Reserved Instance Payment Options

No Upfront RIs – No Upfront RIs offer a significant discount (typically about 30%) compared to On-Demand prices. You pay nothing upfront but commit to pay for the Reserved Instance over the course of the Reserved Instance term. This option is offered with a one year term.

Partial Upfront RIs – Partial Upfront RIs offer a higher discount than No Upfront RIs (typically about 60% for a 3 year term). You pay for a portion of the Reserved Instance upfront, and then pay for the remainder over the course of the one or three year term. This option balances the RI payments between upfront and hourly.

All Upfront RIs – All Upfront RIs offer the highest discount of all of the RI payment options (typically about 63% for a 3 year term). You pay for the entire Reserved Instance term (one or three years) with one upfront payment and get the best effective hourly price when compared to running the same DB instance on an On-Demand basis.

How Billing Works

During billing, running DB instance usage is first compared to your active Reserved Instances to minimize costs. Each hour, if the amount of running instances is less than or equal to the total Reserved Instances you have purchased, all running DB instances will be charged at the Reserved Instance rate. Any usage of running DB instances that exceeds the amount of applicable Reserved Instances you have purchased will be charged the On-Demand rate.

For example, if you own 3 Reserved Instances with the same database engine and instance type (or instance family, if size flexibility applies) in a given region, the billing system checks each hour to see how many total instances you have running that match those parameters. If it is 3 or less, you will be charged the Reserved Instance rate for each instance running that hour. If more than 3 are running, you will be charged the On-Demand rate for the additional instances.

If you purchase a Reserved Instance in a given region where you have a applicable running DB instance, the benefit will automatically be applied to that instance moving forward.

Reserved Instance Size Flexibility

Amazon RDS Reserved Instances provide size flexibility for the MySQL, MariaDB, PostgreSQL, and Amazon Aurora database engines as well as the “Bring your own license” (BYOL) edition of the Oracle database engine. With size flexibility, your RI’s discounted rate will automatically apply to usage of any size in the instance family (using the same database engine). Size flexibility does not apply to Microsoft SQL Server and the License Included (LI) edition of Oracle.

For example, let’s say you purchased a db.m4.2xlarge MySQL RI in US East (N. Virginia). The discounted rate of this RI can automatically apply to 2 db.m4.xlarge MySQL instances without you needing to do anything.

The RI discounted rate will also apply to usage to both Single-AZ and Multi-AZ configurations for the same database engine and instance family. For example, let’s say you purchased a db.r3.large PostgreSQL Single-AZ RI in EU (Frankfurt). The discounted rate of this RI can automatically apply to 50% of the usage of a db.r3.large PostgreSQL Multi-AZ instance in the same region.

How To Purchase Reserved Instances

Reserved Instances can be purchased using the AWS Management Console, AWS CLI or AWS API.

AWS Management Console

Log in to the AWS Management Console, select "RDS" under "Databases".
Ensure you have selected the Region in which you would like to make your Reserved Instance purchases.
Select “Reserved instances” in the navigation pane and click on the “Purchase Reserved DB Instance” button.
Select the database engine, DB instance class, offering type and the term length. You can also enter an optional ID for your purchase.
Adjust the quantity of Reserved DB instances to purchase.
Click on “Continue”, verify the purchase information, and confirm.

Important Notes about Purchases

Reserved Instance prices cover instance costs only. Storage and I/O are still billed separately.
Region, DB Engine, DB Instance Class, Deployment Type and term length must be chosen at purchase, and cannot be changed later.
You can purchase up to 40 Reserved Instances. If you need additional Reserved Instances, complete the form found here.
Reserved Instances may not be transferred, sold, or cancelled and the one-time fee is non-refundable.

Tuesday, December 13, 2022

Best Practices for Running Oracle Database on AWS

Abstract

Amazon Web Services (AWS) offers you the ability to run your Oracle Database in a cloud environment. Running Oracle Database in the AWS Cloud is very similar to running Oracle Database in your data center. To a database administrator or developer, there are no differences between the two environments. However, there are a number of AWS platform considerations relating to security, storage, compute configurations, management, and monitoring that will help you get the best out of your Oracle Database implementation on AWS.

This whitepaper provides best practices for achieving optimal performance, availability, and reliability, and lowering the total cost of ownership (TCO) while running Oracle Database in the AWS Cloud. The target audience for this whitepaper includes database administrators, enterprise architects, systems administrators, and developers who would like to run their Oracle Database in the AWS Cloud.

Introduction

Amazon Web Services (AWS) provides a comprehensive set of services and tools for deploying Oracle Database on the reliable and secure AWS Cloud infrastructure. AWS offers its customers the following options for running Oracle Database on AWS:

Using Amazon Relational Database Service (Amazon RDS) for Oracle, which is a managed database service that helps simplify the provisioning and management of Oracle databases. RDS for Oracle makes it easy to set up, operate, and scale a relational database in the cloud by automating installation, disk provisioning and management, patching, minor version upgrades, failed instance replacement, as well as backup and recovery tasks. The push-button scaling feature of Amazon RDS allows you to easily scale the database instance up or down for better cost management and performance. RDS for Oracle offers both Oracle Database Enterprise Edition and Oracle Database Standard Edition. RDS for Oracle also comes with a License-Included service model, which allows you to pay per use by the hour.
Running a self-managed Oracle Database directly on Amazon Elastic Compute Cloud (Amazon EC2). This option gives you full control over the setup of the infrastructure and database environment. Running the database on Amazon EC2 is very similar to running the database on your own server. You have full control of the Oracle binaries database and have operating system-level access, so you can run monitoring and management agents and use your choice of tools for data replication, backup, and restoration. Furthermore, you have the ability to use every optional module available in Oracle Database. However, this option requires you to set up, configure, manage, and tune all the components, including Amazon EC2 instances, storage volumes, scalability, networking, and security based on AWS architecture best practices. In the fully-managed Amazon RDS (Amazon RDS) service, this is all taken care of for you.
FlashGrid Cluster virtual appliances enable running self-managed Oracle Real Application Cluster (RAC) and Oracle RAC extended clusters (across different AZs) on Amazon EC2. With FlashGrid Cluster you also have full control of the database and have operating system-level access.
Running a self-managed Oracle Database directly on VMware Cloud on AWS. VMware Cloud on AWS is an integrated cloud offering jointly developed by AWS and VMware. Like Amazon EC2, you have full control of the database and have operating system-level access. You can run advanced architectures like Oracle Real Application Cluster (RAC) and Oracle RAC extended clusters (across different AZs) in VMware Cloud on AWS.

Whether you choose to run a self-managed Oracle Database on Amazon EC2 or the fully-managed RDS for Oracle, following the best practices discussed in this whitepaper will help you get the most out of your Oracle Database implementation on AWS. AWS will discuss Oracle licensing options, considerations for choosing Amazon EC2 or Amazon RDS for your Oracle Database implementation, and how to optimize network configuration, instance type, and database storage in your implementation.

PDF

Oracle-database-aws-best-practices.pdf

Thursday, October 6, 2022

How To Open Physical Standby For Read Write Testing and Flashback

GOAL

This article is to open the Standby database in read write mode for any reporting or testing and then move it back to standby database using the flashback technology.

For the purposes of this document, the following fictitious environment is used as an example to describe the procedure:

FRA Location: /u01/oracle/flashback
Restore Point Name: STANDBY_FLASHBACK_TESTING
Sample Table: testing
Sample data: 'testing for flashback on standby database'

*****************

Using a combination of Data Guard, restore points, and Flashback Database, a physical standby database can be opened temporarily in read/write mode for development, reporting, or testing purposes, and then flashed back to a point in the past to be reverted back to a physical standby database. When the database is flashed back, Data Guard automatically synchronizes the standby database with the primary database, without the need to re-create the physical standby database from a backup copy of the primary database.

Perform the following steps to activate the physical standby database as a production database and later resynchronize it with the primary database.

Oracle 11g has a feature in this area called : Snapshot standby database. A Snapshot Standby Database is a fully update-able standby database that is created by converting a physical standby database into a snapshot standby database.

A snapshot Standby is open in the read-write mode and hence it is possible to process transactions independently of the primary database. At the same time, it maintains protection by continuing to receive data from the production database, archiving it for later use.

Using a single command changes made while read-write mode can be discarded and quickly resynchronize the

The below procedure is applicable for 10g but also for higher versions.

Step 1 - In Standby database

A ) Set up a flash recovery area.

If Flash Recovery Area ( FRA ) is not configured in the standby then enable it and make sure to give enough space for to FRA

SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=5G;
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/u01/oracle/flashback';

B ) Cancel Redo Apply and create a guaranteed restore point.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> CREATE RESTORE POINT Standby_flashback_testing GUARANTEE FLASHBACK DATABASE;

To Confirim the details of restore point and its scn and time stamp run

SQL> select NAME,SCN,TIME from v$restore_point;

NAME                                                               SCN                    TIME
--------------------------------------------------     -------------    ------------------------------
STANDBY_FLASHBACK_TESTING    22607810    12-APR-09 01.10.21.000000000 P

Step 2 - In Primary Database

A) On the primary database, switch logs so the SCN of the restore point will be archived on the physical standby database. When using standby redo log files, this step is essential to ensure the database can be properly flashed back to the restore point.

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

B ) Defer log archive destinations pointing to the standby that will be activated.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;

Step 3 - In Standby database

A ) Activate the physical standby database:

SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

Once its done you can check the controlfile status will be changed from Standby to Current

SQL> select CONTROLFILE_TYPE from v$database;

CONTROL
-------
CURRENT

B) Then open the database.

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
SQL> ALTER DATABASE OPEN;

Step 4 - In Standby database

Once the standby database has been activated, you can run reporting tools or perform other testing and activities for days or even weeks, independent of the primary database

Any results stored in the activated database will be lost when you later flash back the database. Results that should be saved must be copied out of the activated database before flashing it back.

For example :

SQL> create table testing ( col1 varchar2 (100));

Table created.

SQL> insert into testing values ( 'testing for flashback on standby database');

1 row created.

SQL> commit;

Commit complete.

Step 5 - In standby database

A ) Revert the active standby database back to Physical standby database

A1. Mount the database.
A2. Flashback the database to restore point.

SQL> STARTUP MOUNT FORCE;

ORACLE instance started.
Total System Global Area  289406976 bytes
Fixed Size                  1290208 bytes
Variable Size             159383584 bytes
Database Buffers          125829120 bytes
Redo Buffers                2904064 bytes
Database mounted.

SQL> FLASHBACK DATABASE TO RESTORE POINT Standby_flashback_testing ;

You can confirm the same by checking the controlfile status. It will be now backup controlfile

SQL> select controlfile_type from v$database;

CONTROL
--------------
BACKUP

B ) Convert to Standby database

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL> STARTUP MOUNT FORCE;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

SQL> select controlfile_type from v$database;

CONTROL
--------------
STANDBY

Step 6 - In standby database

A ) Put the standby database in managed recovery mode.Let archive gap resolution fetch all missing archived redo log files and allow Redo Apply to apply the gap.

Step 7 - In Primary database

A ) Re-enable archiving to the physical standby database:

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

Step 8 - In Standby database

A ) Open the database in Read only mode and ensure that all the transaction done in active mode are no more

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE OPEN READ ONLY;
SQL> select * from testing;
select * from testing
*
ERROR at line 1:
ORA-00942: table or view does not exist

B ) Drop the restore point

SQL> STARTUP FORCE MOUNT;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
SQL> DROP RESTORE POINT Standby_flashback_testing ;

Caution:

While the database is activated, it is not receiving redo data from the primary database and cannot provide disaster protection. It is recommended that there be at least two physical standby databases participating in the configuration so that the primary database remains protected against data loss.

Oracle Metalink - Doc ID 805438.1

Friday, April 22, 2022

Oracle E-Business Suite (EBS) System Schema Migration

With AD and TXK Delta 13, EBS has implemented a set of structural changes that modernize the EBS database architecture. These changes introduce a new schema named EBS_SYSTEM, which is defined with a least privileges model that utilizes public database APIs. In addition, connections from the application tier to the database have been updated to utilize database service names.

Oracle E-Business Suite (EBS) Release 12.2 to use the new EBS System Schema (EBS_SYSTEM).

Section 1: Overview of the EBS System Schema

The Release 12.2 database architecture has been modernized by adoption of the Oracle E-Business Suite System Schema, EBS_SYSTEM.

Prior to the introduction of the EBS_SYSTEM schema, Oracle E-Business Suite installed application objects in the Oracle Database SYS and SYSTEM schemas.

Migration to the EBS System Schema obviates the need for any EBS-owned objects to reside in the SYS or SYSTEM schemas.

Key characteristics of the EBS System Schema include:

Creation of the EBS_SYSTEM schema and associated grant management is performed as follows:
1. Creation of the EBS_SYSTEM schema and is performed by SYS running the adgrants.sql script (supplying the APPS account as the parameter) before applying the AD-TXK Delta 13 RUPs.
2. Grants required by the APPS account are given by the apps_adgrants.sql script being run automatically by the AD-TXK Delta 13 RUP installation process. This script does not need to be run manually as part of normal patching operations.

All EBS database objects that currently reside in the SYS or SYSTEM schemas are migrated to appropriate Oracle E-Business Suite schemas. Depending upon the EBS object type and function, the object is migrated to EBS_SYSTEM, APPS, or APPS_NE.
All Oracle E-Business Suite administration actions (such as running adop, adadmin and other utilities) are now performed by EBS_SYSTEM.
Access to the Oracle database SYS and SYSTEM and the Oracle database server operating system is no longer required for Oracle E-Business Suite system administrative functions.
If any grants need to be fixed after the AD-TXK Delta 13 RUP is applied,

Key benefits of migrating to the EBS System Schema include the provision of support for the following:

Public Oracle Database APIs
Least Privileges Model for database object access
Separation of Duties for administrators
Database service names for application tier database connections
Oracle Database Unified Auditing
Easier interoperability across Oracle Database releases

Diagram 1 - The modernized Oracle E-Business Suite database and its key features

1.1 Public Oracle Database APIs

As part of the Oracle E-Business Suite System Schema Migration, all Oracle E-Business Suite code is updated to map to public Oracle database dictionary objects and APIs. Utilizing public Oracle database APIs provides further capability to lock down EBS runtime accounts.

1.2 Least Privileges Model for Database Object Access

With the migration to the EBS_SYSTEM schema and usage of public Oracle Database APIs, runtime accounts may be constrained even further. As part of this feature, unnecessary privileges are revoked from Oracle E-Business Suite application accounts.

1.3 Separation of Duties for Administrators

Migration to the EBS_SYSTEM schema makes it possible to separate the role of the Oracle E-Business Suite system administrators from database administrators. All Oracle E-Business Suite administration actions (such as running adop, adadmin, and other utilities) will now prompt for the EBS_SYSTEM password instead of the SYSTEM password. Highly privileged operations that were previously run by the SYS or SYSTEM accounts are now run by EBS_SYSTEM.

Access to the Oracle database SYS and SYSTEM and the Oracle database server operating system is no longer required for Oracle E-Business Suite system administration functions. Database patching may be performed by the Oracle database administrator, and Oracle E-Business Suite patching may be performed by the Oracle E-Business Suite system administrator or applications database administrator (DBA).

The passwords for EBS_SYSTEM and SYSTEM must match until after the Completion Patch is successfully applied. Once the Completion Patch has been successfully applied, the password for EBS_SYSTEM should be changed to be different from the SYSTEM schema password.

1.4 Database Service Names for Application Tier Database Connections

As part of modernizing the Oracle E-Business Suite, connections from the Oracle E-Business Suite application tier to the Oracle E-Business Suite database are now performed using database service names.

1.5 Support for Oracle Database Unified Auditing

Once all requirements are met, Oracle E-Business Suite customers are now able to utilize Unified Auditing, the latest method for auditing an Oracle Database. With Unified Auditing, audit data is combined into a single audit trail. A new schema, AUDSYS, is used for storing the Unified Audit Trail. Separation of duties is achieved with multiple database roles to audit configuration and view the audit data.

1.6 Streamline Database Directory Objects

Following migration to EBS System Schema (EBS_SYSTEM), the APPS schema will no longer have the ability to create database directory objects. Database directory objects are now created by the EBS_SYSTEM user.

The following four standard new database directory objects are created with the privileges shown:

Object Name	Privileges
EBS_LOG	Read/Write
EBS_TEMP	Read/Write
EBS_INBOUND	Read
EBS_OUTBOUND	Write

By default, the database directory objects are mapped to a temporary directory in the $ORACLE_HOME on the database tier file system. If a large number of files are written to this directory, your $ORACLE_HOME database tier file system may reach capacity: it is therefore recommended that you instead map the database directory objects to a secure location in a separate mount point from your $ORACLE_HOME database tier file system. For more information, refer to the Oracle Database documentation for your specific database release.

1.7 Interoperabilty Across Oracle Database Releases

Oracle E-Business Suite uptake of database releases will be made easier by EBS only referencing public database views and APIs.

References : Doc ID 2755875.1

AD and TXK Delta 13 for EBS 12.2

Click here for the details of the original post: A D and TXK Delta 13 Updates Now Available for EBS 12.2

Oracle announced the availability of the latest updates for the Applications DBA (AD) and Technology Stack (TXK) infrastructure components of Oracle E-Business Suite Release 12.2. This Delta 13 release for AD and TXK includes new features, plus performance and stability fixes.

Oracle strongly recommend that you apply these new AD and TXK updates at your earliest convenience:

R12.AD.C.Delta.13, Patch 32394134 and Patch 33401305
R12.TXK.C.Delta.13, Patch 32392507 and Patch 33550674

Refer to the following for the latest updates and instructions for applying the latest AD and TXK updates:

Applying the Latest AD and TXK Release Update Packs to Oracle E-Business Suite Release 12.2 (MOS Note 1617461.1)

Note: You should always apply the AD and TXK updates during the same patching cycle.

New Feature: Oracle E-Business Suite (EBS) System Schema Migration

With AD and TXK Delta 13, EBS has implemented a set of structural changes that modernize the EBS database architecture. These changes introduce a new schema named EBS_SYSTEM, which is defined with a least privileges model that utilizes public database APIs. In addition, connections from the application tier to the database have been updated to utilize database service names.

R12.AD.C.Delta.13, Patch 32394134 and Patch 33401305