Getting to Know Oracle Database Objects IOT, Mviews, Clusters and

more…

Aaron Shilo, CEO. .aaron@DBCS co il

Oracle Certified ProfessionalMicrosoft 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-organizedtable

Heap table

Partitionedtable

What are database objects ?

Database objects as we know them are a logical mapping for a segmentsSegments 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 blocksBlocks 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 managegood 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-organizedtable

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 dataReduced storage requirementsSecondary indexes and logical rowidsIOTs have the following restrictions:Must have a primary keyCannot 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 ;

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 ?

Demo 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 ASSELECT * FROM dba_objectsWHERE 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 t1WHERE owner = USER AND object_name = 'T1';

ALTER SESSION SET "_use_nosegment_indexes" = TRUE;

SELECT STATEMENT Optimizer = CHOOSETABLE ACCESS (FULL) OF 'T1'

SELECT STATEMENT Optimizer = CHOOSETABLE ACCESS (BY INDEX ROWID)

INDEX (RANGE SCAN) OF 'I1'

• generates the plan

• the same statement generates a different plan

• With the hidden parameter enabled

Demo Virtual Indexes

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 clustersPerformance 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 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 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 TABLE dept ( deptno NUMBER(3) PRIMARY KEY, . . . ) CLUSTER emp_dept (deptno);

CREATE INDEX emp_dept_indexON CLUSTER emp_dept TABLESPACE users

CREATE INDEX emp_dept_indexON CLUSTER emp_dept TABLESPACE users

Demo clusters

Table partitionsPartitioning 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 advantagesPartitioning 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' )));

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 PartitioningList 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));

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 PartitioningHash 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

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 IndexesLocal 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; create index employees_local_idx

on employees (employee_id) local;

Global Partitioned IndexesGlobal 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_idxon employees(employee_id) global partition by range(employee_id)(partition p1 values less than(5000), partition p2 values less han(maxvalue));

create index employees_global_part_idxon 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_idxon employees(employee_id); create index employees_global_idx

on employees(employee_id);

partition pruningThe 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.

Demo Partitions

External Tables Concepts

The Oracle9i external tables feature is a complement to existing SQL*Loaderfunctionality. 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 applicationsAre a complement to the existing SQL*Loader functionalityAre especially useful for environments in which:

The complete external source must be joined with existing database objects and transformed in a complex mannerThe external data volume is large and used only once

External Tables

SELECT * FROM ex_table;

OS fileExternaltable

External Table Population: Overview

Unload data to external flat filesHandle 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 driverData 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

DPAPIflat files

External Table Parallel Populate Operation

Multiple files can be created.Exactly one parallel execution server per fileThe PARALLEL and LOCATION clauses influence the degree of parallelism.

Coordinator

Parallelexecutionservers

Generatedfiles

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') )PARALLELASSELECT e.first_name,e.last_name,d.department_nameFROM employees e, departments dWHERE e.department_id = d.department_id AND d.department_name in ('Marketing', 'Purchasing');

External Table Projected Columns

2355,1,2289,46,2002355,A,2264,50,100

SELECT COUNT(order_id)FROM order_items_ext;

SELECT COUNT(line_id)FROM order_items_ext;

order_items1.dat

REFERENCED ALLAccessdriver

2 1 1 1

ALTER TABLE order_items_extPROJECT COLUMN {ALL|REFERENCED};

SELECT propertyFROM DBA_EXTERNAL_TABLESWHERE 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.

Demo external table

Materialized ViewsMaterialized 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 system set QUERY_REWRITE_ENABLED = true

Alter session 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 

Description Refresh 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 query COMPLETE

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 refresh FORCE

Indicates that the materialized view will not be refreshed with the Oracle refresh mechanisms NEVER

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 serversTABLESPACE data_smlWITH PRIMARY KEY, ROWID;

CREATE MATERIALIZED VIEW LOG ON serversTABLESPACE data_smlWITH 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_simpleTABLESPACE data_sml ASSelect * from servers;

CREATE MATERIALIZED VIEW mv_simpleTABLESPACE data_sml ASSelect * from servers;

CREATE MATERIALIZED VIEW mv_prebuiltRefresh fast on commitENABLE QUERY REWRITEAS SELECT t.calendar_month_desc AS month,c.cust_state_province AS state, SUM(s.amount_sold) AS salesFROM times t, customers c, sales sWHERE s.time_id = t.time_id AND s.cust_id = c.cust_idGROUP BY t.calendar_month_desc, c.cust_state_province;

CREATE MATERIALIZED VIEW mv_prebuiltRefresh fast on commitENABLE QUERY REWRITEAS SELECT t.calendar_month_desc AS month,c.cust_state_province AS state, SUM(s.amount_sold) AS salesFROM times t, customers c, sales sWHERE s.time_id = t.time_id AND s.cust_id = c.cust_idGROUP 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 setsSuperset of referential constraints:

Normalized dimensionsDenormalized dimensions

Never enforcedOptional 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 nameMonth nameQuarter descriptionDays in quarter

Day

All

Attributes:

Year

Quarter

Month

Fiscal year

Fiscal quarter

Fiscal month

Fiscal week

Dimensions: Example TableSQL> 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 199802-JAN-98 1998-01 1998-Q1 199803-JAN-98 1998-01 1998-Q1 199804-JAN-98 1998-01 1998-Q1 199805-JAN-98 1998-01 1998-Q1 199806-JAN-98 1998-01 1998-Q1 1998

...30-DEC-01 2001-12 2001-Q4 200131-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);

Demo materialized view

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 ComponentsUnstructured 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 LargeAlso 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 SupportedOracle 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 GBCLOB - character data up to 4 GBNCLOB - stores CLOB data for multibyte character sets Stored inside database, can be single rowBFILE - pointer to external file. (File exists on O/S)

Demo LOB

A TipShrinking Segments

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

Shrinkoperation

DataUnusedspace

Data

Unusedspace

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.

Demo Shrink

Aaron Shilo, CEO

Oracle Certified ProfessionalMicrosoft certified technology specialist

 Contact Me:

. .Aaron@DBCS co ilwww.DBCS.co.il0504-477117

http://il.linkedin.com/in/aaronshilo