Extended and restricted rowid in Oracle

A tablespace in Oracle is like a container for holding the physical data files of a database. It's a logical storage unit in an Oracle database and it's where all the tables, indexes, and other objects are stored.
So why do we need to manage tablespaces? Let us say you are moving into a new house. You wouldn't just toss all your stuff into the house randomly, right? You would organize it, room by room. Similarly, tablespace management involves organizing and allocating space for your database objects. It is crucial for maximizing performance, preventing storage issues, and keeping your data safe and accessible. Now, tablespace extent management is a related but different beast. Think of extents as smaller storage blocks within your tablespaces - like boxes in the rooms of your new house. Oracle allocates space for segments in a tablespace in units of one or more extents. When a segment grows and needs more space, Oracle allocates another extent.
There are two methods for managing extents: Dictionary Managed Extents and Locally Managed Extents. In the old days, we used to have Dictionary Managed Extents, where the data dictionary held all the information about the extents. But this method had its drawbacks, like contention for resources and increased complexity. Then Oracle introduced Locally Managed Extents, which keep track of their own free and used space, reducing contention and simplifying space management. It's like giving each room in your house the power to manage its own space!
So, while tablespace management and tablespace extent management might sound similar, they're actually two sides of the same coin. Tablespace management is about overseeing the overall storage of your database objects. Tablespace extent management, on the other hand, is more granular and focuses on how that storage is allocated and organized within the tablespace. By effectively managing both, you can ensure that your Oracle 13c database operates efficiently and remains flexible to the needs of the data it stores. It's a bit like keeping a well-organized, smoothly running house, where every item has its own place and every room knows exactly how much space it has.

Because you have either taken other courses about Oracle administration or have some on-the-job experience with it, you already understand how tablespaces fit into the Oracle architecture. This lesson discusses two key concepts in tablespace management. The contents of the

1. rowid and
2. the methods of tablespace extent management.

The rowid contains a record location. In legacy Oracle databases, the rowid was formatted in an absolute address that was tied to the database. In Oracle, this format, called the restricted rowid, is kept only for backward compatibility. An extended rowid is the new Oracle format for rowid. All rows created in an Oracle database use the extended rowid. The extended rowid is a tablespace-relative address for a record, which makes the rowid portable across databases. The primary purpose for revising the format of the rowid is to enable transportable tablespaces. Transportable tablespaces are covered later in this module.

Once you have created a tablespace master encryption key and have opened the wallet and the database, you can create an encrypted tablespace. When using the create tablespace command, you can specify the encryption algorithm and key length for the encryption. The encrypt keyword in the default storage clause tells Oracle to encrypt the tablespace.

create tablespace ENCR_TSPACE
datafile '/u01/oradata/CC1/secure01.dbf'
size 200m
encryption using 'aes128'
default storage(encrypt);

In this example, the tablespace is encrypted using the AES algorithm, with a key length of 128 bits. The default encryption algorithm is AES128 .
Any table you now create in the ENCR_TSPACE tablespace will be encrypted. Aside from specifying the tablespace, you do not need to modify any of your application code to take advantage of this feature. To see if your tablespaces are encrypted, query the Encrypted column of the DBA_TABLESPACES data dictionary view. You cannot encrypt an existing tablespace. If the objects you need to encrypt are already stored within the database, use the move clause of the alter table command to move them to the encrypted tablespace. If enough space is available, you may be able to use the create table as select command to create a new encrypted table based on an existing unencrypted table. Regardless of the approach you choose, wallet-based security provides an important tool for securing your data without changing your application code. Additional security features available for Oracle DBAs include encrypted backups and secure files.

A new type of rowid called the logical rowid is used to track the location of rows in index-organized tables.
Rows in an index-organized table can move to a different physical location when new rows are inserted or old rows are deleted. Therefore, a traditional rowid (containing the physical location of the record) does not serve the purpose intended for a rowid (a permanent and direct locator of the row). The logical rowid solves this problem by storing information about location that includes primary key information rather than physical block information.
To use this kind of rowid in your PL/SQL code, use the UROWID data type.

The biggest change in the sizing of a tablespace is the capability to choose between two methods of tablespace sizing and extent management:

1. The traditional method, called dictionary managed, which uses the database dictionary to track data blocks and allocate extents. This is the default method.
2. The new method, called locally managed, which uses the tablespace itself to track data blocks and allocate extents. This method can be more efficient because it reduces calls to the database dictionary.

The new method is featured in the next lesson.
In the next lesson you will find out all about locally managed tablespaces and how to create them.