This module describes how to migrate from dictionary-managed to locally managed tablespaces.
This module discusses the following:
| What is a Locally Managed Tablespace? | ||
| Migrating a Non-SYSTEM Tablespace | ||
Move your mouse over this icon to show all screenshots.
You can also move your mouse over each individual icon to see only the screenshot
associated with it.
Prior to Oracle8i, all tablespaces were created as dictionary-managed. Dictionary-managed tablespaces rely on data dictionary tables to track space utilization. Beginning with Oracle8i, you can create locally managed tablespaces, which use bitmaps instead of data dictionary tables to track used and free space. Locally managed tablespaces provide better performance and greater ease of management.
Locally managed tablespaces track all extent information in the tablespace itself using bitmaps, resulting in the following benefits:
| Improved concurrency and speed of space operations, because space allocations and de-allocations predominantly modify locally managed resources (bitmaps stored in header files) rather than requiring centrally managed resources such as enqueues | ||
| Improved performance, because recursive operations that are sometimes required during dictionary-managed space allocation are eliminated | ||
| Readable standby databases are allowed, because locally managed temporary tablespaces (used, for example, for sorts) are locally managed and thus do not generate any undo or redo | ||
| Simplified space allocation--when the AUTOALLOCATE clause is specified, appropriate extent size is automatically selected | ||
| Reduced user reliance on the data dictionary because necessary information is stored in file headers and bitmap blocks | ||
As of Oracle9i Release 2, you can define all tablespaces, including the SYSTEM tablespace, as locally managed tablespaces.
Beginning in Oracle9i the default for non-SYSTEM permanent tablespaces is locally managed whenever both of the following criteria are met:
| The EXTENT MANAGEMENT clause is not specified | ||
| The COMPATIBLE initialization parameter is set to 9.0.0 or higher | ||
You can use the DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL procedure to migrate a tablespace from dictionary-managed to locally managed.
You can use the DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL
procedure to migrate a tablespace from dictionary-managed to locally managed.
Perform the following steps to migrate your dictionary-managed tablespaces to
locally managed. The tablespace must be kept online and read/write during migration.
Note that temporary tablespaces cannot be migrated. You must migrate all non-SYSTEM
tablespaces prior to migrating the SYSTEM tablespace if you intend those tablespaces
to be used in READ WRITE mode.
| 1. |
Invoke SQL*Plus.
|
| 2. |
Query DBA_TABLESPACES to determine the type of extent management used in each tablespace: SELECT tablespace_name, extent_management FROM dba_tablespaces;
|
| 3. |
Query DBA_TABLESPACES to verify that the tablespace you want to migrate is online and in READ WRITE mode: SELECT tablespace_name, status FROM dba_tablespaces;
|
| 4. |
Execute the DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL procedure and specify the name of the tablespace you want to migrate: EXECUTE DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL('<tablespace_name>');
|
| 5. |
Query DBA_TABLESPACES to verify your change: SELECT tablespace_name, status, extent_management FROM dba_tablespaces;
|
As of Oracle9i Release 2, you can define all tablespaces, including the SYSTEM tablespace, as locally managed tablespaces.
You can use the TABLESPACE_MIGRATE_TO_LOCAL procedure of the DBMS_SPACE_ADMIN package to migrate the SYSTEM tablespace from dictionary-managed to a locally managed tablespace.
The following conditions must be met before the migration:
| The database must have a default temporary tablespace that is not SYSTEM | ||
| If you are using rollback segments: | ||
| There are no rollback segments in dictionary-managed tablespaces | ||
| There is at least one online rollback segment in a locally managed tablespace | ||
| If you are using automatic undo management, an undo tablespace must be online | ||
| All tablespaces, other than the tablespace containing rollback segments or undo segments, must be in read-only mode | ||
| The database must be in RESTRICTED mode | ||
All of these conditions are enforced by the TABLESPACE_MIGRATE_TO_LOCAL procedure. You will receive an error message if any of the conditions are not met.
Note: After the SYSTEM tablespace is migrated to locally managed, any dictionary-managed tablespaces in the database cannot be made READ WRITE. If you want to be able to use the dictionary-managed tablespaces in READ WRITE mode, you should migrate these tablespaces to locally managed before migrating the SYSTEM tablespace.
You can migrate your SYSTEM tablespace from dictionary-managed to locally managed by performing the following steps:
| 1. |
Use Recovery Manager or operating system commands to make a whole consistent (complete or full) backup of the database before you begin the migration.
|
| 2. |
Invoke SQL*Plus. Connect as a user with SYSDBA privileges.
|
| 3. |
Verify that you have a temporary tablespace other than SYSTEM by querying DBA_TABLESPACES as follows: SELECT tablespace_name FROM dba_tablespaces WHERE contents = 'TEMPORARY';
|
| 4. |
If you are using rollback segments, verify that no rollback segments are in dictionary-managed tablespaces by querying DBA_SEGMENTS and DBA_TABLESPACES: SELECT s.segment_name, s.tablespace_name, t.extent_management FROM dba_segments s, dba_tablespaces t WHERE s.tablespace_name = t.tablespace_name AND s.segment_type = 'ROLLBACK';
|
| 5. |
If you are using rollback segments, verify that there is at least one online rollback segment in a locally managed tablespace by querying DBA_ROLLBACK_SEGS: SELECT segment_name, status FROM dba_rollback_segs WHERE tablespace_name = '<tablespace_name>';
|
| 6. |
If you are using automatic undo management, verify that the undo tablespace is online by querying DBA_TABLESPACES as follows: SELECT tablespace_name, status FROM dba_tablespaces WHERE contents = 'UNDO';
|
| 7. |
Verify that all tablespaces other than the ones containing rollback segments or undo segments and your temporary tablespace are READ ONLY by querying DBA_TABLESPACES as follows: SELECT tablespace_name, status FROM dba_tablespaces;
|
| 8. |
If any tablespace other than the tablespace containing undo or rollback segments or the temporary tablespace is not in READ ONLY mode, issue the following command to place it in READ ONLY mode: ALTER TABLESPACE <tablespace_name> READ ONLY;
|
| 9. |
Verify that the database is in RESTRICTED mode by querying V$INSTANCE: SELECT logins FROM v$instance;
|
| 10. |
If the database is not in RESTRICTED mode, issue the following command to put it in RESTRICTED mode: ALTER SYSTEM ENABLE RESTRICTED SESSION;
|
| 11. |
Execute the DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL procedure specifying the SYSTEM tablespace: EXECUTE DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL('SYSTEM');
|
| 12. |
Verify your change by querying DBA_TABLESPACES: SELECT extent_management FROM dba_tablespaces WHERE tablespace_name = 'SYSTEM';
|
| 13. |
Issue the following command to disable RESTRICTED mode: ALTER SYSTEM DISABLE RESTRICTED SESSION;
|
| 14. |
Issue the following command for each tablespace you placed in READ ONLY mode to return it to READ WRITE: ALTER TABLESPACE <tablespace_name> READ WRITE;
|
You cannot use the DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL procedure to migrate a temporary tablespace that is dictionary-managed to a locally managed tablespace. You must drop the dictionary-managed temporary tablespace and re-create it as locally managed.
Because space management is much simpler and more efficient in locally managed tablespaces, they are ideally suited for temporary tablespaces. Locally managed temporary tablespaces use tempfiles, that do not modify data outside of the temporary tablespace or generate any redo for temporary tablespace data.
| 1. |
Invoke SQL*Plus and connect as a user with the CREATE TABLESPACE privilege.
|
| 2. |
Query the DBA_TABLESPACES view to determine the name of your dictionary-managed temporary tablespace: SELECT tablespace_name, extent_management FROM dba_tablespaces WHERE contents = 'TEMPORARY';
|
| 3. |
Use the DROP TABLESPACE command to drop your dictionary-managed temporary tablespace. You can include the INCLUDING CONTENTS AND DATAFILES clause to remove the file from the operating system. Alternatively, you can remove the data file with operating system commands. DROP TABLESPACE <tablespace_name>
|
| 4. |
Use the CREATE TEMPORARY TABLESPACE command to create a locally managed temporary tablespace as shown below: CREATE TEMPORARY TABLESPACE <temp_tablespace_name>
|
| 5. |
Query DBA_TABLESPACES view to verify the creation of your locally managed temporary tablespace: SELECT tablespace_name, extent_management FROM dba_tablespaces WHERE contents = 'TEMPORARY';
|
| 6. |
Query V$TEMPFILE or DBA_TEMP_FILES to determine the names of the tempfiles: SELECT ts#, name FROM v$tempfile; SELECT tablespace_name, file_name FROM dba_temp_files;
|