LU 2: MANAGE DATABASE

LO2.4: MANAGE ORACLE STORAGE STRUCTURE

2.4.1. About Database Storage Structures

An Oracle database is made up of physical and logical structures. Physical structures can be seen
and operated on from the operating system, such as the physical files that store data on a disk.

Logical structures are created and recognized by Oracle Database and are not known to the
operating system. The primary logical structure in a database, a tablespace, contains physical
files. The applications developer or user may be aware of the logical structure, but is not usually
aware of this physical structure. The database administrator (DBA) must understand the
relationship between the physical and logical structures of a database.

Figure: shows the relationships between logical and physical structures.

Figure: Oracle Database Storage Structures

1|Page
Oracle Database can automate much of the management of its structure.

From a physical perspective, a multitenant container database (CDB) has basically the same
structure as a non-CDB, except that each pluggable database (PDB) has its own set of
tablespaces (including its own SYSTEM and SYSAUX tablespaces) and data files.

2.4.2. Viewing Database Storage Structure Information

1. Viewing control file information

For databases created with Oracle Database Configuration Assistant (DBCA), three copies of the
control file are automatically created and kept synchronized with each other.

If any control file fails, then your database becomes unavailable. If you have a control file copy,
however, you can shut down your database and re-create the failed control file from the copy,
then restart your database. Another option is to delete the failed control file from
the CONTROL_FILES initialization parameter and restart your database using the remaining
control files.

 Control Files Data Dictionary Views

 The following views display information about control files:

View Description

V$DATABASE Displays database information from the control file

V$CONTROLFILE Lists the names of control files

V$CONTROLFILE_RECORD_SECTION Displays information about control file record

sections

2|Page
View Description

V$PARAMETER Displays the names of control files as specified in

the CONTROL_FILES initialization parameter

 To obtain the location and name of the control files, you can use the following
commands:
Sql>select name from v$controlfile;

Sql>select name,value from v$parameter where name = ‘control_files’;

Sql>show parameter control_files

2. Viewing online redo log file information

Every Oracle database has a set of two or more online redo log files. The set of online redo log
files is collectively known as the redo log for the database. A redo log is made up of redo
entries, which are also called redo records.

The online redo log stores a copy of the changes made to data. If a failure requires a data file to
be restored from backup, then the recent data changes that are missing from the restored data file
can be obtained from the online redo log files, so work is never lost. The online redo log files are
used to recover a database after hardware, software, or media failure.

 The following views provide information on redo logs.

View Description
V$log Displays the redo log file information from the control file
V$logfile Identifies redo log groups and members and member status
V$log_history Contains log history information

3|Page
  The following query returns the control file information about the redo log for a
database.

Select * from v$log;

 To see the names of all of the member of a group, use a query similar to the following:

Select * from v$logfile;

If the status is blank for a member, then the file is in use.

3. Viewing archived redo log file information

An archived redo log file is a copy of one of the filled members of a redo log group. It includes
the redo entries and the unique log sequence number of the identical member of the redo log
group.

When the database is running in ARCHIVELOG mode, the log writer process (LGWR) cannot
reuse and hence overwrite a redo log group until it has been archived. The background process
ARCn automates archiving operations when automatic archiving is enabled. The database starts
multiple archiver processes as needed to ensure that the archiving of filled redo logs does not fall
behind.

 To see the current archiving mode, query the V$DATABASE view:

SELECT LOG_MODE FROM SYS.V$DATABASE;

 The ARCHIVE LOG LIST Command

The SQL*Plus command ARCHIVE LOG LIST displays archiving information for the
connected instance. For example:

SQL> ARCHIVE LOG LIST

4|Page
Database log mode Archive Mode
Automatic archival Enabled
Archive destination D:\oracle\oradata\IDDB2\archive
Oldest online log sequence 11160
Next log sequence to archive 11163
Current log sequence 11163

This display tells you all the necessary information regarding the archived redo log settings
for the current instance:

 The database is currently operating in ARCHIVELOG mode.

 Automatic archiving is enabled.
 The archived redo log destination is D:\oracle\oradata\IDDB2\archive.
 The oldest filled redo log group has a sequence number of 11160.
 The next filled redo log group to archive has a sequence number of 11163.
 The current redo log file has a sequence number of 11163.

 Changing the Database Archiving Mode

To change the archiving mode of the database, use the ALTER DATABASE statement with
the ARCHIVELOG or NOARCHIVELOG clause. To change the archiving mode, you must be
connected to the database with administrator privileges (AS SYSDBA).

The following steps switch the database archiving mode

from NOARCHIVELOG to ARCHIVELOG:

1. Shut down the database instance.

SHUTDOWN

An open database must first be closed and any associated instances shut down before you can
switch the database archiving mode.

5|Page
 2. Start a new instance and mount, but do not open, the database.

STARTUP MOUNT

To enable or disable archiving, the database must be mounted but not open.

3. Change the database archiving mode. Then open the database for normal operations.

ALTER DATABASE ARCHIVELOG;

ALTER DATABASE OPEN;

4. Viewing data file information

Data files are the operating system 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. Temp files are a special class of data files that are associated only with temporary
tablespaces.

Data files can be broken down into the following components:

 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.

6|Page
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.

 Obtaining datafile Information

 DBA_DATA_FILES :Information about database data files

Sql>select *from dba_data_files;

Sql>select file_name from dba_data_files;

 The DBA_DATA_FILES and DBA_TEMP_FILES views contain information on

datafiles and temp files, respectively. This information includes:

 tablespace name
 Filename
 file size
 autoextend settings.

 DBA_TEMP_FILES: describes all temporary files (tempfiles) in the database.

Sql>select *from dba_temp_files;

Sql>select tablespace_name from dba_temp_files;

7|Page
 5. Viewing tablespace information

A database is divided into logical storage units called tablespaces, which group related logical
structures (such as tables, views, and other database objects). For example, all application objects
can be grouped into a single tablespace to simplify maintenance operations.

A tablespace consists of one or more physical data files. Database objects assigned to a
tablespace are stored in the physical data files of that tablespace.

When you create an Oracle database, some tablespaces already exist, such
as SYSTEM and SYSAUX.

Tablespaces provide a means to physically locate data on storage. When you define the data files
that comprise a tablespace, you specify a storage location for these files.

Any schema objects assigned to that tablespace then get located in the specified storage location.
Tablespaces also provide a unit of backup and recovery. The backup and recovery features of
Oracle Database enable you to back up or recover at the tablespace level.

Table 5-1 describes some tablespaces included in the database.

Tablespace Description

EXAMPLE This tablespace contains the sample schemas that are included with Oracle
Database.

SYSTEM This tablespace is automatically created at database creation. Oracle Database uses
it to manage the database. It contains the data dictionary, which is the central set of
tables and views used as a read-only reference for a particular database. It also
contains various tables and views that contain administrative information about the
database. These are all contained in the SYS schema, and can be accessed only by
the SYS user or other administrative users with the required privilege.

SYSAUX This is an auxiliary tablespace to the SYSTEM tablespace.

8|Page
Tablespace Description

Some components and products that used the SYSTEM tablespace or their own
tablespaces in releases prior to Oracle Database 10g now use
the SYSAUXtablespace. Using SYSAUX reduces the load on the SYSTEM tablespace
and reduces maintenance because there are fewer tablespaces to monitor and
maintain. Every Oracle Database 10g or later database release must have
a SYSAUX tablespace.

Components that use SYSAUX as their default tablespace during installation include
Automatic Workload Repository, Oracle Streams, Oracle Text, and Database
Control Repository

TEMP This tablespace stores temporary data generated when processing SQL statements.
For example, this tablespace would be used for query sorting. Every database
should have a temporary tablespace that is assigned to users as their temporary
tablespace. In the preconfigured database, the TEMP tablespace is specified as the
default temporary tablespace. If no temporary tablespace is specified when a user
account is created, then Oracle Database assigns this tablespace to the user.

UNDOTBS1 This is the undo tablespace used by the database to store undo information.

USERS This tablespace is used to store permanent user objects and data. Similar to
the TEMP tablespace, every database should have a tablespace for permanent user
data that is assigned to users. Otherwise, user objects will be created in
the SYSTEM tablespace, which is not good practice. In the preconfigured
database, USERS is designated as the default tablespace for all new users.

 Identify existing tablespaces and datafiles

Use the following query to identify current tablespaces and usage:

SELECT NAME FROM V$TABLESPACE;

9|Page
Use the following query to identify current datafiles:
SELECT NAME FROM V$DATAFILE;

 Obtaining Tablespace Information

 You can get information on tablespaces using following views:

 DBA_TABLESPACES: describes all tablespaces in the database.

SQL>SELECT TABLESPACE_NAME FROM DBA_TABLESPACES;

 The DBA_TABLESPACES view has one row for each tablespace in the database and
includes the following information:

 The tablespace block size

 The tablespace status: online, offline, or read-only
 The contents of the tablespace: undo, temporary, or permanent
 Whether it uses dictionary or locally managed extents
 Whether the segment space management is automatic or manual
 Whether it is a bigfile or smallfile tablespace

2.4.3. Managing Database Storage Structures Using SQL querie

 Managing tabespaces

You create a new tablespaces using the CREATE TABLESPACE statement. You must have
the CREATE TABLESPACE system privilege to create a tablespace.

The steps for creating tablespaces vary by operating system, but the first step is always to use
your operating system to create a directory structure in which your datafiles will be allocated.

You must make several choices when creating a tablespace: whether to make the tablespace
bigfile or smallfile, whether to manage extents locally or with the dictionary, and whether to
manage segment space automatically or manually.

10 | P a g e
  During tablespace creation, you set the following parameters:

 Locally Managed Tablespaces Compared to Dictionary-Managed Tablespaces

 Tablespace Type
 Tablespace Status
 Autoextend Tablespace

 Locally Managed Tablespaces Compared to Dictionary-Managed Tablespaces

Space management within a tablespace involves keeping track of available (free) and used space,
so that space is allocated efficiently during data insertion and deletion.

Oracle recommends creating locally managed tablespaces rather than dictionary-managed

tablespaces.

Locally managed tablespaces keep the space allocation information within the tablespace, not in
the data dictionary, thus offering better performance. By default, Oracle Database sets all newly
created tablespaces to be locally managed with automatic segment management, a feature that
further improves performance.

 Bigfile tablespaces are built on a single datafile (or temp file), which can be as many as
232 data blocks in size. So, a bigfile tablespace that uses 8KB data blocks can be as much
as 32TB in size.

Bigfile tablespaces are intended for very large databases. When a very large database has
thousands of read/write datafiles, operations that must update the datafile headers, such as
checkpoints, can take a relatively long time. If you reduce the number of datafiles, these
operations can complete faster.

11 | P a g e
  To create a bigfile tablespace, use the keyword BIGFILE in the CREATE statement,
like this:

 Small tablespace: With a smallfile tablespace, you can have multiple datafiles for a
tablespace. Each datafile can be as many as 222 data blocks in size. So datafiles in a
smallfile tablespace that uses 8KB data blocks are limited to 32GB.

The smallfile tablespace can have as many as 1,022 datafiles, limiting the 8KB data block
tablespace to slightly less than 32TB—about the same as a bigfile tablespace.

 Tablespace Status

You can set tablespace status as follows:

 Read Write: Users can read and write to the tablespace after it is created. This is the
default.
 Read Only: If the tablespace is created Read Only, then the tablespace cannot be written
to until its status is changed to Read Write.
 Offline: If the tablespace is created Offline, then no users can access it.

 Choosing Extent Management

You can use tablespaces with either local extent management or the older technique of
dictionary extent management. Local extent management is the default if not specified and is
generally the preferred technique.

12 | P a g e
With locally managed tablespaces, you have two options for how extents are allocated:
UNIFORM or AUTOALLOCATE.

 UNIFORM

The UNIFORM option tells the database to allocate and deallocate extents in the tablespace with
the same unvarying size that you can specify or let extents default to 1MB.

Oracle suggests the following extent size guidelines, if you wish to set the extent sizes yourself:

 64KB for small segments

 1MB or medium segments
 64MB for large segments

UNIFORM is the default for temporary tablespaces and cannot be specified for undo
tablespaces.

To create consistent 100MB extents, use the clause EXTENT MANAGEMENT LOCAL
UNIFORM SIZE 100M in the CREATE TABLESPACE statement.

 Here is an example:

 AUTOALLOCATE

AUTOALLOCATE - means that the extent sizes are managed by Oracle. Oracle will choose the
optimal next size for the extents starting with 64KB. Under the AUTOALLOCATE option,
Oracle will manage the extent size automatically.

The extent size starts at 64KB and is progressively increased to 64MB by the database. This
algorithm allows small segments to remain small and large segments to grow without gaining too
many extents. AUTOALLOCATE is best used for a general-purpose mixture of small and
large tables.
13 | P a g e
  Here is an example:

 Choosing Segment Space Management

Segment is a collection of extents that contain all the data for a specific logical storage structure
within a tablespace. Segment Space Management is allow to specify how free and used space
within a segment is to be managed.

 Choosing Segment Space Management

For tablespaces that have local extent management, you can use either manual or automatic
segment space management.

 Manually: Specifying this keyword tells Oracle that you want to use free lists for
managing free space within segments. Free lists are lists of data blocks that have space
available for inserting rows. MANUAL is the default.
 Auto: This keyword tells Oracle that you want to use bitmaps to manage the free space
within segments. A bitmap, in this case, is a map that describes the status of each data
block within a segment with respect to the amount of space in the block available for
inserting rows.

As more or less space becomes available in a data block, its new state is reflected in the
bitmap. Bitmaps allow Oracle to manage free space more automatically, and thus, this
form of space management is called automatic segment-space management.

14 | P a g e
  Here is an example:

 Modifying a Tablespace

Use an ALTER TABLESPACE statement to modify the attributes of a tablespace. Some of the
actions that you can perform on tablespaces include renaming the tablespace, adding a datafile to
a smallfile tablespace, taking a tablespace offline or online, making a tablespace read-only or
read/write.

 Renaming a tablespace

 To rename a tablespace, use an ALTER TABLESPACE statement with a RENAME

clause, like this:

 Adding a Datafile to a Tablespace

Smallfile tablespaces can have multiple datafiles. To add a datafile to a smallfile tablespace, use
an ADD clause with the ALTER TABLESPACE statement.

15 | P a g e
  For example, the following statement adds a 2GB datafile on the /u02 file system to the
receivables tablespace:

 Taking a Tablespace Offline or Online

You need to take a tablespace offline to perform some maintenance operations, such as
recovering the tablespace or moving the datafiles to a new location.

Use the OFFLINE clause with an ALTER TABLESPACE statement to take a tablespace
offline. For example, to take the receivables tablespace offline to move a datafile from the H
drive to the G drive, follow these steps.

1. Take the receivables tablespace offline:

2. Use an operating system program to physically move the file, such as Copy in Microsoft
Windows or cp in Unix.

3. Tell the database about the new location:

4. Bring the tablespace back online:

 Making a Tablespace Read-Only

When a tablespace is read-only, it does not have to be backed up with the nightly or weekly
database backups. Tables in a read-only tablespace can only be selected from; their rows cannot

16 | P a g e
be inserted, updated, or deleted. Use a READ ONLY clause with an ALTER TABLESPACE
statement to mark a tablespace read-only.

 For example, to mark the SALES2003 tablespace read-only, execute the following:

 If you need to make changes to a table in a read-only tablespace, make it read

writable again with the key words READ WRITE, like this:

 Dropping Tablespaces

You must have the DROP TABLESPACE system privilege to drop a tablespace.

 Caution: Once a tablespace has been dropped, the data in the tablespace is not
recoverable. Therefore, make sure that all data contained in a tablespace to be dropped
will not be required in the future. You cannot drop a tablespace that contains any active
segments.

The tablespace can be online or offline, but it is best to take the tablespace offline before
dropping it. To drop a tablespace, use the DROP TABLESPACE statement.

 The following statement drops the users tablespace, including the segments in the
tablespace:

DROP TABLESPACE users INCLUDING CONTENTS;

If the tablespace is empty (does not contain any tables, views, or other structures), you do not
need to specify the INCLUDING CONTENTS clause. Use the CASCADE CONSTRAINTS
clause to drop all referential integrity constraints from tables outside the tablespace that refer to
primary and unique keys of tables inside the tablespace.

The followingDropping a tablespace does not automatically remove the datafiles from the
file system.

17 | P a g e
To delete the datafiles associated with a tablespace at the same time that the tablespace is
dropped, use the INCLUDING CONTENTS AND DATAFILES clause.

 Statement drops the users tablespace and its associated datafiles:

DROP TABLESPACE users INCLUDING CONTENTS AND DATAFILES;

 Managing Datafiles

A datafile belongs to only one tablespace and only one database at a time.

 Operations that you may need to perform on datafiles include the following:

 Resizing them
 Taking them offline or online
 Moving (renaming) them
 Recovering them

A useful technique for managing disk space used by datafiles is to enable AUTOEXTEND,
which tells the database to automatically enlarge a datafile when the tablespace runs out of free
space.

 The AUTOEXTEND attributes apply to individual datafiles and not to the tablespace.

 To resize a datafile manually, use the ALTER DATABASE DATAFILE statement,

like this:

18 | P a g e
  To configure a datafile to automatically enlarge as needed by adding 100MB at a
time up to a maximum of 8,000MB, execute the following:

The value of NEXT is the minimum size of the increments added to the file when it extends.
The value of MAXSIZE is the maximum size to which the file can automatically extend.

To relocate a datafile, take it offline, move it using an operating system command, rename it,
recover it and then bring it back online.

 Here is an example:

19 | P a g e
 3. In the Switch to Undo Tablespace field, select the name of the undo tablespace you
want to switch to. This field includes the names of available undo tablespaces for the
database.

 For example, if the current undo tablespace is named UD1 and you want to switch to the
undo tablespace named UD2, select UD2 in the Switch to Undo Tablespace field.

4. Click OK. A confirmation message appears..

5. Click OK. A confirmation message appears.

 Managing the Online Redo Log

 Online redo log groups and their members
You can create groups and members of online redo log files during or after database creation. To
create new online redo log groups and members, you must have the ALTER DATABASE
system privilege.

 Multiplexing the redo log

Multiplexing provides better protection for data in the case of instance or media failure. To
protect against a failure involving the redo log itself, Oracle Database allows a multiplexed redo
log, meaning that two or more identical copies of the redo log can be automatically maintained in
separate locations.

To multiplex your redo log, you must add members to each redo log group. It is not required that
redo log groups be symmetrical, but Oracle recommends that your groups all have the same
number of members. A database must have a minimum of two redo log groups.

 Multiplexed redo log files

The online redo log of a database instance should consist of multiplexed groups of online redo log
files as shown below:

20 | P a g e
In the above figure, a_log1 and b_log1 are both members of group 1, a_log2, and b_log2 are both
members of group 2, and so forth. Each member of a group must be exactly the same size.

Each member of a log file group is concurrently active—that is, concurrently written to by lgwr—
as indicated by the identical log sequence numbers assigned by lgwr. In the figure, the first lgwr
writes concurrently to both a_log1 and b_log1. Then it writes concurrently to both a_log2 and
b_log2, and so on. Lgwr never writes concurrently to members of different groups (for example,
to a_log1 and b_log2).

Sql>select group#, member from v$logfile order by group#, member;

You can create ‘/u02/app/oracle/oradata/redo01a.log’ file in the same directory, but it is

recommended that you store members on separate disk drives. That way, if there is a drive
failure, you still have access to one member.

 Switching a log file

A log switch occurs when LGWR stops writing to one redo log group and starts writing to another.
By default, a log switch occurs automatically when the current redo log file group fills.

21 | P a g e
  The below query is helpful to know the status of the groups:

Sql> select * from v$log;

When a log switch occurs, the log writer (lgwr) process stops writing to the current redo log
group and starts writing to the next available redo log group. You can force a log switch to make
the current redo group inactive and available for redo log maintenance operations.

For example, you might want to drop the current redo group but are not able to do so until the
group is inactive. You may also want to force a log switch if the current redo group needs to be
archived at a specific time before the members of the group are completely filled. This option is
useful in configurations with large redo log files that take a long time to fill.

Sql> alter system switch logfile;

The status of the current group changes to active and the status of the next group in the list
changes from inactive to current.

 Moving online redo log files:

Online redo log files may be moved while the database is shutdown. Once renamed (or moved),
the DBA should use the ALTER DATABASE command to update the data dictionary.

Although it is possible to indirectly move online redo log files by dropping entire redo log groups
and re-adding the groups in a different location, this solution will not work if there are only two
redo log groups because a database will not open with only one redo log filegroup. Temporarily
adding a third group and dropping the first or second group is an option if the database must be
kept open; alternatively, the method shown here will move the redo log file(s) while the database
is shutdown.

In the following example, we have three redo log file groups with two members each. One member
of each group is on the same volume as the oracle software and should be moved to a different
volume to eliminate any connection between log file filling and accessing oracle software
components. The method you will use here with alter database command.

22 | P a g e
Example:

Sql> select group#, member from v$logfile order by group#, member;

Sql> shutdown immediate;

Sql>! Mv /u01/app/oracle/oradata/redo0[1-3]/log /u04/oradata

Sql>startup mount

Sql>alter database rename file ‘/u01/app/oracle/oradata/redo01.log’ to

‘/u04/oradata/redo01.log’;

Sql> alter database rename file ‘/u01/app/oracle/oradata/redo02.log’ to

‘/u04/oradata/redo02.log’;

Sql> alter database rename file ‘/u01/app/oracle/oradata/redo03.log’ to

‘/u04/oradata/redo03.log’;

Sql> alter database open;

 Now, we can check out the location of the log files from the following query.

Sql> select group#, member from v$logfile order by group#, member;

 Adding the redo log groups:

Sql>alter database add logfile group 4 ‘/u01/app/oracle/oradata/redo03.log’ size 10m;

 Dropping the existing redo log groups:

Sql>alter database drop logfile group 4;

Sql>alter database drop logfile member ‘/u01/app/oracle/oradata/redo03.log’;

Note: To drop an online redo log group, consider the following points:

 An instance requires at least two groups of online redo log files, regardless of the number
of members in the groups.

23 | P a g e
  You can drop an online redo log group only if it is not the active group. If you need to
drop the active group, first force a log switch to occur.

Sql>alter system switch logfile;

To drop a member consider the following points:

 An instance requires at least two groups of online redo log files, regardless of the number
of members in the groups.
 You can drop an online redo log group only if it is not the active group. If you need to
drop the active group, first force a log switch to occur.

 Clearing a redo log file:

Normally we need to clear the redo log if it's corrupted and oracle is not able to reuse it. It may
already be archived or may not be. In both cases, we need to clear it to allow oracle instance to re-
use it.

A redo log file might become corrupted while the database is open, and ultimately stop database
activity because archiving cannot continue. In this situation, the alter database
clear logfile statement can be used to reinitialize the file without shutting down the database.

The following statement clears the log files in redo log group number 3:

Sql>alter database clear logfile group 3;

This statement overcomes two situations where a dropping redo log is not possible:

 If there are only two log groups.

 The corrupt redo logfile belongs to the current group.

If the corrupt redo log file has not been archived, use the unarchived keyword in the statement.

Sql>alter database clear unarchived logfile group 3;

24 | P a g e
This statement clears the corrupted redo logs and avoids archiving them. The cleared redo logs are
available for use even though they were not archived.

 Creating Redo Log Groups and Members

To create new redo log groups and members, you must have the ALTER DATABASE system
privilege. A database can have up to MAXLOGFILES groups.

 Creating Redo Log Groups

To create a new group of redo log files, use the SQL statement ALTER DATABASE with
the ADD LOGFILE clause.

 The following statement adds a new group of redo logs to the database:

ALTER DATABASE ADD LOGFILE '/app/oracleHomeUser7/oradata/orcl/redo004’ SIZE

500M;

 You can also specify the number that identifies the group using the GROUP clause:

ALTER DATABASE ADD LOGFILE GROUP 6'/app/oracleHomeUser7/oradata/orcl/redo006'

size 500M;

 Creating Redo Log Members

In some cases, it might not be necessary to create a complete group of redo log files. A group
could already exist, but not be complete because one or more members of the group were
dropped (for example, because of a disk failure). In this case, you can add new members to an
existing group.

To create new redo log members for an existing group, use the SQL statement ALTER
DATABASE with the ADD LOGFILE MEMBER clause.

25 | P a g e
  The following statement adds a new redo log member to redo log group number 2:

ALTER DATABASE ADD LOGFILE MEMBER '/app/oracleHomeUser7/oradata/orcl/redo005'

TO GROUP 4;

Notice that filenames must be specified, but sizes need not be. The size of the new members is
determined from the size of the existing members of the group.

 Relocating and Renaming Redo Log Members

You can use operating system commands to relocate redo logs, then use the ALTER
DATABASE statement to make their new names (locations) known to the database. This
procedure is necessary, for example, if the disk currently used for some redo log files is going to
be removed, or if datafiles and a number of redo log files are stored on the same disk and should
be separated to reduce contention.

To rename redo log members, you must have the ALTER DATABASE system privilege.
Additionally, you might also need operating system privileges to copy files to the desired
location and privileges to open and back up the database.

Before relocating your redo logs, or making any other structural changes to the database,
completely back up the database in case you experience problems while performing the
operation. As a precaution, after renaming or relocating a set of redo log files, immediately back
up the database control file.

 Use the following steps for relocating redo logs. The example used to illustrate these
steps assumes:

 The log files are located on disk F

 The redo log consists of the
members ‘F:/app/oracleHomeUser7/oradata/orcl/redo004’ SIZE 500M;
and ‘F:/app/oracleHomeUser7/oradata/orcl/redo004’ SIZE 500M;
 The redo log file located on F must be relocated to E.

26 | P a g e
  The new filename will reflect the new location: 'E:/Oracle’ and ‘E:/Oracle’

 Steps for Renaming Redo Log Members

1. Shut down the database.

SQL>SHUTDOWN

2. Copy the redo log files to the new location.

Operating system files, such as redo log members, must be copied using the appropriate
operating system commands. See your operating system specific documentation for more
information about copying files.

 The following example uses operating system commands to move the redo log
members to a new location:

 Run CMD

move F:\APP\ORACLEHOMEUSER7\ORADATA\ORCL\REDO004 E:\Oracle\REDO004

move F:\APP\ORACLEHOMEUSER7\ORADATA\ORCL\REDO005 E:\Oracle\REDO005

3. Startup the database, mount, but do not open it.

CONNECT / as SYSDBA

SQl> STARTUP MOUNT

4. Rename the redo log members.

Use the ALTER DATABASE statement with the RENAME FILE clause to rename
the database redo log files.

27 | P a g e
 ALTER DATABASE

RENAME FILE '/ F:\APP\ORACLEHOMEUSER7\ORADATA\ORCL\REDO004 TO

'E:\Oracle\REDO004' ;

ALTER DATABASE

RENAME FILE '/ F:\APP\ORACLEHOMEUSER7\ORADATA\ORCL\REDO005’ TO

'E:\Oracle\REDO005' ;

5. Open the database for normal operation.

The redo log alterations take effect when the database is opened.

ALTER DATABASE OPEN;

 Dropping Redo Log Groups and Members

In some cases, you may want to drop an entire group of redo log members. For example, you
want to reduce the number of groups in an instance redo log. In a different case, you may want to
drop one or more specific redo log members. For example, if a disk failure occurs, you may need
to drop all the redo log files on the failed disk so that the database does not try to write to the
inaccessible files. In other situations, particular redo log files become unnecessary. For example,
a file might be stored in an inappropriate location.

 Dropping Log Groups

To drop a redo log group, you must have the ALTER DATABASE system privilege.

 Before dropping a redo log group, consider the following restrictions and
precautions:

28 | P a g e
  An instance requires at least two groups of redo log files, regardless of the number of
members in the groups. (A group comprises one or more members.)
 You can drop a redo log group only if it is inactive. If you need to drop the current
group, first force a log switch to occur.
 Make sure a redo log group is archived (if archiving is enabled) before dropping it.
To see whether this has happened, use the V$LOG view.

SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG;

Drop a redo log group with the SQL statement ALTER DATABASE with the DROP
LOGFILE clause.

 The following statement drops redo log group number 3:

ALTER DATABASE DROP LOGFILE GROUP 5;

When a redo log group is dropped from the database, and you are not using the Oracle-managed
files feature, the operating system files are not deleted from disk. Rather, the control files of the
associated database are updated to drop the members of the group from the database structure.
After dropping a redo log group, make sure that the drop completed successfully, and then use
the appropriate operating system command to delete the dropped redo log files.

When using Oracle-managed files, the cleanup of operating systems files is done automatically
for you.

29 | P a g e
  Dropping Redo Log Members

To drop a redo log member, you must have the ALTER DATABASE system privilege.

 Consider the following restrictions and precautions before dropping individual redo
log members:

 You can drop a redo log member only if it is not part of an active or current group. If
you want to drop a member of an active group, first force a log switch to occur.
 Make sure the group to which a redo log member belongs is archived (if archiving is
enabled) before dropping the member. To see whether this has happened, use
the V$LOG view.

To drop specific inactive redo log members, use the ALTER DATABASE statement with
the DROP LOGFILE MEMBER clause.

The following statement drops the redolog

F:\APP\ORACLEHOMEUSER7\ORADATA\ORCL\REDO004

ALTER DATABASE DROP LOGFILE MEMBER

'/ F:\APP\ORACLEHOMEUSER7\ORADATA\ORCL\REDO004';

When a redo log member is dropped from the database, the operating system file is not deleted
from disk. Rather, the control files of the associated database are updated to drop the member
from the database structure. After dropping a redo log file, make sure that the drop completed
successfully, and then use the appropriate operating system command to delete the dropped redo
log file.

30 | P a g e
  Managing control file

 Creating Additional Copies, Renaming, and Relocating Control Files

You can create an additional control file copy for multiplexing by copying an existing control
file to a new location and adding the file name to the list of control files.

Similarly, you rename an existing control file by copying the file to its new name or location,
and changing the file name in the control file list.

In both cases, to guarantee that control files do not change during the procedure, shut down the
database before copying the control file.

 To add a multiplexed copy of the current control file or to rename a control file:

1. Shut down the database.

Sql>shutdown normal

2. Copy an existing control file to a new location, using operating system commands.

cp /u01/oradata/orcl/control01.ctl /u02/oradata/orcl/control02.ctl

3. Starting up database

Sql>startup

4. Edit the CONTROL_FILES parameter in the database initialization parameter file to add
the new control file name, or to change the existing control filename.

Alter Control_files = ‘/u01/oradata/orcl/control01.ctl’,

‘/u02/oradata/orcl/control02.ctl’;

5. Shutdown database
Sql>shutdown normal

31 | P a g e
 6. Restart the database.

Sql>startup;

 Backing Up Control Files

Use the ALTER DATABASE BACKUP CONTROLFILE statement to back up your control files. You
have two options:

1. Back up the control file to a binary file (duplicate of existing control file) using the
following statement:

ALTER DATABASE BACKUP CONTROLFILE TO 'D:/oracle/backup/control.bkp';

2. Produce SQL statements that can later be used to re-create your control file:

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

 Recovering from Control File Corruption Using a Control File Copy

This procedure assumes that one of the control files specified in

the CONTROL_FILES parameter is corrupted, that the control file directory is still accessible,
and that you have a multiplexed copy of the control file.

1. With the instance shut down, use an operating system command to overwrite the bad
control file with a good copy:

copy /u03/oracle/prod/control03.ctl /u02/oracle/prod/control02.ctl

2. Start SQL*Plus and open the database:

SQL> STARTUP

32 | P a g e