OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P23 pot

OCA/OCP Oracle Database 11g All-in-One Exam Guide
176
• LOBSEGMENT, LOBINDEX, LOB PARTITION If a column is defined as a
large object data type, then only a pointer is stored in the table itself: a pointer
to an entry in a separate segment where the column data actually resides.
LOBs can have indexes built on them for rapid access to data within the
objects, and LOBs can also be partitioned.
• CLUSTER A cluster is a segment that can contain several tables. In contrast
with partitioning, which lets you spread one table across many segments,
clustering lets you denormalize many tables into one segment.
• NESTED TABLE If a column of a table is defined as a user-defined object
type that itself has columns, then the column can be stored in its own
segment, as a nested table.
Every segment is comprised of one or more extents. When a segment is created,
Oracle will allocate an initial extent to it in whatever tablespace is specified.
Eventually, as data is entered, that extent will fill. Oracle will then allocate a second
extent, in the same tablespace but not necessarily in the same datafile. If you know
that a segment is going to need more space, you can manually allocate an extent.
Figure 5-2 shows how to identify precisely the location of a segment.
In the figure, the first command creates the table HR.NEWTAB, relying completely
on defaults for the storage. Then a query against DBA_EXTENTS shows that the
Figure 5-2 Determining the physical location of a segment’s extents
Chapter 5: Oracle Storage
177
PART I
segment consists of just one extent, extent number zero. This extent is in file number
4 and is 8 blocks long. The first of the 8 blocks is block number 1401. The size of the
extent is 64KB, which shows that the block size is 8KB. The next command forces
Oracle to allocate another extent to the segment, even though the first extent is not
full. The next query shows that this new extent, number 1, is also in file number 4
and starts immediately after extent zero. Note that it is not clear from this example

whether or not the tablespace consists of multiple datafiles, because the algorithm
Oracle uses to work out where to assign the next extent does not simply use datafiles
in turn. If the tablespace does consist of multiple datafiles, you can override Oracle’s
choice with this syntax:
ALTER TABLE tablename ALLOCATE EXTENT STORAGE (DATAFILE 'filename');
TIP Preallocating space by manually adding extents can deliver a performance
benefit but is a huge amount of work. You will usually do it for only a few tables
or indexes that have an exceptionally high growth rate, or perhaps before bulk
loading operations.
The last query in Figure 5-2 interrogates the view DBA_DATA_FILES to determine
the name of the file in which the extents were allocated, and the name of the tablespace
to which the datafile belongs. To identify the table’s tablespace, one could also query
the DBA_SEGMENTS view.
TIP You can query DBA_TABLES to find out in which tablespace a table
resides, but this will only work for nonpartitioned tables—not for partitioned
tables, where each partition is its own segment and can be in a different
tablespace. Partitioning lets one table (stored as multiple segments)
span tablespaces.
An extent consists of a set of consecutively numbered blocks. Each block has a
header area and a data area. The header is of variable size and grows downward from
the top of the block. Among other things, it contains a row directory (that lists where
in the block each row begins) and row locking information. The data area fills from
the bottom up. Between the two there may (or may not) be an area of free space.
Events that will cause a block’s header to grow include inserting and locking rows.
The data area will initially be empty and will fill as rows are inserted (or index keys
are inserted, in the case of a block of an index segment). The free space does get
fragmented as rows are inserted, deleted, and updated (which may cause a row’s size
to change), but that is of no significance because all this happens in memory, after
the block has been copied into a buffer in the database buffer cache. The free space is
coalesced into a contiguous area when necessary, and always before the DBWn writes

the block back to its datafile.
OCA/OCP Oracle Database 11g All-in-One Exam Guide
178
File Storage Technologies
Datafiles can exist on four device types: local file systems, clustered file systems, raw
devices, and ASM disk groups:
• Files on a file local system These are the simplest datafiles; they exist
as normal operating system files in a directory structure on disks directly
accessible to the computer running the instance. On a PC running Windows
or Linux, these could be internal IDE or SATA drives. On more sophisticated
hardware, they would usually be SCSI disks, or external drives.
• Files on a clustered file system A clustered file system is usually created
on external disks, mounted concurrently on more than one computer. The
clustered file system mediates access to the disks from processes running on
all the computers in the cluster. Using clustered file systems is one way of
implementing RAC: the database must reside on disks accessible to all the
instances that are going to open it. Clustered file systems can be bought from
operating system vendors, or Oracle Corporation’s OCFS (Oracle Clustered
File System) is an excellent alternative. OCFS was first written for Linux and
Windows (for which there were no proper clustered file systems) and bundled
with database release 9i; with 10g it was ported to all the other mainstream
operating systems.
• Files on raw devices It is possible to create datafiles on disks with no file
system at all. This is still supported but is really only a historical anomaly. In
the bad old days before clustered file systems (or ASM) existed, raw devices
were the only way to implement a Parallel Server database. Parallel Server itself
was replaced with RAC in database release 9i.
• Files on ASM devices ASM is Automatic Storage Management, a facility
introduced with database release 10g. This is an alternative to file system–
based datafile storage and covered in detail in Chapter 20.

TIP Some people claim that raw devices give the best performance. With
contemporary disk and file system technology, this is almost certainly not true.
And even if it were true, they are so awkward to manage that no sane DBA
wants to use them.
ASM is tested in detail in the second OCP examination, but an understanding
of what it can do is expected for the first examination. ASM is a logical volume
manager provided by Oracle and bundled with the database. The general idea is that
you take a bunch of raw disks, give them to Oracle, and let Oracle get on with it. Your
system administrators need not worry about creating file systems at all.
A logical volume manager provided by the operating system, or perhaps by a third
party such as Veritas, will take a set of physical volumes and present them to the operating
system as logical volumes. The physical volumes could be complete disks, or they could
be partitions of disks. The logical volumes will look to application software like disks,
Chapter 5: Oracle Storage
179
PART I
but the underlying storage of any one logical volume might not be one physical volume
but several. It is on these logical volumes that the file systems are then created.
A logical volume can be much larger than any of the physical volumes of which it
is composed. Furthermore, the logical volume can be created with characteristics that
exploit the performance and safety potential of using multiple physical volumes.
These characteristics are striping and mirroring of data. Striping data across multiple
physical volumes gives huge performance gains. In principle, if a file is distributed
across two disks, it should be possible to read it in half the time it would take if it
were all on one disk. The performance will improve geometrically, in proportion to
the number of disks assigned to the logical volume. Mirroring provides safety. If a
logical volume consists of two or more physical volumes, then every operating system
block written to one volume can be written simultaneously to the other volume. If
one copy is damaged, the logical volume manager will read the other. If there are
more than two physical volumes, a higher degree of mirroring becomes possible,

providing fault tolerance in the event of multiple disk failures.
Some operating systems (such as AIX) include a logical volume manager as
standard; with other operating systems it is an optional (and usually chargeable)
extra. Historically, some of the simpler operating systems (such as Windows and
Linux) did not have much support for logical volume managers at all. If a logical
volume manager is available, it may require considerable time and skill to set up
optimally.
ASM is a logical volume manager designed for Oracle database files. The definition
of “database file” is broad. Apart from the true database files (controlfile, online redo
log files, and datafiles), ASM can also store backup files, archived redo log files, and
Data Pump files (all these files will be detailed in later chapters). It cannot be used for
the Oracle Home, or for the alert log and trace files.
EXAM TIP ASM can store only database files, not the binaries. The Oracle
Home must always be on a conventional file system.
Exercise 5-1: Investigate the Database’s Data Storage Structures In
this exercise, you will run queries to document a database’s physical structure. The
commands could be run interactively from SQL*Plus or Database Control, but it
would make sense to save them as a script that (with suitable refinements for display
format and for site specific customizations) can be run against any database as part
of the regular reports on space usage.
1. Connect to the database as user SYSTEM.
2. Determine the name and size of the controlfile(s):
select name,block_size*file_size_blks bytes from v$controlfile;
3. Determine the name and size of the online redo log file members:
select member,bytes from v$log join v$logfile using (group#);
OCA/OCP Oracle Database 11g All-in-One Exam Guide
180
4. Determine the name and size of the datafiles and the tempfiles:
select name,bytes from v$datafile
union all

select name,bytes from v$tempfile;
Create and Manage Tablespaces
Tablespaces are repositories for schema data, including the data dictionary (which
is the SYS schema). All databases must have a SYSTEM tablespace and a SYSAUX
tablespace, and (for practical purposes) a temporary tablespace and an undo tablespace.
These four will usually have been created when the database was created. Subsequently,
the DBA may create many more tablespaces for user data, and possible additional
tablespaces for undo and temporary data.
Tablespace Creation
To create a tablespace with Enterprise Manager Database Control, from the database
home page take the Server tab and then the Tablespaces link in the Storage section.
Figure 5-3 shows the result for the default database.
Figure 5-3 The tablespaces in the default ORCL database
Chapter 5: Oracle Storage
181
PART I
There are six tablespaces shown in the figure. For each tablespace, identified by
name, the window shows
• Allocated size This is the current size of the datafile(s) assigned to the
tablespace. It is based on the current size, not the maximum size to which
it may be allowed to expand.
• Space used This is the space occupied by segments in the tablespace that
cannot be reclaimed.
• Allocated space used (%) A graphical representation of the preceding two
figures.
• Allocated free space The space currently available within the tablespace.
• Status A green tick indicates that the tablespace is online, and therefore
that the objects within it should be accessible. An offline tablespace would
be indicated with a red cross.
• Datafiles The number of datafiles (or tempfiles for temporary tablespaces,

if one is being precise) that make up the tablespace.
• Type The type of objects that can be stored in the tablespace. A permanent
tablespace stores regular schema objects, such as tables and indexes. A
temporary tablespace stores only system-managed temporary segments,
and an undo tablespace stores only system-managed undo segments.
• Extent management The technique used for allocating extents to segments.
LOCAL is the default and should always be used.
• Segment management The technique used for locating blocks into which
data insertions may be made. AUTO is the default and is recommended for
all user data tablespaces.
This information could be also be gleaned by querying the data dictionary views
DBA_TABLESPACES, DBA_DATA_FILES, DBA_SEGMENTS, and DB_FREE_SPACE as
in this example:
SQL> select t.tablespace_name name, d.allocated, u.used, f.free,
2 t.status, d.cnt, contents, t.extent_management extman,
3 t.segment_space_management segman
4 from dba_tablespaces t,
5 (select sum(bytes) allocated, count(file_id) cnt from dba_data_files
6 where tablespace_name='EXAMPLE') d,
7 (select sum(bytes) free from dba_free_space
8 where tablespace_name='EXAMPLE') f,
9 (select sum(bytes) used from dba_segments
10 where tablespace_name='EXAMPLE') u
11 where t.tablespace_name='EXAMPLE';
NAME ALLOCATED USED FREE STATUS CNT CONTENTS EXTMAN SEGMAN

EXAMPLE 104857600 81395712 23396352 ONLINE 1 PERMANENT LOCAL AUTO
OCA/OCP Oracle Database 11g All-in-One Exam Guide
182
Click the CREATE button to create a tablespace. The Create Tablespace window

prompts for a tablespace name, and the values for Extent Management, Type, and
Status. In most circumstances, the defaults will be correct: Local, Permanent, and
Read Write. Then the ADD button lets you specify one or more datafiles for the new
tablespace. Each file must have a name and a size, and can optionally be set to
autoextend up to a maximum file size. The autoextend facility will let Oracle increase
the size of the datafile as necessary, which may avoid out-of-space errors.
Figures 5-4 and 5-5 show the Database Control interfaces for creating a tablespace
NEWTS with one datafile.
Figure 5-4 The Create Tablespace window
Chapter 5: Oracle Storage
183
PART I
Clicking the sHOW SQL button would display this command (the line numbers have
been added manually):
1 CREATE SMALLFILE TABLESPACE "NEWTS"
2 DATAFILE 'D:\APP\ORACLE\ORADATA\ORCL11G\newts01.dbf'
3 SIZE 100M AUTOEXTEND ON NEXT 10M MAXSIZE 200M
4 LOGGING
5 EXTENT MANAGEMENT LOCAL
6 SEGMENT SPACE MANAGEMENT AUTO
7 DEFAULT NOCOMPRESS;
Figure 5-5 The Add Datafile window
OCA/OCP Oracle Database 11g All-in-One Exam Guide
184
Consider this command line by line:
Line 1 The tablespace is a SMALLFILE tablespace. This means that it can consist of many
datafiles. The alternative is BIGFILE, in which case it would be impossible to add a
second datafile later (though the first file could be resized.) The Use Bigfile Tablespace
check box in Figure 5-4 controls this.
Line 2 The datafile name and location.

Line 3 The datafile will be created as 100MB but when full can automatically extend in 10MB
increments to a maximum of 200MB. By default, automatic extension is not enabled.
Line 4 All operations on segments in the tablespace will generate redo; this is the default. It is
possible to disable redo generation for a very few operations (such as index generation).
Line 5 The tablespace will use bitmaps for allocating extents; this is the default.
Line 6 Segments in the tablespace will use bitmaps for tracking block usage; this is the default.
Line 7 Segments in the tablespace will not be compressed; this is the default.
Taking the Storage tab shown in Figure 5-4 gives access to options for extent
management and compression, as shown in Figure 5-6.
Figure 5-6 Further options for tablespace creation
Chapter 5: Oracle Storage
185
PART I
When using local extent management (as all tablespaces should), it is possible
to enforce a rule that all extents in the tablespace should be the same size. This is
discussed in the following section. If enabling compression, then it can be applied
to data only when it is bulk-loaded, or as a part of all DML operations. If logging is
disabled, this provides a default for the very few operations where redo generation
can be disabled, such as index creation. Whatever setting is chosen, all DML operations
will always generate redo.
TIP All tablespaces should be locally managed. The older mechanism, known
as dictionary managed, was far less efficient and is only supported (and only
just) for backward compatibility. It has been possible to create locally managed
tablespaces, and to convert dictionary-managed tablespaces to locally managed,
since release 8i.
A typical tablespace creation statement as executed from the SQL*Plus command
line is shown in Figure 5-7, with a query confirming the result.
The tablespace STORETABS consists of two datafiles, neither of which will
autoextend. The only deviation from defaults has been to specify a uniform extent
size of 5MB. The first query in the figure shows that the tablespace is not a bigfile

tablespace—if it were, it would not have been possible to define two datafiles.
The second query in the figure investigates the TEMP tablespace, used by the
database for storing temporary objects. It is important to note that temporary
tablespaces use tempfiles, not datafiles. Tempfiles are listed in the views V$TEMPFILE
Figure 5-7 Tablespace creation and verification with SQL*Plus