Managing Tablespaces and Datafiles

Using multiple tablespaces provides several Advantages

• Separate user data from data dictionary data to reduce contention among dictionary objects and schema objects for the same datafiles.
• Separate data of one application from the data of another to prevent multiple applications from being affected if a tablespace must be taken offline.
• Store different the datafiles of different tablespaces on different disk drives to reduce I/O contention.
• Take individual tablespaces offline while others remain online, providing better overall availability.

Creating  New Tablespaces

You can create Locally Managed or Dictionary Managed Tablespaces. In prior versions of Oracle only Dictionary managed Tablespaces were available but from Oracle ver. 8i you can also create Locally managed tablespaces. The advantages of locally managed tablespaces are

Locally managed tablespaces track all extent information in the tablespace itself by using bitmaps, resulting in the following benefits:

• Concurrency and speed of space operations is improved, because space allocations and deallocations modify locally managed resources (bitmaps stored in header files) rather than requiring centrally managed resources such as enqueues
• Performance is improved, because recursive operations that are sometimes required during dictionary-managed space allocation are eliminated

To create a locally managed tablespace give the following command

SQL> CREATE TABLESPACE ica_lmts DATAFILE '/u02/oracle/ica/ica01.dbf' SIZE 50M

    EXTENT MANAGEMENT LOCAL AUTOALLOCATE;

AUTOALLOCATE causes the tablespace to be system managed with a minimum extent size of 64K.

The alternative to AUTOALLOCATE is UNIFORM. which specifies that the tablespace is managed with extents of uniform size. You can specify that size in the SIZE clause of UNIFORM. If you omit SIZE, then the default size is 1M. The following example creates a Locally managed tablespace with uniform extent size of 256K

SQL> CREATE TABLESPACE ica_lmt DATAFILE '/u02/oracle/ica/ica01.dbf' SIZE 50M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K;

To Create Dictionary Managed Tablespace

SQL> CREATE TABLESPACE ica_lmt DATAFILE '/u02/oracle/ica/ica01.dbf' SIZE 50M EXTENT MANAGEMENT DICTIONARY;

Bigfile Tablespaces (Introduced in Oracle Ver. 10g)

A bigfile tablespace is a tablespace with a single, but very large (up to 4G blocks) datafile. Traditional smallfile tablespaces, in contrast, can contain multiple datafiles, but the files cannot be as large. Bigfile tablespaces can reduce the number of datafiles needed for a database.

To create a bigfile tablespace give the following command

SQL> CREATE BIGFILE TABLESPACE ica_bigtbs

    DATAFILE '/u02/oracle/ica/bigtbs01.dbf' SIZE 50G;

To Extend the Size of a tablespace

Option 1

 You can extend the size of a tablespace by increasing the size of an existing datafile by typing the following command

SQL> alter  database ica datafile ‘/u01/oracle/data/icatbs01.dbf’ resize 100M;

This will increase the size from 50M to 100M

Option 2

You can also extend the size of a tablespace by adding a new datafile to a tablespace. This is useful if the size of existing datafile is reached o/s file size limit or the drive where the file is existing does not have free space. To add a new datafile to an existing tablespace give the following command.

SQL> alter tablespace add datafile  ‘/u02/oracle/ica/icatbs02.dbf’ size 50M;

Option 3

You can also use auto extend feature of datafile. In this, Oracle will automatically increase the size of a datafile whenever space is required. You can specify by how much size the file should increase and Maximum size to which it should extend.

To make a existing datafile auto extendable give the following command

SQL> alter database datafile ‘/u01/oracle/ica/icatbs01.dbf’ auto extend ON next 5M maxsize 500M;

You can also make a datafile auto extendable while creating a new tablespace itself by giving the following command.

SQL> create tablespace ica datafile ‘/u01/oracle/ica/icatbs01.dbf’ size 50M auto extend ON next 5M maxsize 500M;

To decrease the size of a tablespace

You can decrease the size of tablespace by decreasing the datafile associated with it. You decrease a datafile only up to size of empty space in it. To decrease the size of a datafile give the following command

SQL> alter database datafile ‘/u01/oracle/ica/icatbs01.dbf’      resize 30M;

Coalescing Tablespaces

A free extent in a dictionary-managed tablespace is made up of a collection of contiguous free blocks. When allocating new extents to a tablespace segment, the database uses the free extent closest in size to the required extent. In some cases, when segments are dropped, their extents are deallocated and marked as free, but adjacent free extents are not immediately recombined into larger free extents. The result is fragmentation that makes allocation of larger extents more difficult.

You should often use the ALTER TABLESPACE ... COALESCE statement to manually coalesce any adjacent free extents. To Coalesce a tablespace give the following command

SQL> alter tablespace ica coalesce;

Taking tablespaces Offline or Online

You can take an online tablespace offline so that it is temporarily unavailable for general use. The rest of the database remains open and available for users to access data. Conversely, you can bring an offline tablespace online to make the schema objects within the tablespace available to database users. The database must be open to alter the availability of a tablespace.

To alter the availability of a tablespace, use the ALTER TABLESPACE statement. You must have the ALTER TABLESPACE or MANAGE TABLESPACE system privilege.

To Take a Tablespace Offline give the following command

SQL>alter tablespace ica offline;

To again bring it back online give the following command.

SQL>alter tablespace ica online;

To take individual datafile offline type the following command

SQL>alter database datafile ‘/u01/oracle/ica/ica_tbs01.dbf’ offline;

Again to bring it back online give the following command

SQL> alter database datafile ‘/u01/oracle/ica/ica_tbs01.dbf’ online;

Note: You can’t take individual datafiles offline it the database is running in NOARCHIVELOG mode.  If the datafile has become corrupt or missing when the database is running in NOARCHIVELOG mode then you can only drop it by giving the following command

SQL>alter database datafile ‘/u01/oracle/ica/ica_tbs01.dbf’
                                offline for drop;

Making a Tablespace Read only.

Making a tablespace read-only prevents write operations on the datafiles in the tablespace. The primary purpose of read-only tablespaces is to eliminate the need to perform backup and recovery of large, static portions of a database. Read-only tablespaces also provide a way to protecting historical data so that users cannot modify it. Making a tablespace read-only prevents updates on all tables in the tablespace, regardless of a user's update privilege level.

To make a tablespace read only

SQL>alter tablespace ica read only

Again to make it read write

SQL>alter tablespace ica read write;

Renaming Tablespaces

Using the RENAME TO clause of the ALTER TABLESPACE, you can rename a permanent or temporary tablespace. For example, the following statement renames the users tablespace:

ALTER TABLESPACE users RENAME TO usersts;

The following affect the operation of this statement:

• The COMPATIBLE parameter must be set to 10.0 or higher.
• If the tablespace being renamed is the SYSTEM tablespace or the SYSAUX tablespace, then it will not be renamed and an error is raised.
• If any datafile in the tablespace is offline, or if the tablespace is offline, then the tablespace is not renamed and an error is raised.

Dropping Tablespaces

You can drop a tablespace and its contents (the segments contained in the tablespace) from the database if the tablespace and its contents are no longer required. 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. Also, immediately before and after dropping a tablespace from a database, back up the database completely

To drop a tablespace give the following command.

SQL> drop tablespace ica;

This will drop the tablespace only if it is empty. If it is not empty and if you want to drop it anyhow then add the following keyword

SQL>drop tablespace ica including contents;

This will drop the tablespace even if it is not empty. But the datafiles will not be deleted you have to use operating system command to delete the files.

But If  you include datafiles keyword then, the associated datafiles will also be deleted from the disk.

SQL>drop tablespace ica including contents and datafiles;

Temporary Tablespace

Temporary tablespace is used for sorting large tables. Every database should have one temporary tablespace. To create temporary tablespace give the following command.

SQL>create temporary tablespace temp tempfile ‘/u01/oracle/data/ica_temp.dbf’ size 100M
   extent management local  uniform size 5M;

The extent management clause is optional for temporary tablespaces because all temporary tablespaces are created with locally managed extents of a uniform size.  The AUTOALLOCATE clause is not allowed for temporary tablespaces.

Increasing or Decreasing the size of a Temporary Tablespace

You can use the resize clause to increase or decrease the size of a temporary tablespace. The following statement resizes a temporary file:

SQL>ALTER DATABASE TEMPFILE '/u02/oracle/data/lmtemp02.dbf' RESIZE 18M;

The following statement drops a temporary file and deletes the operating system file:

SQL> ALTER DATABASE TEMPFILE '/u02/oracle/data/lmtemp02.dbf' DROP  INCLUDING DATAFILES;

Tablespace Groups

A tablespace group enables a user to consume temporary space from multiple tablespaces. A tablespace group has the following characteristics:

• It contains at least one tablespace. There is no explicit limit on the maximum number of tablespaces that are contained in a group.
• It shares the namespace of tablespaces, so its name cannot be the same as any tablespace.
• You can specify a tablespace group name wherever a tablespace name would appear when you assign a default temporary tablespace for the database or a temporary tablespace for a user.

You do not explicitly create a tablespace group. Rather, it is created implicitly when you assign the first temporary tablespace to the group. The group is deleted when the last temporary tablespace it contains is removed from it.

Using a tablespace group, rather than a single temporary tablespace, can alleviate problems caused where one tablespace is inadequate to hold the results of a sort, particularly on a table that has many partitions. A tablespace group enables parallel execution servers in a single parallel operation to use multiple temporary tablespaces.

The view DBA_TABLESPACE_GROUPS lists tablespace groups and their member tablespaces.

Creating a Temporary Tablespace Group

You create a tablespace group implicitly when you include the TABLESPACE GROUP clause in the CREATE TEMPORARY TABLESPACE or ALTER TABLESPACE statement and the specified tablespace group does not currently exist.

For example, if neither group1 nor group2 exists, then the following statements create those groups, each of which has only the specified tablespace as a member:

CREATE TEMPORARY TABLESPACE ica_temp2 TEMPFILE '/u02/oracle/ica/ica_temp.dbf'

     SIZE 50M

     TABLESPACE GROUP group1;

ALTER TABLESPACE ica_temp2 TABLESPACE GROUP group2;

Assigning a Tablespace Group as the Default Temporary Tablespace

Use the ALTER DATABASE ...DEFAULT TEMPORARY TABLESPACE statement to assign a tablespace group as the default temporary tablespace for the database. For example:

ALTER DATABASE sample DEFAULT TEMPORARY TABLESPACE group2;

Diagnosing and Repairing Locally Managed Tablespace Problems

To diagnose and repair corruptions in Locally Managed Tablespaces Oracle has supplied a package called DBMS_SPACE_ADMIN. This package has many procedures described below:

Be careful using the above procedures if not used properly you will corrupt your database. Contact Oracle Support before using these procedures.

Following are some of the Scenarios where you can use the above procedures

Scenario 1: Fixing Bitmap When Allocated Blocks are Marked Free (No Overlap)

The TABLESPACE_VERIFY procedure discovers that a segment has allocated blocks that are marked free in the bitmap, but no overlap between segments is reported.

In this scenario, perform the following tasks:

1. Call the SEGMENT_DUMP procedure to dump the ranges that the administrator allocated to the segment.
2. For each range, call the TABLESPACE_FIX_BITMAPS procedure with the TABLESPACE_EXTENT_MAKE_USED option to mark the space as used.
3. Call TABLESPACE_REBUILD_QUOTAS to fix up quotas.

Scenario 2: Dropping a Corrupted Segment

You cannot drop a segment because the bitmap has segment blocks marked "free". The system has automatically marked the segment corrupted.

In this scenario, perform the following tasks:

1. Call the SEGMENT_VERIFY procedure with the SEGMENT_VERIFY_EXTENTS_GLOBAL option. If no overlaps are reported, then proceed with steps 2 through 5.
2. Call the SEGMENT_DUMP procedure to dump the DBA ranges allocated to the segment.
3. For each range, call TABLESPACE_FIX_BITMAPS with the TABLESPACE_EXTENT_MAKE_FREE option to mark the space as free.
4. Call SEGMENT_DROP_CORRUPT to drop the SEG$ entry.
5. Call TABLESPACE_REBUILD_QUOTAS to fix up quotas.

Scenario 3: Fixing Bitmap Where Overlap is Reported

The TABLESPACE_VERIFY procedure reports some overlapping. Some of the real data must be sacrificed based on previous internal errors.

After choosing the object to be sacrificed, in this case say, table t1, perform the following tasks:

1. Make a list of all objects that t1 overlaps.
2. Drop table t1. If necessary, follow up by calling the SEGMENT_DROP_CORRUPT procedure.
3. Call the SEGMENT_VERIFY procedure on all objects that t1 overlapped. If necessary, call the TABLESPACE_FIX_BITMAPS procedure to mark appropriate bitmap blocks as used.
4. Rerun the TABLESPACE_VERIFY procedure to verify the problem is resolved.

Scenario 4: Correcting Media Corruption of Bitmap Blocks

A set of bitmap blocks has media corruption.

In this scenario, perform the following tasks:

1. Call the TABLESPACE_REBUILD_BITMAPS procedure, either on all bitmap blocks, or on a single block if only one is corrupt.
2. Call the TABLESPACE_REBUILD_QUOTAS procedure to rebuild quotas.
3. Call the TABLESPACE_VERIFY procedure to verify that the bitmaps are consistent.

Scenario 5: Migrating from a Dictionary-Managed to a Locally Managed Tablespace

To migrate a dictionary-managed tablespace to a locally managed tablespace. You use the TABLESPACE_MIGRATE_TO_LOCAL procedure.

For example if you want to migrate a dictionary managed tablespace ICA2 to Locally managed then give the following command.

EXEC DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('ica2');

Transporting Tablespaces

You can use the transportable tablespaces feature to move a subset of an Oracle Database and "plug" it in to another Oracle Database, essentially moving tablespaces between the databases. The tablespaces being transported can be either dictionary managed or locally managed. Starting with Oracle9i, the transported tablespaces are not required to be of the same block size as the target database standard block size.

Moving data using transportable tablespaces is much faster than performing either an export/import or unload/load of the same data. This is because the datafiles containing all of the actual data are simply copied to the destination location, and you use an import utility to transfer only the metadata of the tablespace objects to the new database.

Starting with Oracle Database 10g, you can transport tablespaces across platforms. This functionality can be used to Allow a database to be migrated from one platform to another. However not all platforms are supported. To see which platforms are supported give the following query.

SQL> COLUMN PLATFORM_NAME FORMAT A30

SQL> SELECT * FROM V$TRANSPORTABLE_PLATFORM;

PLATFORM_ID PLATFORM_NAME                  ENDIAN_FORMAT

----------- ------------------------------ --------------

          1 Solaris[tm] OE (32-bit)        Big

          2 Solaris[tm] OE (64-bit)        Big

          7 Microsoft Windows NT           Little

         10 Linux IA (32-bit)              Little

          6 AIX-Based Systems (64-bit)     Big

          3 HP-UX (64-bit)                 Big

          5 HP Tru64 UNIX                  Little

          4 HP-UX IA (64-bit)              Big

         11 Linux IA (64-bit)              Little

         15 HP Open VMS                    Little

10 rows selected.

If the source platform and the target platform are of different endianness, then an additional step must be done on either the source or target platform to convert the tablespace being transported to the target format. If they are of the same endianness, then no conversion is necessary and tablespaces can be transported as if they were on the same platform.

Important: Before a tablespace can be transported to a different platform, the datafile header must identify the platform to which it belongs. In an Oracle Database with compatibility set to 10.0.0 or higher, you can accomplish this by making the datafile read/write at least once.

SQL> alter tablespace ica read only;

Then,

SQL> alter tablespace ica read write;

Procedure for transporting tablespaces

To move or copy a set of tablespaces, perform the following steps.

1. For cross-platform transport, check the endian format of both platforms by querying the V$TRANSPORTABLE_PLATFORM view.

If you are transporting the tablespace set to a platform different from the source platform, then determine if the source and target platforms are supported and their endianness. If both platforms have the same endianness, no conversion is necessary. Otherwise you must do a conversion of the tablespace set either at the source or target database.

Ignore this step if you are transporting your tablespace set to the same platform.

2. Pick a self-contained set of tablespaces.
3. Generate a transportable tablespace set.

A transportable tablespace set consists of datafiles for the set of tablespaces being transported and an export file containing structural information for the set of tablespaces.

If you are transporting the tablespace set to a platform with different endianness from the source platform, you must convert the tablespace set to the endianness of the target platform. You can perform a source-side conversion at this step in the procedure, or you can perform a target-side conversion as part of step 4.

4. Transport the tablespace set.

Copy the datafiles and the export file to the target database. You can do this using any facility for copying flat files (for example, an operating system copy utility, ftp, the DBMS_FILE_COPY package, or publishing on CDs).

If you have transported the tablespace set to a platform with different endianness from the source platform, and you have not performed a source-side conversion to the endianness of the target platform, you should perform a target-side conversion now.

5. Plug in the tablespace.

Invoke the Export utility to plug the set of tablespaces into the target database.

Transporting Tablespace Example

These steps are illustrated more fully in the example that follows, where it is assumed the following datafiles and tablespaces exist:

Step 1: Determine if Platforms are Supported and Endianness

This step is only necessary if you are transporting the tablespace set to a platform different from the source platform. If ica_sales_1 and ica_sales_2 were being transported to a different platform, you can execute the following query on both platforms to determine if the platforms are supported and their endian formats:

SELECT d.PLATFORM_NAME, ENDIAN_FORMAT

     FROM V$TRANSPORTABLE_PLATFORM tp, V$DATABASE d

     WHERE tp.PLATFORM_NAME = d.PLATFORM_NAME;

The following is the query result from the source platform:

PLATFORM_NAME             ENDIAN_FORMAT

------------------------- --------------

Solaris[tm] OE (32-bit)   Big

The following is the result from the target platform:

PLATFORM_NAME             ENDIAN_FORMAT

------------------------- --------------

Microsoft Windows NT      Little

You can see that the endian formats are different and thus a conversion is necessary for transporting the tablespace set.

Step 2: Pick a Self-Contained Set of Tablespaces

There may be logical or physical dependencies between objects in the transportable set and those outside of the set. You can only transport a set of tablespaces that is self-contained. That is it should not have tables with foreign keys referring to primary key of tables which are in other tablespaces. It should not have tables with some partitions in other tablespaces. To find out whether the tablespace is self contained do the following

EXECUTE DBMS_TTS.TRANSPORT_SET_CHECK('ica_sales_1,ica_sales_2', TRUE);

After executing the above give the following query to see whether  any violations are there.

SQL> SELECT * FROM TRANSPORT_SET_VIOLATIONS;

VIOLATIONS

---------------------------------------------------------------------------

Constraint DEPT_FK between table SAMI.EMP in tablespace ICA_SALES_1 and table

SAMI.DEPT in tablespace OTHER

Partitioned table SAMI.SALES is partially contained in the transportable set

These violations must be resolved before ica_sales_1 and ica_sales_2 are transportable

Step 3: Generate a Transportable Tablespace Set

After ensuring you have a self-contained set of tablespaces that you want to transport, generate a transportable tablespace set by performing the following actions:

Make all tablespaces in the set you are copying read-only.

SQL> ALTER TABLESPACE ica_sales_1 READ ONLY;

Tablespace altered.

SQL> ALTER TABLESPACE ica_sales_2 READ ONLY;

Tablespace altered.

Invoke the Export utility on the host system and specify which tablespaces are in the transportable set.

SQL> HOST

$ exp system/password FILE=/u01/oracle/expdat.dmp
TRANSPORT_TABLESPACES = ica_sales_1,ica_sales_2

If ica_sales_1 and ica_sales_2 are being transported to a different platform, and the endianness of the platforms is different, and if you want to convert before transporting the tablespace set, then convert the datafiles composing the ica_sales_1 and ica_sales_2 tablespaces. You have to use RMAN utility to convert datafiles

$ RMAN TARGET /

Recovery Manager: Release 10.1.0.0.0
Copyright (c) 1995, 2003, Oracle Corporation.  All rights reserved.

 

connected to target database: ica_salesdb (DBID=3295731590)

Convert the datafiles into a temporary location on the source platform. In this example, assume that the temporary location, directory /temp, has already been created. The converted datafiles are assigned names by the system.

RMAN> CONVERT TABLESPACE ica_sales_1,ica_sales_2 
       TO PLATFORM 'Microsoft Windows NT' FORMAT '/temp/%U';

Starting backup at 08-APR-03
using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=11 devtype=DISK
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00005 name=/u01/oracle/oradata/ica_salesdb/ica_sales_101.dbf
converted datafile=/temp/data_D-10_I-3295731590_TS-ADMIN_TBS_FNO-5_05ek24v5

channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00004 name=/u01/oracle/oradata/ica_salesdb/ica_sales_101.dbf
converted datafile=/temp/data_D-10_I-3295731590_TS-EXAMPLE_FNO-4_06ek24vl

channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:45

Finished backup at 08-APR-07

Step 4: Transport the Tablespace Set

Transport both the datafiles and the export file of the tablespaces to a place accessible to the target database. You can use any facility for copying flat files (for example, an operating system copy utility, ftp, the DBMS_FILE_TRANSFER package, or publishing on CDs).

Step 5: Plug In the Tablespace Set

Plug in the tablespaces and integrate the structural information using the Import utility, imp:

IMP system/password FILE=expdat.dmp
  DATAFILES=/ica_salesdb/ica_sales_101.dbf,/ica_salesdb/ica_sales_201.dbf

   REMAP_SCHEMA=(smith:sami) REMAP_SCHEMA=(williams:john)

The REMAP_SCHEMA parameter changes the ownership of database objects. If you do not specify REMAP_SCHEMA, all database objects (such as tables and indexes) are created in the same user schema as in the source database, and those users must already exist in the target database. If they do not exist, then the import utility returns an error. In this example, objects in the tablespace set owned by smith in the source database will be owned by sami in the target database after the tablespace set is plugged in. Similarly, objects owned by williams in the source database will be owned by john in the target database. In this case, the target database is not required to have users smith and williams, but must have users sami and john.

After this statement executes successfully, all tablespaces in the set being copied remain in read-only mode. Check the import logs to ensure that no error has occurred.

Now, put the tablespaces into read/write mode as follows:

ALTER TABLESPACE ica_sales_1 READ WRITE;

ALTER TABLESPACE ica_sales_2 READ WRITE;

Viewing Information about Tablespaces and Datafiles

Oracle has provided many Data dictionaries to view information about tablespaces and datafiles.  Some of them are:

To view information about Tablespaces in a database give the following query

SQL>select * from dba_tablespaces
SQL>select * from v$tablespace;

To view information about Datafiles

SQL>select * from dba_data_files;
SQL>select * from v$datafile;

To view information about Tempfiles

SQL>select * from dba_temp_files;
SQL>select * from v$tempfile;

To view information about free space in datafiles

SQL>select * from dba_free_space;

To view information about free space in tempfiles

SQL>select * from V$TEMP_SPACE_HEADER;

Relocating or Renaming Datafiles

You can rename datafiles to either change their names or relocate them.

Renaming or Relocating Datafiles belonging to a Single Tablespace

To rename or relocate datafiles belonging to a Single Tablespace do the following.

1.       Take the tablespace offline

2.       Rename or Relocate the datafiles using operating system command

3.       Give the ALTER TABLESPACE with RENAME DATAFILE option to change the filenames within the Database.

4.       Bring the tablespace Online

For Example suppose you have a tablespace users with the following datafiles

        /u01/oracle/ica/usr01.dbf’
        /u01/oracle/ica/usr02.dbf’

Now you want to relocate /u01/oracle/ica/usr01.dbf’  to ‘/u02/oracle/ica/usr01.dbf’ and want to rename ‘/u01/oracle/ica/usr02.dbf’ to ‘/u01/oracle/ica/users02.dbf’  then follow the given the steps

1.       Bring the tablespace offline

SQL> alter tablespace users offline;

2.       Copy the file to new location using o/s command.

$cp /u01/oracle/ica/usr01.dbf  /u02/oracle/ica/usr01.dbf’

Rename the file ‘/u01/oracle/ica/usr02.dbf’ to ‘/u01/oracle/ica/users02.dbf’ using o/s command.

$mv  /u01/oracle/ica/usr02.dbf /u01/oracle/ica/users02.dbf

3.       Now start SQLPLUS and type the following command to rename and relocate these files

SQL> alter tablespace users rename file
   ‘/u01/oracle/ica/usr01.dbf’, ‘/u01/oracle/ica/usr02.dbf’ to                     
   ‘/u02/oracle/ica/usr01.dbf’,’/u01/oracle/ica/users02.dbf’;

4.       Now bring the tablespace  Online

SQL> alter tablespace users online;

Procedure for Renaming and Relocating Datafiles in Multiple Tablespaces

You can rename and relocate datafiles in one or more tablespaces using the ALTER DATABASE RENAME FILE statement. This method is the only choice if you want to rename or relocate datafiles of several tablespaces in one operation. You must have the ALTER DATABASE system privilege

To rename datafiles in multiple tablespaces, follow these steps.

1.      Ensure that the database is mounted but closed.

2.      Copy the datafiles to be renamed to their new locations and new names, using the operating system..

3.      Use ALTER DATABASE to rename the file pointers in the database control file.

For example, the following statement renames the datafiles/u02/oracle/rbdb1/sort01.dbf and /u02/oracle/rbdb1/user3.dbf to /u02/oracle/rbdb1/temp01.dbf and /u02/oracle/rbdb1/users03.dbf, respectively:

ALTER DATABASE

    RENAME FILE '/u02/oracle/rbdb1/sort01.dbf',

                '/u02/oracle/rbdb1/user3.dbf'

             TO '/u02/oracle/rbdb1/temp01.dbf',

                '/u02/oracle/rbdb1/users03.dbf;

Always provide complete filenames (including their paths) to properly identify the old and new datafiles. In particular, specify the old datafile names exactly as they appear in the DBA_DATA_FILES view.

4.      Back up the database. After making any structural changes to a database, always perform an immediate and complete backup.

5.      Start the Database