Getting to know oracle database objects iot, mviews, clusters and more…

Getting to Know Oracle Database
Objects IOT, Mviews, Clusters and
more…
Aaron Shilo, CEO
aaron@DBCS.co.il
Oracle Certified Professional
Microsoft certified technology
specialist

* 34 years old
* Married + 3
* 10 years AS a dba consultant instructor architect.
* Was cto @ johnbryce israel
* Oracle certified professional
* Microsoft sql server certified professional
* Today I lead a Database solution service company, DBCS LTD.
* Consultant for Tapuz , bezeq int, cbs , pontis , traffilog, Super-Sal and more.

Agenda
• What are segments ?
• IOT – What are Index-Organized Tables?
• Virtual Indexes
• LOB
• Materialized Views - Also known as snapshots in prior releases
• Clusters
• External Tables
• Partitions
• Partition Pruning
• Partition-wise Joins
• Manageability
• Oracle11g New Features
• External tables (ETL)
• Segment space management (Shrink and defragment)

Data Storage Structures
Cluster Index-organized
table
Heap table
Partitioned
table

What are database objects ?
Database objects as we know them are a logical mapping for a segments
Segments are space-occupying objects in a database.
They use space in the data files of a database.
Segments are made out of extents
Extents are made out of blocks
Blocks are the smallest unit of I/O in the database
A segment is a database object physical storage facility
Of a table/index/cluster etc…
Dba uses the segments in order to manage
good space utilization of data.

Types of segments
Table
A table is the most common means of storing data within a database. A table segment stores that
data for a table. Data within a table segment is stored in no particular order, and the database
administrator (DBA) has very little control over the location of rows within the blocks in a table. All
the data in a table segment must be stored in one tablespace.
Table partition
Scalability and availability are major concerns when there is a table in a database with high
concurrent usage. In such cases, data within a table may be stored in several partitions, each of
which resides in a different tablespace. If a table is partitioned, each partition is a segment, and
the storage parameters can be specified to control them independently.
Table
Table
partition

Types of Segments
(continued)
Cluster
A cluster, like a table, is a type of data segment. Rows in a cluster are stored based on key column
values. A cluster may contain one or more tables. Tables in a cluster belong to the same segment
and share the same storage characteristics. The rows in a clustered table can be accessed with an
index or hashing algorithm.
Index
All the entries for a particular index are stored within one index segment. If a table has three
indexes, three index segments are used. The purpose of this segment is to look up the location of
rows in a table based on a specified key.
Cluster
Index

Types of Segments
(continued)
Index-Organized Table
In an index-organized table, data is stored within the index based on the key value. An index-
organized table does not need a table lookup, because all the data can be retrieved directly from
the index tree.
Index-organized
table

Types of Segments
(continued)
Materialized Views (AKA snapshots)
A materialized view (MV) stores both the definition of a view and the rows resulting from the
execution of the view. Like a view, it uses a query as the basis, but the query is executed at the
time the view is created and the results are stored in a table. You can define the table with the
same storage parameters as any other table and place it in the tablespace of your choice.
When a query can be satisfied with data in a materialized view, the server transforms the query to
reference the view rather than the base tables. By using a materialized view, expensive operations
such as joins and aggregations do not need to be re-executed; instead the statement is rewritten
to query the materialized view.
Materialized view

Why use different segment types?
I'm often asked "when or why should I use an IOT ,MVIEWS ,CLUSTERS etc… ?".
Well all of the above are used to reduce I/O (consistent gets and physical reads) by making the SQL more
efficient.
For example The SQL become more efficient on an IOT and a cluster table because less access is required to gat
all of the data to satisfy the request.
Experienced Oracle DBAs know that I/O is often the single greatest component of response time and regularly
work to reduce I/O. Disk I/O is expensive because when Oracle retrieves a block from a data file on disk, the
reading process must wait for the physical I/O operation to complete.
Disk operations are about 10,000 times slower than a row's access in the data buffers (in Oracle, about 100x
faster due to latch overhead). Consequently, anything you can do to minimize I/O or reduce bottlenecks caused
by contention for files on disk-greatly improves the performance of any Oracle database.

Index organized table (IOT)
Compared to heap tables, IOTs have:
Faster key-based access to table data
Reduced storage requirements
Secondary indexes and logical rowids
IOTs have the following restrictions:
Must have a primary key
Cannot be clustered
create table country
( country_id char(2) constraint
country_id_nn not null,
country_name varchar2(40),currency_name
varchar2(25),
currency_symbol varchar2(3),map blob, flag
blob,
constraint country_c_id_pk primary key
(country_id))
organization index tablespace index ;
Non-key columns
Key column
Row header

Why IOT ?
Faster Index Access
Index-organized tables provide faster access to table rows by the primary key. Also, since rows are stored
in primary key order, range access by the primary key involves minimum block accesses. In order to allow
even faster access to frequently accessed columns, the row overflow storage option can be used to push
out infrequently accessed non-key columns from the B-tree leaf bloc k to an optional overflow storage
area. This limits the size and content of the row portion actually stored in the B-tree leaf block, resulting
in a smaller B-tree and faster access.
Reduced Storage
Index-organized tables maintain a single storage structure -- the B-tree index. Primary key column values
are stored only in the B-tree ind ex and not duplicated in the table and index as happens in a
conventional heap-organized table. Because rows of an index-organized table are stored in primary key
order, a significant amount of additional storage space savings can be obtained throug h the use of key
compression.
Increased 24x7 Availability
Index-organized tables identify rows using logical ROWIDs based on the primary key. The use of logical
ROWIDs enables online reorganization and also does not affect the secondary indexes which remain valid
and usable after the reorganization. This capability reduces or eliminates the downtime for
reorganization of secondary indexes, making index-organized tables beneficial for 24x7 applications.

Increased Scalability
Index-organized tables are highly scalable because of their support for partitioning and parallel operations.
Range partitioned and hash partitioned index-organized tables as well as LOB columns in partitioned index-
organized tables are supported. Parallel query and parallel DML are also supported. Queries on index-organized
tables including partitioned ones use the cost-based optimizer for generating optimal execution flow.
Easy to Use AND Fully Functional
Applications manipulate the index-organized table just like an ordinary table via standard SQL statements. All
Oracle programmatic interfaces including PL/SQL, OCI, and JDBC can access index-organized tables. The full
complement of Oracle utilities and tools are supported including the SQL*Loader (both conventional and direct
path), IMPORT/EXPORT, and transportable tablespace support for point-in-time recovery operations using the
Oracle Recovery Manager (RMAN).
Index organized tables support the standard features available with conventional tables -- secondary indexes,
constraints, triggers, composite columns, object and REF columns, and LOB columns. Key compression is
supported on secondary indexes and the index-organized table as it is itself stored in an in dex. An index-
organized table can also be used as an object table and can be replicated. From the perspective of security,
administration, and tools, index-organized tables are treated in the same fashion as conventional tables.
Why IOT ?

Virtual Indexes
Virtual Indexes are another undocumented feature used by Oracle. Virtual indexes, as the name suggests are pseudo-
indexes that will not behave the same way that normal indexes behave, and are meant for a very specific purpose.
The virtual index wizard functionality allows the user to test a potential new index prior to actually building the new
index in the database. It allows the CBO to evaluate the potential new index for a selected SQL statement by building
an explain plan that is aware of the potential new index. This allows the user to determine if the optimizer would use
the index, once implemented.
I do not see much use of Virtual Indexes in a development area where we can create and drop indexes while testing.
However, this feature could prove handy if a query or group of queries have to be tested in production (for want of
simulation or urgency!), to determine if a new index will improve the performance, without impacting existing or new
sessions.

A virtual index is created in a slightly different manner than the normal indexes. A virtual index has no segment
pegged to it, i.e., the DBA_SEGMENTS view will not show an entry for this. Oracle handles such indexes internally and
few required dictionary tables are updated so that the optimizer can be made aware of its presence and generate an
execution plan considering such indexes.
Effectiveness of new indexes can be tested by generating theoretical execution plans
The CBO will consider virtual indexes if the hidden parameter _use_nosegment_indexes is set to true

1. These are permanent and continue to exist unless we drop them.
2. Their creation will not affect existing and new sessions. Only sessions marked for
Virtual Index usage will become aware of their existence.
3. Such indexes will be used only when the hidden parameter "_use_nosegment_indexes"
is set to true.
4. The Rule based optimizer did not recognize Virtual Indexes when I tested, however,
CBO recognizes them. In all of my examples, I have used CBO. However, I did not carry
out intensive testing in RBO and you may come across exceptions to this view.
5. Dictionary view DBA_SEGMENTS will not show an entry for Virtual Indexes. The table
DBA_INDEXES and DBA_OBJECTS will have an entry for them in Oracle 8i; in Oracle 9i
onwards, DBA_INDEXES no longer show Virtual Indexes.
6. Virtual Indexes cannot be altered and throw a "fake index" error!
7. Virtual Indexes can be analyzed, using the ANALYZE command or DBMS_STATS package,
but the statistics cannot be viewed (in Oracle 8i, DBA_INDEXES will not show this
either). Oracle may be generating artificial statistics and storing it somewhere for
referring it later.
attributes of the Virtual Indexes.

Virtual Indexes
Consider the following analysed table
CREATE TABLE t1 AS
SELECT * FROM dba_objects
WHERE ROWNUM < 1000;
ANALYZE TABLE t1 COMPUTE STATISTICS;
CREATE INDEX i1 ON t1 (owner, object_name) NOSEGMENT;
EXECUTE DBMS_STATS.GENERATE_STATS (USER,'I1');
• A virtual index can be created using the NOSEGMENT keyword
• Statistics must be generated for the new index based on the existing statistics for
the table

Virtual Indexes
The statement
SELECT object_id FROM t1
WHERE owner = USER AND object_name = 'T1';
ALTER SESSION SET "_use_nosegment_indexes" = TRUE;
SELECT STATEMENT Optimizer = CHOOSE
TABLE ACCESS (FULL) OF 'T1'
SELECT STATEMENT Optimizer = CHOOSE
TABLE ACCESS (BY INDEX ROWID)
INDEX (RANGE SCAN) OF 'I1'
• generates the plan
• the same statement generates a different plan
• With the hidden parameter enabled

Table cluster
A cluster is a group of one or more tables that share the same data blocks because they share common
columns and are often used together in join queries. Storing tables in clusters offers the DBA a method to
denormalize data. Clusters are transparent to the end user and programmer.
If this customer has eight orders, each on a different data block, we must perform nine block
fetches to return the query rows. Even if these blocks are already cached in the data buffers, we
still have at least nine consistent gets:
If we re-define the table as a index cluster table, Oracle will physically store the orders rows on the
same data block as the parent customer row,
thereby reducing I/O by a factor of eight:

Performance and clusters
Performance Benefits of Clusters
Disk I/O is reduced and access time improved for joins of clustered tables.
Each cluster key value is stored only once for all the rows of the same key value; it therefore
uses less storage space.
When Not to Use Clusters
If a full scan is executed often on one of the clustered tables: This table is stored on more
blocks than if it had been created alone.
If the data for all rows of a cluster key value exceeds one or two Oracle blocks: To access an
individual row in a clustered key table, the Oracle server reads all blocks containing rows
with the same value.
Full table scans are generally slower on clustered tables than on nonclustered tables.

guidelines for clusters
Choose Appropriate Tables for the Cluster
Use clusters for tables for which the following conditions are true
The tables are primarily queried--that is, tables that are not predominantly inserted into or
updated
Records from the tables are frequently queried together or joined
Choose Appropriate Columns for the Cluster Key
Choose cluster key columns carefully. If multiple columns are used in queries that join the tables,
make the cluster key a composite key. In general, the characteristics that indicate a good cluster
index are the same as those for any index.
A good cluster key has enough unique values so that the group of rows corresponding to each key
value fills approximately one data block. Having too few rows for each cluster key value can waste
space and result in negligible performance gains.
Cluster keys that are so specific that only a few rows share a common value can cause wasted
space in blocks, unless a small SIZE was specified at cluster creation time.
Too many rows for each cluster key value can cause extra searching to find rows for that key.
Cluster keys on values that are too general (for example, male and female) result in excessive
searching and can result in worse performance than with no clustering.

Creating Clusters
You create a cluster using the CREATE CLUSTER statement. The following statement creates a cluster
named emp_dept which stores the emp and dept tables, clustered by the deptno column
You create a table in a cluster using the CREATE TABLE statement with the CLUSTER option. The emp and
dept tables can be created in the emp_dept cluster using the following statements:
A cluster index must be created before any rows can be inserted into any clustered table. The following
statement creates a cluster index for the emp_dept cluster:
CREATE CLUSTER emp_dept (deptno NUMBER(3)) TABLESPACE
users;
CREATE TABLE emp
( empno NUMBER(5) PRIMARY KEY, ename VARCHAR2(15) NOT
NULL,
. . .
deptno NUMBER(3) REFERENCES dept)
CLUSTER emp_dept (deptno);
CREATE TABLE dept
( deptno NUMBER(3) PRIMARY KEY, . . . )
CLUSTER emp_dept (deptno);
CREATE INDEX emp_dept_index
ON CLUSTER emp_dept TABLESPACE users

Table partitions
Partitioning addresses key issues in supporting very large tables and indexes by letting you decompose
them into smaller and more manageable pieces called partitions SQL queries and DML statements do
not need to be modified in order to access partitioned tables. However, after partitions are defined, DDL
statements can access and manipulate individuals partitions rather than entire tables or indexes. This is
how partitioning can simplify the manageability of large database objects. Also, partitioning is entirely
transparent to applications
Each partition of a table or index must have the same logical attributes, such as column names,
datatypes, and constraints, but each partition can have separate physical attributes such as pctfree,
pctused, and tablespaces
Partitioning is useful for many different types of applications, particularly applications that manage large
volumes of data. OLTP systems often benefit from improvements in manageability and availability, while
data warehousing systems benefit from performance and manageability

Partitioning advantages
Partitioning enables data management operations such data loads, index creation and rebuilding, and
backup/recovery at the partition level, rather than on the entire table. This results in significantly
reduced times for these operations
Partitioning improves query performance. In many cases, the results of a query can be achieved by
accessing a subset of partitions, rather than the entire table. For some queries, this technique called
partition pruning can provide order-of-magnitude gains in performance
Partitioning can significantly reduce the impact of scheduled downtime for maintenance operations
Partition independence for partition maintenance operations lets you perform concurrent maintenance
operations on different partitions of the same table or index. You can also run concurrent SELECT and
DML operations against partitions that are unaffected by maintenance operations
Partitioning increases the availability of mission-critical databases if critical tables and indexes are
divided into partitions to reduce the maintenance windows, recovery times, and impact of failures.
Partitioning can be implemented without requiring any modifications to your applications. For example,
you could convert a nonpartitioned table to a partitioned table without needing to modify any of the
SELECT statements or DML statements which access that table. You do not need to rewrite your
application code to take advantage of partitioning

Range Partitioning
Range partitioning maps data to partitions based on ranges of partition key values that you
establish for each partition. It is the most common type of partitioning and is often used with
dates. For example, you might want to partition sales data into monthly partitions.
A typical example is given in the following section.
The statement creates a table (sales_range) that is range partitioned on the
sales_date field.
create table sales_range
( salesman_id number(5), salesman_name varchar2(30), sales_amount number(10),
sales_date date)
partition by range(sales_date)
( partition sales_jan2000 values less than( to_date('02/01/2000','dd/mm/yyyy' )),
partition sales_feb2000 values less than( to_date('03/01/2000','dd/mm/yyyy' )),
partition sales_mar2000 values less than( to_date('04/01/2000','dd/mm/yyyy' )),
partition sales_apr2000 values less than( to_date('05/01/2000','dd/mm/yyyy' )));

List Partitioning
List partitioning enables you to explicitly control how rows map to partitions. You do this by
specifying a list of discrete values for the partitioning key in the description for each partition. This
is different from range partitioning, where a range of values is associated with a partition and
from hash partitioning, where a hash function controls the row-to-partition mapping. The
advantage of list partitioning is that you can group and organize unordered and unrelated sets of
data in a natural way.
The details of list partitioning can best be described with an example. In this case, let's say you
want to partition a sales table by region. That means grouping states together according to their
geographical location as in the following example.
create table sales_list
(salesman_id number(5), salesman_name varchar2(30),
sales_state varchar2(20),sales_amount number(10),
sales_date date)
partition by list(sales_state)
(partition sales_west values('california', 'hawaii'),
partition sales_east values ('new york', 'virginia', 'florida'),
partition sales_central values('texas', 'illinois'),
partition sales_other values(default));

Hash Partitioning
Hash partitioning enables easy partitioning of data that does not lend itself to range or list
partitioning. It does this with a simple syntax and is easy to implement. It is a better choice than
range partitioning when:
You do not know beforehand how much data maps into a given range
The sizes of range partitions would differ quite substantially or would be difficult to balance manually
Range partitioning would cause the data to be undesirably clustered
Note: The concepts of splitting, dropping or merging partitions do not apply to hash
partitions. Instead, hash partitions can be added and coalesced.
create table sales_hash
(salesman_id number(5), salesman_name varchar2(30),
sales_amount number(10), week_no number(2))
partition by hash(salesman_id)
partitions 4 store in (data1, data2, data3, data4);
The preceding statement creates a table sales_hash, which is hash partitioned on salesman_id field.
The tablespace names are data1, data2, data3, and data4

Partitioned Indexes
Just like partitioned tables, partitioned indexes improve manageability, availability, performance, and
scalability.
They can either be partitioned independently (global indexes) or automatically linked to a table's
partitioning method (local indexes .

Local Partitioned Indexes
Local partitioned indexes are easier to manage than other types of partitioned indexes. They also offer
greater availability and are common in DSS environments. The reason for this is equipartitioning: each
partition of a local index is associated with exactly one partition of the table. This enables Oracle to
automatically keep the index partitions in sync with the table partitions, and makes each table-index pair
independent. Any actions that make one partition's data invalid or unavailable only affect a single
partition
You cannot explicitly add a partition to a local index. Instead, new partitions are added to local indexes
only when you add a partition to the underlying table. Likewise, you cannot explicitly drop a partition
from a local index. Instead, local index partitions are dropped only when you drop a partition from the
underlying table
A local index can be unique. However, in order for a local index to be unique, the partitioning key of the
table must be part of the index's key columns. Unique local indexes are useful for OLTP environments
Local Partitioned Index
create index employees_local_idx
on employees (employee_id) local;

Global Partitioned Indexes
Global partitioned indexes
are flexible in that the degree of partitioning and the partitioning key are independent from
the table's partitioning method.
They are commonly used for OLTP environments and offer efficient access to any
individual record.
partitioned indexcreate index employees_global_part_idx
on employees(employee_id)
global partition by range(employee_id)
(partition p1 values less than(5000),
partition p2 values less han(maxvalue));

Global Nonpartitioned Indexes
Global nonpartitioned indexes
behave just like a nonpartitioned index.
They are commonly used in OLTP environments and offer efficient access
to any individual record.
Global nonpartitioned index
create index employees_global_idx
on employees(employee_id);

partition pruning
The Oracle server explicitly recognizes partitions and subpartitions. It then optimizes SQL statements to
mark the partitions or subpartitions that need to be accessed and eliminates (prunes) unnecessary
partitions or subpartitions from access by those SQL statements. In other words, partition pruning is the
skipping of unnecessary index and data partitions or subpartitions in a query.
For each SQL statement, depending on the selection criteria specified, unneeded partitions or
subpartitions can be eliminated. For example, if a query only involves March sales data, then there is no
need to retrieve data for the remaining eleven months. Such intelligent pruning can dramatically reduce
the data volume, resulting in substantial improvements in query performance.
If the optimizer determines that the selection criteria used for pruning are satisfied by all the rows in the
accessed partition or subpartition, it removes those criteria from the predicate list (WHERE clause)
during evaluation in order to improve performance.
Equality, range, LIKE, and IN-list predicates are considered for partition pruning with range or list
partitioning, and equality and IN-list predicates are considered for partition pruning with hash
partitioning.

External Tables Concepts
The Oracle9i external tables feature is a complement to existing SQL*Loader
functionality. It allows you to access data in external sources as if it were in a table in the database.
External tables are read-only. No data manipulation language (DML) operations or index creation is
allowed on an external table.
However, as of Oracle Database 10g, external tables can also be written to. Although neither data
manipulation language (DML) operations nor index creation is allowed on an external table, it is possible
to use the CREATE TABLE AS SELECT command to populate an external table composed of proprietary
format (Direct Path API) flat files that are operating system independent.

Benefits of External Tables
Provide a valuable means for performing basic extraction, transformation, and loading (ETL)
Are transparent to users and applications
Are a complement to the existing SQL*Loader functionality
Are especially useful for environments in which:
The complete external source must be joined with existing database objects and
transformed in a complex manner
The external data volume is large and used only once

External Tables
SELECT *
FROM ex_table;
OS fileExternal
table

External Table Population: Overview
Unload data to external flat files
Handle complex ETL situations
Flat files
(Proprietary format)
CREATE TABLE
… AS SELECT
Tables
Unloading
Tables
Loading
INSERT … SELECT

External Table Population Operation
Uses the ORACLE_DATAPUMP access driver
Data cannot be modified.
Resulting files can be read only with the
ORACLE_DATAPUMP access driver.
You can combine generated files from different sources for
loading purposes.
ORACLE_DATAPUMP
Oracle Database
DPAPI
flat files

External Table Parallel Populate
Operation
Multiple files can be created.
Exactly one parallel execution server per file
The PARALLEL and LOCATION clauses influence the degree
of parallelism.
Coordinator
Parallel
execution
servers
Generated
files
emp1.exp emp2.exp emp3.exp

External Table Population: Example
CREATE TABLE emp_ext
(first_name, last_name, department_name)
ORGANIZATION EXTERNAL
(
TYPE ORACLE_DATAPUMP
DEFAULT DIRECTORY ext_dir
LOCATION ('emp1.exp','emp2.exp','emp3.exp')
)
PARALLEL
AS
SELECT e.first_name,e.last_name,d.department_name
FROM employees e, departments d
WHERE e.department_id = d.department_id AND
d.department_name in
('Marketing', 'Purchasing');

External Table Projected Columns
2355,1,2289,46,200
2355,A,2264,50,100
SELECT COUNT(order_id)
FROM order_items_ext;
SELECT COUNT(line_id)
FROM order_items_ext;
order_items1.dat
REFERENCED
ALL
Access
driver
2 1 1 1

ALTER TABLE order_items_ext
PROJECT COLUMN {ALL|REFERENCED};
SELECT property
FROM DBA_EXTERNAL_TABLES
WHERE table_name = 'ORDER_ITEMS_EXT';
External Table Projected Column:
Examples
The default value is ALL.
REFERENCED is useful for performance when data is known
to be safe.

Materialized Views
Materialized views are schema objects that can be used to summarize, compute, replicate, and
distribute data. They are suitable in various computing environments such as data warehousing, decision
support, and distributed or mobile computing
In data warehouses, materialized views are used to compute and store aggregated data such as sums
and averages. Materialized views in these environments are typically referred to as summaries because
they store summarized data. They can also be used to compute joins with or without aggregations.
Cost-based optimization can use materialized views to improve query performance by automatically
recognizing when a materialized view can and should be used to satisfy a request. The optimizer
transparently rewrites the request to use the materialized view. Queries are then directed to the
materialized view and not to the underlying detail tables or views
Materialized views are similar to indexes in several ways
They consume storage space
They must be refreshed when the data in their master tables changes
They improve the performance of SQL execution when they are used for query rewrites
Their existence is transparent to SQL applications and users
Unlike indexes, materialized views can be accessed directly using a SELECT statement. Depending on the types of
refresh that are required, they can also be accessed directly in an INSERT UPDATE or DELETE statement

query rewrite
Materialized views improve query performance by precalculating expensive join and aggregation
operations on the database prior to execution and storing the results in the database.
The query optimizer automatically recognizes when an existing materialized view can and should be used
to satisfy a request. It then transparently rewrites the request to use the materialized view.
Queries go directly to the materialized view and not to the underlying detail tables. In general, rewriting
queries to use materialized views rather than detail tables improves response

Query rewrite requirements
Even though a materialized view is defined, it will not automatically be used by the query rewrite facility.
You must set the QUERY_REWRITE_ENABLED initialization parameter to TRUE before using query
rewrite.
You also must specify the ENABLE QUERY REWRITE clause if the materialized view is to be considered
available for rewriting queries
Alter system set QUERY_REWRITE_ENABLED = true
Alter session set QUERY_REWRITE_ENABLED = true

Refresh mview
When you define a materialized view, you can specify two refresh options: how to refresh and what type of refresh. If
unspecified, the defaults are assumed as ON DEMAND and FORCE
You can specify how you want your materialized views to be refreshed from the detail tables by selecting one of four
options: COMPLETE, FAST, FORCE, and NEVER
DescriptionRefresh Mode
Refresh occurs automatically when a transaction that modified one of the materialized view's detail tables commits.
This can be specified as long as the materialized view is fast refreshable (in other words, not complex). The ON
COMMIT privilege is necessary to use this mode
On commit
Refresh occurs when a user manually executes one of the available refresh procedures contained in the
DBMS_MVIEW package (REFRESH, REFRESH_ALL_MVIEWS, REFRESH_DEPENDENT)
On demand
Refreshes by recalculating the materialized view's defining queryCOMPLETE
Applies incremental changes to refresh the materialized view using the information logged in the
materialized view logs, or from a SQL*Loader direct-path or a partition maintenance operation
FAST
Applies FAST refresh if possible; otherwise, it applies COMPLETE refreshFORCE
Indicates that the materialized view will not be refreshed with the Oracle refresh mechanismsNEVER

Mview log
When DML changes are made to master table data, Oracle Database stores rows describing those
changes in the materialized view log and then uses the materialized view log to refresh materialized
views based on the master table.
This process is called incremental or fast refresh. Without a materialized view log, Oracle Database must
re-execute the materialized view query to refresh the materialized view.
This process is called a complete refresh. Usually, a fast refresh takes less time than a complete refresh
CREATE MATERIALIZED VIEW LOG ON servers
TABLESPACE data_sml
WITH PRIMARY KEY, ROWID;

Create Materialized view
Simple mview : is a mview that is used for direct query and has no fast refresh option or query rewrite
ability
Complex mview : has query rewrite enabled, refresh fast, and accesses multiple tables
CREATE MATERIALIZED VIEW mv_simple
TABLESPACE data_sml AS
Select * from servers;
CREATE MATERIALIZED VIEW mv_prebuilt
Refresh fast on commit
ENABLE QUERY REWRITE
AS SELECT t.calendar_month_desc AS month,
c.cust_state_province AS state, SUM(s.amount_sold) AS sales
FROM times t, customers c, sales s
WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id
GROUP BY t.calendar_month_desc, c.cust_state_province;

Dimensions
A dimension object defines hierarchical (parent/child) relationships between pairs of column sets, where all the
columns of a column set must come from the same table. A dimension is a superset of the referential integrity
constraints defined in the Oracle Server.
Normalized dimensions are globally equivalent to the relationship between primary keys and not-null foreign keys.
For denormalized dimensions, the established relation is for column sets of the same table, and this relationship
determines whether any child-side columns value has one and only one corresponding parent-side columns value.
Dimensions are more general than traditional referential integrity constraints because you can define a relation
between n columns and m columns, or you can define a relation between two columns with different data types.
Another significant difference between dimensions and constraints is that dimensions are never enforced.
Dimensions (in the context of Oracle9i) are data dictionary structures that define the hierarchies based on columns in
existing database tables. Declaring dimensions:
Enables additional rewrite possibilities without the use of constraints (Implementation of constraints may not
be desirable in a data warehouse for performance reasons.)
Helps document dimensions and hierarchies explicitly

Dimensions
Data dictionary structures
Define hierarchies between pairs of column sets
Superset of referential constraints:
Normalized dimensions
Denormalized dimensions
Never enforced
Optional but highly recommended because they:
Enable additional query rewrites without the use of constraints
Can be used by OLAP tools

Dimensions and Hierarchies
Hierarchy
Day name
Month name
Quarter
description
Days in quarter
Day
All
Attributes:
Year
Quarter
Month
Fiscal year
Fiscal quarter
Fiscal month
Fiscal week

Dimensions: Example Table
SQL> SELECT time_id day
2 , calendar_month_desc month
3 , calendar_quarter_desc quarter
4 , calendar_year year
5 FROM times;
DAY MONTH QUARTER YEAR
--------- -------- ------- ----------
01-JAN-98 1998-01 1998-Q1 1998
02-JAN-98 1998-01 1998-Q1 1998
03-JAN-98 1998-01 1998-Q1 1998
04-JAN-98 1998-01 1998-Q1 1998
05-JAN-98 1998-01 1998-Q1 1998
06-JAN-98 1998-01 1998-Q1 1998
...
30-DEC-01 2001-12 2001-Q4 2001
31-DEC-01 2001-12 2001-Q4 2001

Dimensions and Hierarchies
- YEAR
- QUARTER
- MONTH
- DAY
TIMES table columns TIMES_DIM dimension
- DAY_NAME
- CALENDAR_MONTH_NAME
- DAYS_IN_CAL_QUARTER
Attributes
- CALENDAR_YEAR
- CALENDAR_QUARTER_DESC
- CALENDAR_MONTH_DESC
- TIME_ID

Creating Dimensions and Hierarchies
SQL> CREATE DIMENSION times_dim
2 LEVEL day IS TIMES.TIME_ID
3 LEVEL month IS TIMES.CALENDAR_MONTH_DESC
4 LEVEL quarter IS TIMES.CALENDAR_QUARTER_DESC
5 LEVEL year IS TIMES.CALENDAR_YEAR
6 HIERARCHY cal_rollup (
7 day CHILD OF
8 month CHILD OF
9 quarter CHILD OF
10 year
11 )
12 ATTRIBUTE day DETERMINES (day_name)
13 ATTRIBUTE month DETERMINES (calendar_month_name)
14 ATTRIBUTE quarter DETERMINES
15 (days_in_cal_quarter);

Large Objects - LOB
As applications evolve to encompass increasingly richer semantics, they encounter the need to deal with the
following kinds of data:
• Simple structured data
• Complex structured data
• Semi-structured data
• Unstructured data
Traditionally, the Relational model has been very successful at dealing with simple structured data -- the kind which
can be fit into simple tables. Oracle has added Object-Relational features so that applications can deal with complex
structured data -- collections, references, user-defined types and so on. Our queuing technologies, such as Advanced
Queuing, deal with Messages and other semi-structured data.
LOBs are designed to support the last kind of data -- unstructured data.

Unstructured Data
Unstructured Data Cannot be Decomposed Into Standard Components
Unstructured data cannot be decomposed into standard components. Data about an Employee can be 'structured' into
a Name (probably a character string), an identification (likely a number), a Salary and so on. But if you are given a
Photo, you find that the data really consists of a long stream of 0s and 1s. These 0s and 1s are used to switch pixels on
or off so that you will see the Photo on a display, but they can't be broken down into any finer structure in terms of
database storage.
Unstructured Data is Large
Also interesting is that unstructured data such as text, graphic images, still video clips, full motion video, and sound
waveforms tend to be large -- a typical employee record may be a few hundred bytes, but even small amounts of
multimedia data can be thousands of times larger.
Two Type of LOBs Supported
Oracle supports the following two types of LOBs
• Those stored in the database either in-line in the table or in a separate segment or tablespace, such as
BLOB, CLOB, and NCLOB.
• Those stored as operating system files, such as BFILEs.

Large Objects - LOB
BLOB - binary data that can be extended to 4 GB
CLOB - character data up to 4 GB
NCLOB - stores CLOB data for multibyte character sets
Stored inside database, can be single row
BFILE - pointer to external file. (File exists on O/S)

Shrinking Segments: Considerations
• Online and in-place operation
• Applicable only to segments residing in ASSM tablespaces
• Candidate segment types:
• Heap-organized tables and index-organized tables
• Indexes
• Partitions and subpartitions
• Materialized views and materialized view logs
• Indexes are maintained.
• Triggers are not fired.

Shrinking Segments: Overview
HWM
HWM
Shrink
operation
Data
Unused
space
Data
Unused
space
Reclaimed space

Shrinking Segments Using SQL
ALTER TABLE employees SHRINK SPACE CASCADE;
ALTER … SHRINK SPACE [CASCADE]
TABLE INDEX MATERIALIZED VIEW MATERIALIZED VIEW LOG
MODIFY PARTITION
ALTER TABLE employees ENABLE ROW MOVEMENT;1
2
MODIFY SUBPARTITION

Segment Shrink: Basic Execution
HWM
ALTER TABLE employees SHRINK SPACE COMPACT;
HWM
HWM
ALTER TABLE employees SHRINK SPACE;
1
2

Segment Shrink:
Execution Considerations
•Use compaction only:
•Avoid unnecessary cursor invalidation
•During peak hours
•DML operations and queries can be issued during
compaction.
•DML operations are blocked when HWM is adjusted.

Aaron Shilo, CEO
Oracle Certified Professional
Microsoft certified technology specialist
Contact Me :
Aaron@DBCS.co.il
www.DBCS.co.il
0504-477117
http://il.linkedin.com/in/aaronshilo

Getting to know oracle database objects iot, mviews, clusters and more…

Getting to know oracle database objects iot, mviews, clusters and more…

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Getting to know oracle database objects iot, mviews, clusters and more… (20)

Recently uploaded (20)

Getting to know oracle database objects iot, mviews, clusters and more…