Oracle Essentials Oracle Database 11g (9 page)

Read Oracle Essentials Oracle Database 11g Online

Authors: Rick Greenwald

Embedded Databases

Although Oracle’s database family can be deployed for embedded applications, the footprint and functionality might be more than what you need. Today, Oracle offers other embedded databases including TimesTen, Berkeley DB, and Oracle Database Lite. These database engines have unique code lines in order to provide small footprints and have different intended roles. For this reason, we will describe these briefly in the following subsections but will not explore their capabilities in great detail elsewhere in this book.

Oracle TimesTen

Oracle TimesTen is a relational database that is stored in physical memory and is typically used where very high-performance transaction-processing workloads are present. Access to the TimesTen database is available through SQL, JDBC, JMS, and ODBC. TimesTen databases can be deployed as exclusive or shared and can be created as permanent or temporary.

The database is refreshed by gathering data using TimesTen libraries deployed to applications or by using a Cache Connect option to an Oracle database. Because data is read and updated in memory, average update or read response times are typically measured in the millionths of seconds. The Cache Connect option supports both read and write caching of Oracle database data. Updates can be bidirectional between TimesTen and Oracle.

As is typical for embedded databases, TimesTen requires almost no ongoing administration. Replication is possible from one TimesTen database to another through an option and is, by default, asynchronous.

Oracle Berkeley DB

Oracle Berkeley DB is an extremely small-footprint embedded database engine providing record-level locking. It comes in Java and XML versions. It is designed to be deployed with and run in the same process as your applications. When Berkeley DB

is deployed in this manner, no separate database administration is required. Footprints for the database can be as small as 400 KB.

The Java Edition of Berkeley DB supports the Java Transaction API (JTA), J2EE

Connector Architecture (JCA), and Java Management Extensions (JMX). The database is a single JAR file that is 820 KB in size and runs in the same Java Virtual Machine (JVM) as the application. A Direct Persistence Layer (DPL) is supported for accessing Java objects.

Embedded Databases

The XML Edition of Berkeley DB is most commonly used in network-based applications where content is managed. XQuery and XPath are supported.

Both editions can be configured for high availability using replication. Automatic recovery is also supported. Deployment decisions such as these are made by the application designer at application design time.

Oracle Lite

Oracle Lite is a suite of products enabling mobile use of database-centric applications. Key components of Oracle Lite include the Oracle Lite Database, Mobile Development Kit, and Mobile Server (an extension of the Oracle Application Server).

The Oracle Lite Database engine requires a 50KB to 1 MB footprint depending on the platform. Applications written using Mobile SQL, C++, and Java can use the database. ODBC is also supported. Java support includes Java stored procedures and JDBC. The Oracle Lite Database is also designed to be self-tuning and self-administering and is supported on handheld devices running Windows CE, Symbian, Windows, and Linux.

In typical usage of Oracle Lite, the user will link her handheld or mobile device running the Oracle Lite Database to a large-footprint Oracle Database Server. Data is then automatically synchronized between the two systems. The user will then remove the link and work in disconnected mode. After she has performed her tasks, she will relink and resynchronize the data with the Oracle Database Server.

Oracle Lite supports a variety of synchronization capabilities, including the following:

• Bidirectional synchronization between the mobile device and Oracle’s larger footprint databases

• Publish-and-subscribe based models

• Support for protocols such as TCP/IP, HTTP, CDPD, 802.1, and HotSync You can define priority-based replication of subsets of data. Because data distributed to multiple locations can lead to conflicts—such as which location now has the

“true” version of the data—automated conflict and resolution is provided. You can also customize the conflict resolution.

The Mobile Server provides a single platform for publishing, deploying, synchroniz-ing, and managing mobile applications. The web-based control center can be used for controlling access to mobile applications. Oracle’s former “Web-to-Go” product is also part of the Mobile Server and provides centralized wizard-based application development and deployment.

Chapter 1: Introducing Oracle

Chapter 2

CHAPTER 2

Oracle Architecture2

This chapter focuses on the concepts and structures at the core of the Oracle database. When you understand the architecture of the Oracle server, you’ll have a context for understanding the rest of the features of Oracle described in this book.

An Oracle database consists of both physical and logical components. The first section of this chapter covers the difference between an Oracle database and an instance, and subsequent sections describe physical components, the instance, and the data dictionary.

Databases and Instances

Many Oracle practitioners use the terms
instance
and
database
interchangeably. In fact, an instance and a database are different (but related) entities. This distinction is important because it provides insight into Oracle’s architecture.

In Oracle, the term
database
refers to the physical storage of information, and the term
instance
refers to the software executing on the server that provides access to the information in the database. The instance runs on the computer or server; the database is stored on the disks attached to the server.
Figure 2-1
illustrates this relationship.

The database is
physical
: it consists of files stored on disks. The instance is
logical
: it consists of in-memory structures and processes on the server. For example, Oracle uses an area of shared memory called the System Global Area (SGA) and a private memory area for each process called the Program Global Area (PGA). An instance can be part of one and only one database, although multiple instances can be part of the same database. Instances are temporal, but databases, with proper maintenance, last forever.

Users do not directly access the information in an Oracle database. Instead, they pass requests for information to an Oracle instance.

Database

Server

An Oracle instance consists of

Oracle Instance

processes and memory on the

database server

An Oracle database consists of physical

files on the disk

Oracle Database

Figure 2-1. An instance and a database

The real world provides a useful analogy for instances and databases. An instance can be thought of as a bridge to the database, which can be thought of as an island.

Traffic flows on and off the island via the bridge. If the bridge is closed, the island exists but no traffic flow is possible. In Oracle terms, if the instance is up, data can flow in and out of the database. The physical state of the database is changing. If the instance is down, users cannot access the database even though it still exists physically. The database is static: no changes can occur to it. When the instance comes back into service, the data will be there waiting for it.

Oracle Database Structure

Oracle’s database structures include tablespaces, control files, redo log files, archived logs, block change tracking files, Flashback logs, and recovery backup (RMAN) files.

This section introduces many of the structures and other components that make up a complete database.

Tablespaces

All of the data stored within an Oracle database must reside in a tablespace. A
tablespace
is a logical structure; you can’t look at the operating system and see a tablespace. Each tablespace is composed of physical structures called
datafiles
; each tablespace must consist of one or more datafiles, and each datafile can belong to only one tablespace. When creating a table, youcan specify the tablespace in which to create it. Oracle will then find space for it in one of the datafiles that make up the tablespace.

Chapter 2: Oracle Architecture

Figure 2-2 shows the relationship of tablespaces to datafiles for a database.

DATA1

DATA2

data1_01.dbf

data2_01.dbf

data2_02.dbf

The DATA1

The DATA2

tablespace consists

of one datafile

of two datafiles

Figure 2-2. Tablespaces and datafiles

This figure shows two tablespaces within an Oracle database. When you create a new table in this Oracle database, youmay place it in the DATA1 tablespace or the DATA2 tablespace. It will physically reside in one of the datafiles that make up the specified tablespace.

Oracle’s default tablespaces for all types of tables are
locally managed tablespaces
as of Oracle Database 10
g
Release 2. Locally managed tablespaces enable creation of
bigfile tablespaces
that can leverage 64-bit systems and their ability to manage ultra-large files.

Oracle9
i
introduced the concept of Oracle Managed Files (OMFs), which enable your database to automatically create, name, and delete, where appropriate, all the files that make up your database. OMFs reduce the maintenance overhead of naming and tracking the filenames for your database, as well as avoiding the problems that can result from human errors in performing these tasks. Since Oracle Database 10
g
, OMFs and bigfile tablespaces combine to make datafiles appear completely transparent.

Oracle databases can be deployed on up to 64,000 datafiles. Because a bigfile tablespace can contain a file that is 1,024 times larger than a smallfile tablespace, and bigfile tablespaces have 32 KB block sizes on 64-bit operating systems, the Oracle database can grow to up to 8 exabytes in size (an exabyte is equivalent to a million terabytes).* The bigfile tablespace is designed for use with Oracle’s Automatic Storage Management (ASM), other logical volume managers that support striping, and RAID.†

* The ultimate size of a bigfile depends on the limitations of the underlying operating system.

†
RAID stands for “redundant array of inexpensive disks” and is described in Chapter 7.

Databases and Instances

Files of a database

There are actually three fundamental types of physical files that make up an Oracle database:

• Control files

• Datafiles

• Redo log files

These three fundamental types represent the physical database itself.
Figure 2-3
illustrates the three types of files and their interrelationships.

Control

Files

Identify

Record changes to

Datafiles

Redo Log Files

Figure 2-3. The files that make up a database

The control file contains locations for other physical files that form the database: the datafiles and redo log files. It also contains key information about the contents and state of the database, including:

• The name of the database

• When the database was created

• Names and locations of datafiles and redo log files

• Tablespace information

• Datafile offline ranges

• The log history and current log sequence information

Chapter 2: Oracle Architecture

• Archived log information

• Backup set, pieces, datafile, and redo log information

• Datafile copy information

• Checkpoint information

In addition to providing fundamental information at startup, control files are also useful when removing a database. Since Oracle Database 10
g
, the DROP DATABASE command can be used to delete the database files listed in the database control file as well as the control file itself.

Database Initialization

At Oracle database instance startup, initialization parameters are read to determine how the database will leverage physical infrastructure and for other key instance configuration information. Initialization parameters are stored in an instance initialization parameter file, often refered to as
INIT.ORA
, or, since Oracle9
i
, in a repository called the server parameter file (or
SPFILE
). The number of initialization parameters that must be specified has been greatly reduced with each Oracle database release. Oracle provides a sample initialization file that can be used at database startup, and the Database Configuraton Assistant (DCA) prompts you for values that must be provided on a custom basis (such as database name).

The set of initialization parameters that must be specified in Oracle Database 11
g
include:

CONTROL_FILES

The control file locations

DB_NAME

The local database name

DB_DOMAIN

The database domain name (such as us.companyname.com)

LOG_ARCHIVE_DEST

The log archive destination

LOG_ARCHIVE_DEST_STATE

The parameter that enables log archiving

DB_RECOVERY_FILE_DEST