A mandatory tablespace that consists of the data dictionary, including definitions of tables, views, and stored procedures needed by the database. Oracle Database automatically maintains information in this tablespace.
An user-created tablespace that consists of application data. As you create and enter data into tables, Oracle Database fills this space with your data.
System-managed tablespaces that contain undo data for each instance. Each Oracle RAC instance uses a different value for n in the tablespace name. These tablespaces are used for automatic undo management.
A system tablespace that contains rollback segments. If you do not use automatic undo management, then you must configure the RBS tablespace. The RBS tablespace should only be used when needed for compatibility with earlier versions of Oracle Database.
Посмотреть, какие табличные пространства имеются в базе данных можно следующим запросом.
В каких файлах хранятся табличные пространства.
Табличное пространство system
В табличном пространстве system хранится «Словарь данных Oracle»
Каждая база данных Oracle содержит набор таблиц, доступных только для чтения и известных как словарь данных (data dictionary), который содержит метаданные (информацию о различных компонентах базы данных). Словарь данных Oracle – сердце системы управления базой данных.
Oracle не позволяет обращаться к таблицам словаря данных напрямую. Он создает представления на базе этих таблиц и общедоступные синонины для тих представлений, к которым могут обращаться пользователи. Существует три набора представлений словаря данных: USER, ALL и DBA – каждый из которых содержит сходный набор представлений со сходным набором столбцов.
Посмотреть содержимое табличного пространства system
Табличное пространство sysaux
Табличное пространство sysaux служит вспомогательным табличным пространством по отношению к табличному пространству system.
Табличные пространства Oracle: типы, виды, назначение и управление
Размер ваших табличных пространств зависит от размера ваших таблиц и индексов, а также общего объема данных в баз — здесь не существует правил о минимальном и максимальном размере табличного пространства (максимально возможный размер слишком велик, чтобы принимать это ограничение во внимание). Обычным делом являются табличные пространства размером в 100 Гбайт, сосуществующие в одной и той же базе данных с табличными пространствами в 1 Гбайт и даже намного меньше.
Файлы данных, содержащие данные табличных пространств, все вместе составляют общий объем физического пространства, выделенного определенной базе данных. Размер табличного пространства складывается из размеров файлов, содержащих данные, и если вы сложите все размеры табличных пространств или размеры всех файлов данных, то получите размер самой базы данных. Если вы выйдете за пределы базы данных, добавляя новые данные, вам понадобится добавить новые табличные пространства с новыми файлами данных, добавить новые файлы данных к существующим табличным пространствам, или же увеличить существующие файлы данных табличных пространств. Как это делается будет показано в следующих моих статьях.
Не существует простого и общеприменимого правила, регламентирующего количество табличных пространств, которые вы можете иметь в одной базе данных Oracle.
Следующие пять табличных пространств обычно представляют собой табличные пространства по умолчанию, которые должны иметь все базы данных, даже несмотря на то, что в принципе можно создать базу данных включающую всего два из них:
Традиционно администраторы Oracle используют десятки, а иногда и сотни табличных пространств для хранения всех прикладных таблиц и индексов, и если вы уверены, что действительно потребуется большое количество табличных пространств для группирования всех взаимосвязанных прикладных таблиц и индексов, то это нормально. Однако вы не обязаны использовать большое количество табличных пространств. Сегодня большинство организаций применяют диспетчер Logical Volume Manager для разнесения логических томов и файлов данных на множество физических дисков. Таким образом, крупные табличные пространства могут занимать несколько физических дисков. Раньше приходилось создавать разные табличные пространства на разных физических дисках, чтобы избежать конкуренции ввода-вывода, но современные структуры организации дисков устранили эту проблему, и вы при желании можете обойтись меньшим числом табличных пространств. Вы можете использовать только одно табличное пространство для всех прикладных данных, по-скольку файлы данных, являющиеся частью табличного пространства, могут быть “размазаны” по нескольким дискам. Именно поэтому традиционное требование размещать таблицы и индексы в разных табличных пространствах отныне не так важно.
Для чего нужны табличные пространства?
Табличные пространства выполняют ряд ключевых функций в базе данных Oracle, но концепция табличного пространства не является общей для всех реляционных баз данных. Так, например, в базе данных Microsoft SQL Server эта концепция не используется вообще. Ниже приведен краткий список преимуществ использования табличных пространств.
Табличные пространства теперь используются, прежде всего, для разделения определенных групп таблиц и индексов. Это может быть важно, если вы хотите перемещать табличные пространства между разными базами данных и платформами, используя утилиту Oracle Data Pump, или если вы применяете разные размеры блоков данных в разных табличных пространствах. Если вы полагаете, что вам не придется выполнять эти административные задачи с использованием табличных пространств, то можете применять всего пару табличных пространств для хранения всех данных базы.
Размеры блоков и табличные пространства
Каждое табличное пространство использует размер блока по умолчанию, установленный для базы данных, если только вы не создадите табличного пространства с нестандартным размером блока. Как уже говорилось, Oracle позволяет иметь несколько размеров блоков в дополнение к размеру блока по умолчанию. Поскольку табличные пространства в конечном итоге состоят из блоков данных Oracle, это означает, что можно иметь табличные пространства с разными размерами блоков Oracle в одной и той же базе данных. Это замечательное средство, которое предоставляет возможность выбирать наиболее подходящий размер блока для табличного пространства, в зависимости от структуры данных содержащихся в нем таблиц.
Настройка размера блока для табличного пространства обеспечивает несколько преимуществ
Оптимизация операций дискового ввода-вывода. Помните, что сервер базы данных Oracle должен читать табличные данные с физических дисков в область буфера кэширования для дальнейшей обработки. Одной из главных ваших целей,как администратора базы данных, является оптимизация дорогостоящего ввода-вывода при чтении и записи на диск. Если у вас есть таблицы с очень длинными строками, лучше выбрать большой размер блока — тогда каждое чтение извлечет больше данных, чем вы получите при меньшем размере блока, и в результате для получения того же объема данных понадобится меньше операций чтения. Таблицы с большими объектами (LOB) также выиграют от очень блоков очень большого размера. С другой стороны, таблицы с малой длиной строки могут использовать блоки малого размера в качестве строительных блоков табличного пространства. Если у вас в базе есть индексы огромного размера, вам понадобится большой размер блока для их табличного пространства, чтобы каждое чтение извлекало большее количество указателей индекса.
Оптимальное кэширование данных. Oracle выделяет отдельные пулы для блоков различного размера, что приводит к лучшему использованию памяти Oracle. Мы поговорим об этом в последующих разделах.
Облегчение переноса табличных пространств. Если есть табличные пространства с несколькими размерами блоков, легче будет использовать средство “переносных табличных пространств”. В дальнейшем я планирую опубликовать статью, в которой вы найдете примеры, демонстрирующие процесс переноса табличных пространств между базами данных Oracle (готово! читайте эту статью).
На заметку! Каждое табличное пространство Oracle состоит из одного или более файлов операционной системы с данными, и каждый такой файл может относиться только к одному табличному пространству. Во время создания базы данных только два табличных пространства должны присутствовать обязательно. Это табличное пространство System (ключевое табличное пространство Oracle, содержащее данные словаря Oracle) и табличное пространство Sysaux (которое является вспомогательным табличным пространством для System и содержит данные, используемые различными продуктами и средствами Oracle). При инсталляции Oracle сначала автоматически создает табличное пространство System, а за ним — Sysaux, но вы указываете файл данных для каждого из них. Позднее можно добавлять и удалять табличные пространства по своему желанию, однако нельзя удалить или переименовать табличные пространства System и Sysaux.
Конечно, вы должны также создать отдельные табличные пространства приложений, чтобы хранить данные и индексы. Именно эти табличные пространства будут составлять основную часть размера базы данных.
Локально управляемые табличные пространства Oracle сами хранят информацию для управления пространством в файлах данных и отслеживают состояние свободы или занятости блоков каждого файла данных. Информация о свободном и занятом пространстве в файлах данных хранится в виде битовых карт внутри заголовков файла данных. Битовые карты (bitmaps) — это структуры, использующие отдельные биты для описания места в блоке или группе блоков. Помните, что когда объекту нужно расти,Oracle выделяет ему новое пространство, измеряемое в экстентах, а не в индивидуальных блоках данных. Поэтому когда новый экстент должен быть выделен объекту, Oracle выбирает первый свободный файл данных и просматривает его битовую карту в поисках свободных непрерывных блоков данных. Если подходящий блок найден, то Oracle выделяет экстент и затем изменяет битовую карту в файле данных, чтобы изменить статус занятости блоков в экстенте.
Во время этого процесса словарь данных никак не используется, поэтому рекурсивные операции SQL значительно сокращены. Информация отката (rollback) не генерируется во время этого обновления битовых карт файлов данных. Это преимущество особенно существенно, если база данных относится к типу OLTP, с многочисленными вставками, удалениями и обновлениями, которые происходят непрерывно.
Типы табличных пространств
Помимо табличных пространств System и Sysaux, скорее всего, у вас будут табличные пространства Undo и Temporary. У вас также будет несколько других “постоянных” табличных пространств для хранения данных и индексов.
Ниже перечислены ключевые типы табличных пространств, с которыми вам, вероятно, придется встретиться.
An undo tablespace is a type of permanent tablespace used by Oracle Database to manage undo data if you are running your database in automatic undo management mode. Oracle strongly recommends that you use automatic undo management mode rather than using rollback segments for undo.
When you create a tablespace, it is initially a read/write tablespace. You can subsequently use the ALTER TABLESPACE statement to take the tablespace offline or online, add data files or temp files to it, or make it a read-only tablespace.
You can also drop a tablespace from the database with the DROP TABLESPACE statement.
Oracle Database Concepts for information on tablespaces
ALTER TABLESPACE and DROP TABLESPACE for information on modifying and dropping tablespaces
You must have the CREATE TABLESPACE system privilege. To create the SYSAUX tablespace, you must have the SYSDBA system privilege.
Before you can create a tablespace, you must create a database to contain it, and the database must be open.
To use objects in a tablespace other than the SYSTEM tablespace:
If you are running the database in automatic undo management mode, then at least one UNDO tablespace must be online.
If you are running the database in manual undo management mode, then at least one rollback segment other than the SYSTEM rollback segment must be online.
Use this clause to determine whether the tablespace is a bigfile or smallfile tablespace. This clause overrides any default tablespace type setting for the database.
A bigfile tablespace contains only one data file or temp file, which can contain up to approximately 4 billion (2 32 ) blocks. The minimum size of the single data file or temp file is 12 megabytes (MB) for a tablespace with 32K blocks and 7MB for a tablespace with 8K blocks. The maximum size of the single data file or temp file is 128 terabytes (TB) for a tablespace with 32K blocks and 32TB for a tablespace with 8K blocks.
A smallfile tablespace is a traditional Oracle tablespace, which can contain 1022 data files or temp files, each of which can contain up to approximately 4 million (2 22 ) blocks.
If you omit this clause, then Oracle Database uses the current default tablespace type of permanent or temporary tablespace that is set for the database. If you specify BIGFILE for a permanent tablespace, then the database by default creates a locally managed tablespace with automatic segment-space management.
Restriction on Bigfile Tablespaces
You can specify only one data file in the DATAFILE clause or one temp file in the TEMPFILE clause.
Oracle Database Administrator’s Guide for more information on using bigfile tablespaces
Use the following clauses to create a permanent tablespace. (Some of these clauses are also used to create a temporary or undo tablespace.)
Note on the SYSAUX Tablespace
You must specify EXTENT MANAGEMENT LOCAL and SEGMENT SPACE MANAGEMENT AUTO for the SYSAUX tablespace. The DATAFILE clause is optional only if you have enabled Oracle Managed Files. See «DATAFILE | TEMPFILE Clause» for the behavior of the DATAFILE clause.
Restrictions on the SYSAUX Tablespace
You cannot specify OFFLINE or TEMPORARY for the SYSAUX tablespace.
DATAFILE | TEMPFILE Clause
Specify the data files to make up the permanent tablespace or the temp files to make up the temporary tablespace. Use the datafile_tempfile_spec form of file_specification to create regular data files and temp files in an operating system file system or to create Oracle Automatic Storage Management (Oracle ASM) disk group files.
You must specify the DATAFILE or TEMPFILE clause unless you have enabled Oracle Managed Files by setting a value for the DB_CREATE_FILE_DEST initialization parameter. For Oracle ASM disk group files, the parameter must be set to a multiple file creation form of Oracle ASM filenames. If this parameter is set, then the database creates a system-named 100 MB file in the default file destination specified in the parameter. The file has AUTOEXTEND enabled and an unlimited maximum size.
Media recovery does not recognize temp files.
file_specification for a full description, including the AUTOEXTEND parameter and the multiple file creation form of Oracle ASM filenames
Notes on Specifying Data Files and Temp Files
On some operating systems, Oracle does not allocate space for a temp file until the temp file blocks are actually accessed. This delay in space allocation results in faster creation and resizing of temp files, but it requires that sufficient disk space is available when the temp files are later used. To avoid potential problems, before you create or resize a temp file, ensure that the available disk space exceeds the size of the new temp file or the increased size of a resized temp file. The excess space should allow for anticipated increases in disk space use by unrelated operations as well. Then proceed with the creation or resizing operation.
file_specification for a full description, including the AUTOEXTEND parameter
Use the permanent_tablespace_attrs clauses to set the attributes of the tablespace.
MINIMUM EXTENT Clause
size_clause for information on that clause and Oracle Database VLDB and Partitioning Guide for more information about using MINIMUM EXTENT to control fragmentation
Use the BLOCKSIZE clause to specify a nonstandard block size for the tablespace. In order to specify this clause, the DB_CACHE_SIZE and at least one DB_ n K_CACHE_SIZE parameter must be set, and the integer you specify in this clause must correspond with the setting of one DB_ n K_CACHE_SIZE parameter setting.
Restriction on BLOCKSIZE
You cannot specify nonstandard block sizes for a temporary tablespace or if you intend to assign this tablespace as the temporary tablespace for any users.
Oracle recommend that you do not store tablespaces with a 2K block size on 4K sector size disks, because performance degradation can result.
Oracle Database Reference for information on the DB_ n K_CACHE_SIZE parameter and Oracle Database Concepts for information on multiple block sizes
Specify the default logging attributes of all tables, indexes, materialized views, materialized view logs, and partitions within the tablespace. This clause is not valid for a temporary or undo tablespace.
The tablespace-level logging attribute can be overridden by logging specifications at the table, index, materialized view, materialized view log, and partition levels.
logging_clause for a full description of this clause
Use this clause to put the tablespace into FORCE LOGGING mode. Oracle Database will log all changes to all objects in the tablespace except changes to temporary segments, overriding any NOLOGGING setting for individual objects. The database must be open and in READ WRITE mode.
FORCE LOGGING mode can have performance effects. Refer to Oracle Database Administrator’s Guide for information on when to use this setting.
Restriction on Forced Logging
You cannot specify FORCE LOGGING for an undo or temporary tablespace.
Use this clause to specify whether to create an encrypted or unencrypted tablespace. If you create an encrypted tablespace, then Transparent Data Encryption (TDE) is applied to all data files of the tablespace.
Specify ENCRYPT to create an encrypted tablespace. Specify DECRYPT to create an unencrypted tablespace.
If you omit this clause, then the value of the ENCRYPT_NEW_TABLESPACES initialization parameter determines whether the tablespace is encrypted upon creation. Refer to Oracle Database Reference for more information on the ENCRYPT_NEW_TABLESPACES initialization parameter.
The DEFAULT clause lets you specify default parameters for the tablespace.
Use this clause to specify default compression of data for all indexes created in the tablespace. This clause is not valid for a temporary tablespace. The subclauses of this clause have the same semantics as they have for the advanced_index_compression clause of the CREATE INDEX statement. Refer to the advanced_index_compression clause of CREATE INDEX for the full semantics of these subclauses.
Use the inmemory_clause to specify the default In-Memory Column Store (IM column store) settings for all tables and materialized views created in the tablespace. This clause is not valid for a temporary tablespace.
Specify INMEMORY to enable all tables and materialized views for the IM column store.
Specify NO INMEMORY to disable all tables and materialized views for the IM column store. This is the default.
Use the ilm_clause to specify default Automatic Data Optimization settings for all tables created in the tablespace. This clause is not valid for a temporary tablespace. Refer to the ilm_clause of CREATE TABLE for the full semantics of this clause.
ONLINE | OFFLINE Clauses
Use these clauses to determine whether the tablespace is online or offline. This clause is not valid for a temporary tablespace.
Specify ONLINE to make the tablespace available immediately after creation to users who have been granted access to the tablespace. This is the default.
Specify OFFLINE to make the tablespace unavailable immediately after creation.
The data dictionary view DBA_TABLESPACES indicates whether each tablespace is online or offline.
The extent_management_clause lets you specify how the extents of the tablespace will be managed.
After you have specified extent management with this clause, you can change extent management only by migrating the tablespace.
AUTOALLOCATE specifies that the tablespace is system managed. Users cannot specify an extent size. You cannot specify AUTOALLOCATE for a temporary tablespace.
The DICTIONARY keyword is deprecated. It is still supported for backward compatibility. However, Oracle recommends that you create locally managed tablespaces. Locally managed tablespaces are much more efficiently managed than dictionary-managed tablespaces. The creation of new dictionary-managed tablespaces is scheduled for desupport.
Oracle Database Concepts for a discussion of locally managed tablespaces
Restrictions on Extent Management
Extent management is subject to the following restrictions:
The segment_management_clause is relevant only for permanent, locally managed tablespaces. It lets you specify whether Oracle Database should track the used and free space in the segments in the tablespace using free lists or bitmaps. This clause is not valid for a temporary tablespace.
Specify MANUAL if you want the database to manage the free space of segments in the tablespace using free lists. Oracle strongly recommends that you do not use this setting and that you create tablespaces with automatic segment-space management.
To determine the segment management of an existing tablespace, query the SEGMENT_SPACE_MANAGEMENT column of the DBA_TABLESPACES or USER_TABLESPACES data dictionary view.
If you specify AUTO segment management, then:
Restrictions on Automatic Segment-Space Management
This clause is subject to the following restrictions:
You can specify this clause only for a permanent, locally managed tablespace.
You cannot specify this clause for the SYSTEM tablespace.
Oracle Automatic Storage Management Administrator’s Guide for information on automatic segment-space management and when to use it
Oracle Database Reference for information on the data dictionary views
Use this clause in conjunction with the ALTER DATABASE FLASHBACK clause to specify whether the tablespace can participate in FLASHBACK DATABASE operations. This clause is useful if you have the database in FLASHBACK mode but you do not want Oracle Database to maintain Flashback log data for this tablespace.
This clause is not valid for temporary or undo tablespaces.
Specify FLASHBACK OFF to take the tablespace out of FLASHBACK mode. Oracle Database will not save any Flashback log data for this tablespace. You must take the data files in this tablespace offline or drop them prior to any subsequent FLASHBACK DATABASE operation. Alternatively, you can take the entire tablespace offline. In either case, the database does not drop existing Flashback logs.
The FLASHBACK mode of a tablespace is independent of the FLASHBACK mode of an individual table.
Oracle Database Backup and Recovery User’s Guide for information on Oracle Flashback Database
ALTER DATABASE and FLASHBACK DATABASE for information on setting the FLASHBACK mode of the entire database and reverting the database to an earlier version
Specify UNDO to create an undo tablespace. When you run the database in automatic undo management mode, Oracle Database manages undo space using the undo tablespace instead of rollback segments. This clause is useful if you are now running in automatic undo management mode but your database was not created in automatic undo management mode.
Oracle Database always assigns an undo tablespace when you start up the database in automatic undo management mode. If no undo tablespace has been assigned to this instance, then the database uses the SYSTEM rollback segment. You can avoid this by creating an undo tablespace, which the database will implicitly assign to the instance if no other undo tablespace is currently assigned.
This clause is valid only for undo tablespaces.
RETENTION GUARANTEE specifies that Oracle Database should preserve unexpired undo data in all undo segments of tablespace even if doing so forces the failure of ongoing operations that need undo space in those segments. This setting is useful if you need to issue an Oracle Flashback Query or an Oracle Flashback Transaction Query to diagnose and correct a problem with the data.
RETENTION NOGUARANTEE returns the undo behavior to normal. Space occupied by unexpired undo data in undo segments can be consumed if necessary by ongoing transactions. This is the default.
This clause has the same semantics for undo tablespaces as for permanent tablespaces. Refer to tablespace_encryption_clause in the documentation on permanent tablespaces for full information.
Restrictions on Undo Tablespaces
Undo tablespaces are subject to the following restrictions:
You cannot create database objects in this tablespace. It is reserved for system-managed undo data.
Oracle Database Administrator’s Guide for information on automatic undo management and undo tablespaces and Oracle Database Reference for information on the UNDO_MANAGEMENT parameter
CREATE DATABASE for information on creating an undo tablespace during database creation, and ALTER TABLESPACE and DROP TABLESPACE
Use this clause to create a temporary tablespace, which is an allocation of space in the database that can contain transient data that persists only for the duration of a session. This transient data cannot be recovered after process or instance failure.
The transient data can be user-generated schema objects such as temporary tables or system-generated data such as temp space used by hash joins and sort operations. When a temporary tablespace, or a tablespace group of which this tablespace is a member, is assigned to a particular user, then Oracle Database uses the tablespace for sorting operations in transactions initiated by that user.
You can create two types of temporary tablespaces:
You can create a shared temporary tablespace by specifying the TEMPORARY TABLESPACE clause. A shared temporary tablespace stores temp files on shared disk, so that the temporary space is accessible to all database instances. Shared temporary tablespaces were available in prior releases of Oracle Database and were called «temporary tablespaces.» Elsewhere in this guide, the term «temporary tablespace» refers to a shared temporary tablespace unless specified otherwise.
Starting with Oracle Database 12 c Release 2 (12.2), you can create a local temporary tablespace by specifying the LOCAL TEMPORARY TABLESPACE clause. Local temporary tablespaces are useful in an Oracle Clusterware environment. They store a separate, nonshared temp files for each database instance, which can improve I/O performance. A local temporary tablespace must be a BIGFILE tablespace.
Specify FOR ALL to instruct the database to create separate, nonshared temp files for all HUB and LEAF nodes.
Specify FOR LEAF to instruct the database to create separate nonshared temp files for only LEAF nodes.
This clause is relevant only for temporary tablespaces. Use this clause to determine whether tablespace is a member of a tablespace group. A tablespace group lets you assign multiple temporary tablespaces to a single user and increases the addressability of temporary tablespaces.
Specify a group name to indicate that tablespace is a member of this tablespace group. The group name cannot be the same as tablespace or any other existing tablespace. If the tablespace group already exists, then Oracle Database adds the new tablespace to that group. If the tablespace group does not exist, then the database creates the group and adds the new tablespace to that group.
Specify an empty string (‘ ‘) to indicate that tablespace is not a member of any tablespace group.
Restriction on Tablespace Groups
Tablespace groups support only shared temporary tablespaces. You cannot add a local temporary tablespace to a tablespace group.
This clause has the same semantics for temporary tablespaces as for permanent tablespaces. Refer to tablespace_encryption_clause in the documentation on permanent tablespaces for full information.
ALTER TABLESPACE and «Adding a Temporary Tablespace to a Tablespace Group: Example» for information on adding a tablespace to a tablespace group
CREATE USER for information on assigning a temporary tablespace to a user
Oracle Database Administrator’s Guide for more information on tablespace groups
Restrictions on Temporary Tablespaces
These examples assume that your database is using 8K blocks.
Creating a Bigfile Tablespace: Example
The following example creates a bigfile tablespace bigtbs_01 with a data file bigtbs_f1.dbf of 20 MB:
Creating an Undo Tablespace: Example
The following example creates a 10 MB undo tablespace undots1 :
Creating a Temporary Tablespace: Example
This statement shows how the temporary tablespace that serves as the default temporary tablespace for database users in the sample database was created:
Assuming that the default database block size is 2K, and that each bit in the map represents one extent, then each bit maps 2,500 blocks.
The following example sets the default location for data file creation and then creates a tablespace with an Oracle-managed temp file in the default location. The temp file is 100 M and is autoextensible with unlimited maximum size. These are the default values for Oracle Managed Files:
Adding a Temporary Tablespace to a Tablespace Group: Example
The following statement creates the tbs_temp_02 temporary tablespace as a member of the tbs_grp_01 tablespace group. If the tablespace group does not already exist, then Oracle Database creates it during execution of this statement:
Creating Basic Tablespaces: Examples
This statement creates a tablespace named tbs_01 with one data file:
This statement creates tablespace tbs_03 with one data file and allocates every extent as a multiple of 500K:
Enabling Autoextend for a Tablespace: Example
This statement creates a tablespace named tbs_02 with one data file. When more space is required, 500 kilobyte extents will be added up to a maximum size of 100 megabytes:
Creating a Locally Managed Tablespace: Example
The following statement assumes that the database block size is 2K.
This statement creates a locally managed tablespace in which every extent is 128K and each bit in the bit map describes 64 blocks.
The following statement creates a locally managed tablespace with uniform extents and shows an example of a table stored in that tablespace:
The initial segment size of the table is 2M.
The following example creates a locally managed tablespace without uniform extents:
The initial segment size of the table is 2M. Oracle Database determines the size of each extent and the total number of extents allocated to satisfy the initial segment size. The segment’s maximum size is limited to 100M.
Creating an Encrypted Tablespace: Example
In the following example, the first statement enables encryption for the database by opening the wallet. The second statement creates an encrypted tablespace.
Specifying Segment Space Management for a Tablespace: Example
The following example creates a tablespace with automatic segment-space management:
Creating Oracle Managed Files: Examples
The following example sets the default location for data file creation and creates a tablespace with a data file in the default location. The data file is 100M and is autoextensible with an unlimited maximum size:
The following example creates a tablespace with an Oracle-managed data file of 100M that is not autoextensible:
