ALTER TABLESPACE tablespacename
[MINIMUM EXTENT integer [K|M]
[DEFAULT storage clause]

Resizing a Tablespace

ALTER TABLESPACE mydb1data
ADD DATAFILE ‘\mydatabases\mydb1\mydb1data02.dbf’
SIZE 100M;

ALTER DATABASE
DATAFILE ‘\mydatabases\mydb1\mydb1data01.dbf’
RESIZE 500M;

To allow the data file to extend itself automatically;

ALTER DATABASE
DATAFILE ‘\mydatabases\mydb1\mydb1data01.dbf’
SIZE 250M
AUTOEXTEND ON NEXT 25M MAXSIZE 500M;

Moving Data Files with ALTER TABLESPACE

ALTER TABLESPACE mydb1data
RENAME DATAFILE ‘/mydatabases/mydb1/mydb1data01.dbf’
TO ‘/mydatabases3/mydb1/mydb1data01.dbf’;

Moving Data Files with ALTER DATABASE

ALTER DATABASE mydb1
RENAME FILE ‘/mydatabases/mydb1/system01.dbf’,'/mydatabases/mydb1/system02.dbf’
TO ‘/mydatabases3/mydb1/system01.dbf’,'/mydatabases3/mydb1/system02.dbf’;

1. Free Extent Information is NOT stored in Data Dictionary
2. Bitmap Segments are used to keep track of the free space usage
3. Within the tablespace, there are bitmap segments
4. Each bit in the Bitmap corresponds to a Data Block or a group of Data Blocks and the value in the bit indicates that the blocks are free or used
5. Whenever a block is used or freed for reuse, Oracle changes the value of the bitmap to show the new status of the block
6. Contention is significantly reduced on the data dictionary tables
7. Coalescing of free space is NOT required

Dictionary Managed Tablespaces

1. This is the default method for the creation of tablespace
2. Free Extent Information is stored in Data Dictionary
3. Contention is significantly INCREASED on the data dictionary tables
4. Oracle updates the appropriate tables in the data dictionary whenever an extent is allocated or deallocated in relation to the tablespace
5. Coalescing is required in frequently updated segments in Dictionary Managed Tablespaces

To indicate the Space Management during the creation of a Tablespace, EXTENT MANAGEMENT clause needs to be specified as follows:

EXTENT_MANAGEMENT [DICTIONARY | LOCAL [AUTOALLOCATE | UNIFORM [SIZE integer [K|M]]]

DROP TABLESPACE tablespacename
INCLUDING CONTENTS
[AND DATAFILES | INCLUDING DATAFILES]
CASCADE CONSTRAINTS;

• INCLUDING CONTENTS - Causes all the segments in the tablespace to be dropped
• AND DATAFILES (or INCLUDING DATAFILES) - Causes all the data files associated with the tablespace to be dropped from the operating system
• CASCADE CONSTRAINTS - Causes all the referential integrity constraints from other tablespaces’ tables that refer to primary and unique keys on the tables in the dropped tablespace to be themselves dropped

A tablespace that still contains data cannot be dropped without specifying the INCLUDING CONTENTS option.

If AND DATAFILES parameter is not specified, only the pointers in the control files that reference the data files associated with the tablespace are dropped along with the associated data dictionary information. This means that the data files still exist and must be deleted explicitly with the appropriate operating system commands.

It is recommended to take offline any tablespace that is intended to drop, even read-only tablespaces, so that no transactions are accessing the segments in the tablespace when the drop command is issued.

CREATE TABLESPACE tablespace_name
[DATAFILE clause]
[MINIMUM EXTENT integer [K]]
[BLOCKSIZE integer [K]]
[LOGGING | NOLOGGING]
[DEFAULT storage_clause]
[ONLINE | OFFLINE]
[PERMANENT | TEMPORARY]

• tablespace_name – Name of the tablespace to be created
• DATAFILE – to assign the location of data file associated with the tablespace. AUTOEXTEND is an optional clause to signify the auto extension of data files. REUSE is another optional clause to use an existing data file for the tablespace to be created
• MINIMUM EXTENT - ensures that every extent used in the tablespace is at least this size and is always a multiple of this size
• BLOCKSIZE – ensures that each block in the extents allocated is of this size
• LOGGING – All changes in this tablespace should be written to the online redo log files
• NOLOGING – Changes in this tablespace should not be written to the online redo log files
• ONLINE - creates the tablespace online and available for users to start using immediately
• OFFLINE - makes the tablespace unavailable immediately, and users are not able to use it for storage until the DBA has brought it online
• PERMANENT - specifies that the tablespace can be used to hold permanent objects
• TEMPORARY – signifies that the tablespace can be used only to hold temporary data and temporary objects

Undo Tablespace

• Undo Tablespace stores only Undo Segments
• Only Oracle has direct control over Undo Tablespace
• Undo Tablespace contains only one Data File

The CREATE TABLESPACE statement for undo tablespaces follows:

CREATE UNDO TABLESPACE mydb1_undo1
DATAFILE ‘/mydatabases/mydb1/mydb1_undo1.dbf’
SIZE 100M;

Temporary Tablespaces

• Oracle uses temporary tablespaces for sort operations
• Temporary tablespaces cannot contain any other type of data
• Temporary tablespaces cannot contain any permanent objects
• The sort segment (Temporary Segment) in the temporary tablespace is created at the time of the first large sort operation in the instance
• This segment (Temporary Segment) expands by allocating extents until the segment is equal to or greater than the total storage demands of all the active sorts running in the given instance
• Temporary tablespaces are always created with NOLOGGING mode enabled
• Temporary tablespaces can never be set to read-only
• Temporary tablespaces’ data files (known as tempfiles) can never be renamed
• To optimize the performance of sorts, the temporary tablespaces’ UNIFORM EXTENT SIZE should be used and should be a multiple of SORT_AREA_SIZE

The following is an example of the CREATE TABLESPACE statement for temporary tablespaces:

CREATE TEMPORARY TABLESPACE mydb1_temp
TEMPFILE ‘/mydatabases/mydb1/mydb1_temp01.dbf’
SIZE 1000M
EXTENT MANAGEMENT LOCAL
UNIFORM SIZE 10M;

Default Temporary Tablespaces

• To avoid using SYSTEM tablespace for sorting operations, a Default Temporary Tablespace in the database is needed
• All users created without the TEMPORARY TABLESPACE clause will have the defined Default as their Temporary Tablespace
• Default Temporary Tablespace is always Locally Managed when created during Database creation
• The DEFAULT TEMPORARY TABLESPACE can be reassigned to a database user by use of the ALTER DATABASE command
• After a default temporary tablespace has been defined, it cannot be dropped until a new temporary tablespace is defined
• It cannot be taken offline
• It cannot be made read-only
• It cannot be altered to make it a permanent tablespace

To set a tablespace as the default temporary tablespace after the database has been created, the following command creates a Deafult Temporary Tablespace:

ALTER DATABASE
DEFAULT TEMPORARY TABLESPACE mydb_temp1;

V$LOGFILES – This view provides the current status of all the redo logs

V$LOG_HISTORY – Contains information concerning archived redo logs from the control file. From here you can find the System Change Number (SCN) view of the archived log files

V$LOGHIST – This view contains information about the redo log file history from the control file

NOARCHIVELOG Mode

• The Online Redo Log Files are overwritten automatically as they are cycled
• NOARCHIVELOG Mode is mainly suitable for Data Warehousing Environment where there is little change other than Bulk Loads
• NOARCHIVELOG Mode is also suitable for systems where Database downtime is permissible
• The database cannot be receovered upto the Last Committed Transaction while in NOARCHIVELOG Mode
• Database Recovery is only possible using the last Backup taken

ARCHIVELOG Mode

• Online Redo Log Files are always Archived before being overwritten by the LGWR, this ensures no loss of even a single committed transaction at any point of time
• A Full Database Backup can be performed while the database is operational
• Database Recovery is possible to the point of Last Committed Transaction
• ARCHIVELOG Mode is basically for two reasons – Backup & Recovery

LOG_ARCHIVE_START

• The LOG_ARCHIVE_START initialization parameter controls whether archiving should be automatic when the instance starts up
• LOG_ARCHIVE_START can take one of the two values at at a time - TRUE or FALSE
• LOG_ARCHIVE_START = TRUE implies archiving of the online Redo Log Files will automatically start at the instance startup
• LOG_ARCHIVE_START = FALSE implies archiving of the online Redo Log Files will NOT automatically start at the instance startup

To manually archive the redo log files, you would simply enter the following command:

ALTER SYSTEM ARCHIVE LOG ALL;

Information in the Data Dictionary

Information on the archive logs can be obtained by querying V$INSTANCE as shown in the following example:

SELECT archiver FROM V$INSTANCE;

It is very much important for the following reasons:-

1. Splitting members of a particular Redo Log Group into different groups, helps to avoid loss of database information after a database crash
2. Separating archive log files from the location of the online redo log files and placing these on different disks or disk groups reduces contention between the ARCn process and the LGWR process
3. Redo log files should also be placed on different disks or disk groups than data files to reduce the possibility of contention between LGWR and DBWn, as well as to reduce the chances of losing both redo log files and data files in case of a loss of a disk or disk group.

Sizing the Redo Log Files

• The minimum size for online redo log files is 50 KB
• The maximum size is operating system dependent
• Each member of a Group can have different sizes although there is no real benefit to having different sized groups
• The size of the Redo Log Files is mainly governed by the frequency of Log Switches & Checkpoints
• If there is frequent Log Switches,  larger Redo Log Files may be needed
• If Log Switches and Checkpoints are only during Database Shutdown,  smaller Redo Log Files may be needed
• If it is observed that the ARCHIVER (ARCn) and CHECKPOINT (CKPT) waits to perform its activities until  the log file is available, then one or two Redo Log Groups may be added

Dropping Redo Log Groups

• An instance requires at least two active groups of Online Redo Log Files
• An active or current Group cannot be dropped
• When the Online Redo Log Group is dropped, the associated operating system files are also deleted

ALTER DATABASE [database name] DROP LOGFILE {GROUP integer| (‘filename’, ‘filename’…)}

Dropping Redo Log Members

• The Redo Log Member cannot be the last valid member of the group
• To drop a Redo Log Member of the active group, manual Log Switch is needed
• In ARCHIVELOG mode, if the Log File Group to which the member is associated has not yet been archived, the member cannot be dropped
• Operating System files are not deleted automatically when Online Redo Log File member is dropped

ALTER DATABASE DROP LOGFILE MEMBER <logfile name>;

Clearing Online Redo Logs

• A Redo Log Group may sometimes become corrupt which may also corrupt all the members
• DBA needs to reinitialize the corrupted Online Redo Log Group again
• Clearing Online Redo Log Group is same as adding a new Online Redo Log Group and dropping the offending Online Redo Log Group
• Whether the Online Redo Log Group has been archived or not, the Online Redo Log Group can be reinitialized

Reinitialization can be accomplished through an ALTER DATBASE command as in the following example:

ALTER DATABASE CLEAR LOGFILE GROUP 2;

If the corrupt Redo Log Group has not yet been archived, the UNARCHIVED parameter needs to be used in the above command.

ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2;

Renaming Online Redo Logs

ALTER DATABASE RENAME FILE <old_name> TO <new_name>;

Multiplexing and Maintaining Online Redo Log Files

Multiplexing and Maintaining Online Redo Log Files It is often desirable to add redo log file groups to the database to make sure that the first group is ready to be overwritten before the last group is full. This can often happen if a great deal of activity occurs on the database, and the database is in ARCHIVELOG mode. To add a group to a database that has two redo log file groups, you would issue an ALTER DATABASE command as follows: ALTER DATABASE ADD LOGFILE GROUP 3 ('/mydatabases/mydb1/log3a.dbf', '/mydatabases2/mybd1/log3b.dbf') SIZE 1M; Or in Windows ALTER DATABASE ADD LOGFILE GROUP 3 ('c:\mydatabases\mydb1\log3a.dbf', 'd:\mydatabases2\mybd1\log3b.dbf') SIZE 1M; The generic format of the command is as follows: ALTER DATABASE [database name] ADD LOGFILE [GROUP integer] filespec, filespec; All the information in the brackets is optional, and you would specify the name, location, and size with the filespec variable. The value required for use as the GROUP number can be selected and provided for each redo log file group that you want to add. If omitted, Oracle generates the value automatically. Adding a Log File Member to a Group Oracle, similar to its suggestions on control files, suggests that redo log files be multiplexed. To do this, Oracle allows you to use the ALTER DATABASE command to add the LOGFILE MEMBER. This is accomplished in Unix as follows: ALTER DATABASE ADD LOGFILE MEMBER '/mydatabases2/mybd1/log1b.dbf' TO GROUP 1 '/mydatabases2/mybd1/log2b.dbf' TO GROUP 2 '/mydatabases2/mybd1/log3b.dbf' TO GROUP 3; It is important to fully specify the filename for the new members; otherwise, Oracle places the files in the default directory of the database server. If a file by the name that you have specified already exists, it must have the same size as the existing file for the GROUP specified, and you must specify the REUSE option; otherwise, the command fails. But how do you determine how many redo log files you need for your database situation? Optimum Number of Online Redo Log Files Determining the appropriate number of online redo log groups for your given database instance can be an exercise in creativity. You simply need to test different configurations to determine what is needed for your database. In some cases, a database instance may indeed only require two groups. Other situations may mean that additional groups are needed to guarantee that the groups will always be available to LGWR to use. You will start to see messages in the LGWR trace files and in the alert file that indicate that LGWR has started to have to wait. It will wait for available groups because checkpoints have not completed, or archival of the log file has not completed. At this point, the log groups need LGWR processing that can’t occur until there are freed other groups. If this happens, it is time to add additional redo log groups to the database. Although it is possible, with the Oracle server, to have multiplexed redo log file groups with different numbers of members in each group, it is better to try to maintain a symmetric configuration. Having different numbers of files in different groups should be only maintained as a temporary result of some unintended event (such as disk failure or other accidental situation). Location, Location, Location When you multiplex the online redo log files, you need to be sure to place the members on different disks or different groups of disks. By splitting up members like this, you are less likely to have a database crash because an entire group is unavailable in case of a loss of a disk. Also, separating archive log files from the location of the online redo log files and placing these on different disks or disk groups reduces contention between the ARCn process and the LGWR process. Ideally, redo log files should also be placed on different disks or disk groups than data files to reduce the possibility of contention between LGWR and DBWn, as well as to reduce the chances of losing both redo log files and data files in case of a loss of a disk or disk group. Sizing the Redo Log Files Although the minimum size for online redo log files is 50KB, the maximum size is operating system specific. Members of different GROUPS can have different sizes, although there is no real benefit to having different sized groups. Each member of a given group has to have the same size as the other members of that group. The following situations will help to guide you in determining whether you have the right number of online redo log files: If you have many log switches and checkpoints during a given time period, you may want larger redo log members. If you have frequent log switches, you may want larger redo log members. If you only see log switches and checkpoints when the database is shut down, you may want smaller redo log members. If you see several points where the Archiver or Checkpoint has to wait to perform its activities until the log file is available, you may want to add one or more redo log groups. You are starting to see many “checkpoint not complete” messages in your alert logs. Dropping Redo Log Groups

Adding a Log File Group to the Database

To add a group to a database that has two redo log file groups, you would issue an ALTER DATABASE command as follows:

ALTER DATABASE ADD LOGFILE GROUP 3
(‘/mydatabases/mydb1/log3a.dbf’, ‘/mydatabases2/mybd1/log3b.dbf’)
SIZE 1M;

Adding a Log File Member to a Group

ALTER DATABASE ADD LOGFILE MEMBER
‘/mydatabases2/mybd1/log1b.dbf’ TO GROUP 1
‘/mydatabases2/mybd1/log2b.dbf’ TO GROUP 2
‘/mydatabases2/mybd1/log3b.dbf’ TO GROUP 3
;

Structure of Online Redo Log Files

Online Redo Log Files are arranged in groups. Each group contains atleast one member (the redo log file).
To avoid losing of database information, Oracle always suggest Multiplexing of Redo Log Files like the multiplexing of Control Files.

In case of Redo Log Files, the members of each group are kept in different disks.

In the above figure, the  duplicate copies of the Redo Log Files (Member 1) in Disk 1 has also been kept in another Disk 2 to avoid losing database information in case of instance or system failure.

The Log Writer (LGWR) keep on writing to the members of Redo Log Group 1 till it becomes full. As soon as the member of the Group 1 becomes full with data, the LGWR switches to the next group that is Group 2. This is called Log Switching.  After LGWR writes to each of the Redo Log Files of all the Redo Log Groups, it starts writing  again to the members from Group 1 overwriting the old contents of the members of the Group 1.
So the Redo Log Files works in a cyclic fashion.

Initial Redo Log Files

Initially during database creation, the Redo Log Files are created using the CREATE DATABSE command, where two parameters are specified for the creation of Redo Log Files – MAXLOGFILES and MAXLOGMEMBERS.

MAXLOGFILES - Maximum no. of Redo Log Groups
MAXLOGMEMBERS - Maximum no. of Redo Log Members in each group

The default and maximum values for the above parameters are operating system dependant.

Force Log Switch

Log switches are done automatically periodically, but as a DBA you can force a log switch to occur with the ALTER SYSTEM command as follows:

ALTER SYSTEM SWITCH LOGFILE;