DBA Lecture
DBA Lecture
Management
Chapter 2 – Oracle Architecture
1
Deploying Physical Components
Control Files
Datafiles
Redo Log Files
2
Control Files
A database should have at least two copies of the control file on
different physical disks.
• to avoid the risk of losing track of database.
• all copies of the control file are kept in sync by Oracle DBMS.
• performance overhead of writing to multiple control files is insignificant.
Location of control files is defined by CONTROL_FILES
initialization parameter.
Example – specifying multiple copies of control files by indicating
multiple locations in the CONTROL_FILES parameter:
control_files = (/u00/oradata/control.001.dbf,
/u01/oradata/control.002.dbf,
/u02/oradata/control.003.dbf) 3
Datafiles
Datafiles contain the actual data stored in the database
• tables, indexes, data dictionary and rollback segments
A datafile is composed of Oracle database blocks that are composed of
operating system blocks on a disk.
Oracle block sizes range from 2 KB to 32 KB.
Datafiles belong to only one database and to only one tablespace
within that database.
Tuning the I/O subsystem to improve Oracle performance typically
involves moving datafiles from one set of disks to another, which is
done automatically using Automatic Storage Management.
4
Figure 2-4. Oracle blocks and operating system blocks
5
Setting the Database Block Size
Block size is the minimum amount of data that can be read or written
at one time.
Oracle defaults to a block size based on the operating system used.
DB_BLOCK_SIZE instance initialization parameter sets the default
block size for the database.
Up-to five other block sizes can be set in a database.
6
Setting the Database Block Size
The implications of the block size
• Having smaller blocks (4 KB) might be appropriate for transaction
processing systems. Oracle won’t waste system resources by transferring
larger blocks that contain additional data not required by the transaction.
• Using bigger database blocks enables each block read to deliver more
data to the requesting user. Data warehouses usually have larger blocks,
such as 8 KB or 16 KB. Each I/O operation might take a little longer due
to the larger block size, but the reduced number of operations will end
up improving overall performance.
7
Datafiles
Datafile structure
• Header - first block of each datafile
– contains critical information that maintains overall integrity of database
• Checkpoint structure - a logical timestamp in the header
– indicates the last point at which changes were made to the datafile
– determines which redo logs to apply
Extents and segments
• Datafiles have three organizational levels from logical point of view: data
blocks, extents, and segments.
• Extent - set of contiguous data blocks within a datafile
• Segment - an object composed of one or more extents (e.g. table)
– First, data is updated in the same data block. If there is not enough space, Oracle
writes data to a new data block that could be in a different extent. 8
Redo Logfiles
Containss a “recording” of the changes made to the database as a result
of transactions and internal Oracle activities.
Changed blocks are cached in memory and some changed blocks
might not have been written out to the datafiles when instance failure
occurs.
When failure occurs, log file is used to play back the changes lost.
Redo log files are also used for “undo” operations when a
ROLLBACK statement is issued.
9
Redo Logfiles
Suppressing Redo Logging
• By default, Oracle logs all changes made to the database.
• Generation of redo logs adds a overhead.
• Redo log generation can be supressed to speed up operationsbut
recovery will not be possible in the event of failure.
• NOLOGGING keyword is used in the SQL statements to suppress redo
logging for that operation.
• Table or tablespace can be marked with NOLOGGING attribute to
suppress logging for all applicable operations.
10
Redo Log Files
Multiplexing redo logfiles
• Each Oracle instance uses a thread of redo to record the changes it
makes to the database.
• A thread of redo is composed of redo log groups, which are composed of
one or more redo log members.
• Multiple copies of each redo logfiles are kept to protect from disk
failures and disasters.
• Oracle writes synchronously to all redo log members.
• Oracle will wait until all copies of the redo log have been updated on
disk before the redo write is considered done.
• Performance will be constrained by the slower disk.
11
Figure 2-5. A thread of redo
12
Redo Logfiles
How Oracle uses the redo logs
• Once Oracle fills one redo logfile, it automatically begins to use the next
logfile.
• When the server cycles through all the available redo logfiles, it returns
to the first one and reuses it.
• Oracle keeps track of the different redo logs by using a redo log
sequence number.
• Operating system uses the redo logfile to identify the physical file, while
Oracle uses the redo logfile sequence number to determine the order in
which the logs were filled and cycled.
13
Figure 2-6. Cycling redo logs
14
Redo Logfiles
Naming conventions for redo logs
• Operating system names for the various files that make up a database are
very important for humans to identify these files by their names.
• You should use naming conventions that capture the purpose and some
critical details about the nature of the file.
• Example:
– redog1m1.log, redog1m2.log, ...
– The redo prefix and .log suffixes indicate that this is redo log information. The
g1m1 and g1m2 character strings capture the group and member numbers.
15
Redo Logfiles
Two types of redo logs for Oracle:
1. Online redo logs
– The operating system files that Oracle cycles through to log the changes made to
the database
2. Archived redo logs
– Copies of the filled online redo logs made to avoid losing redo data as the online
redo logs are overwritten
16
Redo Log files
Oracle database can run in one of two modes with respect to archiving
redo logs:
• NOARCHIVELOG
– Redo logs are not archived.
– As Oracle cycles through the logs, the filled logs are reinitialized and
overwritten.
– Disadvantage - where a failure could lead to unrecoverable data.
• ARCHIVELOG
– When Oracle rolls over to a new redo log, it archives the previous redo log.
– Prevents gaps in the history.
– The archived redo logs, plus the online redo logs, provide a complete history of all changes made to
the database.
17
Redo Logfiles
ARCHIVELOG mode and automatic archiving
• Automatic archiving for an Oracle database is enabled with the
following SQL command:
ALTER DATABASE ARCHIVELOG
• In ARCHIVELOG mode, Oracle marks the redo logs for archiving as it
fills them.
• The full log files must be archived before they can be reused.
18
Redo Logfiles - ARCHIVELOG mode and automatic
archiving
• Archive log destination must have enough room for the logs that Oracle
will automatically write.
• If the archive log file destination is full, Oracle will hang since it can’t
archive additional redo log files.
• The archive log destination is set using parameter:
LOG_ARCHIVE_DEST = C:\ORANT\DATABASE\ARCHIVE
• The format for archive redo log names is specified using parameter:
LOG_ARCHIVE_FORMAT = ORCL%t_%s_%r.arc
19
Redo Logfiles - ARCHIVELOG mode and automatic
archiving
• The format for archive redo log names is specified using parameter:
LOG_ARCHIVE_FORMAT = ORCL%t_%s_%r.arc
• Wildcasrds
– %t - include thread number as part of the filename
– %s - include log sequence number as part of the filename
– %r - include resetlogs ID as part of the filename
20
Figure 2-7. Cycling redo logs with archiving
21
Redo Logfiles - ARCHIVELOG mode and automatic
archiving
• The archived redo logs are critical for database recovery.
• Multiple archive log destinations can be specified.
• You can also specify whether all copies must succeed or not.
• Following initialization parameter specifies an additional location for
redundant redo logs:
LOG_ARCHIVE_DUPLEX_DEST
• Initialization parameter indicates whether the redo log must be
successfully written to one or all of the locations. Valid values are 1
through 10 if multiplexing and 1 or 2 if duplexing.
LOG_ARCHIVE_MIN_SUCCEED_DEST
22
Instance Memory and Processes
Oracle instance comprises of area of shared memory and collection of
background processes.
Shared Memory
• All the processes of an instance share the area of memory called the
System Global Area (SGA).
Background processes
• Interact with the operating system.
• Interact with each other to manage the memory structures.
• Manage the actual database on disk.
23
Instance Memory and Processes
System Global Area (SGA)
• Area of shared memory for an instance
• Made up of various components
• All the system and user processes of an instance share the SGA
• Size of SGA can be changed while the Orcale instance is running
• Granule - the smallest amount of memory that can be added or
subtracted from the SGA
• Automatic Memory Management
– SGA_TARGET initialization parameter is set to automatically distribute the
memory among various SGA components.
24
Figure 2-8. An Oracle instance
25
Memory Structures for an Instance
System Global Area is composed of multiple areas:
• Database buffer cache
• Shared pool
• Redo log buffer
• Java pool
• Large pool
• Streams pool
26
Memory Structures for an Instance
Database buffer cache
• Holds blocks of data retrieved from and written to the database.
– Disks are the slowest component of a computer system
– Notion of waiting to perform I/O until absolutely necessary by deferring non-
critical I/O operations instead of performing them immediately
• Memory buffer caches users’ requests and datafiles to improve the
performance of database.
• Uses least recently used (LRU) algorithm.
27
Memory Structures for an Instance
Types of buffer pools in database buffer cache:
• DEFAULT
– Standard database buffer cache used by all objects unless otherwise indicated.
– Dynamic parameter DB_CACHE_SIZE is automatically sized if SGA_TARGET
is set.
• KEEP
– Used for frequently used objects user wishes to cache
– Size is specified using initialization parameter DB_KEEP_CACHE_SIZE
• RECYCLE
– Used for objects that are less likely to access again
– Size is specified using initialization parameter DB_RECYCLE_CACHE_SIZE
28
Memory Structures for an Instance
Shared pool
• Caches various constructs that can be shared among users.
– Caches SQL queries and results for reuse if the same statement is submitted
again.
– PL/SQL functions are also loaded into the shared pool for execution and the
functions and results are cached.
– Caches information from the Oracle data dictionary.
• LRU algorithm is used.
• SHARED_POOL_SIZE initialization parameter can be manually
specified, or is automatically sized if SGA_TARGET is set.
– Default value is 64 MB or 128 MB for 32-bit and 64-bit platforms respectively if
SGA_TARGET is not set.
29
Memory Structures for an Instance
Redo log buffer
• Holds information about changes to the database, called redo log entries,
until it is written to the physical redo log files stored on a disk.
• Improves performance by avoiding the overhead of constantly writing
the redo logs to disk.
• Circular buffer
• Initialization parameter LOG_BUFFER sets the size in bytes. The
default value of this size is four times the DB_BLOCK_SIZE.
30
Memory Structures for an Instance
The SGA includes several other pools:
Large pool
• Provides memory allocation for various I/O server processes, backup, and
recovery, and provides session memory where shared servers are used.
Java pool
• Provides memory allocation for Java objects and Java execution, including
data in the Java Virtual Machine in the database.
Streams pool
• Provides memory allocation used to buffer Oracle Streams queued
messages in the SGA instead of in database tables and provides memory
for capture and apply.
31
Memory Structures for an Instance
Automatic PGA management
• Oracle automatically manages the memory allocated to an instance
Program Global Area (PGA).
• The PGA consists of session memory and a private SQL area.
• There is a PGA allocated for each service, which corresponds to a
pluggable database in Oracle Database 12c.
• PGA_AGGREGATE_TARGET initialization parameter controls the
amount of memory allocation. Default value is 10 MB or 20% of the size
of the SGA, whichever is greater.
• PGA_AGGREGATE_LIMIT parameter sets a hard limit on the total
amount of memory that the PGA can use. When this limit is reached, the
sessions using the greatest amount of the PGA are paused until the
memory usage drops. 32
Background Processes for an Instance
Database Writer (DBWn)
• Writes database blocks from the database buffer cache in the SGA to the
datafiles on disk.
• An Oracle instance can have up to 20 DBW processes to handle the I/O
load to multiple datafiles.
• DBW writes blocks out of the cache for two main reasons:
– After checkpoint to bring the datafile contents in line with the redo that was
written out for the committed transactions.
– To free space in the buffer cache. The blocks written out are the least recently
used blocks.
33
Background Processes for an Instance
Log Writer (LGWR)
• Writes the redo information from the log buffer in the SGA to all copies
of the current redo log file on disk.
• As transactions proceed, the associated redo information is stored in the
redo log buffer in the SGA.
• When a transaction is committed, LGWR is invoked to write it to disk.
34
Background Processes for an Instance
System Monitor (SMON)
• Maintains overall health and safety for an Oracle instance.
• Performs crash recovery when the instance is started after a failure.
• Cleans up adjacent pieces of free space in the datafiles by merging them
into one piece and gets rid of space used for sorting rows when that
space is no longer needed.
Process Monitor (PMON)
• Watches over the user processes that access the database.
• Is responsible for cleaning up any of the left behind resources and for
releasing any locks held by the failed process.
35
Background Processes for an Instance
Archiver (ARCn)
• Creates a copy of filled redo log files to the specified archive log
destination(s).
• Up to 10 Archiver processes are possible
• LOG_ARCHIVE_MAX_PROCESSES initialization parameter specifies
maximum limit
– Default value is 2 and is rarely changed.
36
Background Processes for an Instance
Checkpoint (CKPT)
• Updates datafile headers whenever a checkpoint is performed.
Recover (RECO)
• Automatically cleans up failed or suspended distributed transactions.
Job Queue
• Provides a scheduler service used to schedule user PL/SQL statements or
procedures in batch.
37
Configuration, Engineered Systems, and the Cloud
Oracle database requires too much maintenance and configuration
• Allows fine-tuning
• Has become more self-tuning and self-managing
• Configuration can be set incorrectly
Engineered systems
• Pre-assembled and preconfigured systems.
• Faster to start using your Oracle Database.
• System will be properly configured and balanced to operate optimally.
Oracle Database Cloud
• Two different cloud levels: DBaaS and PaaS.
38
The Data Dictionary
Oracle database includes a set of metadata that describes the data
structure including table definitions and integrity constraints.
Oracle data dictionary - tables and views that hold metadata
• These tables and views can be quried using standard SQL statements.
• Data dictionary tables are contained in SYSTEM tablespace.
Dynamic data dictionary tables
• Continually updated to reflect the current state of database
• Preceded by the V$ or GV$ prefixes
Static data dictionary tables
• Prefixed by DBA_, ALL_, or USER_ to indicate the scope of the objects
39