CERTIFICATION OBJECTIVES

7.01 Explain How Oracle Database Server Automatically Manages Space

7.02 Save Space by Using Compression
7.03 Proactively Monitor and Manage Tablespace Space Usage
7.04 Use the Segment Advisor
7.05 Reclaim Wasted Space from Tables and Indexes by Using the Segment Shrink
Functionality
7.06 Manage Resumable Space Allocation
Two-Minute Drill
Q&A Self Test

S pace management in an Oracle database can be (and usually should be) largely
automatic. The DBA creates tablespaces consisting of one or more datafiles, gives the
developers a quota on the tablespaces, and Oracle takes care of everything from then on.
It is, however, important to understand how space is assigned to segments and within
segments, as well as how to monitor space usage. Also, some facilities will permit more
efficient use of space, such as compression and segment reorganization through the
segment shrink capability.
When a user hits a space limit, an error will be returned and the statement that hit the
limit will fail. This situation should of course be avoided, but if it does occur the user can
be protected by enabling the resumable space allocation facility.
CERTIFICATION OBJECTIVE 7.01
Explain How Oracle Database Server Automatically Manages Space
Space is managed at three levels: the tablespace, the segment, and the block. Assigning
space to tablespaces by creating and modifying datafiles was discussed in Chapter 6.
Once these physical structures are in place, management moves to the logical level: how
space is assigned to segments, and how space is used within segments. Figure 6-
1 in Chapter 6 describes the Oracle storage model. If this is not completely clear, review
the associated material before proceeding.
Extent Management
Space is allocated to a segment in the form of an extent, which is a set of consecutive
Oracle blocks. Every datafile has a bitmap that describes the state of the block in the file:
whether it is free or are a part of an extent that has been assigned to a segment. When a
segment fills up and needs to extend, Oracle will search the bitmaps of the files of the
tablespace for free space, select one file, and create a new extent of an appropriate size
by modifying the bitmap. The extent can then be assigned to the segment.
A segment is a container for an object, but the two are not the same thing: it is possible
for the object to exist without a segment. When a segment is first created, it will have at
least one extent—but it is possible for some objects to exist without a segment. Study the
code in Figure 7-1. The first two queries show the tables (four) and indexes (two) in the
currently logged-on schema, with the flag that shows whether a segment has been
created for them. The third query shows the segments. The table BONUS exists logically,
but has no segment within which it can be contained.
FIGURE 7-1 Objects and segments

Deferred segment creation can have some odd effects. For example,
problems with a quota will not show up when creating a table—only when
inserting into it.
The key to understanding this situation is the instance parameter
DEFERRED_SEGMENT_CREATION, which defaults to TRUE. If set to TRUE, this
parameter instructs Oracle not to create a segment until the object actually contains
some data. At table creation time, only the data dictionary structure describing the table
is created. Only subsequently, when an attempt is made to insert a row into the table, is
the segment created. It is possible to control this behavior, and to override the
parameter setting, with the SEGMENT CREATION clause of the CREATE TABLE
statement. Figure 7-2 demonstrates this, showing that a segment is created consisting of
one extent when a row is inserted into a table.
FIGURE 7-2 Deferred segment creation

Segment creation is always immediate for objects created by internal users such as SYS or
SYSTEM, no matter what the setting of the parameter. Attempting to use the SEGMENT
CREATION DEFERRED clause as SYS returns an error.
EXERCISE 7-1
Segment Space Management
In this exercise, you observe the allocation of extents to segments.
1. Connect to the database as user SYSTEM.
2. Create a schema to work in for this exercise and then connect to it:
 3. Check that the DEFERRED_SEGMENT_CREATION parameter is set to TRUE,
which is the default, and set it if it is not:

4. Create tables and indexes as follows:

5. Determine what segments have been created:

6. Insert a row into EX7A and EX7B.

7. Run the queries from step 5 again.

Automatic Segment Space Management (ASSM)

A table segment consists of multiple blocks, in one or more extents. When an attempt is
made to insert a row into the table, Oracle must make a decision: into which block
should the row be placed? This is determined by a bitmap that reflects how full each
block in the segment is. By inspecting the bitmap, Oracle can determine whether a block
has sufficient space to accept the new row. The mapping is not precise, but rather works
in 25-percent ranges: between 0 and 25 percent free space; 25 to 50 percent free space;
50 to 75 percent free space; and 75 to 100 percent free space. In addition, the bitmap
shows whether the block is not actually formatted at all (that is, it is assigned to the
segment but has not yet been used) or is classed as full and is therefore not available for
inserts no matter how small the new row is.
As rows are inserted into blocks and deleted from blocks, the status of the block (in
terms of to which of the 25-percent bands it belongs) is adjusted in the bitmap.
A problem related to the selection of a block for an insert is how to manage the situation
where a row changes size. Some Oracle data types are of variable length: principally, the
VARCHAR2 data type. If a VARCHAR2 column is updated such that it becomes longer,
the row will become longer. Furthermore, if any columns are NULL when a row is
inserted, they will take no space at all. It follows from this that when UPDATE
statements are executed that expand a VARCHAR2 or populate a previously NULL
column, the row will become bigger. It will therefore require more space in the block.
By default, Oracle reserves 10 percent of a block for row expansion. This is the
PCTFREE (percent free) setting for the segment, set at segment creation time (though it
can be modified later). A block whose usage has exceeded the PCTFREE setting for the
segment is classed by the ASSM bitmap as FULL, and therefore the block is not available
for insert even though it may in fact still have some free space. So if, on average, the
rows in a block increase by no more than 10 percent during their lifetime, there is no
problem: enough space will be available for the new versions of the rows. If a row
expands such that there is not sufficient space in the block, it must be moved to a block
with sufficient space. This is known as row migration.

Row migration is caused by UPDATE statements. INSERT and DELETE can never result in
row migration.
When a row is migrated, it is removed from the block in which it resides, and inserted
into a different block with sufficient space. The new block will be located by searching
the ASSM bitmap. So in effect, when a user executes an UPDATE, this becomes an
INSERT and DELETE: a more expensive operation. Furthermore, the ROWID of the
row (the physical locator of the row) is not changed. The ROWID still points to the
original block, which now stores no more than a “forwarding address” for the row: the
address of the block to which the row has been moved. The fact that the ROWID
remains unchanged is good and bad. It is good because there is no need to adjust any
indexes: they will still point to the original location. It is bad because when the row is
retrieved through an index search, an extra I/O operation will be needed to read the row
from its new location. This is, of course, transparent to SQL but may in extreme
circumstances result in performance degradation.
Closely related to row migration is the issue of row chaining. A chained row is a row that
is larger than the block. Clearly, if the blocksize is 8K and the row is 20K, then the row
must be distributed across three blocks. At insert time, all three blocks will be located by
searching the ASSM bitmap for blocks available for insertion, and when retrieving the
row later all three blocks may be read (depending on which columns are projected by
the query). The ROWID of a chained row points to the first block of the row, as is also
the case with a migrated row.
CERTIFICATION OBJECTIVE 7.02
Save Space by Using Compression
Compression comes in various forms, some of which require a separate license: the
Advanced Compression option. The primary purpose of compression is to reduce disk
space requirements, but there is sometimes a fringe benefit: improved performance for
subsequent queries. Compression may, however, cause performance degradation in
some circumstances, and should therefore be approached with caution. An advisor
capability will estimate the space savings that compression can achieve for a table.
Compression comes in three forms:
Basic table compression compresses data within a block when rows are inserted
through a direct load operation. Subsequent DML operations will cause the rows to be
uncompressed (and possibly migrated as a result of this).
 Advanced row compression will compress rows no matter how they are inserted, and
maintain the compression though DML. The compression is still on a block-by-block
basis.
Hybrid Columnar Compression (HCC) restructures data into compression units of
several megabytes, and is available only on certain storage platforms.
Basic compression (which is the default type) is in fact de-duplication. If a repeating
pattern of characters occurs within a block, the pattern is stored once only in a symbol
table, with a reference to the symbol table stored in each row where the pattern occurs.
Advanced row compression uses the same de-duplication technology. Either way, the
compression is per block: the symbol tables are not usable outside of the block in which
they exist. HCC is true compression, in that it uses compression algorithms to reduce
the space needed to store data. HCC is not applied per block, but across groups of
blocks, which further enhances the achievable compression ratios.
The type of compression is determined at table creation time. Compression can be
added or removed after creation, but any such change will not affect existing rows. To
bring the change into effect, the table must be reorganized. Typically, this would be
accomplished with an ALTER TABLE…MOVE statement.
The syntax to create a table with basic or advanced compression is a normal creation
statement, with a suffix specifying the compression type:

EXERCISE 7-2
Investigate Compression
In this exercise, you determine the effects of compression on storage requirements.
1. Connect to the EX7 schema created in the previous exercise.
2. Adjust a table to use basic compression:

3. Insert 100,000 rows into the compressed and uncompressed tables, using a direct
load:

4. Analyze the tables, and note the number of blocks used:

Note the effect of compression.

5. Update the rows:

6. Rerun the code from step 4. What does this tell you about basic compression and
DML? Note that to preserve the compression ratio, rather than have it degrade to even
worse than no compression at all, it would be necessary to implement advanced
compression, not basic compression.

CERTIFICATION OBJECTIVE 7.03

Proactively Monitor and Manage Tablespace Space Usage
The database will automatically monitor tablespace usage, through the server alert
system. Figure 7-3 shows a query against the DBA_THRESHOLDS view.
FIGURE 7-3 Tablespace thresholds and usage

The first two lines of the output for Figure 7-3 show the system-generated thresholds for
a temporary tablespace and the undo tablespace: tablespaces of these types are not
monitored. This is because a simple check of free space is useless for tablespaces of
these types, as they are usually fully occupied by temporary or undo segments. What
matters is whether the temporary or undo segments within them are full: this is a more
complex metric that is not configured by default.
The third line of the query’s output shows the database-wide default alerts for all
tablespaces that do not have an alert explicitly configured. The warning alert is set at
greater than or equal to 85 percent, and the critical alert at greater than or equal to 97
percent.
In addition to the alert system, which will inform you of issues according to
preconfigured thresholds, Oracle maintains a history of tablespace usage. This is stored
in the AWR, the information being gathered as part of the AWR snapshots created by
the MMON process. This information can be seen in the
DBA_HIST_TBSPC_SPACE_USAGE view. The second query in Figure 7-3 joins this
view to the V$TABLESPACE view (the join is necessary to retrieve the tablespace name)
and shows the history of space usage for each tablespace. Note that there is one row per
tablespace per snapshot. It can be seen that the snapshot frequency has been set to every
15 minutes and that (in the few lines displayed) there was no change in the usage within
the EXAMPLE tablespace.
You may wish to write your own reporting code that queries
DBA_HIST_TBSPC_SPACE_USAGE to gain a picture of how space is being
used in the database, so that you can add space to tablespaces before
alerts are raised.
CERTIFICATION OBJECTIVE 7.04
Use the Segment Advisor
The Segment Advisor is a tool that attempts to generate recommendations regarding
reorganizing segments to reclaim space. The issue is that over time, in some
circumstances, table and index segments may become larger than is necessary for the
amount of data contained within them.
An obvious example is many rows having been deleted. Deletion frees up space within
the segment, but the segment itself remains the same size. This will affect the table
segment and all associated index segments. In most cases, if space has ever been
assigned to a segment, then even if it is not needed now, it will be needed again. For
example, the process of loading data into data warehouse tables often involves inserting
many rows into a staging table, processing and deleting them. But even though the table
may be empty at the end of the day’s run, all the space will be needed again the next day.
It is therefore not enough to examine the current state of a table to determine if it is
excessively large: one must also consider the history of space usage. The Segment
Advisor can do this. It considers data in the AWR as well as the current state of the
objects. The recommendations are based on a sampled analysis of the object, and also
historical information used to predict future growth trends.
The Segment Advisor runs, by default, every night as an autotask scheduled job. The
autotask does not attempt to analyze every segment. It selects segments on these
criteria:
Segments in tablespaces that have crossed a space usage threshold
Segments that have had the most activity
Segments that have the highest growth rate
To see the results of the autotask, use the DBMS_SPACE.ASA_RECOMMENDATIONS
function. This function returns a table with the results of the last run. Figure 7-4 shows
an example of querying the result of the Segment Advisor autotask, followed by the
commands that implement its recommendations.
FIGURE 7-4 Retrieving and implementing the Segment Advisor’s autotask advice
The Segment Advisor autotask runs by default. Many DBAs never look at
its advice. You should either look at the results or disable the task.
CERTIFICATION OBJECTIVE 7.05
Reclaim Wasted Space from Tables and Indexes by Using the Segment
Shrink Functionality
When a row is deleted, the space it was occupying in its block becomes available for
reuse when another row is inserted. However, the nature of the activity against a table
can result in a significant amount of wasted space within the table. This could be
reclaimed with a MOVE operation: following a move, all the blocks will be consecutively
full of freshly reinserted rows. But during the move, the table is locked, and following it
all the indexes must be rebuilt. For many environments, this makes use of MOVE to
reorganize tables impossible. The SHRINK command avoids these problems. It can be
run without any impact on end users. A limitation is that the table’s tablespace must
have been created to use automatic segment space management. Tables in tablespaces
that use the older freelist technique for managing segment space usage cannot be
shrunk, because (unlike the new bitmap method) the freelist does not include sufficient
information for Oracle to work out how full each block actually is.
The underlying implementation of a table shrink is to relocate rows from the end of the
table into blocks toward the beginning of the table, by means of matched INSERT and
DELETE operations, and then, when all possible moves have been done, to bring the
high water mark of the table down to the last currently used block and release all the
space above this point. There are two distinct phases: the compact phase moves the rows
in a series of small transactions, through normal DML that generates both undo and
redo and uses row locks. The second phase is a DDL command. As with any DDL
command, this is a transaction against the data dictionary: it will execute almost
instantaneously, but will require a very short table lock. This last step is often referred to
as “relocating the high water mark (HWM) of the segment.”

A table shrink operation generates undo and redo. Indexes are maintained, because the shrink
is implemented as a set of DML transactions. There is no table lock during the compaction,
but individual rows will be locked while they are being moved.
The syntax of the SHRINK SPACE command is as follows:

Using the keyword COMPACT carries out the first phase, but not the second: the rows
are relocated, but the space is not actually released from the segment. The reason for
using this is that while the compaction can occur during normal running hours (though
it may take many hours to complete on a large table), it is possible that the DDL at the
end will hang due to concurrency with other transactions, and it will also invalidate
parsed SQL in the library cache. So it may be necessary to shrink the table with the
COMPACT keyword first, and then again without COMPACT during a maintenance
period: it will be fast, because the compaction will have already been done. The
CASCADE keyword instructs Oracle also to shrink dependent objects, such as indexes.
Before a table can be shrunk, you must enable row movement for the table:

The SHRINK SPACE COMPACT command reorganizes the contents of the segment, but does
not return space to the tablespace.
Enabling row movement is necessary because the nature of the operation means that
row IDs will be changing. The same row (no change to the primary key) will be in a
different physical location and will therefore have a different row ID. This is something
that Oracle will not permit unless row movement has been enabled.

A table must be in a tablespace with automatic segment space management and row movement
must have been enabled, or it cannot be shrunk. If these conditions have not been met, a
MOVE may be the only way to reorganize the table.
Figure 7-4 shows enabling row movement for a table, followed by a SHRINK SPACE
that reclaims space from both the table and its index.
Compression is incompatible with SHRINK SPACE: you will need to
uncompress before shrinking. To do this, use ALTER
TABLE…NOCOMPRESS and ALTER TABLE…MOVE.
CERTIFICATION OBJECTIVE 7.06
Manage Resumable Space Allocation
Many operations can fail for reasons of inadequate space. This typically shows up as an
inability to add another extent to a segment, which itself can have several causes: a
datafile could be full; an auto-extensible datafile or tempfile could be on a disk that is
full; an undo segment could be in an undo tablespace that is full; an operation requiring
temporary space could be using a temporary tablespace that is full; or a user could have
reached their quota limit on a tablespace. Whatever the reason, space-related errors
tend to be dreadfully time consuming.
Consider an exercise to load data into a data warehouse. The first time you attempt this,
it fails because the destination tablespace runs out of space. The data that did go in must
be rolled back (which may take as long as the insert), the tablespace extended, and the
load done again. Then it fails because of inadequate undo space; therefore, you roll back,
increase the undo tablespace, and try again. Then it fails during index rebuilding,
because of a lack of temporary space. And so on. Exercises such as this are the bane of
many DBAs’ lives. The resumable space allocation feature can be the solution.
If you enable resumable space allocation, when an operation hits a space problem (any
space problem at all), rather than failing with an error (and in many cases rolling back
what it did manage to do) the operation will be suspended. To the user, this will show as
the session hanging. When the error condition is resolved, it will continue. All
suspended sessions (currently suspended and previously suspended but now running
again) are listed in the view DBA_RESUMABLE.
To enable resumable space allocation at the session level, the command is

The TIMEOUT option lets you specify for how long the statement should hang. If this
time is reached without the problem being resolved, the error is returned and the
statement fails. If there is no specified TIMEOUT, the session will hang indefinitely.

It is possible for a process to be suspended and resumed many times,

without your knowledge. The DBA_RESUMABLE view will show you
details of the current or the last suspension only.
It is also possible to enable resumable space for all sessions, by setting an instance
parameter. This is a dynamic parameter. For example, here is how to set a timeout of
one minute:

This will cause all sessions that hit a space problem to be suspended for up to one
minute.
The expdb and impdp Data Pump utilities have the command-line switch
RESUMABLE=Y (the default is N), which will allow Data Pump jobs to
suspend if they hit space problems. This is extremely useful.
There is little point in enabling resumable space allocation for a session or the instance
if you don’t do anything about the problem that caused a session to be suspended.
Suspended sessions will, by default, be reported through the server alert system, be
displayed by Database Control, and be listed in the DBA_RESUMABLE data dictionary
view. Having spotted a problem, you can fix it interactively from another session. Or you
can create an AFTER SUSPEND ON DATABASE trigger, which that will run whenever a
session is suspended. This trigger could report the problem (perhaps by generating an e-
mail), or it could include code to investigate the problem and fix it automatically.

The UTL_MAIL package is not available by default. You must create it by

running the utlmail.sql and prvtmail.plb scripts.
For example, here is how to send an e-mail:

If you create an AFTER SUSPEND ON DATABASE trigger that attempts to

fix problems, remember that it might hit a space problem itself.
EXERCISE 7-3
Use Resumable Space Allocation
In this exercise, you will set up a space allocation problem and enable resumable space
allocation to gain the opportunity to fix it without an error.
 1. Connect to your database as user SYSTEM and create a tablespace to use for this
exercise. Here is how with SQL*Plus:

2. Create a table in the tablespace, with fixed-length rows. It will be impossible to

insert 2,000 rows without filling the tablespace:

3. Run this query to force an error:

The illustration shows steps 1, 2, and 3.

4. Note the error ORA-01653.

5. Alter the session to enable resumable space allocation:

6. Rerun the code from step 3. The session will hang.

7. Start another SQL*Plus session, connected as SYSTEM, and run this query:

Note that the ERROR_NUMBER column is reporting the error that would have been
returned to the session, had it not been suspended.
8. From your second SQL*Plus session, fix the problem:

9. Observe that the query from step 6 will now complete successfully, with no
intervention required.
10. Tidy up by dropping the tablespace:

CERTIFICATION SUMMARY
This chapter describes the facilities within the database for managing space. Space
management can be largely automatic. Space is allocated to segments on demand, in the
form of extents. The extent size can be determined by the server, or fixed at a uniform
size for all extents in the tablespace. Space within segments is used in the most efficient
manner possible, using bitmaps that track the space usage of each block.
Compression can reduce the size of objects considerably. Basic compression works only
for direct loads: rows inserted or updated by subsequent INSERT or UPDATE
operations will not be compressed. Advanced row compression can maintain
compression for all rows in all circumstances.
The Segment Advisor runs every night, as an autotask. It never implements its
recommendations, but will detect segments where reorganization would result in a
space saving. One method of reorganizing is to use the SHRINK SPACE command,
which will compact all rows of a table into as few blocks as possible. By default, SHRINK
SPACE will continue by releasing the free space from the segment and returning it to the
tablespace for reuse elsewhere. The COMPACT keyword prevents this final step: the
rows are compacted, but the space is not released. The CASCADE keyword propagates
the shrink operation to all dependent objects, such as indexes.
If a statement hits a space error, it will fail, and any work it did will be rolled back.
Enabling the resumable space allocation mechanism causes the statement to hang
rather than fail, and to continue execution once the problem is fixed.

TWO-MINUTE DRILL
Explain How Oracle Database Server Automatically Manages Space
Space is allocated to segments, on demand, in the form of extents. Extent usage is
tracked by bitmaps.
Space usage within a segment is tracked, in 25-percent bands, by bitmaps.
Save Space by Using Compression
Basic compression de-duplicates data when inserted through a direct load.
Advanced row compression can maintain the de-duplication compression through
conventional DML.
Proactively Monitor and Manage Tablespace Space Usage
The Server Alert system is preconfigured to raise alerts when a tablespace is 85-
percent full (warning) and 97-percent full (critical).
Alerts are not raised for temporary or undo tablespaces.
Alert thresholds can be configured at any value for any tablespace individually.
Use the Segment Advisor
The Segment Advisor runs every night as an autotask.
The advice will be to shrink a table, if so doing would release a significant amount of
space.
The Segment Advisor considers historical usage as well as the current usage.
Reclaim Wasted Space from Tables and Indexes by Using the Segment
Shrink Functionality
A table shrink operation relocates rows toward the front of the segment, and (by
default) releases free space at the end.
A shrink is an online and in-place operation: it requires no additional space while
running, and the table is not locked against other DML.
Manage Resumable Space Allocation
 Resumable space allocation can be enabled for a session or for the instance.
If a session hits a space error, it will hang until the problem is fixed—or until a
timeout expires.
A database trigger can be configured to fire whenever a session is suspended.

SELF TEST
Explain How Oracle Database Server Automatically Manages Space
1. Which statements are correct about extents? (Choose all correct answers.)
A. An extent is a consecutive grouping of Oracle blocks.
B. An extent is a random grouping of Oracle blocks.
C. An extent can be distributed across one or more datafiles.
D. An extent can contain blocks from one or more segments.
E. An extent can be assigned to only one segment.
2. Which of these are types of segment? (Choose all correct answers.)
A. Sequence
B. Stored procedure
C. Table
D. Table partition
E. View
Save Space by Using Compression
3. Which form of compression uses compression algorithms rather than de-
duplication algorithms? (Choose the best answer.)
A. Compression implemented with COMPRESS BASIC.
B. Compression implemented with ROW STORE COMPRESS ADVANCED.
C. Hybrid Columnar Compression.
D. All Oracle compression methods use compression algorithms.
E. All Oracle compression methods use de-duplication algorithms.
Proactively Monitor and Manage Tablespace Space Usage
4. You receive an alert warning you that a tablespace is nearly full. What action could
you take to prevent this becoming a problem, without any impact for your users?
(Choose two correct answers.)
A. Purge all recycle bin objects in the tablespace.
B. Shrink the tables in the tablespace.
C. Shrink the indexes in the tablespace.
D. Move one or more tables to a different tablespace.
E. Move one or more indexes to a different tablespace.
5. Which process is responsible for sending the alert when a tablespace usage critical
threshold is reached? (Choose the best answer.)
A. Database Control
B. The DBMS_SERVER_ALERT package
C. MMON, the Manageability Monitor process
D. The server process of the session that detected the problem
E. DBWn, the Database Writer, when it detects the problem
Use the Segment Advisor
6. When will the Segment Advisor run? (Choose two correct answers.)
A. Every night, as an autotask
B. On demand
C. Automatically when a tablespace crosses a threshold for space usage
D. Automatically when a session is suspended by the resumable space allocation
mechanism
Reclaim Wasted Space from Tables and Indexes by Using the Segment
Shrink Functionality
7. Which of the following commands will shrink space in a table or index segment and
relocate the HWM?
A. alter table employees shrink space compact hwm;
B. alter table employees shrink space hwm;
C. alter table employees shrink space compact;
D. alter table employees shrink space;
E. alter index employees shrink space cascade;
8. What is required before shrinking a table? (Choose all that apply.)
A. Triggers must be disabled
B. Indexes must be dropped.
C. Row movement must be enabled.
D. Automatic segment space management must be enabled.
E. LOB columns must be dropped.
Manage Resumable Space Allocation
9. How can you enable the suspension and resumption of statements that hit space
errors? (Choose all the correct answers.)
A. Issue an ALTER SESSION ENABLE RESUMABLE command.
B. Issue an ALTER SYSTEM ENABLE RESUMABLE command.
C. Set the instance parameter RESUMABLE_STATEMENTS.
D. Set the instance parameter RESUMABLE_TIMEOUT.
E. Use the DBMS_RESUMABLE.ENABLE procedure.
10. If a statement is suspended because of a space error, what will happen when the
problem is fixed? (Choose the best answer.)
A. After the resumable timeout has expired, the statement will continue executing from
the point it had reached.
B. After the resumable timeout has expired, the statement will start executing from the
beginning again.
C. The statement will start executing from the beginning immediately after the problem
is fixed.
D. The statement will continue executing from the point it had reached immediately
after the problem is fixed.
LAB QUESTION
Create a table containing 100,000 rows, all of which are different, and another table
with the same number of identical rows. Analyze the tables to determine how many
blocks they occupy:
How many blocks do the tables occupy? Enable compression for the tables. What
compression ratio do you achieve?
Delete all the rows from one table, and truncate the other table. How many blocks do
they occupy now? How would you reduce this?

SELF TEST ANSWERS

Explain How Oracle Database Server Automatically Manages Space
1. A and E. One extent is several consecutive Oracle blocks, and one segment
consists of one or more extents.
B, C, and D are incorrect. They misinterpret the Oracle storage model.
2. C and D. A table can be a type of segment, and so can a table partition.
A, B, and E are incorrect. These exist only as objects defined within the data
dictionary. The data dictionary itself is a set of segments.
Save Space by Using Compression
3. C. Hybrid Columnar Compression is true compression.
A, B, D, and E are incorrect. A and B are incorrect because both BASIC and
ADVANCED compression are in fact based on de-duplication. D and E are incorrect
because Oracle can use either technique.
Proactively Monitor and Manage Tablespace Space Usage
4. A and B. Both purging dropped objects and shrinking tables will release space
immediately, with no downtime.
C, D, and E are incorrect. An index can be shrunk, but this will release space within
the index, not return it to the tablespace. Relocating either indexes or tables has
implications for the availability of the data.
5. C. The MMON background process raises alerts.
A, B, D, and E are incorrect. A is incorrect because although Database Control
reports alerts, it does not raise them. B is incorrect because the
DBMS_SERVER_ALERT API is used to configure the alert system—it does not
implement it. D and E are incorrect because foreground and background processes will
encounter problems, not warn of their imminence.
Use the Segment Advisor
6. A and B. Unless the autotask has been disabled, it will run in every
maintenance window. It can also be invoked on demand.
C and D are incorrect. C is incorrect because although a tablespace usage alert will
cause the autotask to analyze all objects in the tablespace in the next maintenance
window, this does not happen when the alert is raised. D is incorrect because the only
action triggered by suspension of a session is running the AFTER SUSPEND ON
DATABASE trigger.
Reclaim Wasted Space from Tables and Indexes by Using the Segment
Shrink Functionality
7. D. SHRINK SPACE both compacts the data and moves the HWM. While the
HWM is being moved, DML operations on the table are blocked.
A, B, C, and E are incorrect. A, B, and E are syntactically incorrect. C is incorrect
because COMPACT only performs the shrink operation but does not move the HWM
after shrinking the segment.
8. C and D. Row movement is necessary, because a shrink will change row IDs.
ASSM is needed in order to give the necessary information on how full a block is.
A, B, and E are incorrect. A is incorrect because triggers will not fire for the
operation: they will continue to fire for any other DML. B is incorrect because indexes
are maintained during a shrink. E is incorrect because LOB segments will not block a
table shrink. They will be shrunk themselves if CASCADE is specified.
Manage Resumable Space Allocation
9. A and D. These are the only two methods to enable resumable space allocation.
B, C, and E are incorrect. B and C are incorrect because resumable space allocation
is enabled at the system level with the instance parameter
RESUMABLE_TIMEOUT. E is incorrect because although there is a package called
DBMS_RESUMABLE, it does not (rather annoyingly) include a procedure to enable
resumable space allocation.
10. D. As “suspended” implies, the statement will continue from the point at which
it stopped.
A, B, and C are incorrect. The timeout controls how long the suspension can last
before returning an error: it is the period during which the problem can be fixed.
LAB ANSWER
Here is a possible solution: