Expert One-on-One Oracle Chapter 2: Architecture

1. Expert One-on-One Oracle
Chapter 2 - Architecture

2. Overview
• Oracle is designed to be a very portable database
that's why the physical architecture of Oracle
looks different on different operating systems.
• The physical mechanisms used to implement
Oracle from platform to platform vary, the
architecture is sufficiently generalized enough
that you can get a good understanding of how
Oracle works on all platforms.

3. Major Components Of The Oracle
Architecture
• Files
• Memory Structures
• Physical processes and threads

4. • Parameter files ‐ These files tell the Oracle instance where to find the
control files.
For example, how big certain memory structures are, and so on.
• Data files ‐ For the database (these hold your tables, indexes and all other
segments).
• Redo log files ‐ Our transaction logs.
• Control files ‐ Which tell us where these data files are, and other relevant
information about their state.
• Temp files ‐ Used for disk‐based sorts and temporary storage.
• Password files ‐ Used to authenticate users performing administrative
activities
over the network. We will not discuss these files in any detail.

5. The files
associated with an instance are :
• Parameter files
These files tell the Oracle instance where to find
the control files.
For example, how big certain memory structures
are, and so on.

6. The Files that make up database:
• Data files
For the database (these hold your tables, indexes and all other
segments).
• Redo log files
Our transaction logs.
• Control files
Which tell us where these data files are, and other relevant
information about their state.
• Temp files
Used for disk‐based sorts and temporary storage.
• Password files
Used to authenticate users performing administrative
activities over the network. We will not discuss these files in
any detail.

7. Parameter files
• The parameter file for a database is commonly
known as an init file, or an init.ora file.
• Without a parameter file, you cannot start an Oracle
database.
• The Oracle init.ora file is a very simple file in its
construction. It is a series of variable
name/value pairs. It’s look like this.
• db_name = ʺtkyte816ʺ
• db_block_size = 8192
• control_files = (ʺC:oradatacontrol01.ctlʺ,
ʺC:oradatacontrol02.ctlʺ)

8. Data files
• Data files, along with redo log files, are the most
important set of files in the database. This
is where all of your data will ultimately be
stored.
• Every database has at least one data file
associated with it, and typically will have many
more than one.

9. • What we will discuss in this section is how
Oracle organizes
these files, and how data is organized within
them. In order to understand this we will
have to understand what a tablespace, segment,
extent, and block are.

10. • Segments are simply your database objects that
consume storage ‐ objects such as tables,
indexes, rollback segments, and so on.
• Every object that consumes storage is ultimately
stored in a single segment.
• Segments themselves consist of one or more
extent. An extent is a contiguous allocation of
space in a file.
• Extents, in turn, consist of blocks. A block is the
smallest unit of space allocation in Oracle.

11. • Blocks are where your rows of data, or index
entries, or temporary sort results will be
stored. Blocks in
Oracle are generally one of three common sizes ‐
2 KB, 4 KB, or 8 KB (although 16 KB and
32 KB are also permissible).

12. The relationship between segments,
extents, and blocks looks
like this:

13. • The block size for a database is a constant once
the database is. All blocks have the same general
format, which looks something like this:

14. Table Space
• A tablespace is a container ‐ it holds segments.
Each and every segment belongs to
exactly one tablespace.

15. • In summary, the hierarchy of storage in Oracle is as
follows:
• 1. A database is made up of one or more tablespaces.
• 2. A tablespace is made up of one or more data files.
A tablespace contains segments.
• 3. A segment is made up of one or more extents. A
segment exists in a tablespace.
• 4. An extent is a contiguous set of blocks on disk.
• 5. A block is the smallest unit of allocation in the
database. A block is the smallest unit
of I/O used by a database.

16. Temp Files
• Temporary data files (temp files) in Oracle are a
special type of data file. Oracle will use
temporary files to store the intermediate results
of a large sort operation, or result set,
when there is insufficient memory to hold it all
in RAM.
• Data objects like table or an index never stored
in these type of files because data objects must
be stored permanently.

17. Control files
• The control file is a fairly small file that
contains a directory of the other files Oracle
needs.
• The parameter file (init.ora file) tells
the instance where the control files are, the
control files tell the instance where the
database and online redo log files are.

18. Redo Log Files
• Redo log files are extremely crucial to the Oracle
database. These are the transaction logs
for the database. They are used only for recovery
purposes ‐ their only purpose in life is to
be used in the event of an instance or media
failure, or as a method of maintaining a
standby database for failover.
• There is a online redo log files either.

19. Online Redo Log
• Every Oracle database has at least two online
redo log files.
• Oracle will write to log file 1, and when it
gets to the end of this file, it will switch to log file
2, and rewrite the contents of that file
from start to end.
• When it has filled log file 2, it will switch back to
log file 1.

20. Assume we have three log files.

21. The Memory Structures
• SGA, System Global Area
This is a large, shared memory segment that virtually all Oracle
processes will access at one point or another.
• PGA, Process Global Area
This is memory, which is private to a single process or thread, and is
not accessible from other processes/threads.
• UGA, User Global Area
This is memory associated with your session. It will be found either
in the SGA or the PGA depending on whether you are running in
MTS mode (then itʹll be in the SGA), or dedicated server (itʹll be in
the PGA).
• We will briefly discuss the PGA and UGA, and then move onto the
really big structure, the SGA.

22. PGA
• The PGA, the Program Global Area or Process
Global Area, is some sort of memory and
allocates a small amount to each connecting user
to Oracle (default 5M). It keeps data and control
information.
• The PGA is never allocated out of Oracleʹs SGA.

23. UGA
• The UGA is in effect, your sessionʹs state. It is
memory that your session must always be able to
get to. The location of the UGA is wholly
dependent on how Oracle has been configured to
accept connections.

24. SGA
• SGA, ie System (Shared) Global Area. It consists
of memory groups that hold data and control
information for the Oracle instance. The
components of the SGA,
• Redo Log buffer (log_buffer)
• Buffer cache (db_cache_size)
• Shared pool (shared_pool_size)
• Large pool (large_pool_size)
• Java pool (java_pool_size)

25. Redo log buffer
• The redo buffer is where data that needs to be
written to the online redo logs will be cached
temporarily before it is written to disk.

26. Buffer cache
• The buffer cache is where Oracle will store
database blocks before writing them to disk, and
after reading them in from disk.
• This is a crucial area of the SGA for us.

27. Shared Pool
• The shared pool is one of the most critical pieces
of memory in the SGA, especially in regards to
performance and scalability. A shared pool that
is used incorrectly will be a disaster.
• The shared pool is where Oracle caches many
bits of ʹprogramʹ data. When we parse a query,
the results of that are cached here.

28. Large Pool
• Fields dedicated to I/O server processes and
backup/restore operations.
• Oracle does not expect the database
administrator to set these values most of the
time. In fact, it has a structure that dynamically
adjusts these values.

29. Java Pool
• Field where Java procedures are used. If you are
running any java code on Oracle this memory
should be set to a certain amount.

30. Thanks for listening.