Database Administration

BIT-352
Sundar Shrestha
Feb 2024
Unit 1
Unit 1.1 Introductions
1. Overview of Oracle Database
2. Relational Database Concept
3. Overview Oracle Database Architecture
4. Overview Oracle Multitenant Architecture
5. Overview Oracle Data Guard
6. Overview Oracle Real Application Cluster (RAC)
7. Overview Oracle Automatic Storage Manager (ASM)
8. Oracle Cloud
9. Database Administration Tasks
 ORACLE DATABASE SERVER

• A database instance contains a set of Oracle Database background processes and

memory structures. The main memory structures are the System Global Area (SGA)
and the Program Global Areas (PGAs). The background processes operate on the
stored data (data files) in the database and use the memory structures to do their
work. A database instance exists only in memory.

• Oracle Database also creates server processes to handle the connections to the
database on behalf of client programs, and to perform the work for the client
programs; for example, parsing and running SQL statements, and retrieving and
returning results to the client programs. These types of server processes are also
referred to as foreground processes
 Overview
of
racle Database Architecture
 ORACLE DATABASE SERVER

• An Oracle Database consists of at least one database instance and one database. The database instance handles
memory and processes. The database consists of physical files called data files, and can be a non- container database
or a multitenant container database. An Oracle Database also uses several database system files during its operation.

• A single-instance database architecture consists of one database instance and one database. A one-to-one
relationship exists between the database and the database instance. Multiple single-instance databases can be
installed on the same server machine. There are separate database instances for each database. This configuration is
useful to run different versions of Oracle Database on the same machine.

• An Oracle Real Application Clusters (Oracle RAC) database architecture consists of multiple instances that run on
separate server machines. All of them share the same database. The cluster of server machines appear as a single
server on one end, and end users and applications on the other end. This configuration is designed for high
availability, scalability, and high-end performance.

• The listener is a database server process. It receives client requests, establishes a connection to the database
instance, and then hands over the client connection to the server process. The listener can run locally on the
database server or run remotely. Typical Oracle RAC environments are run remotely.
ORACLE DATABASE SERVER
 Architecture

A Database Instance is an interface

between client applications (users)
and the database.
An Oracle instance consists of three
main parts: System Global Area
(SGA), Program Global Area (PGA),
and background processes.The SGA
is a shared memory structure
allocated when the instance
started up and is released when it
is shut down.

The SGA is a group of shared memory structures that contain data and control information for one database instance.
Different from the SGA, which is available to all processes, PGA is a private memory area allocated to each session when
the session starts and released when the session ends.
ORACLE DATABASE SERVER INSTANCE
A database instance is a set of memory structures that manage database files.

A database is a set of physical files on disk created by the CREATE DATABASE statement.
The instance manages its associated data and serves the users of the database.

Every running Oracle database is associated with at least one Oracle database
instance. Because an instance exists in memory and a database exists on disk, an
instance can exist without a database and a database can exist without an
instance.

When an instance is started, Oracle Database allocates a memory area called the
system global area (SGA) and starts one or more background processes. The SGA
serves various purposes, including the following:

1. Maintaining internal data structures that many processes and threads access
concurrently
2. Caching data blocks read from disk
3. Buffering redo data before writing it to the online redo log files
4. Storing SQL execution plans
 ORACLE DATABASE SERVER INSTANCE
Figure shows components of an Oracle database instance.

Oracle processes running on a single computer share the SGA. The

way in which Oracle processes associate with the SGA varies
according to operating system.

A database instance includes background processes. Server

processes, and the process memory allocated in these processes,
also exist in the instance. The instance continues to function when
server processes terminate.
 ORACLE DATABASE SERVER

• A database instance contains a set of Oracle Database background processes and

memory structures. The main memory structures are the System Global Area (SGA)
and the Program Global Areas (PGAs). The background processes operate on the
stored data (data files) in the database and use the memory structures to do their
work. A database instance exists only in memory.

• Oracle Database also creates server processes to handle the connections to the
database on behalf of client programs, and to perform the work for the client
programs; for example, parsing and running SQL statements, and retrieving and
returning results to the client programs. These types of server processes are also
referred to as foreground processes
Memory Structure
Memory Structure
Memory Structures
Oracle Database allocates a memory area and starts
background processes when an instance is started.

The memory area stores information such as the following:

• Program code
• Information about each connected session, even if it is
not currently active
• Information needed during program execution, for
example, the current state of a query from which rows
are being fetched
• Information such as lock data that is shared and
communicated among processes
• Cached data, such as data blocks and redo records, that
also exists on disk
Memory Structure
Oracle Database includes several memory areas, each of which contains
multiple subcomponents. The basic memory structures associated with
Oracle Database include:

System global area (SGA)

•The SGA is a group of shared memory structures, known as SGA
components, that contain data and control information for one Oracle
Database instance. All server and background processes share the SGA.
Examples of data stored in the SGA include cached data blocks and shared
SQL areas.

Program global area (PGA)

•A PGA is a nonshared memory region that contains data and control
information exclusively for use by an Oracle process. Oracle Database
creates the PGA when an Oracle process starts.
•One PGA exists for each server process and background process. The
collection of individual PGAs is the total instance PGA, or instance PGA.
Database initialization parameters set the size of the instance PGA, not
individual PGAs.
User global area (UGA)
•The UGA is memory associated with a user session.

Software code areas

Software code areas are portions of memory used to store code that is being
run or can be run. Oracle Database code is stored in a software area that is
typically at a different location from user programs—a more exclusive or
protected location.
 Memory Management
Memory management involves maintaining optimal sizes for the Oracle instance memory structures as demands on the database change. Oracle Database
manages memory based on the settings of memory-related initialization parameters.

The basic options for memory management are as follows:

✔ Automatic memory management

You specify the target size for the database instance memory. The instance automatically tunes to the target memory size, redistributing memory as
needed between the SGA and the instance PGA.

✔ Automatic shared memory management

This management mode is partially automated. You set a target size for the SGA and then have the option of setting an aggregate target size for the
PGA or managing PGA work areas individually.

✔ Manual memory management

Instead of setting the total memory size, you set many initialization parameters to manage components of the SGA and instance PGA individually.

If you create a database with Database Configuration Assistant (DBCA) and choose the basic installation option, then automatic memory management is the
default.
Process Architecture and
Structure
 A process is a mechanism in an operating system that can run a series of steps. The process execution
architecture depends on the operating system. For example, on Windows an Oracle background process is a
thread of execution within a process. On Linux and UNIX, an Oracle process is either an operating system
process or a thread within an operating system process.
 Processes run code modules. All connected Oracle Database users must run the following modules to access a
database instance:
• Application or Oracle Database utility
A database user runs a database application, such as a precompiler program or a database tool such as
SQL*Plus, that issues SQL statements to a database.
• Oracle database code
Each user has Oracle database code executing on their behalf that interprets and processes the
application's SQL statements.
The database creates server processes in various ways, depending on the connection methods.
The connection methods are as follows:
• Bequeath
SQL*Plus, an OCI client, or another client application directly spawns the server process.
• Oracle Net listener
The client application connects to the database through a listener.
• Dedicated broker
This is a database process that creates foreground processes. Unlike the listener, the broker resides within the
database instance. When using a dedicated broker, the client connects to the listener, which then hands off
the connection to the dedicated broker. When a connection does not use bequeath, the database creates the
server process as follows:
1. The client application requests a new connection from the listener or broker.
2. The listener or broker initiates the creation of a new process or thread.
3. The operating system creates the new process or thread.
4. Oracle Database initializes various components and notifications.
5. The database hands over the connection and connection-specific code.
Optionally, if you use of the dedicated broker connection method, then you can pre-create a pool of server
processes with the DBMS_PROCESS package. In this case, the Process Manager (PMAN) background process
monitors the pool of pre-created processes, which wait to be associated with a client request. When a
connection requires a server process, the database skips Steps 2-4 of process creation and performs only Step
5. This optimization improves performance.
 A process normally runs in its own private memory area. Most processes can periodically write to an associated trace
file.
 A database instance contains or interacts with multiple processes.
• Multiprocess and Multithreaded Oracle Database Systems
Multiprocess Oracle Database (also called multiuser Oracle Database) uses several processes to run different
parts of the Oracle Database code and additional Oracle processes for the users—either one process for each
connected user or one or more processes shared by multiple users.
 Types of Processes
A database instance contains or interacts with multiple processes. Processes are divided into the following types:

A client process runs the application or Oracle tool code.

An Oracle process is a unit of execution that runs the Oracle database code. In the multithreaded architecture, an Oracle
process can be an operating system process or a thread within an operating system process. Oracle processes include the
following subtypes:
– A background process starts with the database instance and perform maintenance tasks such as performing
instance recovery, cleaning up processes, writing redo buffers to disk, and so on.
– A server process performs work based on a client request. For example, these processes parse SQL queries,
place them in the shared pool, create and execute a query plan for each query, and read buffers from the database buffer
cache or from disk.

Note:
Server processes, and the process memory allocated in these processes, run in the database instance. The instance
continues to function when server processes terminate.

– A child process performs additional tasks for a background or server process.

The process structure varies depending on the operating system and the choice of Oracle Database options. For example,
you can configure the code for connected users for dedicated server or shared server connections. In a shared server
architecture, each server process that runs database code can serve multiple client processes.
Multiprocess and Multithreaded Oracle Database Systems
• Multiprocess Oracle Database (also called multiuser Oracle Database) uses several processes to run
different parts of the Oracle Database code and additional Oracle processes for the users—either one
process for each connected user or one or more processes shared by multiple users.
• Most databases are multiuser because a primary advantage of a database is managing data needed by
multiple users simultaneously. Each process in a database instance performs a specific job. By dividing the
work of the database and applications into several processes, multiple users and applications can connect
to an instance simultaneously while the system gives good performance.
• You must set the THREADED_EXECUTION initialization parameter to TRUE to run the database in threaded
mode. In threaded mode, some background processes on UNIX and Linux run as processes (with each
process containing one thread), whereas the remaining Oracle processes run as threads within processes.
• In a database running in threaded mode, PMON and DBW might run as operating system processes,
whereas LGWR and CMON might run as threads within a single process. Two foreground processes and a
parallel execution (PX) server process might run as threads in a second operating system process. A third
operating system process might contain multiple foreground threads. Thus, "Oracle process" does not
always mean "operating system process."
 Client Server Process
When a user runs an application such as a Pro*C program or SQL*Plus, the
operating system creates a client process (sometimes called a user process) to run
the user application. The client application has Oracle Database libraries linked into
it that provide the APIs required to communicate with the database.
Client processes differ in important ways from the Oracle processes interacting
directly with the instance. The Oracle processes servicing the client process can
read from and write to the SGA,
whereas the client process cannot. A client process can run on a host other than
the database host, whereas Oracle processes cannot.
For example
SQL> CONNECT SYS@inst1 AS SYSDBA
• Enter password: *********
• Connected to an idle instance.database.
On the client host, a search of the processes for either sqlplus or sample shows only the sqlplus
client process:
% ps -ef | grep -e sample -e sqlplus | grep -v grep clientuser

29437 29436 0 15:40 pts/1 00:00:00 sqlplus as sysdba

On the database host, a search of the processes for either sqlplus or sample shows a server process
with a nonlocal connection, but no client process:
% ps -ef | grep -e sample -e sqlplus | grep -v grep
serveruser 29441 1 0 15:40 ? 00:00:00 oraclesample
 Server Processes
Oracle Database creates server processes to handle the requests of client
processes connected to the instance. A client process always communicates with
a database through a separate server process.
Server processes created on behalf of a database application can perform one or
more of the following tasks:
1. Parse and run SQL statements issued through the application, including
creating and executing the query plan
2. Execute PL/SQL code
3. Read data blocks from data files into the database buffer cache (the DBW
background process has the task of writing modified blocks back to disk)
4. Return results in such a way that the application can process the information
 Dedicated Server Process

In dedicated server connections, the client

connection is associated with one and only one
server process.

On Linux, 20 client processes connected to a

database instance are serviced by 20 server
processes. Each client process communicates
directly with its server process. This server process
is dedicated to its client process for the duration of
the session.
The server process stores process-specific
information and the UGA in its PGA.
 Dedicated Server Process
A one-to-one ratio exists between the client processes
and server processes. Even when the user is not actively
making a database request, the dedicated server process
remains—although it is inactive and can be paged out on
some operating systems.

In the dedicated server architecture, the user and server

processes communicate using different mechanisms:
 The host operating system's inter-process
communication (IPC) mechanism is used to perform its
job, If the client process and the dedicated server
process run on the same computer.
 If the client process and the dedicated server process
run on different computers, then the program interface
provides the communication mechanisms (such as the
network software and Oracle Net Services) between
the programs.
 Shared Server Process
In shared server connections, client applications connect over a network to a dispatcher process, not a server process. For example, 20 client
processes can connect to a single dispatcher process.
The dispatcher process receives requests from connected clients and puts them into a request queue in the large pool. The first available shared
server process takes the request from the queue and processes it. Afterward, the shared server places the result into the dispatcher response
queue. The dispatcher process monitors this queue and transmits the result to the client.

Like a dedicated server process, a shared server process has its own PGA. However, the UGA for a session is in the SGA so that any shared
server can access session data.

In a shared server architecture, a dispatcher directs multiple incoming network session requests to a pool of shared server processes
The shared pool eliminates the need for a dedicated server process for each connection. An idle shared server process from the pool picks up a
request from a common queue. The potential benefits of shared server are as follows:

 Reduces the number of processes on the operating system

A small number of shared servers can perform the same amount of processing as many dedicated servers.
 Reduces instance PGA memory
Every dedicated or shared server has a PGA. Fewer server processes means fewer PGAs and less process management.
 Increases application scalability and the number of clients that can simultaneously connect to the database
 May be faster than dedicated server when the rate of client connections and disconnections is high.

Shared server has several disadvantages, including slower response time in some cases,
incomplete feature support, and increased complexity for setup and tuning. As a general
guideline, only use shared server when you have more concurrent connections to the
database than the operating system can handle.
 Overview of

Multitenant Architecture
Grid computing, a new IT architecture introduce that produces more resilient and lower cost enterprise information
system (IS). With grid computing, group of independent, modular hardware and software components can be
connected and rejoined on demand to meet the changing needs of businesses.
The concept of a multitenant database was introduced with Oracle 12c,
18c, 19c, and beyond. Within this framework, there exists a primary
database known as the Container Database (CDB), akin to a basket. This
CDB doesn't contain any user or application data itself; rather, it serves
as a container for multiple pluggable databases (PDBs), each isolated
within the CDB. Img * https://dotnettutorials.net/lesson/oracle-multitenant-architecture/

Each pluggable database operates independently within the container,

with users restricted to their respective PDBs. Access between users in
different PDBs is only possible through a database link, a topic we'll delve
into later. The DBA responsible for managing the Container Database is
referred to as the CDB Administrator, while those managing the individual
Pluggable Databases are known as PDB Administrators. However, it's
entirely feasible for a single DBA to handle both roles concurrently.
 Advantages of Multitenant Architecture

Oracle Multitenant, with its container database architecture, represents a pioneering approach tailored for cloud
environments. It introduces self-contained "pluggable databases" or PDBs for each application or tenant. From an
application's perspective, the PDB serves as the entire database, ensuring seamless operation without
modifications. Provisioning PDBs is swift, and their portability simplifies tasks such as load balancing or
transitioning to the cloud.
 Advantages of Multitenant Architecture

Multiple PDBs can be seamlessly integrated into a single Multitenant Container Database (CDB). For a database
administrator (DBA), the CDB serves as the central management point. Common tasks, such as upgrades, high
availability configurations, and backups, are streamlined at the CDB level, enabling efficient management of
numerous databases as a unified entity. However, granular control is retained when necessary, providing
flexibility.
Technical efficiency is significantly enhanced through shared infrastructure. A unified set of background
processes and a global memory area, known as the System Global Area (SGA), are shared among all PDBs.
Consequently, this architecture facilitates the consolidation of more applications per server, resulting in
substantial gains in operational efficiency.
Overview of

Data Guard
Overview

Oracle Data Guard is a robust solution ensuring enterprise data remains highly available,
protected, and recoverable in the event of disasters.
By offering a comprehensive suite of services, Oracle Data Guard facilitates the creation,
maintenance, management, and monitoring of one or more standby databases. These
standby databases serve as duplicates of the production database, ensuring data
integrity and availability. In the event of a planned or unplanned outage affecting the
production database, Oracle Data Guard seamlessly switches any standby database to
assume the production role, thereby minimizing downtime.
Overview

Moreover, Oracle Data Guard can complement traditional backup, restoration, and
clustering methods, enhancing data protection and availability. Its transport services are
also leveraged by other Oracle features such as Oracle Streams and Oracle Golden
Gate, ensuring efficient and reliable transmission of redo data from a source database
to remote destinations.
Furthermore, Oracle Data Guard offers administrators the flexibility to optimize
production database performance by delegating resource-intensive tasks such as
backups and reporting to standby systems, thus enhancing overall system efficiency.
An Oracle Data Guard configuration consists of one primary database and up to
thirty destinations, which can be geographically dispersed. These databases are
connected via Oracle Net, enabling communication between them regardless of their
location. Management of primary and standby databases can be done through either
the SQL command-line interface or the Oracle Data Guard broker interfaces, which
include a command-line interface (DGMGRL) and a graphical user interface
integrated into Oracle Enterprise Manager Cloud Control.
 Primary Database: The primary database serves as the main database accessed
by most applications. It can be either a single-instance Oracle database or an
Oracle Real Application Clusters (Oracle RAC) database.
 Standby Databases: Standby databases are transactionally consistent copies of
the primary database, maintained automatically by Oracle Data Guard through the
transmission and application of redo data. Standby databases can also be single-
instance Oracle databases or Oracle RAC databases.
Types of Standby Databases:
 Physical standby database: Maintains a physically identical copy of the primary
database, allowing for read-only access and patching in rolling fashion.
 Logical standby database: Contains the same logical information as the primary
database, enabling rolling upgrades and maintenance with minimal downtime.
 Snapshot standby database: Fully updatable standby database used for temporary
purposes, such as testing, with redo data applied upon conversion back to a
physical standby database.
 Overview of

Real Application Cluster (RAC)

RAC Architecture
 Real Application Cluster (RAC)
Real Application Clusters (RAC) is a solution designed to enhance the availability of Oracle DB
systems. It achieves this by clustering two or more nodes (instances) into a unified database
using shared disks, effectively eliminating single points of failure from the database side. Clusters
consist of interconnected computers or servers, presenting themselves as a single entity to end
users and applications. With Oracle RAC, you have the capability to cluster Oracle databases.

To implement RAC, Oracle utilizes Oracle Clusterware as the underlying infrastructure, binding
multiple servers together to function as a cohesive system. Oracle Clusterware serves as a
comprehensive cluster management solution, seamlessly integrating with Oracle Database. It is a
mandatory component for deploying Oracle RAC and enables both single-instance Oracle
databases and Oracle RAC databases to leverage the Oracle high-availability infrastructure.
Additionally, Oracle Clusterware facilitates the creation of a clustered storage pool that can be
utilized by any combination of single-instance and Oracle RAC databases.
 Real Application Cluster (RAC)

Oracle RAC, short for Oracle Real Application Clusters, is a feature embedded within Oracle
Database that facilitates the clustering of multiple interconnected servers, transforming them
into a unified database system. This clustering capability delivers heightened availability,
scalability, and performance enhancements for critical database applications.

In an Oracle RAC setup, numerous server nodes, also known as instances, share access to
a common pool of database files stored on shared storage. Each server node operates its
individual instance of the Oracle Database software, responsible for managing its designated
workload and data segment. These instances interact and synchronize through a high-speed
interconnect to maintain data consistency and coordination.
 Real Application Cluster (RAC)

Through Oracle RAC, the distribution of workload across the cluster can dynamically adjust, enabling
applications to effortlessly scale with changing demands. Additionally, it offers fault tolerance by
ensuring uninterrupted database operations in the face of server or network failures.

Overall, Oracle RAC stands as a robust solution tailored to deliver high availability, scalability, and
performance for large-scale database deployments, making it particularly suited for applications
necessitating continuous data access and minimal downtime.
Oracle Database can be configured in two fundamental ways: as a single instance (SI) database (non-cluster) or
as a Real Application Clusters (RAC) database.
In a single instance database, all components including the Oracle software, database files, memory, and
processes reside on one server. This setup entails a one-to-one relationship between the instance (memory and
processes) and the database (database files).
Conversely, Oracle RAC environments feature a one-to-many relationship between the database and instances.
Here, a single Oracle RAC database can accommodate up to 100 instances, all accessing one shared database.
All servers within an Oracle RAC environment must belong to the same Oracle Real Application Clusters.
 Overview of

Automatic Storage Management (ASM)

Overview of Automatic Storage Management (ASM)
Oracle ASM is Oracle's recommended storage management solution, offering an alternative to
conventional volume managers, file systems, and raw devices. It serves as both a volume
manager and file system for Oracle Database files, supporting single-instance Oracle Database
and Oracle Real Application Clusters (Oracle RAC) configurations.
Using disk groups to store data files, Oracle ASM manages disks collectively and evenly
distributes file content to eliminate hot spots and ensure uniform performance. Disk groups
facilitate dynamic addition or removal of disks without database downtime, with automatic
redistribution of file contents by Oracle ASM.
The volume manager functionality of Oracle ASM provides flexible server-based mirroring
options, including normal and high redundancy disk groups. Additionally, Oracle Managed Files
(OMF) simplifies database file management by automatically creating and naming files in
designated locations and conforming to file name constraints.
Overview of Automatic Storage Management (ASM)
Furthermore, Oracle ASM reduces administrative overhead by consolidating data storage into a
small number of disk groups, thereby improving I/O performance. It can coexist with other storage
management options, simplifying integration into existing environments.

Oracle ASM offers user-friendly management interfaces such as SQL*Plus, the Oracle ASM
Command Line Utility (ASMCMD), and Oracle ASM Configuration Assistant (ASMCA).
 Overview of (ASM) Instances

An Oracle ASM instance shares similarities with an Oracle Database instance, possessing a System
Global Area (SGA) and background processes akin to those in Oracle Database. However, due to its
streamlined tasks, the SGA of an Oracle ASM instance is considerably smaller. Additionally, Oracle ASM
minimally impacts server performance and does not mount databases; instead, it mounts disk groups to
make ASM files available to database instances.
Overview of (ASM) Instances
Installed in the Oracle Grid Infrastructure home before Oracle Database, Oracle ASM and database
instances require shared disk access. Oracle ASM instances manage disk group metadata,
encompassing disk membership, available space, file names, and data file extents. In clustered
environments, each node hosts an Oracle ASM instance, with multiple database instances potentially
sharing one ASM instance per node.
Failure of an Oracle ASM instance in a standard cluster causes database instances on that node to fail,
whereas in Oracle Flex ASM, database instances can access remote ASM instances. Unlike file system
driver failures, Oracle ASM instance failures do not necessitate OS restarts. In Oracle RAC
environments, surviving nodes automatically recover from ASM instance failures.
A single node configuration may include one Oracle ASM instance and multiple database instances. The
ASM instance manages metadata and allocates space for ASM files, responding to file creation or
access requests from database instances. Such a setup typically involves multiple disk groups, with one
ASM instance serving multiple database instances.
 Overview of (ASM) Instances

In an Oracle RAC environment, each node hosts one Oracle ASM instance serving multiple databases
within the cluster. These databases are consolidated and share two Oracle ASM disk groups. Figure 1-2
illustrates this configuration.
A clustered storage pool, managed by Oracle Clusterware, enables multiple single-instance Oracle
Databases to share disk groups without requiring an Oracle RAC license. Each node must have Oracle
Clusterware installed for disk group sharing, regardless of Oracle RAC installation. Although Oracle ASM
instances on separate nodes need not belong to an ASM cluster, they must be part of an ASM cluster to
communicate and share disk groups. Nodes outside an ASM cluster cannot share disk groups.
Overview of

Oracle Cloud
Overview of Oracle Cloud

What is Oracle Cloud?

Oracle Cloud is a comprehensive cloud computing platform provided by Oracle

that offers high-performance and cost-effective infrastructure services. It combines
the elasticity of public cloud with the control and predictability of on-premises
infrastructure. Key features include off-box network virtualization, which enables
provisioning of physical, dedicated hosts without hypervisor overhead, and
disaster recovery capabilities provided by availability domains and regions.
Overall, Oracle Cloud Infrastructure provides a robust and secure environment for
deploying and managing applications and workloads in the cloud.
Oracle Cloud is an extensive and integrated set of cloud services that spans a broad range of
categories, including compute, storage, networking, database, security, analytics, applications, and
more. It provides customers with the flexibility to build, deploy, and manage a wide variety of
applications and workloads, from simple web applications to complex enterprise solutions.
Oracle Cloud offers a comprehensive suite of cloud computing services, including:
 Infrastructure as a Service (IaaS): Provides on-demand computing resources, including virtual
machines, storage, and networking, allowing customers to quickly provision and scale
infrastructure as needed.
 Platform as a Service (PaaS): Offers a range of development and deployment tools and services,
including application development, database management, integration, analytics, and more, to
enable customers to build and deploy applications faster and more efficiently.
 Software as a Service (SaaS): Delivers a wide range of cloud-based applications and services,
including enterprise resource planning (ERP), customer relationship management (CRM), human
capital management (HCM), and more, to help customers streamline business processes and
drive innovation.
Oracle Cloud provides customers with a choice of deployment models, including public cloud, private
cloud, and hybrid cloud, to meet their specific business requirements and preferences. It also offers a
range of security features and controls to help protect data and applications in the cloud.
With Oracle Cloud, customers can benefit from high performance, reliability, scalability, and security,
enabling them to accelerate innovation, reduce costs, and drive business growth in the cloud.
 Oracle Database

Administration Tasks
 Evaluate the Database Server Hardware:
Assess how Oracle Database and associated applications can efficiently utilize available computer
resources.
 Install the Oracle Database Software:
Installation of Oracle Database server software along with any front-end tools and database
applications.
 Plan the Database:
Strategize the logical storage structure, overall database design, and backup strategy.
 Create and Open the Database:
Creation of the database structure followed by opening it for normal use.
 Back Up the Database:
Perform the backup strategy devised for the database structure.
 Enroll System Users:
Grant database access to users in line with the Oracle license agreement and assign appropriate
privileges.
 Implement the Database Design:
Develop the planned logical structure by creating tablespaces and database objects.
 Back Up the Fully Functional Database:
Conduct database backup once the implementation is complete, and backup after any structural
changes.
 Tune Database Performance:
Optimize database performance using Oracle Database's resource management feature.
 Download and Install Release Updates:
Regularly update the Oracle software with Release Updates and Release Update Revisions.
 Roll Out to Additional Hosts:
Extend the configured, tuned, patched, and tested Oracle Database installation to other hosts when
necessary.
Unit 1.1 Introductions
1. Overview of Oracle Database
2. Relational Database Concept
3. Overview Oracle Database Architecture
4. Overview Oracle Multitenant Architecture
5. Overview Oracle Data Guard
6. Overview Oracle Real Application Cluster (RAC)
7. Overview Oracle Automatic Storage Manager (ASM)
8. Oracle Cloud
9. Database Administration Tasks