Professional Documents
Culture Documents
Case Study-Oracle Mod Iii
Case Study-Oracle Mod Iii
Case Study-Oracle Mod Iii
Mod III
History
Relational model was introduced in 1970.
Research and development effort was initiated at IBMs San Jose Research
Center.
It led to the announcement of two commercial relational DBMS products by
IBM in the 1980s:
SQL/DS for DOS/VSE (disk operating system/virtual storage extended)
and for VM/CMS (virtual machine/ conversational monitoring system)
environments, introduced in 1981;
DB2 for the MVS operating system, introduced in 1983.
Another relational DBMS, INGRES, was developed at the University of
California, Berkeley, in the early 1970s .
INGRES became a commercial RDBMS marketed by Ingres, Inc., a
subsidiary of ASK, Inc., and is presently marketed by Computer
Associates.
Other popular commercial RDBMSs include
Oracle of Oracle, Inc.; Sybase of Sybase, Inc.; RDB of Digital Equipment
Corp, now owned by Compaq; INFORMIX of Informix, Inc.; and UNIFY
of Unify, Inc.
History
Besides the RDBMSs many implementations of the
relational data model appeared on the personal
computer (PC) platform in the 1980s.
These include RIM, RBASE 5000, PARADOX,OS/2
Database Manager, DBase IV, XDB, WATCOM SQL, SQL
Server (of Sybase, Inc.), SQL Server (of Microsoft), and
most recently Access (also of Microsoft, Inc.).
They were initially single-user systems, but more
recently they have started offering the client/server
database architecture and are becoming compliant
with Microsofts Open Database Connectivity (ODBC),
a standard that permits the use of many front-end
tools with these systems
Oracle database
Contains :
One or more data files; these contain the actual data.
Two or more log files called redo log ;these record all changes
made to data and are used in the process of recovering, if
certain changes do not get written to permanent storage.
One or more control files; these contain control information
such as database name, file names and locations, and a
database creation timestamp. This file is also needed for
recovery purposes.
Trace files and an alert log; background processes have a
trace file associated with them and the alert log maintains
major database events
Oracle Instance
The set of processes that constitute an instance of the servers
operation is called an Oracle Instance,
which consists of a System Global Area and a set of
background processes.
It has the following components:
1. System global area (SGA): This area of memory is used for
database information shared by users. Oracle assigns an SGA
area when an instance starts. For optimal performance, the
SGA is generally made as large as possible, while still fitting
in real memory.
SGA
The SGA is divided into several types of memory structures:
1. Database buffer cache: This keeps the most recently
accessed data blocks from the database. By keeping most
frequently accessed data blocks in this cache, the disk I/O
activity can be significantly reduced.
2. Redo log buffer, which is the buffer for the redo log file
and is used for recovery purposes.
3. Shared pool, which contains shared memory constructs;
these include shared SQL areas, which contain parse trees
of SQL queries and execution plans for executing
SQL statements.
Oracle Instance
1. SGA
2. User processes: Each user process corresponds
to the execution of some or some tool.
3. Program global area (PGA) : This is a memory
buffer that contains data and control information
for a server process. A PGA is created by Oracle
when a server process is started.
4. Oracle processes: A process is a "thread of
control" or a mechanism in an operating system
that can execute a series of steps. A process has
its own private memory area where it runs. Oracle
processes are divided into server processes and
background processes.
Oracle Processes
Oracle creates server processes to
handle requests from connected user
processes .
The background processes are
created for each instance of Oracle .
Background processes
Database Writer (DBWR): Writes the modified blocks from the buffer cache
to the data files on disk
Log writer (LGWR): Writes from the log buffer area to the on-line disk log
file.
Checkpoint (CKPT): Refers to an event at which all modified buffers in the
SGA since the last checkpoint are written to the data files . The CKPT process
works with DBWR to execute a checkpointing operation.
System monitor (SMON): Performs instance recovery, manages storage
areas by making the space contiguous, and recovers transactions skipped
during recovery.
Process monitor (PMON): Performs process recovery when a user process
fails. It is also responsible for managing the cache and other resources used by
a user process.
Archiver (ARCH): Archives on-line log files to archival storage if configured to
do so.
Recoverer process (RECO): Resolves distributed transactions that are
pending due to a network or systems failure in a distributed database.
Dispatchers (Dnnn): In multithreaded server configurations, route requests
from connected user processes to available shared server processes. There is
one dispatcher per standard communication protocol supported.
Lock processes (LCKn): Used for inter-instance locking when Oracle runs in a
parallel server mode.
Storage Organization in
Oracle
Storage
Each Database is divided into one
or more different tablespaces.
As a minimum there is always a
System and Users tablespace.
One or more data files are
created in each tablespace.
These data files are associated
with only one database.
18
Physical Storage
Physical Storage is organized in terms of
data blocks, extents and segments.
Data blocks are the finest (smallest) size
of storage. They are also called logical
blocks, page or Oracle blocks.
An Extent is a specific number of
contiguous data blocks.
A Segment is a set of extents for a data
structure.
19
Data Blocks
A Data Block has the following
components:
Header: Contains the general block
information such as block address &
type of segment.
Table Directory: Contains information
about tables that have data in the data
block.
Row Directory: Contains information
about the actual rows.
20
21
Extents
The amount of space initial allocated
to an extent is determine by the
Create command. Incremental
extents are allocated when the initial
one becomes full and their size is
determined by Create command.
All extents allocated to index exist as
long as the index exists.
22
Segments
There are four types of Segments:
Data segments: Each non-clustered
table and each cluster has a Single
data segment.
Index segments: Each index has a
single index segment.
Temporary segments: Used by SQL
as a temporary work area.
Rollback segments: Used for
undoing transactions.
23
INDEXING
&
HASHING
Basic Concepts
pointer
Access time
Insertion time
Deletion time
Space overhead
Access types supported efficiently. E.g.,
records with a specified value in the attribute
or records with an attribute value falling in a
specified range of values.
This strongly influences the choice of index, and
depends on usage.
Ordered Indices
In an ordered index, index entries are stored sorted
on the search key value. E.g., author catalog in
library.
Primary index: in a sequentially ordered file,
the index whose search key specifies the sequential
order of the file.
Also called clustering index
The search key of a primary index is usually but not
necessarily the primary key.
Multilevel Index
If primary index does not fit in memory,
access becomes expensive.
Solution: treat primary index kept on disk as a
sequential file and construct a sparse index
on it.
outer index a sparse index of primary
index
inner index the primary index file
If even outer index is too large to fit in main
memory, yet another level of index can be
created, and so on.
Indices at all levels must be updated on
insertion or deletion from the file.
Non-clustering Indices
Frequently, one wants to find all the records
whose values in a certain field satisfy some
condition, and the file is not ordered on the
field.
Example 1: In the account database stored
sequentially by account number, we may want to find
all accounts in a particular branch.
Example 2: As above, but where we want to find all
accounts with a specified balance or range of
balances.
34
CIS552
Brighton
A-217
750
Downtown
A-101
500
Downtown
A-110
600
Miami
A-215
700
Perryridge
A-102
400
Perryridge
A-201
900
Perryridge
A-218
700
Redwood
A-222
700
Round Hill
A-305
350
35
CIS552
36
Secondary Indices
Index record points to a bucket that contains pointers to all the actual records with that
particular search-key value.
Secondary indices have to be dense, since the file is not sorted by the search key.
Hashing
Static Hashing
A bucket is a unit of storage containing one or more
records (a bucket is typically a disk block).
In a hash file organization we obtain the bucket of a
record directly from its search-key value using a hash
function.
Hash function h is a function from the set of all searchkey values K to the set of all bucket addresses B.
Hash function is used to locate records for access,
insertion as well as deletion.
Records with different search-key values may be
mapped to the same bucket; thus entire bucket has to
be searched sequentially to locate a record.
Hash file
organization of
account file, using
branch_name as key
Hash Functions
Handling of Bucket
Overflows
Bucket overflow
can occur because of
Insufficient buckets
Skew in distribution of records. This can
occur due to two reasons:
multiple records have same search-key value
chosen hash function produces non-uniform
distribution of key values
Hashing can
be used not
only for file
organization,
but also for
indexstructure
creation.
A hash
index
organizes the
search keys,
with their
associated
record
pointers, into
a hash file
structure.
Hash Indices
Deficiencies of Static
In static hashing, Hashing
function h maps search-key values to a
fixed set of B of bucket addresses. Databases grow or
shrink with time.
Dynamic Hashing
All the entries that point to the same bucket have the same
values on the first ij bits.
Example (Cont.)
Example (Cont.)
Example (Cont.)
Example (Cont.)
Hash structure after insertion of
Redwood and Round Hill records
In practice:
PostgreSQL supports hash indices, but discourages use due to
poor performance
Oracle supports static hash organization, but not hash indices
SQLServer supports only B+-trees
To drop an index
drop index <index-name>
Indexing in Oracle
Hashing in Oracle