1. מימוש מערכות מסדי נתונים (236510)
Lecture 1 :
Oracle Database 12c Architecture Part2
Rev : 2.3 Date modified :
By David Yitzhak
Global Hebrew Virtual PASS Chapter :
Sqlsaturday Israel 2016 :
Oracle Database 11g: Administration Workshop I

2. Oracle Database 12c Architecture: Major background processes
There are several aspects to note. Communication with the database is initiated through a
sqlplus user process. Typically, the user process connects to the database over the network. This requires that you
configure and start a listener process. The listener process hands off incoming connection requests to an Oracle server
process, which handles all subsequent communication with the client process. If a remote connection is initiated as a
sys*-level user, then a password file is required. A password file is also required for local sys* connections that don’t
use OS authentication.
The instance consists of memory structures and background processes. When the instance starts, it reads the
parameter file, which helps establish the size of the memory processes and other characteristics of the instance.
When starting a database, the instance goes through three phases: nomount (instance started), mount (control files
opened), and open (data files and online redo logs opened).
The number of background processes varies by database version (more than 300 in the latest version of Oracle).
You can view the names and descriptions of the processes via this query:
SQL> select name, description from v$bgprocess;
The major background processes include
DBWn: The database writer wr • ites blocks from the database buffer cache to the data files.
• CKPT: The checkpoint process writes checkpoint information to the control files and
data file headers.
• LGWR: The log writer writes redo information from the log buffer to the online redo logs.
• ARCn: The archiver copies the content of online redo logs to archive redo log files.
• RVWR: The recovery writer maintains before images of blocks in the fast recovery area.
• MMON: The manageability monitor process gathers automatic workload repository statistics.
• MMNL: The manageability monitor lite process writes statistics from the active session history
buffer to disk.
• SMON: The system monitor performs system level clean-up operations, including
instance recovery in the event of a failed instance, coalescing free space, and cleaning up
temporary space.
• PMON: The process monitor cleans up abnormally terminated database connections and also
automatically registers a database instance with the listener process.
• RECO: The recoverer process automatically resolves failed distributed transactions.
ARCn: The archiver copies the content of online redo logs to archive redo log files.
CKPT: Checkpoint process writes checkpoint information : checkpoint position, SCN to control files and data file headers , location in online redo log to begin recovery, and so on
DBWn: Database writer writes dirty modified blocks from DB buffer cache to the data files.
LGWR: The log writer writes redo information from the log buffer to the online redo logs.
Oracle Database 11g: Administration Workshop I

3. Oracle Database 12c Architecture major background processes
DBWn: The database writer writes blocks from the database buffer cache to the data files.
CKPT: The checkpoint process writes checkpoint information to the control files and data file headers.
LGWR: The log writer writes redo information from the log buffer to the online redo logs.
ARCn: The archiver copies the content of online redo logs to archive redo log files.
RVWR: The recovery writer maintains before images of blocks in the fast recovery area.
MMON: The manageability monitor process gathers automatic workload repository statistics.
MMNL: The manageability monitor lite process writes statistics from the active session history buffer to disk.
SMON: The system monitor performs system level clean-up operations, including instance recovery in the event of a failed instance, coalescing free space, and cleaning up temporary space.
PMON: The process monitor cleans up abnormally terminated database connections and also automatically registers a database instance with the listener process.
RECO: The recoverer process automatically resolves failed distributed transactions.
Oracle Database 11g: Administration Workshop I

4. Checkpoint Process (CKPT)
Mandatory Background Processes
Updates the control file and data file headers with checkpoint information and signals DBW to write blocks to disk.
Checkpoint information includes the checkpoint position, SCN, location in online redo log to begin recovery, and so on
CKPT does not write data blocks to data files or redo blocks to online redo log files
System change number (SCN) is Oracle's clock - every time we commit, the clock increments. The SCN just marks a consistent point in time in the database. 
A checkpoint is the act of writing dirty modified blocks from the buffer cache to disk. 
DB ALWAYS has transactions going on. SMON and many other background processes are always doing work, the database (unless it is opened read only) is always doing transactions. 
Checkpoint Process (CKPT)
The checkpoint process (CKPT) updates the control file and data file headers with
checkpoint information and signals DBW to write blocks to disk. Checkpoint
information includes the checkpoint position, SCN, location in online redo log to begin
recovery, and so on. As shown in Figure CKPT does not write data blocks to data
files or redo blocks to online redo log files.
Oracle Database 11g: Administration Workshop I

5. Database Writer Process(DBWn )
Write modified (dirty) buffer in database buffer cache to disk
Asynchronously while performing other process to advance checkpoint .

6. Log Writer Process (LGWR)
Writes the redo log buffer to a redo log file on disk writes
When user commit a transaction
When the redo log buffer is one-third full
Before a DBWn process writes modified buffers to disk
Every 3 seconds

7. Online Redo Logs(ORLs )
Crucial to the Oracle database
Transaction logs for DB
Two types of redo log files: online and archived
Used for recovery purposes in the event of an instance or media failure.
What Is Redo?
Redo log files are crucial to the Oracle database. These are the transaction logs for the database. Oracle maintains two
types of redo log files: online and archived. They are used for recovery purposes; their main purpose in life is to be
used in the event of an instance or media failure.
If the power goes off on your database machine, causing an instance failure, Oracle will use the online redo logs
to restore the system to exactly the committed point it was at immediately prior to the power outage. If your disk drive
fails (a media failure), Oracle will use both archived redo logs and online redo logs to recover a backup of the data that
was on that drive to the correct point in time. Moreover, if you “accidentally” truncate a table or remove some critical
information and commit the operation, you can restore a backup of the affected data and recover it to the point in
time immediately prior to the “accident” using online and archived redo log files.
Archived redo log files are simply copies of old, full online redo log files. As the system fills up log files, the ARCn
process makes a copy of the online redo log file in another location, and optionally puts several other copies into local
and remote locations as well. These archived redo log files are used to perform media recovery when a failure is caused
by a disk drive going bad or some other physical fault. Oracle can take these archived redo log files and apply them to
backups of the data files to catch them up to the rest of the database. They are the transaction history of the database.

8. Online Redo Log Switches
log writer is the background process responsible for writing transaction information from redo log buffer (in the SGA) to the online redo log files (on disk).
Log writer flushes the contents of the redo log buffer when any of thefollowing are true:
A COMMIT is issued.
A log switch occurs.
Three seconds go by.
Redo log buffer is one-third full.
Redo log buffer fills to one megabyte.
Reuse of Online Redo Log Files
Multiple Copies of Online Redo Log Files
Online Redo Log Switches
Oracle Database uses only one online redo log file at a time to store records written
from the redo log buffer. The online redo log file to which the log writer process
(LGWR) process is actively writing is called the current online redo log file.
A log switch occurs when the database stops writing to one online redo log file and
begins writing to another. Normally, a switch occurs when the current online redo log
file is full and writing must continue. However, you can configure log switches to
occur at regular intervals, regardless of whether the current online redo log file is
filled, and force log switches manually.
Log writer writes to online redo log files circularly. When log writer fills the last
available online redo log file, the process writes to the first log file, restarting the cycle.
Figure illustrates the circular writing of the redo log.
Multiple Copies of Online Redo Log Files
Oracle Database can automatically maintain two or more identical copies of the online
redo log in separate locations. An online redo log group consists of an online redo log
file and its redundant copies. Each identical copy is a member of the online redo log
group. Each group is defined by a number, such as group 1, group 2, and so on.
Maintaining multiple members of an online redo log group protects against the loss of
the redo log. Ideally, the locations of the members should be on separate disks so that
the failure of one disk does not cause the loss of the entire online redo log.
In Figure A_LOG1 and B_LOG1 are identical members of group 1, while A_LOG2
and B_LOG2 are identical members of group 2. Each member in a group must be the
same size. LGWR writes concurrently to group 1 (members A_LOG1 and B_LOG1),
then writes concurrently to group 2 (members A_LOG2 and B_LOG2), then writes to
group 1, and so on. LGWR never writes concurrently to members of different groups.
Overview of the Online Redo Log
Physical Storage
Oracle Database 11g: Administration Workshop I

9. Reuse of Online Redo Log
At time 1, Block A is read from Data File AA into the buffer cache and modified.
At time 2 the redo-change vector information (how the block changed) is written to the log buffer.
At time 3 the log-writer process writes the Block Achange-vector information to online redo log 1.
At time 4 a log switch occurs, and online redo log 2 becomes the current online redo log
Redo protected until the modified (dirty) buffer is written to disk
At time 1, Block A is read from Data File AA into the buffer cache and modified. At time 2 the redo-change vector
information (how the block changed) is written to the log buffer. At time 3 the log-writer process writes the Block A
change-vector information to online redo log 1. At time 4 a log switch occurs, and online redo log 2 becomes the
current online redo log
Reuse of Online Redo Log Files
Oracle Database 11g: Administration Workshop I

10. Oracle normally only writes change vectors to the redo stream
Oracle only records a change vector in the
redo stream that specifies which block changed and how it was changed. Figure shows Oracle operating under
normal conditions.

11. Logging and Archiving Redo Log Files Archive Log Files Arch 1 LGWR
Group 1
Group 3
Group 2
ARCH
Arch 2
Arch 5
Arch 4
Arch 3
Arch 6
Redo Log Files
Archive Log Files

12. Oracle Database 11g: Administration Workshop I 9 - 12
Database and Instance
Database
Set of files, located on disk, that store data. These files can exist independently of a database instance.
Database instance
Set of memory structures that manage database files. Instance consists of a shared memory area, called the system global area (SGA), and a set of background processes.
An instance can exist independently of database files.
For each user connection to the instance, a client process runs the application. Each client process is associated with its own server process. Server process has its own private session memory, known as the program global area (PGA).
Database and Instance
An Oracle database server consists of a database and at least one database instance,
commonly referred to as simply an instance.Because an instance and a database are so
closely connected, the term Oracle database is sometimes used to refer to both instance
and database.
In the strictest sense the terms have the following meanings:
• Database
A database is a set of files, located on disk, that store data. These files can exist
independently of a database instance.
• Database instance
An instance is a set of memory structures that manage database files. The instance
consists of a shared memory area, called the system global area (SGA), and a set of
background processes. An instance can exist independently of database files.
Figure 1-1 shows a database and its instance. For each user connection to the instance,
a client process runs the application. Each client process is associated with its own
server process. The server process has its own private session memory, known as the
program global area (PGA).
A database can be considered from both a physical and logical perspective. Physical
data is data viewable at the operating system level. For example, operating system
utilities such as the Linux ls and ps can list database files and processes. Logical data
such as a table is meaningful only for the database. A SQL statement can list the tables
in an Oracle database, but an operating system utility cannot.
The database has physical structures and logical structures. Because the physical and
logical structures are separate, you can manage the physical storage of data without
affecting access to logical storage structures. For example, renaming a physical
database file does not rename the tables whose data is stored in this file.
Oracle Database 11g: Administration Workshop I

13. Oracle Database 11g: Administration Workshop I 9 - 13
Oracle Instance
A database instance is a set of memory structures that manage database files.
When an instance is started, Oracle Database allocates a memory area called the system global area (SGA) and starts one or more background processes.
SGA serves various purpose:
Maintaining internal data structures that many processes and threads access Concurrently .
Caching data blocks read from disk
Buffering redo data before writing it to the online redo log files
Storing SQL execution plans
Oracle Database 11g: Administration Workshop I

14. Database Architecture : Databases and Instances
Instance memory Structures (RAM) and Background processes (CPU) that uses the physical components to manipulate and retrieve data.
Database set of physical files (Datafiles) saved on the disk that store information. created by the CREATE DATABASE statement.
One instance communicates with one database.
The host machine is where users and applications connect and interact.
If the machine goes down for some reason, DB will be unavailable. The solution : Real Application Clusters (RAC) .
Oracle Database 11g: Administration Workshop I

15. Database Architecture : Databases and Instances
Rules :
An instance can exist without a database.
Database can exist without an instance but would be useless
An instance can access only one database.
You can set up multiple instances to access the same set of files or one database. Clustering is the basis for the Oracle Real Application Clusters feature .
Reason to distinguish between Instance and Database
Single Instance VS RAC
Relationship through separation .
Other RDBMS like SQL Server , Sybase ,DB2 terms means different things
Rules :
An instance can exist without a database.
Database can exist without an instance but would be useless
Every running Oracle database is associated with at least one Oracle database instance.
An instance can access only one database. When you start your instance, the next step is to mount that instance to a database. An instance can mount only one database at a time.
You can set up multiple instances to access the same set of files or one database. Clustering is the basis for the Oracle Real Application Clusters feature .
Reason to distinguish between Instance and Database
Single Instance VS RAC
Relationship through separation .
Other RDBMS like SQL Server , Sybase ,DB2 terms means different things
Oracle Database 11g: Administration Workshop I

16. Oracle Database 12c Architecture
DB components : memory structures, process structures , and storage structures.
Process and memory structures together are called an instance;
Storage structure is called a database.
Instance and DB are called an Oracle server.
One instance communicates with one database.
The host machine is where users and applications connect and interact.
If the machine goes down for some reason, DB will be unavailable. Solution : Real Application Clusters (RAC)
Each Oracle database consists of several schemas that reside in tablespaces.
Tablespace is a logical storage structure at the highest level in the database.
Each tablespace consists of one or more data files.
The database has user data and overhead like database dictionary, memory, control files, archived log files, flashback files, etc.
Oracle Database 11g: Administration Workshop I

17. Online Redo Log Switches
log writer is the background process responsible for writing transaction information from redo log buffer (in the SGA) to the online redo log files (on disk).
Log writer flushes the contents of the redo log buffer when any of thefollowing are true:
A COMMIT is issued.
A log switch occurs.
Three seconds go by.
Redo log buffer is one-third full.
Redo log buffer fills to one megabyte.
Reuse of Online Redo Log Files
Multiple Copies of Online Redo Log Files
Online Redo Log Switches
Oracle Database uses only one online redo log file at a time to store records written
from the redo log buffer. The online redo log file to which the log writer process
(LGWR) process is actively writing is called the current online redo log file.
A log switch occurs when the database stops writing to one online redo log file and
begins writing to another. Normally, a switch occurs when the current online redo log
file is full and writing must continue. However, you can configure log switches to
occur at regular intervals, regardless of whether the current online redo log file is
filled, and force log switches manually.
Log writer writes to online redo log files circularly. When log writer fills the last
available online redo log file, the process writes to the first log file, restarting the cycle.
Figure illustrates the circular writing of the redo log.
Multiple Copies of Online Redo Log Files
Oracle Database can automatically maintain two or more identical copies of the online
redo log in separate locations. An online redo log group consists of an online redo log
file and its redundant copies. Each identical copy is a member of the online redo log
group. Each group is defined by a number, such as group 1, group 2, and so on.
Maintaining multiple members of an online redo log group protects against the loss of
the redo log. Ideally, the locations of the members should be on separate disks so that
the failure of one disk does not cause the loss of the entire online redo log.
In Figure A_LOG1 and B_LOG1 are identical members of group 1, while A_LOG2
and B_LOG2 are identical members of group 2. Each member in a group must be the
same size. LGWR writes concurrently to group 1 (members A_LOG1 and B_LOG1),
then writes concurrently to group 2 (members A_LOG2 and B_LOG2), then writes to
group 1, and so on. LGWR never writes concurrently to members of different groups.
Overview of the Online Redo Log
Physical Storage
Oracle Database 11g: Administration Workshop I

18. Reuse of Online Redo Log
At time 1, Block A is read from Data File AA into the buffer cache and modified.
At time 2 the redo-change vector information (how the block changed) is written to the log buffer.
At time 3 the log-writer process writes the Block Achange-vector information to online redo log 1.
At time 4 a log switch occurs, and online redo log 2 becomes the current online redo log
Redo protected until the modified (dirty) buffer is written to disk
At time 1, Block A is read from Data File AA into the buffer cache and modified. At time 2 the redo-change vector
information (how the block changed) is written to the log buffer. At time 3 the log-writer process writes the Block A
change-vector information to online redo log 1. At time 4 a log switch occurs, and online redo log 2 becomes the
current online redo log
Reuse of Online Redo Log Files
Oracle Database 11g: Administration Workshop I

19. Oracle Database 12c Architecture
DB components : memory structures, process structures , and storage structures.
Process and memory structures together are called an instance;
Storage structure is called a database.
Instance and DB are called an Oracle server.
One instance communicates with one database.
The host machine is where users and applications connect and interact.
If the machine goes down for some reason, DB will be unavailable. Solution : Real Application Clusters (RAC)
Oracle Database 11g: Administration Workshop I

20. Oracle database server- Real Application Cluster
More than one instance communicates to a single database .
If an instance fails, the remaining instances in the RAC pool remain open and active. Connections from failed instances can be failed-over to active instances.
Oracle manages the connection load balancing and failover automatically.
Oracle Database 11g: Administration Workshop I

21. Oracle RAC architecture and components
Oracle Database 11g: Administration Workshop I

22. User and Server Processes
Additional memory structure : program global area (PGA) is also created for each server process.
PGA stores user-specific session information like bind variables and session variables.
Every server process on the server has a PGA memory area.
Oracle Database 11g: Administration Workshop I

23. User and Server Processes
Example On a Unix system :
User initiates SQL*Plus to connect to Oracle database. User process with process ID by david.
This starts another server process that connects to the instance with process ID owned by database server user oracle.
$ ps -ef |grep sqlplus | grep -v grep
david :51 pts/2 00:00:00 sqlplus
$ ps -ef |grep | grep -v grep
david :51 pts/2 00:00:00 sqlplus
oracle :52 ? 00:00:00 oracleC12DB1
(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=tcp)))
Oracle Database 11g: Administration Workshop I

24. Connections and Sessions
A database connection is a physical communication pathway between a client process and a database instance.
A database session is a logical entity in the database instance memory that represents the state of a current user login to a database.
session lasts from the time the user is authenticated by the database until the time the user disconnects or exits the database application.
A single connection can have 0, 1, or more sessions established on it.
The sessions are independent: a commit in one session does not affect transactions in other sessions.
Connections and Sessions
A database connection is a physical communication pathway between a client process
and a database instance.
During a connection, a communication pathway is established using available
interprocess communication mechanisms or network software. Typically, a connection
occurs between a client process and a server process or dispatcher, but it can also
occur between a client process and Oracle Connection Manager (CMAN).
A database session is a logical entity in the database instance memory that represents
the state of a current user login to a database. For example, when a user is
authenticated by the database with a password, a session is established for this user. A
session lasts from the time the user is authenticated by the database until the time the
user disconnects or exits the database application.
A single connection can have 0, 1, or more sessions established on it. The sessions are
independent: a commit in one session does not affect transactions in other sessions.
Multiple sessions can exist concurrently for a single database user. As shown in the
following figure, user hr can have multiple connections to a database. In dedicated
server connections, the database creates a server process on behalf of each connection.
Only the client process that causes the dedicated server to be created uses it. In a
shared server connection, many client processes access a single shared server process.
Oracle Database 11g: Administration Workshop I

25. How Many Databases on One Server?
Architecture with one server per database
Profitable for the hardware vendor but in many environments isn’t an economical use of resources.
Oracle Database 11g: Administration Workshop I

26. How Many Databases on One Server?
Multiple databases sharing one set of Oracle binaries on a server
If you have enough memory, CPU, and disk resources consider creating multiple databases on one server.
You can create a new installation of the Oracle binaries for each database or have multiple databases share one set of Oracle binaries.
If you have requirements for different versions of Oracle binaries, you must have multiple Oracle homes .
Oracle Database 11g: Administration Workshop I

27. How Many Databases on One Server?
One database used by multiple applications and users
If you don’t have the CPU, memory, or disk resources to create multiple databases on one server
To save Oracle License because it is usually per cpu core .
be careful not to use public synonyms, because there may be collisions between applications.
It’s typical to create different schemas and tablespaces to be used by different applications in such environments.
Oracle Database 11g: Administration Workshop I

28. Oracle Database 11g: Administration Workshop I 9 - 28
Oracle Database 12c — Multitenant architecture with pluggable databases
Oracle Database 12c comes with a major architectural change compared to its predecessors.
Oracle Database 12c allows multitenancy: you can have more than one database in a structure called a container database. The database overhead will be shared by all the databases in the container database.
The databases in the container database are called pluggable databases.
Administration and resource overhead are reduced .
Oracle Database 11g: Administration Workshop I

29. Benefits of the Multitenant Architecture for Database Consolidation
Cost reduction
Easier management and monitoring of the physical database
Separation of data and code
Secure separation of administrative duties
Ease of performance tuning
Support for Oracle Database Resource Manager
Fewer database patches and upgrades
Single CDB
efits of the Multitenant Architecture for Database Consolidation
Database consolidation is the process of consolidating data from multiple databases
into one database on one computer. Starting in Oracle Database 12c, the Oracle
Multitenant option enables you to consolidate data and code without altering existing
schemas or applications.
The PDB/non-CDB compatibility guarantee means that a PDB behaves the same as a
non-CDB as seen from a client connecting with Oracle Net. The installation scheme for
an application back end that runs against a non-CDB runs the same against a PDB and
produces the same result. Also, the run-time behavior of client code that connects to
the PDB containing the application back end is identical to the behavior of client code
that connected to the non-CDB containing this back end.
Operations that act on an entire non-CDB act in the same way on an entire CDB, for
example, when using Oracle Data Guard and database backup and recovery. Thus, the
users, administrators, and developers of a non-CDB have substantially the same
experience after the database has been consolidated.
Figure 17-3 depicts the databases in Figure 17-2 after consolidation onto one computer.
The DBA team is reduced from five to three, with one CDB administrator managing
the CDB while two PDB administrators split management of the PDBs
Using the multitenant architecture for database consolidation has the following
benefits:
• Cost reduction
By consolidating hardware and sharing database memory and files, you reduce
costs for hardware, storage, availability, and labor. For example, 100 PDBs on a
single server share one database instance and one set of database files, thereby
requiring less hardware and fewer personnel.
• Easier and more rapid movement of data and code
By design, you can quickly plug a PDB into a CDB, unplug the PDB from the CDB,
and then plug this PDB into a different CDB. The implementation technique for
plugging and unplugging is similar to the transportable tablespace technique.
• Easier management and monitoring of the physical database
The CDB administrator can attend to one physical database (one set of files and one
set of database instances) rather than split attention among dozens or hundreds of
non-CDBs. Backup strategies and disaster recovery are simplified.
• Separation of data and code
Although consolidated into a single physical database, PDBs mimic the behavior of
non-CDBs. For example, if user error loses critical data, a PDB administrator can
use Oracle Flashback or point-in-time recovery to retrieve the lost data without
affecting other PDBs.
• Secure separation of administrative duties
A user account is common, which means that it can connect to any container on
which it has privileges, or local, which means that it is restricted to a specific PDB.
A CDB administrator can use a common user account to manage the CDB. A PDB
administrator uses a local account to manage an individual PDB. Because a
privilege is contained within the container in which it is granted, a local user on
one PDB does not have privileges on other PDBs within the same CDB.
• Ease of performance tuning
It is easier to collect performance metrics for a single database than for multiple
databases. It is easier to size one SGA than 100 SGAs.
• Support for Oracle Database Resource Manager
In a multitenant environment, one concern is contention for system resources
among the PDBs running on the same computer. Another concern is limiting
resource usage for more consistent, predictable performance. To address such
resource contention, usage, and monitoring issues, you can use Oracle Database
Resource Manager (see “Database Resource Manager”).
• Fewer database patches and upgrades
It is easier to apply a patch to one database than to 100 databases, and to upgrade
one database than to upgrade 100 databases.
Oracle Database 11g: Administration Workshop I

30. What is the cloud Defined “as a Service”
IaaS
Compute
Storage
Network
PaaS
Data BI
Java
Mobile
IoT
SaaS
HCM
ERP
CRM
PLM
Cloud is here and now
New businesses and enterprises are adopting the cloud

31. Oracle Database as a Service
Automated Infrastructure and Database Administration
11g
12c
Compute Shape
CPU and Memory On-Demand
Block and Object Storage
Upsize, add archives all with encryption
Upgrade and Patch
Upgrade automation
Point-in-time Recovery
Recover from human error
Point-to-point Networking
Open just the ports you need
Service Integration
Add PaaS offerings when Needed
31:30
Post install
Small part of automated services
Automation saves cost
Cost is the top IT spend
In addition to provisioning automation
THEME 1: intelligent automation optimizes top database management activities; keeps you on the golden path
Automation reduces human error, and human variation; a consistent fleet is an easier fleet to manage
Compute shape; inventory, shut down, re-apply inventory on new larger size, assistants kick in and increase memory
Block and object; can add storage on the fly, inventory to be updated
Upgrade and Patch: new oracle home, shutdown and remount
Java service; will require networking to open the JDBC connection pools
Robust automation reduces administrative time and promotes standardization improving manageability and availability

32. Oracle Database Cloud Service Rich DBaaS Tools and Web User Interfaces
Oracle Confidential - For Internal Use Only