Database Administration

Installations
Network Environments And
Storage
Configurations
 Configuring Network Environment

 Configuring Network Environment,

 Overview of Network Configuration,
 Oracle Net Listener Configuration and Management,
 Oracle Net Naming Methods,
 Tools for Configuring and Managing the Oracle Network,
 Using the Net Configuration Assistant,
 Configure Client Connections with Net Manager,
 View Listener Configuration,
 Start and Stop the Oracle Listener
 Use TNSPING to Test Oracle Net Connectivity
 Connect to the Database
 Configure Net Services with Enterprise Manager
 Oracle Net Listener
Configuration
• On the database host, the Oracle Net listener is a process that listens for client
connection requests.
• A client is any application that connects to Oracle Database to send or retrieve data.
• Oracle Net is a software layer that resides on the client computer and on the Oracle
database host computer.
• A service name is a logical representation of a database, which is the way a database
is presented to clients. A single database can be presented as multiple services.
• "listener.ora" is a default listener configuration file located at "network/admin" folder
in Oracle home directory. Eg "C:\Program files\Oracle\network\admin"
• Listener.ora contains protocol address that identified databases along with protocol
specific information.
(DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=dbhost.localhost.com.np)
(PORT=1521)))
• This default listener is named LISTENER, supports no service names on startup, and
listens on the following TCP/IP protocol address
(ADDRESS=(PROTOCOL=tcp)(HOST=host_name)(PORT=1521))
• The service names, or the databases that they represent, to which the listener
forwards client requests, can be configured in the listener.ora file.
• Service registration is performed by the listener registration (LREG) process— an
instance background process—of each database instance.
 Start, Stop and Viewing Listener Configuration
• The Oracle Net listener (the listener) runs on your database host and handles incoming
client requests. You can view the listener status, start and stop, at the command line.
• To view information about the listener at the command line:
• Open a command window.
• Enter the following command:
lsnrctl Start
lsnrctl Stop
lsnrctl status
 Oracle Client Connections
• Oracle client can connect to database server with following elements.

1. Connect Descriptors:
Specify the database to which client wants to connect using description. Descriptor
consist of database service name along with protocol to be used.
Eg DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=my-server)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=mydb.us.localhost.com)
 Oracle Client Connections
• Oracle client can connect to database server with following elements.

1. Naming Methods:

A naming method is a resolution method used by a client application to resolve a

connect identifier to a connect descriptor when attempting to connect to a database
service.
• Easy Connect Naming
• Local Naming
• Directory Naming
 Oracle Client Connections
• Oracle client can connect to database server with following elements.

1. Connection Request:
Users initiate a connection request by providing a connect string. A connect string
includes a user name and password, and a connect identifier. This connect identifier
can be the connect descriptor itself, or a name that resolves to the connect descriptor
using mapping information stored in one or more repositories accessed with the
naming methods described in "Naming Methods". This name is referred to as a net
service name.
 Storage Structures

 Overview of Data Storage,

 The Database Block,

 Overview of Tablespaces and Datafiles,

 Use Enterprise Manager to view the Storage Structure of the Database,

 Create and Alter Tablespace Commands,

 Temporary Tablespaces,

 Create and Manage Datafiles,

 Use OMF,

 Drop Tablespaces and Datafiles

 Overviews
 Oracle database consists of physical and logical structures.
 Physical structures, such as data files on disk, are visible and operable from the
operating system.
 Logical structures, managed by Oracle Database, are not recognized by the operating
system.
 Tablespace is a primary logical structure containing physical files.
 Developers and users usually interact with logical structures without knowledge of the
underlying physical setup.
 Database administrators (DBAs) must understand the relationship between physical
and logical structures.
 Overview of Data Blocks
A data block is a unit of logical storage managed by oracle database in
database data, also called an Oracle block or page. A data block is the
minimum unit of database I/O.
 Database data is store in disk files built upon OS blocks.
 Oracle data block is a logical storage structure above OS block.

When the database requests a data block, the operating system translates
this operation into a requests for data in permanent storage. The logical
separation of data blocks from operating system blocks has the following
implications:
• Applications do not need to determine the physical addresses of data on
disk.
• Database data can be striped or mirrored on multiple physical disks.
 Overview of Data Blocks
Database Block Size
Every database has a database block size.

The DB_BLOCK_SIZE initialization parameter sets the data block size for a database when it is created. The size is
set for the SYSTEM and SYSAUX tablespaces and is the default for all other tablespaces. The database block size
cannot be changed except by recreating the database.

If DB_BLOCK_SIZE is not set, then the default data block size is operating system-specific. The standard data block
size for a database is 4 KB or 8 KB. If the size differs for data blocks and operating system blocks, then the data block
size must be a multiple of the operating system block size.
 DATA FILES
Data files are the operating system physical files that store the data within the database. The data is written to these files
in an Oracle proprietary format that cannot be read by other programs. Tempfiles are a special class of data files that are
associated only with temporary tablespaces.

Data files can be broken down into the following components logical storage structure:

• Segment : A segment contains a specific type of database object. For example, a table is stored in a table segment, and
an index is stored in an index segment. A data file can contain many segments.
• Extent : An extent is a contiguous set of data blocks within a segment. Oracle Database allocates space for segments in
units of one extent. When the existing extents of a segment are full, the database allocates another extent for that
segment.
• Data block : A data block, also called a database block, is the smallest unit of I/O to database storage. An extent
consists of several contiguous data blocks. The database uses a default block size at database creation.
After the database has been created, it is not possible to change the default block size without re-creating the database.
It is possible, however, to create a tablespace with a block size different than the default block size.

Segments, extents, and data blocks are all logical structures. Only Oracle Database can determine how many data blocks
are in a file. The operating system recognizes only files and operating system blocks, not the number of data blocks in an
Oracle Database file. Each data block maps to one or more operating system blocks.
 DATA FILES
Oracle database must have at least one data file. Oracle Database stores
database data in structures called data files. It is a physical store tablespace
in data files.

Each nonpartitioned schema object and each partition of an object is

stored in its own segment, which belongs to only one tablespace.

• Each tablespace consists of one or more data files, which conform to the
operating system in which Oracle Database is running.
• The data for a database is collectively stored in the data files located in
each tablespace of the database.
• A segment can span one or more data files, but it cannot span multiple
tablespaces.
• A database must have the SYSTEM and SYSAUX tablespaces.

Oracle Database automatically allocates the first data files of any database
for the SYSTEM tablespace during database creation. The SYSTEM
tablespace contains the data dictionary, a set of tables that contains
database metadata. Typically, a database also has an undo tablespace and a
temporary tablespace (usually named TEMP).
 TABLESPACES AND DATA FILES

A tablespace is a logical storage container for segments.

Segments are database objects, such as tables and indexes, that
consume storage space. At the physical level, a tablespace stores
data in one or more data files or temp files.

A database must have the SYSTEM and SYSAUX tablespaces.

The following figure shows the tablespaces in a typical database.
The following sections describe the tablespace types.

Some of the default tablespace included in oracle database are

1. SYSTEM
2. SYSAUX
3. TEMP
4. UNDOTBS1
5. USERS
6. EXAMPLE
 TABLESPACES AND DATA FILES
A permanent tablespace groups persistent schema objects.
The segments for objects in the tablespace are stored
physically in data files.

Each database user is assigned a default permanent

tablespace. A very small database may need only the default
SYSTEM and SYSAUX tablespaces.

Tablespaces are used to achieve the following goals:

• Control disk space allocation for database data
• Assign a quota (space allowance or limit) to a database user
• Take individual tablespaces online or offline without
affecting the availability of the whole database
• Perform backup and recovery of individual tablespaces
• Import or export application data by using the Oracle Data
Pump utility An undo tablespace is a locally managed tablespace
• Create a transportable tablespace that you can copy or reserved for system-managed undo data.
move from one database to another, even across platforms Like other permanent tablespaces, undo tablespaces
contain data files. Undo blocks in these files are grouped in
extents.
 TABLESPACES AND DATA FILES
A temporary tablespace contains transient data that
persists only for the duration of a session. No
permanent schema objects can reside in a temporary
tablespace. A temp file stores temporary tablespace
data.

Temporary tablespaces are either shared or local.

A shared temporary tablespace stores temp files on
shared disk, so that the temporary space is accessible to
all database instances.
In contrast, a local temporary tablespace stores
separate, non-shared temp files for every database
instance.
You can create local temporary tablespaces for both
read-only and read/write database instances. When Advantages
many read-only instances access a single database, local • Improving I/O performance by using local rather than shared disk
temporary tablespaces can improve performance for storage
queries that involve sorts, hash aggregations, and joins. • Avoiding expensive cross-instance temporary space management
• Improving instance startup performance by eliminating on-disk
space metadata management
 Tablespace Commands
 Create Tablespace

Adding Tablespace would be done with following syntax or SQL command

CREATE TABLESPACE TBSPACE1 ;
CREATE TABLESPACE TBSPACE2 DATAFILE SIZE 400m;
CREATE TABLESPACE TBSPACE3 DATAFILE ‘bmc_oraclefile1.dbf‘ AUTOEXTEND ON MAXSIZE 800M;
Create Temp files for temporary tablespace
CREATE TEMPORARY TABLESPACE TBSPACE01;
ALTER TABLESPACE TBSPACE01 ADD TEMPFILE ;

 Alter Tablespace

ALTER TABLESPACE TBSPACE1 ADD DATAFILE ‘bmc_oraclefile2.dbf SIZE 100M; -- AUTOEXTEND

ON;

 Delete
DROP TABLESPACE TBSPACE1;
DROP TABLESPACE TBSPACE1 INCLUDING CONTENTS;

 View Tablespace
SELECT TBSPACE1 FROM dba_tablespaces;
SELECT TBSPACE1, FILENAME FROM dba_data_files;
 Oracle Managed Files (OMF)
Utilizing Oracle Managed Files streamlines Oracle Database administration by eliminating the need for direct
management of operating system files by the DBA. Instead, with Oracle Managed Files, you designate file system
directories where the database autonomously creates, names, and manages files at the level of database objects.
For instance, when creating a tablespace, you only need to express the intention to create it; there's no
requirement to specify the name and path of the tablespace's data file using the DATAFILE clause. This
functionality seamlessly integrates with logical volume managers (LVM).

Internally, the database utilizes standard file system interfaces to manage various database structures, including
tablespaces, redo log files, control files, archived logs, block change tracking files, flashback logs, and RMAN
backups. Initialization parameters allow you to specify the file system directory for a particular type of file.
Consequently, the database ensures the creation and deletion of unique files—Oracle managed files—as needed.
It's important to note that this feature does not impact the creation or naming of administrative files like trace
files, audit files, alert logs, and core files.
 Oracle Managed Files (OMF)
Specify file operations in terms of database objects rather than file names

Parameters Descriptions
DB_CREATE_FILE_DEST Define the location of the default file
system directory for data files and
temporary files.
DB_CREATE_ONLINE_LOG_DEST_n Defines the location ofr redo log files and
control file creation
DB_RECOVERY_FILE_DEST Default location for the fast recovery area

SQL > ALTER SYSTEM SET DB_CREATE_FILE_DEST = ‘C:\oracle_home\oradata\ ’ ;

SQL > CREATE TABLESPACE tbspc1;
 CONTROL FILES
The control file serves as the database's cornerstone, overseeing its physical elements and
facilitating the location of all other database files. Due to its critical role, Oracle suggests
duplicating the control file, ensuring redundancy by having multiple identical copies. For
databases initialized through the Oracle Database Configuration Assistant (DBCA), two
synchronized control file copies are automatically generated.

In the event of a control file failure, the database becomes inaccessible. However, if a
duplicate control file is available, you can proceed to shut down the database and recreate
the faulty control file using the duplicate. Subsequently, the database can be restarted.
Alternatively, you have the option to remove the malfunctioning control file from the
CONTROL_FILES initialization parameter and restart the database using the remaining
control files.
 CONTROL FILES

1. Control file is a small binary file associated with only one database. Although multiple
identical copies are permitted. Control file manages the state of database and locate
database files.
2. Control files consist of name of database with Unique identifier (DBID).
3. Control file consist of time stamp of creation of database.
4. Contains information about data files, online redo log files and other files.
5. It holds information regarding tablespace information.
CONTROL FILES
PURPOSE OF THE “CONTROL FILE”

• It holds Metadata (Information) about data files, online redo log files, and so on that are required to open
the database.
The control file tracks structural changes to the database. For example, when an administrator adds, renames,
or drops a data file or online redo log file, the database updates the control file to reflect this change.

• Metadata that must be accessible when the database is not open.

The control file contains information required to recover the database, including checkpoints. A checkpoint
indicates the SCN (System Change Number) in the redo stream where instance recovery would be required to
begin. Every committed change before a checkpoint SCN is guaranteed to be saved on disk in the data files. At
least every three seconds the checkpoint process records information in the control file about the checkpoint
position in the online redo log.

Oracle Database reads and writes to the control file continuously during database use and must be available
for writing whenever the database is open. For example, recovering a database involves reading from the
control file the names of all the data files contained in the database. Other operations, such as adding a data
file, update the information stored in the control file.
 Importance

1. The control file must be available for writing by the Oracle Database server
whenever the database is open.
2. Without the control file, the database cannot be mounted and recovery is difficult.

3. By default, at least one copy of the control file is created during database creation.
On some operating systems the default is to create multiple copies. You should
create two or more copies of the control file during database creation. You can also
create control files later, if you lose control files or want to change particular
settings in the control files.
 Online Redo Log Files
An Oracle database typically maintains a collection of two or more online redo log files, collectively referred to
as the redo log. These files record changes made to the data, providing a crucial mechanism for data recovery
in the event of failures such as hardware or software issues. Should a data file need restoration from backup,
recent changes can be retrieved from the redo log, ensuring no work is lost. To further safeguard against
failures involving the redo log itself, Oracle Database can duplicate the files, maintaining identical copies on
different disks, a process known as multiplexing.

The redo log is organized into groups, each comprising one or more redo log files along with their duplicate
copies. These duplicates, stored on separate disks, serve to enhance system resilience. Each group is identified
by a unique number, such as Group 1. For instance, in a setup with three redo log groups, each group might
contain two members stored on distinct disks to ensure maximum availability.
 Online Redo Log Files

Redo Threads
When speaking in the context of multiple database instances, the redo log for each database instance is also referred to as a
redo thread. In typical configurations, only one database instance accesses an Oracle Database, so only one thread is present.
In an Oracle Real Application Clusters environment, however, two or more instances concurrently access a single database and
each instance has its own thread of redo. A separate redo thread for each instance avoids contention for a single set of redo
log files, thereby eliminating a potential performance bottleneck.

Redo Log Contents

The redo log files contain redo records, which are composed of groups of change vectors. Each change vector describes a
modification made to a single database block. For instance, altering a salary value in an employee table generates a redo
record comprising change vectors detailing adjustments to the data segment block, the undo segment data block, and the
transaction table of the undo segments.

These redo entries capture data necessary to reconstruct all database changes, including those in the undo segments, thereby
safeguarding rollback information. During database recovery using redo data, the database utilizes the change vectors in redo
records to implement alterations to the relevant blocks.
 Online Redo Log Files

Redo records are temporarily stored in a circular manner within the redo log buffer of
the System Global Area (SGA), and the Log Writer (LGWR) background process writes
them to one of the redo log files. Upon transaction commitment, LGWR transfers the
transaction redo records from the redo log buffer to a redo log file, assigning a System
Change Number (SCN) to identify the redo records for each committed transaction.
Only when all redo records linked with a specific transaction are securely stored on disk
in the online logs is the user process notified of the transaction's commitment.

Redo records can also be written to a redo log file before the corresponding
transaction is committed. If the redo log buffer becomes full or another transaction
commits, LGWR flushes all redo log entries in the buffer to a redo log file, even if some
redo records are not yet committed. If necessary, the database can rollback these
changes.
 Online Redo Log Files

How Oracle Database Writes to the Redo Log

•The redo log for a database comprises two or more redo log files.
•A minimum of two files is necessary to ensure continuous availability for writing,
especially when the database is in ARCHIVELOG mode.
•LGWR (Log Writer) follows a circular writing pattern when writing to redo log files.
•When the current redo log file is filled, LGWR moves on to write to the next
available redo log file.
•Upon filling the last available redo log file, LGWR returns to the first redo log file and
resumes writing, thus initiating a new cycle.
•Figure 11-1 illustrates the circular writing process of the redo log file, with numbers
indicating the sequence in which LGWR writes to each file.
•Filled redo log files are recycled for reuse depending on whether archiving is
enabled or disabled.
• If archiving is disabled (NOARCHIVELOG mode), a filled redo log file becomes
available once the changes recorded in it are written to the data files.
• If archiving is enabled (ARCHIVELOG mode), a filled redo log file is available
to LGWR after the changes recorded in it have been written to the data files
and the file has been archived.