A database is a set of files located on disk that store data.

An instance is a set of memory structures

that manage database files. The instance consists of shared memory structures and a set of Oracle
processes.
Let's describe the instance first. When instance is started, Oracle database allocates a memory calle
d System Global Area, or SGA, and starts Oracle background processes. System Global Area is a gr
oup of shared-memory structures known as SGA components that contain data and control informati
on for one Oracle database instance. Information stored in the SGA is shared by all server and back
ground processes.
Examples of data stored in the SGA include cached data blocks read from data files and shared SQL
areas. The background processes of the Oracle instance manage memory structures, asynchronous
ly perform I/O to write data to a file on a disk, and perform general maintenance tasks. Each backgro
und process has a unique name and a unique responsibility in Oracle Database system.
Every running Oracle Database is associated with at least one Oracle Database instance. Because
an instance exists in memory and a database is a
set of files on disk, an instance can exist without a database, and a database can exist without an in
stance.
The second part of a basic database system is Oracle Database. Oracle Database is simply a set of
files stored in the storage system. There are three basic database files-- control files, redo log files, a
nd data files. Control files contain database structure and synchronization information. Redo log files
store changes made to the database. User data is stored in a set of data files which physically reside
on a disk in the storage system.
Data files are organized in tablespaces. Each tablespace contains one or more data files. When req
uested by SQL statement, data is read from data file and stored in SGA or in the Program Global Ar
ea, PGA, of a server process.
On the left side of the diagram, we can see the user process. User process is usually not running on
the same host as a database server, but rather, it runs on a client computer. User process runs appli
cation like SQL Plus, from which all requests are sent over the Oracle Net software to server process
spawned by the listener.
A listener process is not visible in this diagram, but it is the process which enables remote connectio
n to a database server. It usually runs on port 1521, but database administrators can choose a differ
ent port if needed. So SQL request is sent from the user process over the Oracle Net to the server pr
ocess. Server process has access to both memory structures, as well as to storage structures of the
database server. It will execute a SQL command, returning results back over the Oracle Net to the u
ser process.
In a dedicated server architecture shown on this slide, each server process also has its own private
memory called Program Global Area, or PGA. PGA is used to store a server's process private data n
ot shared with other processes. This concludes the topic on Oracle Database Server architecture.

In general, there are two types of Oracle databases, a non-container database, or non-CDB, which i
s a traditional Oracle database that cannot contain pluggable databases. This type of database was
used in previous Oracle database software versions. Although current version of Oracle database so
ftware doesn't support non-CDBs anymore, some customers may still use previous versions of Oracl
e software with non-CDB databases.
And, a multitenant container database, which is a single physical database that contains zero, one, o
r many user-created pluggable databases. The multitenant architecture enables an Oracle database
to be a multitenant container database. A pluggable database is a portable collection of schemas, sc
hema objects, and non-schema objects that appear to an Oracle client as a non-CDB database.
Multitenant architecture is using a concept of containers. Container is a logical collection of data or
metadata within the multitenant architecture. Some containers are pre-created by Oracle. Some cont
ainers are created by users.
Pluggable database is simply a container which contains a portable set of database schemas and da
tabase objects. Pluggable databases can be easily unplugged from and plugged into any other conta
iner database, effectively moving data for one or more PDBs between alternate databases.
Let's have a look on different container types a CDB can contain. Every CDB has the following conta
iners-- the system container, which is the logical container for the CDB itself and includes the CDB$
ROOT container and all PDBs in the container database. There is exactly one system container in e
ach container database.
Each container database also contains exactly one root container. The root container stores Oracle-
supplied metadata and common users. An example of metadata is the source code for Oracle-
supplied PL SQL packages.
A common user is a database user known in every container. The root container is named CDB$RO
OT. In each CDB, there is exactly one seed PDB. The seed PDB is a system-supplied template that
the CDB can use to create the new PDBs. The seed PDB belonging to root container is named PDB
$SEED. You should not add or modify objects in PDB$SEED.
Each container database contains zero or more user-created PDBs. A PDB contains data and code r
equired for a specific set of features. For example, a PDB can support the specific applications, such
as human resources or sales application. PDB can belong either to system container or to an applica
tion container.
If a PDB belongs to an application container, then it is an application PDB. An application seed is an
optional application PDB that acts as a user-created PDB template, enabling you to create new appli
cation of PDBs rapidly. And finally, a CDB contains zero or more application containers.
Application container consists of exactly one application root and the PDBs plugged into this root. W
hereas the system container contains the CDB$ROOT and all the PDBs within the container databas
e, an application container includes only the PDBs plugged into the application root.
An application root belongs to the CDB$ROOT and no other container. Application container enable
s sharing of user defined-objects like tables and views across multiple application PDBs, which is not
possible in PDBs as belonging to the system container.
Let's have a look on this diagram this diagram represents the relationship between containers and e
xplores application container in more details. Each CDB has exactly one CDB$ROOT container, exa
ctly one PDB$SEED container, and zero or more user-created PDBs. An application container consi
sts of an application root, optional application seed, and zero or more application PDBs.
In non-CDB architecture used by Oracle previously, each database always contains its own instance
-- that means its own set of background processes, its own SGA, and its own copy of Oracle-
supplied data and metadata. Because, in multitenant architecture, all PDBs in the same CDB share
one set of background processes, the same memory structures, and one set of Oracle-supplied data
and metadata stored in CDB$ROOT container, multitenant architecture is consuming less resources
and is more efficient.
In this diagram, we have more detailed representation of multi-tenant architecture. In this slide, we c
an see that in addition to previously-mentioned shared components, PDBs is container database are
also sharing some database files-- control files, redo log files, and, optionally, undo tablespaces. Eve
ry Oracle database has one or more control file.
Control file
is a small binary file which contains the physical structure of the database. It contains various metad
ata-- for example database name, synchronization information, list of data files and redo log files for t
he CDB, backup metadata, and so on. The redo log files store all changes made to the database as t
hey occur. Redo log files are most crucial structures for recovery operations.
Undo tablespaces are used to store undo records. Undo records are used to roll back or undo chang
es to the database when needed. This slide also demonstrates that each PDB has its own set of dat
a files containing user-defined application data and corresponding metadata.
This concludes the topic on Oracle multitenant architecture.

In a nonclustered database server configuration, each database instance is associated with only one
container database. Data files are stored on local storage. If there are multiple container databases
on the same server in a nonclustered configuration, then there is a separate and distinct database in
stance for each container database. Failure of that server will inevitably lead to loss of all instances f
or each container database. This makes this database server a single point of failure.
In a clustered database servers configuration, each database usually has multiple instances on sepa
rate servers for the same shared database. Data files are stored on shared storage. Oracle Real Ap
plication Cluster Database is an example for a cluster system that combines the processing power of
multiple interconnected computers to provide system redundancy, scalability, and high availability.
Oracle Real Application Cluster provides customers with the highest database availability by removin
g individual database servers as single point of failure. In a clustered server environment, the databa
se itself is shared across a pool of servers, which means that if any server in the server pool fails, th
e database continues to run on surviving servers. Oracle Real Application Cluster not only enables c
ustomers to continue processing database workloads in the event of a single server
Failure. It also helps to further reduce cause of downtime by reducing amount of time databases are
taken offline for planned maintenance operations. Most planned maintenance operations in Real Ap
plication clustered databases can be performed in a rolling fashion, one database server at a time, le
aving some of the instances available at any point in time. This concludes the topic on Oracle Datab
ase Server configurations.

Sharding is using a shared-nothing database architecture, because shards do not share physical re
sources such as CPU, memory, or storage devices. Shards are also loosely copied in terms of softw
are. They do not run clusterware. From a database administrator's perspective, an SDB consists of
multiple databases that can be managed either collectively or individually. However, from an applicat
ion developer's perspective, an SDB looks like a single database. The number of shards and the dist
ribution of data across them are completely transparent to database applications.
Horizontal partitioning used in sharded databases involves splitting a database table shards so that
each shard contains the table with the same columns but a different subset of roles. The diagram in t
he slide shows an unsharded table on the left, with the rows represented by different colors. On the r
ight, the same table data is shown horizontally partitioned across three shards or independent datab
ases. Each partition of the logical table resides in a specific shard. We refer to such a table as a shar
ded table.
Shards are typically hosted on dedicated servers. These servers can be commodity hardware or eng
ineered systems. The shards can run on
a single instance or Oracle RAC databases. They can be placed on-premises, in a cloud, or in a hyb
rid on-premises and cloud configuration.
The key benefits of sharding are linear scalability and complete fault isolation for the most demandin
g OLTP applications. Sharding is intended for custom applications that are suitable for a sharded dat
abase architecture. Applications that use sharding must have a well-defined data model and a data d
istribution strategy that primarily accesses data using a sharding key. Examples of sharding key inclu
de customer ID, account number, or country ID.
This includes the topic on Oracle Database sharding architecture.

In order to access Oracle Database interactive architecture diagrams, navigate to Oracle Help Cente
r first. Then click Database, Oracle Database,
and What's New link. In the Interactive Architecture Diagram section, click either the Single Instance
link or the Clustered link, depending on your preferences. This concludes the topic on interactive Ora
cle Database architecture diagrams.

On this page, click Database icon. In Database Documentation site, click Oracle Database link. In Or
acle Database Documentation page, click What's New. In Interactive Architecture Diagram section, t
here are two useful links. Single Instance link, which is covering single instance database architectur
e, and Cluster Database link, which is covering cluster database architecture.
Let's click Single Instance link. This will take us to the first diagram on single instances. In order to n
avigate to the next diagram, to the previous diagram, or to the first diagram, you can use the set of b
uttons in top left corner. In order to display all instructions on how to use these diagrams, click Show
Instructions.
Each diagram is basically a set of objects. Some of the objects are clickable. If you right click a clicka
ble object, you will be taken to a corresponding topic in Oracle Documentation site. If you left click a
clickable object, if there is more detailed diagram covering this object, it will be displayed.
If you would like to learn offline, there is a possibility to click Show PDF. In this case, all diagrams an
d comments are exported to a PDF file. With this, demo
on interactive architecture diagrams comes to an end.

You have to realize that you connect client applications to the database instances, not to the databas
es. A connection is a physical communication pathway between a client process and a database inst
ance. A user session is a logical entity that represents the state of the current user login to the datab
ase instance. A session lasts from the time
a user is authenticated until the time the user disconnects or exits the client application.
Before a user session is created, authentication process must take place. There are several ways in
which authentication can be performed. For administrative tasks, administrators will usually connect
directly to host on which database server is running. After configuring a connection to required install
s via operating system environment variables, authentication can be performed by operating system.
First example in this slide is demonstrating local connection with operating system authentication. He
re, the user is connected directly to operating system where database server is running. If user in op
erating system is a member of predefined operating system group, no user name or password is req
uired for authentication.
Operating system environment variables are used to indicate to which database installs this connecti
on should be established. This type of connection is usually used by database administrators to start
up, shut down, database or perform some other maintenance operations. As these DBA clouds here
indicate, that session will connect with administrator's privileges needed for startup or shutdown.
For regular database user connections, client tool usually resides on a different host, not the same a
s Oracle database server host. This time, remote connection wireless is needed, and authentication i
s performed by database using user name and password pair.
Second example is demonstrating such a connection. Before at sign, username and password is spe
cified. After at sign, connection information is provided. This particular example is demonstrating Eas
y Connect. Main advantage of Easy Connect is that no configuration files are needed. To successfull
y establish a collection, Easy Connect requires hostname, port of the listener, and instant service na
me registered with the listener.
If the port of the listener is default, 1521, then column and listener port can be skipped. In addition to
EasyConnect, there are some other alternative methods of connecting to Oracle Database instance
via listener. The local naming method is using net service names specified in Oracle Net Configurati
on file name tnsnames.ora.
Each net service name maps to a connect descriptor. Client is using a short connect identifier specifi
ed after at sign. Disconnect identifier is mapped to complete connect descriptor containing hostname
, port number, and service name. During a connection, Connect Identifier is searched in tnsnames.or
, and if found, corresponding connect descriptor is used.
This concludes the topic on connecting to Oracle Database instance
I will open the terminal. I will put it to a full-screen mode. I am going to demonstrate three types of co
nnections to Oracle database instance. The first type is a local connection usually used by database
administrators.
Database administrator has to establish a connection to the Linux environment first. The user under
which the DBA is connected is member of predefined operating system group, which was declared d
uring the installation as a group for DBAs. That basically means that you don't need to know any use
rname or password in order to connect with administrator privileges, to the database but you have to
set some environment variables first.
The first variable is $ORACLE_SID. The second variable is $ORACLE_HOME. As you can see, both
variables are empty at this moment in my environment. There is a shell script called oraenv which w
as designed to set all variables appropriately, but I have to provide $ORACLE_SID, which is the syst
em identifier of the instance to which I would like to connect. So after that, all the variables will contai
n proper values.
So this is the $ORACLE_SID, and this is the $ORACLE_HOME, which is the directory to which the
Oracle database software was installed. Because I
am member of operating system group DBA, I can right now establish a connection without providing
username and password. So let's do it-- sqlplus / as
sysdba. After running this command, I will be connected as user sys, and my container database, as
you can see, contains two user-defined PDBs called orclpdb1 and orclpdb2.
Next connection type I would like to demonstrate is usually not used by DBAs, rather by regular data
base users. These users usually do not have an access to the operating system that the database s
erver is running, but they can create a connection via listener. This connection type is called Easy C
onnect. The main advantage of Easy Connect is that no configuration files are needed.
In orclpdb1 one pluggable database, I have a user called HR. So I will demonstrate a connection to t
his HR schema wire listener running on port 1521. So what I have to do is to specify sqlplus userna
me, and after at sign, I have to provide a hostname.
After colon, I have to specify the port of the listener. And after slash, I have to specify the Oracle serv
ice name with which the instance is registered with listener-- orclpdb1. Of course, I have to specify th
e password, and I'm in.
So I have a look. show user says "HR". show content on name will show me I'm connected to the plu
ggable database orclpdb1. And now, I can start issuing SQL commands.
The last connection type I would like to demonstrate here is using a local naming. Local naming is th
e method of translating connect identifier to connect descriptor. Under $ORACLE_HOME/network/
admin, there is usually file called tnsnames.ora This tnsnames.ora file will contain pairs. So let me sh
ow you.
In the file, the first part is called Connect Identifier or Oracle Net Service Name, and the second part
will contain full connect descriptor. In the connect descriptor, you have to specify the host, the listene
r port, and the service name to which you would like to connect.
So this is the connection to the root container, orclpdb2 and orclpdb1 connections are visible at the b
ottom of this file. So right now, if you have such a file, what you can do, you can connect this way-- H
R@-- and just to specify the connect identifier from the file.
And I'm again in and connected to container orclpdb1 as a user HR. With this, demo on connecting t
o an Oracle database instance comes to an end.

Each tool has its own purpose. Some operations can be performed in more than one tool. Choosing
a tool for a task often comes down to personal preference. Some DBAs and developers prefer comm
and line tools. Some prefer a graphical user interface tools.
Most frequently used command line tools are SQL Plus and SQLcl. SQL Plus is an interactive and b
atch-ready tool that is installed with every Oracle Database server or client installation. It is the most
basic Oracle Database tool, with the basic command line interface commonly used by users, adminis
trators, and programmers.
Oracle SQL Developer Command Line, SQLcl, is a free command line interface for Oracle Database
. It allows you to interactively or batch execute SQL PL/SQL commands. SQLcl provides inline editin
g, statement completion, and command recall for feature rich experience while also supporting your
previously written SQL Plus script.
You can start SQL Plus from the command line or from the Start Menu on Windows client. SQL Plus
Command Line Interface can be used to execute SQL Plus, SQL, and PL/SQL commands to perfor
m following activities. You can enter, edit, run, store, retrieve, and save SQL commands and PL/SQL
blocks.
You can also format, calculate, store, and print query results. Using a Describe command, you can li
st columns definitions for any table. SQL Plus is also used to perform database administration tasks.
First example on this slide is demonstrating a typical DBA session in SQL Plus.
DBA will connect to host where Oracle Database instance is running first, then it will set appropriate
operating system and write environment variables, and it will use operating system authentication to
connect to a database instance. After successful authentication, DBA can start executing commands
.
In this example, Show User is executed to display currently connected user. Second example is displ
aying typical non-DBA session, which is running script file name script.sql. After specifying binary, us
ername and password is specified. After first at sign, connect identifier is provided.
This example assumes tnsnames.ora configuration file is used to translate connect identifier to comp
lete connection string. After next @ sign, file name of script file is specified. Script file can contain a
mixture of SQL, PL SQL, and SQL*Plus commands.
In addition to previously-mentioned command line tools, DBAs and developers are frequently using t
he following graphical user interface tools. SQL Developer is a free graphical user interface which all
ows database users and administrators to do their database tasks in fewer clicks and keystrokes. Or
acle Database Configuration Assistant is a tool for creating and configuring on Oracle Databases.
Enterprise Manager Database Express is a web-based database management tool that is built inside
the Oracle database. It supports key performance management and basic database administration f
unctions. Enterprise Manager Cloud Control is system management software that delivers centralize
d monitoring, administration, and lifecycle management functionality for complete IT Infrastructure, in
cluding systems running Oracle and non-Oracle technologies. Let's have a closer look on these tools
.
Oracle SQL Developer is free, integrated development environment that simplifies the development
and management of Oracle database in both traditional and cloud deployments. SQL Developer offe
rs complete end-to-end development of your PL SQL applications, a worksheet for running queries a
nd scripts, a DBA console for managing the database, a Reports interface, a complete data modelin
g solution, and a migration platform for moving your third-party databases to Oracle.
Next, I will cover Database Configuration Assistant. Database Configuration Assistant is a tool for cr
eating and configuring an Oracle database. DBCA can be launched by the Oracle Universal Installer,
depending upon the type of install that you select. If you choose to Create and Configure Database, t
hen Oracle Universal Installer will start DBCA at the end of the installation to configure the database.
If you choose to only install the database software using Oracle Universal Installer, then you must m
anually run DBCA after the installation to create and configure database.
DBCA is important tool for creating container databases and pluggable databases. In addition to dat
abase creation, it is also able to configure existing databases, delete databases, manage templates,
manage pluggable databases, and manage Oracle real application cluster database instances. You
can run DBCA in interactive mode or non-interactive/silent mode. Interactive mode provides a graphi
cal interface and guided workflow for creating and configuring a database. Non-interactive/silent mod
e enables you to script database creation. You can run DBCA in non-interactive silent mode by speci
fying command line arguments, or response file, or both.
Oracle Enterprise Manager Database Express is a lightweight tool that you can use to manage a con
tainer database and all of its pluggable databases except the SEED$PDB. It provides an out-of-box
browser-based management solution, performance monitoring, configuration management, administ
ration, diagnostic, and tuning. Enterprise Manager Express uses a web-based console, communicati
ng with the built-in web server available in XMLDB.
Enterprise Manager Express connection is leveraging Oracle Listener and shared server architectur
e. As requests from the console are processed, the Enterprise Manager Express servelet handles th
e requests, including authentication, session management, compression, and caching. The servelet
passes requests for reports to the common reporting framework and actions requiring shell files to th
e file manager. This architecture is illustrated in the slide.
Enterprise Manager Express is available only when database is open. This means that Enterprise M
anager Database Express cannot be used to start the database instance. Other operations that requi
re that the database change state, such as Enable or Disable Archive Look Mode, are also not availa
ble in Enterprise Manager Express. Enterprise Manager Express is configurable with a single click in
Database Configuration Assistant.
Oracle Enterprise Manager Cloud Control is Oracle's management platform providing a single locatio
n for managing all your Oracle deployments, whether they be in your data centers or in Oracle Cloud
. Through deep integration with Oracle's product stack, Enterprise Manager Cloud Control provides
management and automation support for Oracle applications, databases, middleware, hardware, an
d engineered systems.
Enterprise Manager Cloud Control 13c includes the following features. Enterprise-ready framework,
which provides modular and extensible architecture, self-updatable entities, and centralized incident
management. Unified cloud management, which provides complete lifecycle management for board
on-premises cloud and platform-as-a-service services on Oracle Cloud. Chargeback and capacity pl
anning, which provides chargebacks based on target types and uses automatic workload repository
warehouse to consolidate AWR reports from multiple databases across the enterprise.
Exadata and Exologic management provides an integrated view of the hardware and software in an
Exadata and complete lifecycle management for Exalogic system. Configuration management provid
es an integrated set of tools, agentless discovery, and integration with My Oracle Support. Provisioni
ng and patching provides profiles for provisioning known configurations, user-defined deployment pr
ocedures, and a software library integrated with self-updating capabilities. Application Quality Manag
ement provides database replay, applications server replay, real application testing integrated with d
ata masking, and test database management that includes application data model.
Database management provides management of Oracle database systems, including performance
management and change lifecycle management. Middleware management provides a complete man
agement of middleware systems. And finally, applications management, which provides managemen
t of fusion applications.
This slide shows you at a glance which tool can be used to perform which task. As you can see, all t
he listed tools can create container databases or pluggable databases. Some tools can create plugg
able databases only. For exporting architecture, DBCA and Oracle Universal Installer cannot be use
d.
Many other specialized tools are used to assist with database administration. DBA is using them to
manage all components of database system. The tools include Listener Control to manage listener,
Oracle Net Configuration Assistant and Oracle Net Manager to manage Oracle Net configuration file
s, Automatic Diagnostic Repository command interpreter to manage logs and trace files, SQL*LOAD
ER to load data from flat files, Oracle Data Pump Import, and Oracle Data Pump Export to export or i
mport data from or to Oracle database. This list doesn't cover all the tools available, such as Recove
ry Manager, which is used for backup and recovery purposes.
This concludes the topic on Oracle tools.
I would like to start with a graphical user interface tool called Oracle Enterprise Manager Database E
xpress. Enterprise Manager Database Express is a lightweight tool for basic database administration
. So I am going to connect to a pluggable database called orclpdb1, which belongs to container data
base orclcdb.
On the Home page of the pluggable database on the left side, you can see a status of the pluggable
database, incidents generated in last 24 hours, as well as running jobs. On the right side, basic perfo
rmance statistics, resource consumption, and SQL statements monitored in last hour. From the confi
guration manual, you can access initialization parameters. If the initialization parameter is modifiable
at the PDB level, you can change it. You can also access, on the memory management page, basic
SGA and PGA-related statistics.
In the Storage menu, you can manage your tablespaces. You can create new tablespaces, drop tabl
espaces, or you can add data files to existing tablespaces. In the Security menu, you can manage y
our users, roles, and profiles. You can create the new users, or you can change characteristics of exi
sting users. You can grant system privileges, object privileges, and roles to your users, and also, you
can revoke them.
In the Performance menu, you can access Performance Hub. Performance Hub provides a consolid
ated view of all performance data in a single page. You only need to select the time range using a ti
me picker at the top right of the page, and the Detail step will show the performance data for
the selected period.
Performance Hub organizes performance data into different apps like activity, workload, and monitor
ed SQL statements. Let's have a look on this statement, which is currently executing in my environm
ent. By clicking SQL ID, you will be taken to a page with more detailed execution statistics. You can
access time and rate statistics, I/O statistics, as well as plan statistics. So Enterprise Manager Expre
ss is a useful DBA tool for basic administration and performance monitoring.
The next tool I would like to demonstrate is a command-line tool called SQLcl SQLcl is is SQL Devel
oper Command Line although it looks similar to SQL*Plus, SQLcl is based on
a Java engine, and that's why it is more powerful.
So let me demonstrate some commands you can use in SQLcl. SQLcl can be used by database ad
ministrators to start up or shut down pluggable databases, or by regular users. The binary is called S
QL, and after that, you have to provide the username, at sign, pluggable database name, which is or
clpdb1, as sysdba if I would like to demonstrate startup and shutdown, and I have to provide a pass
word.
So right now, I am connected using SQLcl to my orclpdb1 database. Let's verify it. show
pdbs should display just this one PDB, orclpdb1.
Let's run shutdown immediate, which will close pluggable database. show pdbs will confirm. After sta
rtup, you can make pluggable database available again to non-DBA users.
In the second part of the SQLcl demo, we will use non-DBA connection. So let me connect as a user
HR to my overseas orclpdb1. And let's set logical page size to 50. If I run a select command, like sel
ect * from countries, result of this command is displayed the same way as in SQL*Plus.
In SQLcl, you have more options. You can now set SQL format CSV, and the same data will be displ
ayed in different format. So here you are, Comma-Separated Values format. If you like JSON, set S
QL format JSON, and the same data will be displayed in JSON format. If you prefer XML, SET SQL
FORMAT XML, and the same data will be displayed in XML format. If you would like to reset it back t
o the default, set SQL format default.
So right now, we are back to the SQL*Plus format. You can also define aliases. alias job
count=select count(*) from
jobs. After alias is defined, you can simply call alias, and the associated Select will be executed.
Next, I would like to demonstrate repeat command. Let's imagine you are running a select like this--
select to char sysdate from dual, which will display current time. Let's repeat last command five time
s with delay of three seconds. First run, second run, third run, fourth run, and fifth run. Nice, isn't it?
SQLcl has a history command. Like an operating system, you can use arrows. Can you see? I'm just
pressing the arrow up and arrow down. So you can just navigate to the command you would like to e
xecute again and press Enter. You can also have a look how many times each command was issue
d. So here, you can see that I run 11 times select * from countries.
So both tools I already demonstrated were able to start up or shut down pluggable database. Let's h
ave a look on something else. As you probably know, in order to establish a remote connection, liste
ner must be running. Listener has its own tool. It's called lsnrctl. So if I run lsnrctl
status, the status of the listener is displayed. I can see a port on which it is listening, also the service
s which are registered with the listener.
So when I run lsnrctl stop, listener will go down. After that, SQL*Plus attempt to use the listener will f
ail. orclpdb1, and let's provide a password. As you can see, I am receiving TNS:no listener error mes
sage. In order to start up the listener again, use the same tool-- lsnrctl start. Let's try the connection
again. sqlplus system orclpdb1, and now connection succeeds.
With this, demo on Oracle tools comes to an end.

It is important to plan how the logical structure of the database will affect system performance and v
arious database management operations. For example, before creating any tablespaces for your dat
abase, you should know how many data files will make up the tablespace, what type of information w
ill be stored in each tablespace, and where the data files will be physically stored.
Information such as the availability of network gated storage and bandwidth for the private storage n
etwork is also important. If storage area networks are going to be used, knowing how the logical volu
mes are configured is useful. When planning the overall logical storage of database structure, take in
to account the effects that the structure will have when the database is actually created and running.
You may have database objects that have special storage requirements due to type or size.
Plan
the relational design of the database objects and the storage characteristics for each of these object
s. By planning the relationship between each object and its physical storage before creating it, you c
an directly affect the performance of the database as a unit. Be sure to plan for the growth of the dat
abase.
In distributed database environments, this planning stage is very important. The physical location of f
requently accessed data affects application performance. During the planning stage, develop a back
up strategy for the database. You can alter the logical structure or design of the database to improve
backup efficiency.
Different types of databases have their own specific instance and storage requirements. Oracle Data
base Configuration Assistant includes templates for creation of these different types of databases. T
here are the following templates available. General-
purpose template, which is suggested for general-purpose or transaction processing usage, such as
working with transactions and storing them for a medium length of time. OLTB of the workload is use
d, for example, in billing systems for a software house.
Data warehouse template should be used for storing data for long periods and retrieving them in rea
d operations. The slide lists
a few examples like research and marketing data or federal tax payments. And finally, custom templ
ate. This one is suitable for customized databases that do not fit into the general purpose or data war
ehouse template. An example is combined OLTB and data warehouse functionality.
Before creating a new database, you should decide which character set will be used. When compute
r systems process characters, they use numeric codes instead of the graphical representation of the
character. An encoded character set maps numeric codes to characters that
the computer or terminal can display or receive. Different character sets support different character r
epertoires.
The character set is chosen at the time of database creation. Choose the correct character set that b
est meets your business requirements now and in the future, because it can be challenging to chang
e character sets later on. For best performance, choose a character set that avoids character set con
version and uses the most efficient encoding for the languages desired.
Single-byte character sets result in better performance then multi-byte character sets, and they also
are the most efficient in terms of space requirements. However, single-byte character sets limit how
many languages you can support. To choose your correct database character set, evaluate your curr
ent and future business requirements, as well as technical requirements. For example, the XML and
Java standards required UNICODE.
There are two main groups of encoding schemas, single-byte character sets and multi-byte characte
r sets. In single-byte character sets, each character occupies one byte. Single-bytes 7-bit encoding s
chemas can define up to 128 characters. Single-byte 8-bit encoding schemas can define up to 256 c
haracters.
An example of 7-bit character set is American Standard Code for Information Interchange, ASCII. 7-
bit American US-7-ASCII. An example of 8-bit character set is International Organization for Standar
d, ISO-8859-1, West European, WE8ISO8859P1.
A varying-width multi-byte character set is represented by one or more bytes per character. Multi-
byte character sets are commonly used for Asian language support. Unicode belongs to this group.
Unicode is a universal encoded character set that enables information from any language to be store
d using a single character set. Unicode provides a unique code for every character, regardless of the
platform, program, or language. In Oracle database, the AL32U/TF8 character set supports the lates
t version of Unicode standard.
The Unicode standard has been adopted by many software and hardware vendors. Many operating
systems and browsers now support Unicode. Unicode is required by standards such as XML, Java, J
avaScript, LDAP, and WML. In general, Oracle recommends the use of Unicode for all new database
s because it is the most flexible character set and avoids future conversions. This concludes the first
part of the topic on Oracle database creation using DBCA.
Let's continue with an explanation of how character sets are used. The NLS_LANG environment vari
able defines a client terminal's character encoding scheme. Different clients can use different encodi
ng schemes. Oracle NLS_LANG on the client side with the database character set and performs a c
onversion if required.
When the database character set and the client character set are the same, the database assumes t
hat the data being sent or received is of the same character set, so no validations or conversions are
performed. Character set at conversion may be required in client-server environment if a client applic
ation resides on a different platform then the server and if the platforms do not use the same charact
er encoding schemes.
Character data passed between the client and the server must be converted between the two encodi
ng schemes. Character conversion occurs automatically and transparently through Oracle Net. Invali
d data usually enters a database when the NLS_LANG environment variable is not set properly on th
e client.
The NLS_LANG value should reflect the encoding of the incoming data. When the NLS_LANG envir
onment variable is set appropriately, the database can automatically convert incoming data from the
client operating system. When the NLS_LANG environmental variable is not set appropriately, the d
ata entering the database is not converted properly.
For example, let's suppose that the database character set is Unicode, AL32UTF8. The client is on E
nglish Windows operating system, code page WE8MSWIN1252. And the NLS_LANG setting on the
client is incorrect, AL32UTF8. Data entering the database is encoded in WE8MSWIN1252 and is not
converted to AL32UTF data because the NLS_LANG setting on the client matches the database cha
racter set.
The Oracle Database Server assumes that no conversion is necessary. Data is not converted proper
ly, and invalid data is entered successfully into the database. Character codes from WE8MSWIN125
2 is interpreted by server as completely different character with the same code in AL32UTF8 charact
er set.
When another client with proper NLS settings, which is WE8MSWIN1252, is retrieving the same char
acters, this time, conversion will occur, causing completely different characters to be displayed for th
e second client. Unfortunately, no error or warning is displayed.
This slide lists various tasks which can be performed by Database Configuration Assistant. Oracle D
atabase Configuration Assistant is a tool for creating and configuring an Oracle database. You can u
se DBCA to create a database from a template supplied by Oracle or from a template that you create
. A DBCA template is an XML file that contains information required to create a database.
Select the template suited to the type of workload your database will support. If you are not sure whi
ch to choose, then use the General Purpose or Online Transaction Processing template. You can als
o create custom templates to meet your specific workload requirements.
The information in templates includes database structures, database options, initialization parameter
s, and storage attributes. Seed templates contain also backup of seed database. Templates can be
used just like scripts, but they are more powerful than scripts because you have option of duplicating
a database from a seed template. Duplication saves time because you copy the files of an existing d
atabase, referred to as a seed database, to the requested location.
For a container database, you can use DBCA to perform pluggable database operations. You can cr
eate, delete, and unplug PDBs. You can also use DBCA to change the configuration of an existing d
atabase or delete databases.
You can also create a database using the non-interacting silent mode of DBCA. Non-interactive silen
t mode enables you to script database creation. You can run DBCA in non-interactive silent mode by
specifying command line arguments, a response file, or both.
A response file is a text file typically recorded during graphical user interface DBCA session. It recor
ds all your responses during DBCA dialogues. As it is a text file, it can be also edited using a text edi
tor to allow more customization.
In this slide, we can see two examples of running DBCA in silent mode. First example will create a n
ew container database named ORCL with one PDB named PDB1. Second example will delete datab
ase ORCL. This concludes the topic on database creation using Database Configuration Assistant.

Again, Oracle Linux machine will be used, so let's connect to it first. After setting environment to 19C
database software, I can simply type DBCA to start Database Configuration Assistant. On
the first page, I will select Create a Database option. On the second page, Advanced Configuration.
Here, I will simply press Next, as I am happy with general purposal of transaction processing templat
e, which is the default. I have to specify content and database name first, CDB1. And I will create jus
t one pluggable database called PDB1. I will inherit database storage attributes from template.
And because we are not going to specify fast recovery area or enabling archiving mode, I will simply
press Next here. On this page, you can choose with which of these
scenario you would like to register your container database. Because Listener running on port 1521 i
s fine, I will simply press Next.
We are not going to configure database vault or label security, so I will simply press Next here. Here,
you can change SGA size or PGA size. You can change character set, or you can add sample sche
mas to your database. I will simply press Next.
On this page, you can configure Enterprise Manager Database Express Port or you can register it wit
h Enterprise Manager Cloud Control. On this page, I will specify one password for all administrative
accounts.
On the last page, you can specify whether you would like DBCA to create database, and/or save as
a database template, and/or generate a database creation script. In this demo, I will simply create a
database. After pressing Finish button, database creation process will start.
After approximately 15 minutes, CDB1 Container Database is created. So I will close DBCA now, an
d we will check if the database was created properly. So first of all, let's set environment to CDB1. C
onnect to CDB1, and let's see what is the status of the PDBs.
As we can see, PDB1 is opening read/write mode, so it looks like everything is working as expected.
I would like to demonstrate DBCA in silent mode. Because resources in our environment are limited,
I would like to shut down CDB1 first.
So CDB1 is down, and let's create a new container database called CDB2. In order to avoid typos, I
put the command to a shell script. So let's have a look on the shell script. Here, you can see that I wil
l call DBCA in silent mode.
It will create a database using a general purpose template. The database, container database will be
called CDB2, and it will create one pluggable database called PDB1. You can also see that we are tr
ying to configure Enterprise Manager Database Express Port to 5502. So let's start the script.
So as we can see, database CDB2 was created, so let's check if everything is working as expected.
First, I will set Environment to CDB2. Let's connect to a SQL Plus and run Show PDBs. As we can s
ee, PDB1 is open in the read/write mode, so everything looks fine. With this, demo on creating a new
container database using DBCA comes to an end.

Before database users can connect to a database instance, a database administrator must start
it. The database instance and database go through various stages as the database is made availabl
e for access by users. The database instance is started first, then the database is mounted and, final
ly, opened.
You can use STARTUP command in SQL*Plus with various options to start database instance. Start
up stages we will list on this slide are also used as clauses in STARTUP command and ALTER DAT
ABASE command used when changing stage from NOMOUNT to MOUNT or from MOUNT to OPEN
.
The first stage is NOMOUNT. During this stage, Oracle software reads an initialization parameter file
, starts Oracle instance, and opens the alert
log and trace files. An instance is typically started directly to NOMOUNT during database creation, d
uring recreation of control files, or in certain backup and recovery scenarios. In NOMOUNT mode, on
ly DBAs can connect to database.
The next stage is MOUNT. During this stage, Oracle software associates container database with a
previously started database instance, opens and reads the control files that are specified in the initial
ization parameter files, and updates the names and statuses of the data files and online redo log file
s. No checks, however, are performed to verify the existence of the data files and online redo log file
s at this time. Start an instance in MOUNT mode to perform some maintenance operations, such as
performing full database recovery. In MOUNT mode, only DBAs can connect to database.
The last stage is OPEN. At this stage, Oracle software opens the redo log files and data files accordi
ng to the list registered in the control files. Startup in OPEN mode to enable non-DBA users to conne
ct to the database instance.
This is the default and most frequently-requested stage. Because it is the default, OPEN option is ve
ry rarely specified explicitly in startup command. DBAs usually run simple STARTUP command with
no option to reach this stage.
You can open a database either in read/write mode or in read-only mode. In read-only mode, no per
manent database object can change. Permanent tables can be queried only.
Read/write mode is default. If your database is a container database, STARTUP open command ope
ns at CDB root container in read/write mode and PDB$SEED in read-only mode. User-created PDBs
are not opened automatically. They stay in MOUNT mode. DBA can open them manually, or he can
configure automatic opening.
There is also fourth option of STARTUP command, which performs restart of running database insta
nce. If specified them the bodies perform first, followed by startup command to requested stage. So
metimes, you need to shut down the database instance-- for example, to change a static parameter
or patch a database server. Use SHUTDOWN command to shutdown the database instance.
There are four shutdown modes available-- ABORT, IMMEDIATE, NORMAL, and TRANSACTIONA
L. When you shut down the database with the NORMAL mode, the database waits for all connected
users to disconnect before shutting down. NORMAL mode is the default mode of shutdown. When y
ou shutdown a database with IMMEDIATE mode, Oracle Database terminates any executing SQL st
atements and disconnects users. Active transactions are terminated and uncommitted changes are r
olled back, leaving database in constant state. This is the most frequently-used shutdown mode.
When you shut down a database in TRANSACTIONAL mode, the database prevent users from starti
ng new transactions but waits for all current transactions to complete before shutting down. This mo
de can take a significant amount of time depending on the nature of current transactions.
If the other shutdown mode don't work. You can use ABORT mode. ABORT mode platforms least a
mount of work before shutting down. Because this mode puts the database in an inconsistent state a
nd requires crash recovery before startup, use it only when necessary. It is typically used in no other
form of shutdown works, when there are problems with starting the database instance, or when you
need to shut down immediately because of an impending situation, such as notice of power outage
within seconds. ABORT mode is usually the fastest shutdown mode, while normal is the slowest one
.
The table in this slide describes behavior of different shutdown modes. As we can see, no shutdown
mode allows new connections. SHUTDOWN NORMAL will wait until all sessions log out and will writ
e changed blocks from memory to data first during checkpoint. SHUT-DOW IMMEDIATE will termina
te and roll back all transactions, followed by checkpoint. SHUTDOWN TRANSACTIONAL will wait un
til all transactions are finished. After that, it will terminate all sessions and perform checkpoint as well
. SHUTDOWN ABORT doesn't wait at all. It will simply deallocate SGA and stop
the processes. No checkpoint is performed.
The diagram in this slide shows the IMMEDIATE, TRANSACTIONAL, and NORMAL SHUTDOWN m
odes. On the way down, uncommitted changes are rolled back for SHUTDOWN IMMEDIATE, datab
ase buffer caches returned to corresponding data files, and resources are released. The result is con
sistent database. During next startup, no instance or crash recovery is needed.
Diagram in this slide shows ABORT and FORCE mode behavior. This time, buffers from buffer cach
e are not synchronized with data files. Uncommitted changes are not rolled back, resulting in inconsi
stent database. During the next STARTUP to OPEN mode, automatic crash recovery will occur. It wil
l use redo log files and undo segments to perform crash recovery, and when successful, databases i
s opened.
This concludes the topic on starting up and shutting down a database instance.

The ALTER PLUGGABLE DATABASE command lets you change from any open mode to another fo
r a PDB. Either the command requires you to be connected with administrator privileges-- as sysoper
, as sysdba, as sysbackup, or as sysdg. In the example on this slide, PDB1 will be opened. Its open
mode will change from mount to read/write. Use keyword ALL instead of PDB name to open all user-
created PDBs in one command.
So the command is ALTER PLUGGABLE DATABASE ALL OPEN. To close PDB1, one use ALTER
PLUGGABLE DATABASE PDB1 CLOSE command. Similarly, you can close all user-created PDBs
using ALTER PLUGGABLE DATABASE ALL CLOSE.
Starting up a PDB and opening a PDB means the same thing, and you will find both phrases in docu
mentation and online resources. When you open a PDB, the database server opens the data files for
that PDB. Similar to a container database, a PDB has several levels of being open, and these levels
are referred to as open modes.
The open modes are read/write, read-only, migrate, and mounted. Let's start with read/write. A PDB i
n open read/write mode allows both queries as well as user transactions to proceed. A PDB in open
read-only mode allows queries but doesn't allow user changes. When a PDB is in open migrate mod
e, you can run database upgrade scripts on that PDB. And finally, mounted-- when a PDB is in moun
ted state, it is closed. It doesn't allow changes to any object, and it is accessible only to database ad
ministrators.
After restarting a CDB instance, by default, all PDBs except the seed PDB are mounted. The seed P
DB is open read-only. If you want the PDBs to automatically open whenever the CDB restarts, use th
e SAVE STATE clause of the ALTER PLUGGABLE DATABASE command to preserve a PDB's ope
n mode across CDB restarts. You can save state for all PDBs or for a particular PDB.
So what you can do, you can put all your user-created PDB to an open mode required after restart of
CDB and issue ALTER PLUGGABLE DATABASE ALL SAVE STATE to remember state for all curre
ntly open PDBs. If the PDB is currently closed, no information is stored by SAVE STATE command, r
esulting in a default mount mode for that particular PDB after CDB restart. This way, after next CDB r
estart, all PDB with stored open state are opened automatically.
An example in this slide explains how this feature works. In case one, let's assume PDB1 is open in r
ead-write mode when ALTER DATABASE SAVE STATE command is issued. In this case, open stat
e is saved in database. So after the next restart of CDB, PDB1 will be opened automatically in read-
write mode.
In case two, PDB is mounted-- that means closed-- when ALTER DATABASE SAVE STATE comma
nd is issued. This time, PDB1 is not open, so no state is saved, resulting in default behavior after CD
B restart. PDB1 is not opened automatically. It will be mounted.
In case three, PDB1 is open in read-only mode when ALTER PLUGGABLE DATABASE SAVE STA
TE is issued. This read-only open state is saved in database, so after CDB restart, PDB will be open
automatically in read-only mode. If you wish to revert back to default behavior, use DISCARD STAT
E clause of ALTER PLUGGABLE DATABASE command. In this case,
it doesn't really matter in which state PDB1 is when command is issued. It will always result in mount
mode after CDB restart.
This concludes the topic on opening and closing pluggable databases.
My orclcdb database is currently down, so I will connect using a SQL*PLUS, and I will started to nom
ount mode. Startup nomount will start the database instance. In order to mount database, I will use a
lter database mount command. And in order to open it, alter database open command will be used.
Let's run show pdbs command. Because by default, pluggable databases are just mounted, you can
see that both orclpdb1 and orclpdb2 are in mount stage. So they are not open.
Let's check save state. In order to avoid typos, I prepared a small script to see if there is any state sa
ved in the database. As we can see, no PDB has a saved state. So let's open orclpdb1 pluggable da
tabase.
Let's save state for all currently open pluggable databases. Verified. So here, we can see, just orclpd
b1 will be opened automatically following the restart of CDB. Let's test it.
This time, I will start up to open mode. So instance is started first. After that, database is mounted. A
nd finally, database is opened. Because we saved state for orclpdb1, I expect it will be opened in rea
d/write mode.
Let's check it. Here, you can see that although orclpdb1 is open in the read/write mode, or orclpdb2 i
s just mounted. Let's open PDB2 to us well.
And while both pluggable databases are open, let's run alter pluggable database all save state again
. Let's check it. So right now, both pluggable databases have saved state.
Shut down, and start up. After this startup, both pluggable databases should be opened in read/
write mode. With this, demo on shutting down and starting up database instances comes to an end.