Tablespace: Difference between revisions
No edit summary |
Seanohagan (talk | contribs) mNo edit summary |
||
Line 15: | Line 15: | ||
</ref> and serves to allocate storage for all [[DBMS]] managed segments. (A database segment is a database object which occupies physical space such as [[table (database)|table]] data and [[index (database)|indexes]].) Once created, a tablespace can be referred to by name when creating database segments. |
</ref> and serves to allocate storage for all [[DBMS]] managed segments. (A database segment is a database object which occupies physical space such as [[table (database)|table]] data and [[index (database)|indexes]].) Once created, a tablespace can be referred to by name when creating database segments. |
||
Tablespaces specify only the database storage locations, not the logical database structure, or [[logical schema|database schema]]. For instance, different objects in the same schema may have different underlying tablespaces. Similarly, a tablespace may service segments for more than one schema. Sometimes it can be used to specify schema as to form a bond between logical and |
Tablespaces specify only the database storage locations, not the logical database structure, or [[logical schema|database schema]]. For instance, different objects in the same schema may have different underlying tablespaces. Similarly, a tablespace may service segments for more than one schema. Sometimes it can be used to specify schema as to form a bond between logical and physical data. |
||
By using tablespaces, an administrator can control the disk layout of an installation. A common use of tablespaces is to optimize performance. For example, a heavily used index can be placed on a fast [[SCSI]] [[Hard disk|disk]]. On the other hand, a database table which contains archived data that is rarely accessed could be stored on a less expensive but slower [[Advanced Technology Attachment|IDE]] disk. |
By using tablespaces, an administrator can control the disk layout of an installation. A common use of tablespaces is to optimize performance. For example, a heavily used index can be placed on a fast [[SCSI]] [[Hard disk|disk]]. On the other hand, a database table which contains archived data that is rarely accessed could be stored on a less expensive but slower [[Advanced Technology Attachment|IDE]] disk. |
Revision as of 01:14, 26 February 2014
This article needs additional citations for verification. (December 2009) |
A tablespace is a storage location where the actual data underlying database objects can be kept. It provides a layer of abstraction between physical and logical data,[1] and serves to allocate storage for all DBMS managed segments. (A database segment is a database object which occupies physical space such as table data and indexes.) Once created, a tablespace can be referred to by name when creating database segments.
Tablespaces specify only the database storage locations, not the logical database structure, or database schema. For instance, different objects in the same schema may have different underlying tablespaces. Similarly, a tablespace may service segments for more than one schema. Sometimes it can be used to specify schema as to form a bond between logical and physical data.
By using tablespaces, an administrator can control the disk layout of an installation. A common use of tablespaces is to optimize performance. For example, a heavily used index can be placed on a fast SCSI disk. On the other hand, a database table which contains archived data that is rarely accessed could be stored on a less expensive but slower IDE disk.
While it is common for tablespaces to store their data in a filesystem file, a single file must be part of a single tablespace. Some database management systems allow tablespaces to be configured directly over operating-system device entries, called raw devices, providing better performance by avoiding the OS filesystem overheads.
Oracle stores data logically in tablespaces and physically in datafiles associated with the corresponding tablespace.
References
- ^
Oppel, Andrew J. (2009). Databases: a beginner's guide. McGraw Hill Professional. p. 44. ISBN 978-0-07-160846-6. Retrieved 2011-05-23.
[...] a logical file that forms a layer of abstraction between the physical and logical layers, thereby providing better logical data independence.