Oracle Database Administration -

Fundamental Oracle Concepts: The Big Picture

• Oracle Database: Think of this as the actual library building and all the books (data) inside
it. It's made up of physical files stored on your computer's disks.
o Data Files: These are like the bookshelves holding the actual information – your
tables, indexes, and all user data.
o Control Files: These are like the library's master catalog. They know where all the
data files are, the database's name, and critical information needed to start and run
the database. They are super important; lose them, and you're in big trouble.
o Online Redo Log Files: Imagine a security log that records every single change
made in the library (every book borrowed, returned, or page written). This is crucial
for recovering the database if something goes wrong (like a power outage).
• Oracle Instance: This is like the library staff (librarians, security guards, etc.) and the space
they work in (desks, computers). It's the set of memory structures and background
processes that actually manage and access the database files.
o One instance typically manages one database.
o SGA (System Global Area): A large, shared memory area used by all the "library
staff" (Oracle processes). It's like a central workroom.
▪ Database Buffer Cache: A part of the SGA where frequently accessed data
from data files is kept temporarily. This speeds things up because reading
from memory is much faster than reading from disk.
▪ Shared Pool: Another part of the SGA that stores recently used SQL
commands and program code, so Oracle doesn't have to re-process them
every time. Also holds data dictionary information (metadata about database
objects).
▪ Redo Log Buffer: A small area in the SGA that temporarily holds those
"change records" before they are written out to the Online Redo Log Files.
o PGA (Program Global Area): Each "librarian" (server process working for a user)
gets their own private workspace (memory) for tasks like sorting data or holding
session-specific information.
o Background Processes: These are like specialized "staff members" that run
continuously in the background, performing essential tasks to keep the database
running smoothly.

Section 1. Oracle Database Architecture (Continued)

Table 1: Key Instance Components & Their Roles

 What it Does (In Simpler
Component Type Why it's Important
Terms)

Efficiency,
Main shared workspace for the
SGA Memory performance by
Oracle instance.
sharing resources.

Database SGA Holds copies of recently used Speeds up data

Buffer Cache Component data blocks from disk. access significantly.

Reduces parsing
SGA Stores parsed SQL, PL/SQL
Shared Pool overhead, speeds up
Component code, and data dictionary cache.
query execution.

Temporarily stores transaction Efficiently batches

Redo Log SGA
changes before writing to redo log redo writes for better
Buffer Component
files. performance.

Private memory for each server Allows individual

PGA Memory process (e.g., for sorting, session processes to do their
data). work.

Keeps the database

Background Automated "workers" performing
Processes healthy, consistent,
Proc. crucial database tasks.
and recoverable.

Process Monitor: Cleans up Frees up resources,

PMON Process after user processes that prevents orphaned
abnormally disconnect or fail. processes.

System Monitor: Performs

Ensures database
instance recovery on startup (if
SMON Process consistency, reclaims
needed), cleans up temporary
unused space.
space.

Database Writer: Writes

Makes changes
DBWn Process changed ("dirty") data blocks from
permanent on disk.
the buffer cache to data files.

Ensures changes are

Log Writer: Writes transaction
recorded for
LGWR Process changes from the redo log buffer
recovery, ACID
to the online redo log files.
compliance.
 Checkpoint: Signals DBWn to Synchronizes files,
CKPT Process write, updates control files and reduces recovery
data file headers with SCN. time.

Archiver: (If ARCHIVELOG Protects against data

ARCn Process mode is on) Copies filled online loss by saving
redo logs to an archive location. transaction history.

Diagram 1: Basic Oracle Architecture (Conceptual Flow)

+-------------------+ "Hello, I want to connect!" +------------------

----+ "Let me find a server for you" +-----------------------+
| Client | ----------------------------------> | Listener
| ------------------------------------> | Oracle Instance |
| (User Application)| | (The "Doorman")
| | (Memory + Processes) |
+-------------------+ +------------------
----+ | - SGA (Shared Workroom) |

| - PGA (Private Desks) |

| - Background Staff |

+----------+------------+

| (Reads/Writes)

+-----------------------+

| Oracle Database |

| (The Physical Library)|

| - Data Files (Books) |

| - Control Files (Cat.)|

| - Redo Logs (Chg Log)|

+-----------------------+
content_copydownload
Use code with caution.

• Logical Storage Structures (How Oracle Organizes Data Internally):

o Data Blocks: The smallest piece of data Oracle reads or writes (e.g., 8KB). Think of
it as a page in a book.
o Extents: A collection of several contiguous (next to each other) data blocks. Like a
chapter in a book.
o Segments: A collection of extents, all allocated for a specific database object (like a
table or an index). Think of it as the entire book "Employees Table" or "Employees
Index."
o Tablespaces: The largest logical container. It groups related segments. A
tablespace is physically made up of one or more data files. Think of it as a "Fiction
Section" or "Non-Fiction Section" in the library. This helps organize data, manage
space, and perform operations like backup/recovery on specific parts of the
database.

Diagram 2: Logical vs. Physical Storage Hierarchy (How it Maps)

LOGICAL STORAGE (How Oracle sees it) PHYSICAL STORAGE (How your OS sees
it)
------------------------------------ -----------------------------------
----
Tablespace "SALES_DATA" <-------------> Datafile "sales01.dbf" (e.g.,
C:\oradata\sales01.dbf)
| (Made of many OS blocks)
+-- Segment: Table "ORDERS"
| |
| +-- Extent 1 (e.g., 64KB of data blocks)
| | |
| | +-- Data Block (e.g., 8KB)
| | +-- Data Block
| | ...
| +-- Extent 2 (e.g., another 64KB of data blocks)
 | ...
|
+-- Segment: Index "ORDERS_PK_IDX"
...
content_copydownload
Use code with caution.

• Oracle Listener (The "Doorman"):

o Purpose: A separate process that "listens" on the network for incoming connection
requests from client applications (like SQL Developer or your Java app). When a
request comes, the Listener figures out which database instance the client wants to
connect to and then hands off the connection to a dedicated server process for that
instance.
o Control Command: LSNRCTL (Listener Control utility)
▪ lsnrctl status : Checks if the listener is running and what services it
knows about.
▪ lsnrctl start : Starts the listener process.
▪ lsnrctl stop : Stops the listener process. Clients won't be able to make
new connections.
▪ lsnrctl help : Shows all available commands for the utility.

Section 2. Database Administrative Tasks

• Start Oracle Database ( STARTUP command):

o Purpose: This command brings your Oracle database online, making it ready for
users. It involves starting the instance (memory and processes) and then opening the
actual database files.
o Stages (It happens in steps):
1. NOMOUNT: The instance starts (memory is allocated, background
processes are launched). At this stage, the instance doesn't
know which database it's going to manage. The control files haven't been
read yet. Useful for tasks like creating a new database or recreating control
files.
2. MOUNT: The instance reads the control files. Now it knows the database's
name and the location of data files and redo log files. The database is
"mounted" but not yet open for general user access. Useful for certain
maintenance tasks like renaming data files or enabling/disabling archiving.
3. OPEN: The instance opens all the data files and redo log files. The database
is now fully operational and available for users to connect and perform
queries and transactions.
 o Common STARTUP Commands:
▪ STARTUP; (This is the most common, equivalent to STARTUP OPEN; - goes
through all stages to fully open)
▪ STARTUP NOMOUNT; (Starts instance, stops at NOMOUNT stage)
▪ STARTUP MOUNT; (Starts instance, stops at MOUNT stage)
▪ ALTER DATABASE MOUNT; (If in NOMOUNT, moves to MOUNT stage)
▪ ALTER DATABASE OPEN; (If in MOUNT, moves to OPEN stage, making it
available)

Diagram 3: Database Startup Stages (Visual Flow)

Issuing the STARTUP Command
|
V
+-------------------------------------------------+
| Stage 1: NOMOUNT |
| - Instance started (SGA, PGA, Background Procs) |
| - Control files NOT YET read. |
| - Database identity UNKNOWN to instance. |
+---------------------+---------------------------+
| (If you used `STARTUP MOUNT;` or `ALTER
DATABASE MOUNT;`)
V
+-------------------------------------------------+
| Stage 2: MOUNT |
| - Control files ARE READ. |
| - Instance knows database name & file locations.|
| - Data files NOT YET open. Users cannot access. |
+---------------------+---------------------------+
| (If you used `STARTUP OPEN;` or `ALTER DATABASE
OPEN;`)
V
+-------------------------------------------------+
| Stage 3: OPEN |
| - Data files and redo log files ARE OPENED. |
| - Database is fully available for users. |
+-------------------------------------------------+

content_copydownload
 Use code with caution.

• Shutdown Oracle Database ( SHUTDOWN command):

o Purpose: This command properly closes the database and stops the instance. It's
important to shut down cleanly to avoid data corruption or long recovery times.
o Shutdown Options (How you want to stop it):

Table 2: SHUTDOWN Command Options Explained

Instanc
e
Impact on
Recover When to
Option What Happens Users &
y Use
Transactions
Needed
?

Ideal for
Waits for all Very polite, but
planned
currently can take a long
maintenan
connected users to time if users
ce when
NORMAL disconnect don't log off. No
you can
themselves. No Transactions
afford to
new connections complete
wait
allowed. normally.
indefinitely.

Prevents new Good for

connections and Less disruptive scheduled
new transactions. than IMMEDIAT outages
Waits for E if long when you
TRANSACTION
all active transactio transactions are No want
AL
ns to finish running. current
(commit or Ensures current work to
rollback). Then work completes. finish
disconnects users. cleanly.

Most
Prevents new
commonly For most
connections. Rolls
used. Quick routine
back any active,
and clean. shutdowns,
IMMEDIATE uncommitted No
Users are patches, or
transactions.
kicked off, work quick
Disconnects all
not saved is restarts.
current users.
lost.
 Emergenc
Stops the instance Abrupt. Data in
y only! If
immediately, like memory buffers
the
pulling the plug. is lost. Yes, on
database
ABORT No clean Database will be next
is hung or
dismount, no in an startup.
other
rollback of inconsistent
methods
transactions. state.
fail.

Section 3. Managing Tablespaces

• Oracle Tablespace (Logical Storage Organizer):

o Purpose: A tablespace is a logical grouping of database objects (like tables and
indexes). Physically, it's made up of one or more data files.
o Why use Tablespaces?
▪ Organization: Group related application data together
(e.g., HR_DATA_TS , SALES_INDEX_TS ).
▪ Space Management: Allocate specific amounts of disk space to different
parts of your application.
▪ Availability: You can take specific tablespaces offline for maintenance (e.g.,
to repair a datafile) while the rest of the database remains online.
▪ Backup & Recovery: Allows for partial database backup and recovery (e.g.,
restore just one application's tablespace).
▪ Performance: Can place data files for different tablespaces on different
disks to distribute I/O load.
o Default Tablespaces (Oracle creates these for you):

Table 3: Common Default Tablespaces and Their Purpose

Tablespace
Primary Purpose Is it Critical?
Name

Holds the Data Dictionary – the core metadata

SYSTEM Absolutely Yes!
about your entire database.

An auxiliary tablespace to SYSTEM . Stores

Yes, very
SYSAUX data for various Oracle features (like AWR,
important.
Optimizer stats).

Often the default tablespace for new users if No, for user
USERS
you don't specify another one. data.
 Stores "undo" information. This is used to roll
UNDOTBS1 (or
back transactions and for read consistency (so Absolutely Yes!
similar)
queries see data as it was at a point in time).

Used for temporary operations like large sorts

Yes, for many
(e.g., ORDER BY on a big table), hash joins,
TEMP operations to
creating indexes. Data here is session-specific
complete.
and transient.

Diagram 4: Tablespace and Datafile Relationship (Visual)

+-------------------------------------------------+ (Logical View)
| Tablespace "APPLICATION_DATA" |
| |
| (Contains segments like "CUSTOMERS" table, |
| "ORDERS" table, "CUST_IDX" index, etc.) |
| |
| Mapped to one or more physical files: |
| +-----------------------------------------+ |
| | Datafile 1: "app_data01.dbf" (on DiskA) | |
| +-----------------------------------------+ |
| +-----------------------------------------+ |
| | Datafile 2: "app_data02.dbf" (on DiskB) | |
| +-----------------------------------------+ |
+-------------------------------------------------+

content_copydownload

Use code with caution.

• Key Tablespace Commands:

o Create a new tablespace:
CREATE TABLESPACE my_app_data DATAFILE
'/u01/oradata/MYDB/myappdata01.dbf' SIZE 100M AUTOEXTEND ON NEXT
10M MAXSIZE 500M;
▪ DATAFILE : Specifies the physical file path and initial size.
▪ AUTOEXTEND ON : Allows the datafile to grow automatically if it runs out of
space.
▪ NEXT : How much it grows by each time.
▪ MAXSIZE : The maximum size it can grow to.
 o Drop (delete) a tablespace:
DROP TABLESPACE my_app_data INCLUDING CONTENTS AND DATAFILES;
▪ INCLUDING CONTENTS : Deletes all objects (tables, indexes) within the
tablespace.
▪ AND DATAFILES : Also deletes the physical data files from the operating
system.
▪ CASCADE CONSTRAINTS : If tables in this tablespace are referenced by
foreign keys in other tablespaces, this option drops those constraints. (Use
with caution!)
o Extend a tablespace (add more space):
▪ Option 1: Add a new datafile:
ALTER TABLESPACE my_app_data ADD DATAFILE
'/u01/oradata/MYDB/myappdata02.dbf' SIZE 50M;
▪ Option 2: Resize an existing datafile:
ALTER DATABASE DATAFILE '/u01/oradata/MYDB/myappdata01.dbf'
RESIZE 200M;
o Create a temporary tablespace:
CREATE TEMPORARY TABLESPACE my_temp_ts TEMPFILE
'/u01/oradata/MYDB/mytemp01.dbf' SIZE 50M EXTENT MANAGEMENT LOCAL
UNIFORM SIZE 1M;
▪ TEMPFILE is used instead of DATAFILE for temporary tablespaces.
o Tablespace Group (for Temporary Tablespaces):
▪ Allows you to group multiple temporary tablespaces and assign the group as
the default temporary space for users. This can help distribute temporary
segment activity.
▪ Create new temp TS and add to group: CREATE TEMPORARY TABLESPACE
temp1 TEMPFILE ... TABLESPACE GROUP group_name;
▪ Add existing temp TS to group: ALTER TABLESPACE temp_existing
TABLESPACE GROUP group_name;

Section 4. Users & Privileges (Who Can Do What)

• User: An account that can connect to the Oracle database. Each user typically has a
schema of the same name where their objects (tables, views, etc.) are created.
• CREATE USER (Creating a new database account):
o Purpose: To define a new user who can log in and potentially own objects or access
data.
o Key Clauses Explained in Table Below.
 o Important: After creating a user, they usually need the CREATE SESSION privilege
granted to them before they can actually log in. GRANT CREATE SESSION TO
new_user;

Table 4: Key CREATE USER Clauses Explained

Clause Purpose Example

IDENTIFIED Sets the user's password for IDENTIFIED BY

BY database authentication. ComplexPwd123!

Specifies where this user's

tables and indexes will be
DEFAULT DEFAULT TABLESPACE
stored by default if not
TABLESPACE USER_DATA_TS
specified during object
creation.

Specifies which tablespace will

TEMPORARY be used for this user's TEMPORARY TABLESPACE
TABLESPACE temporary operations (like TEMP_TS
sorting).

Limits how much disk space QUOTA 100M ON

QUOTA ... ON
the user can consume in a USER_DATA_TS or QUOTA
...
specific tablespace. UNLIMITED ON USER_DATA_TS

Assigns a set of resource limits

PROFILE and password policies to the PROFILE APP_USER_PROFILE
user.

Forces the user to change their

PASSWORD
password the first time they log PASSWORD EXPIRE
EXPIRE
in.

LOCK prevents the user from

ACCOUNT
logging in. UNLOCK enables ACCOUNT LOCK
LOCK/UNLOCK
login.

• Privileges (Permissions): These define what a user is allowed to do.

o System Privileges: Allow performing database-wide actions or actions on any object
of a certain type.
▪ Examples: CREATE TABLE (can create tables in own schema), CREATE ANY
TABLE (can create tables in any schema), ALTER USER , CREATE
SESSION (to log in), SYSDBA (powerful admin privilege).
 o Object Privileges: Allow performing specific actions on specific objects owned by a
user (or on objects they've been granted access to).
▪ Examples: SELECT ON employees (can query the employees
table), INSERT ON orders (can add rows to orders table), UPDATE ON
products , DELETE ON customers , EXECUTE ON my_procedure .
• GRANT (Giving Permissions):
o Purpose: To give specific system or object privileges (or roles) to a user or another
role.
o Syntax Examples:
▪ Granting a system privilege: GRANT CREATE TABLE TO scott;
▪ Granting an object privilege: GRANT SELECT, INSERT ON hr.employees
TO scott;
▪ WITH ADMIN OPTION : If you grant a privilege WITH ADMIN OPTION , the
recipient can then grant that same privilege to other users. (e.g., GRANT
CREATE TABLE TO manager_user WITH ADMIN OPTION; )
• REVOKE (Taking Away Permissions):
o Purpose: To remove privileges (or roles) that were previously granted.
o Syntax Examples:
▪ Revoking a system privilege: REVOKE CREATE TABLE FROM scott;
▪ Revoking an object privilege: REVOKE SELECT, INSERT ON
hr.employees FROM scott;
• ALTER USER (Modifying User Accounts):
o Purpose: To change various attributes of an existing user account.
o Common Uses:
▪ Change password: ALTER USER scott IDENTIFIED BY
new_strong_password;
▪ Lock an account (e.g., if an employee leaves): ALTER USER scott
ACCOUNT LOCK;
▪ Unlock an account: ALTER USER scott ACCOUNT UNLOCK;
▪ Force password change on next login: ALTER USER scott PASSWORD
EXPIRE;
▪ Change default tablespace: ALTER USER scott DEFAULT TABLESPACE
new_users_ts;
▪ Assign a different profile: ALTER USER scott PROFILE
secure_app_user_profile;
• DROP USER (Deleting a User Account):
o Purpose: To completely remove a user from the database.
o Syntax: DROP USER username;
 ▪ CASCADE : This is a very important option. If the user owns any objects
(tables, views, etc.), you MUST use CASCADE to drop the user and all their
objects. DROP USER scott CASCADE; Be extremely careful
with CASCADE as it deletes data!

Diagram 5: Privileges and Roles Concept (How they relate)

+---------------------+ Grants Privileges +--------------------
-+ Grants Role +----------+
| System Privileges | ------------------------> | User A
| (e.g., a DBA) | |
| (e.g., CREATE ANY | | (e.g., a Power
User)| | User B |
| TABLE, BACKUP DB) | +--------------------
-+ | |
+---------------------+
+----------+

^
+---------------------+ Grants Privileges +--------------------
-+ | (User B, C, D
| Object Privileges | ------------------------> | Role X
| --- Assigns Role X to ---+ get all
| (e.g., SELECT on | | (e.g.,
"SALES_READ")| | privileges of
| SALES_TABLE, | +--------------------
-+ | Role X)
| EXECUTE on |
V
| CALC_REVENUE_PROC) |
+----------+
+---------------------+
| User C |

+----------+

V
 +----------+

| User D |

+----------+

content_copydownload

Use code with caution.

• How to Grant All System Privileges to a User (Generally Not Recommended for regular
users):
o GRANT ALL PRIVILEGES TO username;
o This grants a very wide range of system privileges. It does not grant object privileges
on other users' objects unless those object privileges are part of the "ALL
PRIVILEGES" set (which is rare for specific objects). For full admin capability, users
often get roles like DBA . Use with extreme caution.
• How to Grant SELECT Object Privilege on a specific table:
o GRANT SELECT ON schema_name.table_name TO user_name; (e.g., GRANT
SELECT ON hr.employees TO intern_user; )
o To grant SELECT on all tables in a specific schema to another user, you usually need
to write a small PL/SQL script that dynamically generates and executes
the GRANT statements for each table.
• How to Unlock a User Account:
o ALTER USER username ACCOUNT UNLOCK;
o If you also want to reset their password at the same time (common if locked due to
failed attempts):
ALTER USER username IDENTIFIED BY new_temporary_password ACCOUNT
UNLOCK;
• How to List Users in the Oracle Database:
o Query the DBA_USERS data dictionary view (requires appropriate privileges):
SELECT username, account_status, default_tablespace, created FROM
dba_users ORDER BY username;
▪ account_status will show if the account is OPEN , LOCKED , EXPIRED , etc.

Section 5. Roles (Grouping Privileges for Easier Management)

• Role: A named collection of privileges. Instead of granting many individual privileges to each
user, you can:
 1. Create a role.
2. Grant all the necessary privileges to that role.
3. Grant the role to users.
o This makes managing permissions much simpler. If you need to change permissions
for a group of users, you just change the privileges granted to the role, and it affects
all users who have that role. (See Diagram 5 above).
• CREATE ROLE (Creating a new group of privileges):
o Purpose: To define a new role that can then have privileges granted to it.
o Syntax: CREATE ROLE sales_read_only_role;
▪ IDENTIFIED BY password : You can make a role password-protected. The
user would need to provide this password when enabling the role in their
session using SET ROLE .
▪ NOT IDENTIFIED (default): No password needed to enable the role.
o After creating the role, grant privileges to it:
GRANT SELECT ON sales_data TO sales_read_only_role;
GRANT SELECT ON products TO sales_read_only_role;
o Then, grant the role to users:
GRANT sales_read_only_role TO user_jane, user_john;
• SET ROLE (Activating/Deactivating Roles in Your Current Session):
o Purpose: When a user logs in, their default roles are usually enabled. However, they
can use SET ROLE to enable specific roles (especially password-protected ones) or
disable roles for their current session.
o Syntax:
▪ SET ROLE role_name; (Enables a specific non-password-protected role)
▪ SET ROLE role_name IDENTIFIED BY role_password; (Enables a
password-protected role)
▪ SET ROLE ALL; (Enables all roles granted to the user, except those
requiring a password if not provided)
▪ SET ROLE NONE; (Disables all roles for the current session, except the
mandatory PUBLIC role and any default roles unless they are also explicitly
disabled)
• ALTER ROLE (Modifying an Existing Role):
o Purpose: To change properties of a role, most commonly to add or remove a
password.
o Syntax:
▪ ALTER ROLE sales_read_only_role NOT IDENTIFIED; (Removes
password protection)
▪ ALTER ROLE admin_tasks_role IDENTIFIED BY
new_secure_password; (Adds/changes password)
 • DROP ROLE (Deleting a Role):
o Purpose: To remove a role from the database. When a role is dropped, it's
automatically revoked from all users and other roles to whom it was granted.
o Syntax: DROP ROLE sales_read_only_role;

Section 6. User Profiles (Setting Resource and Password Rules)

• User Profile: A named set of limits that control:

1. Database Resources: How much CPU, I/O, concurrent sessions, etc., a user can
consume.
2. Password Management: Rules for password complexity, lifetime, reuse, account
locking after failed attempts, etc.
o Assigning profiles helps enforce security policies and manage resource usage.
o If a user isn't explicitly assigned a profile, they get the DEFAULT profile.
• CREATE PROFILE (Defining a new set of limits):
o Purpose: To create a new profile with specific resource and password parameter
settings.
o Syntax (with examples of limits - see Table 5 for more):
CREATE PROFILE app_user_profile LIMIT
SESSIONS_PER_USER 5
CPU_PER_SESSION 300000 -- In hundredths of a second (e.g., 3000
seconds)
IDLE_TIME 30 -- In minutes
FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LIFE_TIME 90; -- In days
o After creating, assign it to users: ALTER USER scott PROFILE
app_user_profile;

Table 5: Common Profile Limits and Their Meaning

Limit Typical
Parameter What it Controls
Type Use Case

Prevent
resource
Maximum number of hogging by
Resource
SESSIONS_PER_USER concurrent sessions a one user
Limits
user can have. opening
many
sessions.
 Stop
Maximum CPU time runaway
(in 1/100ths of a queries
CPU_PER_SESSION
second) a single from
session can use. consuming
all CPU.

Maximum time (in Free up

minutes) a session resources
IDLE_TIME
can be inactive before from idle
being disconnected. sessions.

Prevent
Max data blocks read
very I/O
from memory/disk for
LOGICAL_READS_PER_CALL intensive
a single database call
single
(parse, exec, fetch).
operations.

Protect
Number of
against
Password consecutive failed
FAILED_LOGIN_ATTEMPTS brute-force
Limits login tries before the
password
account is locked.
attacks.

Enforce
Number of days a regular
password remains password
PASSWORD_LIFE_TIME
valid before it must be changes
changed. for
security.

Number of days an Cooldown

account stays locked period after
PASSWORD_LOCK_TIME
after exceeding failed suspected
login attempts. attack.

Give users
Days a user gets a a chance
warning before their to change
PASSWORD_GRACE_TIME
password expires password
(they can still log in). before
expiry.
 Prevent
Minimum number of
immediate
days before an old
PASSWORD_REUSE_TIME reuse of
password can be
old
reused.
passwords.

Min number Prevent

of different passwords cycling
PASSWORD_REUSE_MAX to be used before an through a
old one can be small set of
reused. passwords.

Specifies a PL/SQL Enforce

function to check strong
PASSWORD_VERIFY_FUNCTION
password complexity password
(e.g., length, chars). policies.
• ALTER PROFILE (Modifying an Existing Profile's Limits):
o Purpose: To change one or more limits in an already defined profile.
o Syntax: ALTER PROFILE app_user_profile LIMIT FAILED_LOGIN_ATTEMPTS
5 PASSWORD_LIFE_TIME 60;
• DROP PROFILE (Deleting a Profile):
o Purpose: To remove a profile definition from the database.
o Syntax: DROP PROFILE app_user_profile;
▪ CASCADE : If the profile is currently assigned to any users, you must
use CASCADE . This will de-assign the profile from those users, and they will
revert to using the DEFAULT profile. DROP PROFILE app_user_profile
CASCADE;

Section 7. Data Migration (Moving Data In and Out)

• External Tables (Querying Files Like Tables):

o Purpose: Allows you to define a table structure in Oracle that points to data stored in
external flat files (like CSV, text files) without actually loading the data into the
database. You can then query this "external table" using SQL just like a regular table.
o Key Features:
▪ Data remains in the external file.
▪ Typically read-only (you can't INSERT , UPDATE , DELETE on most external
tables).
▪ Useful for ETL (Extract, Transform, Load) processes, accessing large log
files, or integrating data from non-Oracle systems quickly.
 o Simplified Steps:
1. Create a DIRECTORY Object: Tell Oracle where the external file is located on
the server.
CREATE OR REPLACE DIRECTORY ext_table_dir AS
'/srv/data/external_files';
2. Grant Permissions on Directory: Give the user who will create/query the
external table READ (and sometimes WRITE for log files) access to this
directory object.
GRANT READ, WRITE ON DIRECTORY ext_table_dir TO
my_etl_user;
3. Create the External Table Definition:
CREATE TABLE emp_ext_data (
emp_id NUMBER, emp_name VARCHAR2(100), hire_date
VARCHAR2(10)
) ORGANIZATION EXTERNAL (
TYPE ORACLE_LOADER
DEFAULT DIRECTORY ext_table_dir
ACCESS PARAMETERS (RECORDS DELIMITED BY NEWLINE FIELDS
TERMINATED BY ',' MISSING FIELD VALUES ARE NULL)
LOCATION ('employees.csv')
) REJECT LIMIT UNLIMITED;

Diagram 6: External Table Concept (How Oracle Accesses External Data)

Your SQL Query: SELECT emp_name FROM emp_ext_data WHERE emp_id = 101;
|
V
+-------------------------------------------------+
| Oracle Database Instance |
| - Knows "emp_ext_data" is an external table. |
| - Uses its definition & DIRECTORY object info. |
+---------------------+---------------------------+
| (Reads data through the OS)
V
+-------------------------------------------------+ Reads File
+----------------------+
| Directory Object "EXT_TABLE_DIR" | ----------------->
| External File |
| (Points to OS path: /srv/data/external_files/) |
| (e.g., employees.csv)|
 +-------------------------------------------------+
+----------------------+

content_copydownload

Use code with caution.

• SQL*Loader ( sqlldr ) (Bulk Loading Data from Files):

o Purpose: A powerful command-line utility provided by Oracle to load large volumes
of data from external flat files (text, CSV, fixed-width) into Oracle database tables. It's
very fast and flexible.
o Key Components:
▪ Data File: The file containing the actual data to be loaded
(e.g., emp_data.csv ).
▪ Control File ( .ctl ): A text file you create that tells SQL*Loader:
▪ Which table to load into.
▪ How the data file is formatted (e.g., fields separated by commas,
positions of data).
▪ How to map columns from the file to table columns.
▪ Any data transformations needed.
▪ Log File (Generated): Records details of the load process, including errors
and successes.
▪ Bad File (Generated): Contains records from the data file that SQL*Loader
couldn't load due to errors.
▪ Discard File (Generated, Optional): Contains records that were filtered out
based on conditions in the control file.
o Basic Execution: sqlldr userid=scott/tiger control=load_emp.ctl
data=emp_data.csv log=load_emp.log

Diagram 7: SQL*Loader Process (Simplified Flow)

+----------------------+ +--------------------------+
| Data File | | Control File (load.ctl) |
(Instructions for loading)
| (e.g., emp_data.csv) | | - Target table |
+--------+-------------+ | - Field delimiters |
| | - Column mapping |
+-------+-----------+ +--------------
------------+
| | Parameter
File (optional)|
 | (Inputs to SQL*Loader) | (userid,
control file, |
V | log file
names, etc.) |
+----------------------------+ +------------+-
------------+
| SQL*Loader Executable | <-------------------------------+
| (`sqlldr`) |
+-------------+--------------+
| (Connects to DB & Loads Data)
V
+----------------------------+
| Oracle Database |
| (Data loaded into tables) |
+----------------------------+

content_copydownload

Use code with caution.

• Data Pump Export ( expdp ) (Modern Export Utility):

o Purpose: A server-side utility for very fast export (unload) of data and metadata
(table definitions, users, roles, etc.) from an Oracle database into a set of "dump
files." This is the preferred method over the older exp utility.
o Key Features: Runs on the database server, high-speed, parallel processing,
filtering, compression, encryption.
o Basic Execution:
0. A DIRECTORY object must exist on the server, pointing to an OS directory
where dump files will be written.
CREATE OR REPLACE DIRECTORY dpump_dir AS
'/backup/datapump';
GRANT READ, WRITE ON DIRECTORY dpump_dir TO system;
1. Run expdp from the command line (often on the server):
expdp system/password@db_service DIRECTORY=dpump_dir
DUMPFILE=hr_schema_%U.dmp LOGFILE=hr_export.log SCHEMAS=HR
PARALLEL=4
▪ DIRECTORY : The Oracle directory object.
▪ DUMPFILE : Name pattern for dump files ( %U allows multiple files for
parallelism).
▪ SCHEMAS : Specifies which schemas to export.
 ▪ PARALLEL : Number of parallel processes to use.
• Data Pump Import ( impdp ) (Modern Import Utility):
o Purpose: A server-side utility to load data and metadata from dump files (created
by expdp ) into an Oracle database. This is the preferred method over the
older imp utility.
o Basic Execution:
0. The dump files and a DIRECTORY object pointing to them must exist.
1. Run impdp from the command line:
impdp system/password@db_service DIRECTORY=dpump_dir
DUMPFILE=hr_schema_%U.dmp LOGFILE=hr_import.log SCHEMAS=HR
TABLE_EXISTS_ACTION=REPLACE
▪ TABLE_EXISTS_ACTION=REPLACE : If tables already exist, drop and
recreate them. Other options: SKIP , APPEND , TRUNCATE .
▪ Can also remap schemas, tablespaces, etc., during import.

Diagram 8: Data Pump (expdp/impdp) Process (High-Level)

(1. EXPORT with `expdp`)
+-----------------+ Unloads to +-----------------+
| Source Database | ----------------> | Dump File Set |
| (Data & Metadata)| | (On Server Disk |
+-----------------+ | via DIRECTORY |
| Object) |
+--------+--------+
|
| (2. IMPORT with
`impdp`)
V
+-----------------+
| Target Database |
| (Loads Data & |
| Metadata) |
+-----------------+

content_copydownload

Use code with caution.

Section 8. Database Links (Connecting to Other Databases)

• Database Link: A schema object within your local database that allows you to access
objects (like tables and views) located in a remote Oracle database (or sometimes other
types of databases if configured with gateways). It's like creating a shortcut or a bridge to
another database.
o Why use them? To query or manipulate data that resides in a different database
without having to manually copy it over.
o Types:
▪ Private Database Link: Created by and usable only by the owner (the user
who created it).
▪ Public Database Link: Created by a DBA, potentially usable by any user in
the local database (they still need privileges on the remote objects they are
trying to access).
• CREATE DATABASE LINK (Building the Bridge):
o Purpose: To define the connection to the remote database.
o Syntax (Private Link Example):
CREATE DATABASE LINK sales_db_link
CONNECT TO remote_sales_user IDENTIFIED BY "R3m0t3P@sswOrd"
USING 'sales_tns_entry'; -- TNS alias from tnsnames.ora or full
connect string
o Syntax (Public Link Example):
CREATE PUBLIC DATABASE LINK finance_db_link ... ;
o How to Use: Once created, you append @database_link_name to the object name
in your SQL:
SELECT * FROM remote_customers_table@sales_db_link WHERE country
= 'USA';

Diagram 9: Database Link Concept (Accessing Remote Data)

+-----------------------------------+ +----
-------------------------------+
| Local Database | |
Remote Database |
| | |
(e.g., on a different server) |
| User in local DB issues query: | |
|
| `SELECT order_id, order_total` | |
Contains table "ORDERS" |
| `FROM orders@FINANCE_DB_LINK` | |
Owned by "FINANCE_USER" |
 | `WHERE customer_id = 123;` | |
|
| | Uses DB Link
"FINANCE_DB_LINK" | |
| DB Link "FINANCE_DB_LINK" defined| (Connects as FINANCE_USER
| |
| to connect to remote DB as | with stored password)
| |
| "FINANCE_USER". | --------------------------------
---> | |
+-----------------------------------+ +----
-------------------------------+

content_copydownload

Use code with caution.

• ALTER DATABASE LINK (Modifying the Bridge):

o Purpose: Most commonly used to update the password for the remote user specified
in the database link if that password changes on the remote database.
o Syntax:
ALTER DATABASE LINK sales_db_link
CONNECT TO remote_sales_user IDENTIFIED BY "NewR3m0t3P@ss!";
• DROP DATABASE LINK (Removing the Bridge):
o Purpose: To delete a database link definition.
o Syntax:
▪ For private link: DROP DATABASE LINK sales_db_link;
▪ For public link: DROP PUBLIC DATABASE LINK finance_db_link;

Section 9. Useful Tips

• Show tables (How to list tables in Oracle):

o Oracle doesn't have a simple SHOW TABLES; command like MySQL. Instead, you
query Data Dictionary Views. These views are special tables that Oracle maintains to
store metadata about the database itself.
o Why use these views? They provide detailed information and allow fine-grained
querying of database objects.

Table 6: Data Dictionary Views for Listing Tables

 View Name What it Shows Privileges Needed to Query

Tables owned
by
USER_TABLES the currently None (you can always see your own).
connected
user.

Tables that
the currently
connected
user has
permission to
ALL_TABLES None.
access (either
they own them,
or someone
granted them
privileges).

All tables in
the entire
database, Typically DBA role, or SELECT ANY
DBA_TABLES
regardless of DICTIONARY / SELECT_CATALOG_ROLE privilege.
owner or
permissions.
o Example: SELECT table_name, owner FROM all_tables WHERE owner =
'HR';
• How To Fix the “ORACLE initialization or shutdown in progress” error:
o What it means: The database instance is not fully open and ready for normal
operations. It's stuck in one of the startup or shutdown phases.
o Common Causes:
▪ A previous SHUTDOWN ABORT or an instance crash (e.g., server power loss).
The database needs recovery.
▪ The database was intentionally started to NOMOUNT or MOUNT state and not
yet opened.
▪ A shutdown command ( NORMAL , TRANSACTIONAL , IMMEDIATE ) is currently
in progress and hasn't completed.
o General Fix Steps (Connect as SYSDBA or SYSOPER ):
1. Check current status: SELECT status FROM v$instance; (Might
show MOUNTED , STARTED (for NOMOUNT), etc.)
 2. If a normal shutdown seems stuck or you suspect a problem, a clean
abort and restart is often the quickest way (but be aware this forces
instance recovery):
SHUTDOWN ABORT;
STARTUP; (This will automatically attempt instance recovery if needed and
then open the database.)
3. If STARTUP; fails or you want more control:
▪ STARTUP MOUNT;
▪ Then check the alert log for errors.
▪ If no major errors, try: ALTER DATABASE OPEN;
4. Always check the Alert Log: The alert log file (location varies but often
in $ORACLE_BASE/diag/rdbms/your_db_name/your_instance_name/t
race/alert_your_instance_name.log ) contains detailed error
messages and is crucial for diagnosing startup problems.

Final Tips for Your Exam:

• Understand the "Why": Don't just memorize commands; understand why you would use a
particular command or feature.
• Key Differences: Be clear on distinctions like Database vs. Instance, System vs. Object
Privileges, SHUTDOWN IMMEDIATE vs. ABORT .
• Core Components: Know the main SGA parts (Buffer Cache, Shared Pool) and the primary
roles of key background processes (PMON, SMON, DBWn, LGWR, CKPT).
• Practical Scenarios: Think about when you'd create a tablespace, add a user, grant a role,
or use Data Pump.
• Read Carefully: Ensure you understand what the exam question is asking before
answering.
• Relax! You've prepared. Take a deep breath.