Oracle® Database New Features Guide 12c Release 2 (12.2)

Oracle Database
New Features Guide

12c Release 2 (12.2)
E72282-02
September 2016
Oracle Database New Features Guide, 12c Release 2 (12.2)

E72282-02
Copyright 2016, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on
use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your
license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license,
transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse
engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is
prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If
you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on
behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software,
any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are
"commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agencyspecific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the
programs, including any operating system, integrated software, any programs installed on the hardware,
and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.
No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications.
It is not developed or intended for use in any inherently dangerous applications, including applications that
may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you
shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its
safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this
software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of
their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are
used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron,
the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro
Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products,
and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly
disclaim all warranties of any kind with respect to third-party content, products, and services unless
otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates
will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party
content, products, or services, except as set forth in an applicable agreement between you and Oracle.
Contents
Preface .............................................................................................................................................................. xiii
Audience .....................................................................................................................................................
xiii
Documentation Accessibility ...................................................................................................................
xiii
Related Documents....................................................................................................................................
xiii
Conventions................................................................................................................................................
xiii
Part I
1
Oracle Database 12.2 New Features

1.1
1.2
1.3
1.4
1.5
Part II
2
Oracle Database 12.2 New Features Summary
Application Development ..............................................................................................................
1-1
1.1.1
Database Development Productivity Tools Enhancements...........................................
1-1
1.1.2
Oracle SQL and PL/SQL Improvements..........................................................................
1-3
1.1.3
JSON Support........................................................................................................................
1-5
Availability .......................................................................................................................................
1-5
1.2.1
Online Operations ................................................................................................................
1-5
Big Data and Data Warehousing ...................................................................................................
1-6
1.3.1
Dimensional In-Database Analysis....................................................................................
1-6
Compression and Archiving ..........................................................................................................
1-7
1.4.1
Index Compression Enhancements ...................................................................................
1-7
Database Overall..............................................................................................................................
1-7
1.5.1
Core Database Improvements ............................................................................................
1-7
1.5.2
Pluggable Databases Ease of Adoption.............................................................................
1-9
Oracle Database 12.2 New Features Details
Approximate Query Processing

2.1 About Approximate Query Processing ........................................................................................
2.2 Running Queries Containing Exact Functions Using SQL Functions that Return
2-2
Approximate Values ...........................................................................................................................
2-2
2.3
About Approximate Aggregates ...................................................................................................
2-3
2.4
Using Percentile Functions that Return Approximate Results .................................................
2-5
2.5
Creating Materialized Views Based on Approximate Queries .................................................
2-7
iii
2.6
Refreshing Materialized Views Based on Approximate Queries .............................................
2-7
2.7
Query Rewrite and Materialized Views Based on Approximate Queries ..............................
2-8
2.8
SQL Language Reference Details for Approximate Query Processing ................................. 2-10
APPROX_COUNT_DISTINCT_AGG ............................................................................. 2-10
2.8.2
APPROX_COUNT_DISTINCT_DETAIL........................................................................ 2-11
2.8.3
APPROX_MEDIAN ........................................................................................................... 2-14
2.8.4
APPROX_PERCENTILE.................................................................................................... 2-17
2.8.5
APPROX_PERCENTILE_AGG ........................................................................................ 2-20
2.8.6
APPROX_PERCENTILE_DETAIL................................................................................... 2-20
2.8.7
TO_APPROX_COUNT_DISTINCT ................................................................................. 2-24
2.8.8
TO_APPROX_PERCENTILE ............................................................................................ 2-25
Materialized Views
3.1
About ON STATEMENT Refresh for Materialized Views ........................................................
3-2
3.2
Restrictions on Materialized Views with ON STATEMENT Refresh ......................................
3-2
3.3
Using Real-time Materialized Views ............................................................................................
3-3
3.3.1
Overview of Real-time Materialized Views .....................................................................
3-3
3.4
Creating Real-time Materialized Views........................................................................................
3-5
3.5
Converting an Existing Materialized View into a Real-time Materialized View ...................
3-7
3.6
Listing Real-time Materialized Views...........................................................................................
3-7
3.7
Enabling Query Rewrite to Use Real-time Materialized Views................................................
3-8
3.8
Using Real-time Materialized Views During Query Rewrite ...................................................
3-8
3.9
Using Real-time Materialized Views for Direct Query Access .............................................. 3-10
3.10
Monitoring Materialized View Refresh Operations ............................................................... 3-12

3.10.1
About Materialized View Refresh Statistics ................................................................. 3-13
3.10.2
Overview of Managing Materialized View Refresh Statistics ................................... 3-13
3.10.3
About Data Dictionary Views that Store Materialized View Refresh Statistics...... 3-14
3.10.4
Collecting Materialized View Refresh Statistics .......................................................... 3-15
3.10.5
Retaining Materialized View Refresh Statistics ........................................................... 3-17
3.10.6
Viewing Materialized View Refresh Statistics Settings .............................................. 3-19
3.10.7
Purging Materialized View Refresh Statistics.............................................................. 3-20
3.10.8
Viewing Materialized View Refresh Statistics ............................................................. 3-21
3.10.9
Analyzing Materialized View Refresh Performance Using Refresh Statistics ........ 3-25
Partitioning
4.1
iv
2.8.1
About Creating List-Partitioned Tables........................................................................................
4-1
4.1.1
Creating an Automatic List-Partitioned Table .................................................................
4-1
4.1.2
Creating a Multi-column List-Partitioned Table..............................................................
4-2
4.2
Creating a Table with Read-Only Partitions or Subpartitions ..................................................
4-3
4.3
Filtering Maintenance Operations.................................................................................................
4-4
4.4
Creating a Table for Exchange With a Partitioned Table...........................................................
4-5
4.5
About Splitting Partitions and Subpartitions ..............................................................................
4-6
4.6
Converting a Non-Partitioned Table to a Partitioned Table .....................................................
4-7
10
Handling Data Errors

5.1
Handling Data Errors with SQL ....................................................................................................
5-1
5.2
SQL Language Reference Details for Handling Data Errors.....................................................
5-2
5.2.1
CAST .....................................................................................................................................
5-3
5.2.2
TO_BINARY_DOUBLE ......................................................................................................
5-8
5.2.3
TO_BINARY_FLOAT .........................................................................................................
5-9
5.2.4
TO_DATE ........................................................................................................................... 5-11
5.2.5
TO_DSINTERVAL ............................................................................................................ 5-13
5.2.6
TO_NUMBER ..................................................................................................................... 5-15
5.2.7
TO_TIMESTAMP .............................................................................................................. 5-16
5.2.8
TO_TIMESTAMP_TZ ....................................................................................................... 5-17
5.2.9
TO_YMINTERVAL ........................................................................................................... 5-18
5.2.10
VALIDATE_CONVERSION .......................................................................................... 5-20
Advanced Aggregates for Analysis

6.1
LISTAGG Function ..........................................................................................................................
6-1
6.2
LISTAGG as Aggregate...................................................................................................................
6-2
6.3
SQL Language Reference Details for Advanced Aggregates....................................................
6-4
6.3.1
6-4
LISTAGG ..............................................................................................................................
Moving a Table to a New Segment or Tablespace

7.1
About Moving a Table to a New Segment or Tablespace..........................................................
7-1
7.2
Moving a Table.................................................................................................................................
7-2
Overview of Analytic Views

8.1
What Are Analytic Views? .............................................................................................................
8-1
8.2
Privileges for Analytic Views.........................................................................................................
8-3
8.3
Application Programming Interfaces for Analytic Views .........................................................
8-4
8.4
Compilation States of Analytic Views ..........................................................................................
8-7
8.5
Classifications for Analytic Views.................................................................................................
8-7
8.6
Share Analytic Views with Application Containers...................................................................
8-8
Advanced Index Compression

9.1
Creating an Index Using Advanced Index Compression ..........................................................
9-1
9.2
About Tablespaces with Default Compression Attributes ........................................................
9-2
9.3
Tablespaces with Default Compression Attributes ....................................................................
9-3
9.4
Creating Tablespaces with Default Compression Attributes....................................................
9-3
Longer Identifier Names

10.1
Database Object Naming Rules ................................................................................................ 10-1
Part III
11
Oracle Database 12.1 New Features Summary

11.1
Application Development .......................................................................................................... 11-1

11.1.1
A
A.1
Oracle SQL and PL/SQL Improvements...................................................................... 11-1
DBMS_MVIEW_STATS
Using DBMS_MVIEW_STATS .............................................................................................................. A-1
A.1.1
DBMS_MVIEW_STATS Overview............................................................................................ A-1
A.1.2
DBMS_MVIEW_STATS Security Model .................................................................................. A-1
A.2 Summary of DBMS_MVIEW_STATS Subprograms.......................................................................... A-2

A.2.1
PURGE_REFRESH_STATS Procedure ..................................................................................... A-2
A.2.2
SET_MVREF_STATS_PARAMS Procedure............................................................................. A-3
A.2.3
SET_SYSTEM_DEFAULT Procedure........................................................................................ A-4
Index
vi
List of Examples
2-1
2-2
3-1
3-2
3-3
3-4
3-5
3-6
3-7
3-8
3-9
3-10
3-11
3-12
3-13
3-14
3-15
3-16
3-17
3-18
3-19
3-20
3-21
3-22
3-23
3-24
3-25
3-26
3-27
3-28
4-1
4-2
4-3
4-4
4-5
4-6
5-1
6-1
6-2
7-1
7-2
8-1
8-2
9-1
9-2
Creating a Materialized View Based on Approximate Queries ........................................... 2-7

Refreshing Materialized Views Based on Approximate Queries ........................................ 2-8
Creating a Materialized View with ON STATEMENT Refresh........................................... 3-2
Creating a Real-time Materialized View.................................................................................. 3-6
Converting a Materialized View into a Real-time Materialized View................................. 3-7
Listing Real-time Materialized Views in the Current Users Schema.................................. 3-8
Enabling Query Rewrite for Real-time Materialized Views.................................................. 3-8
Using Real-time Materialized Views During Query Rewrite............................................... 3-9
Creating a Real-Time Materialized View and Using it in Queries..................................... 3-10
Setting Materialized View Refresh Statistics Collection Level for the Database............. 3-16
Disabling Statistics Collection for Materialized View Refresh........................................... 3-16
Setting the Materialized View Statistics Collection Level for the Entire Database......... 3-17
Setting the Materialized View Statistics Collection Level for Multiple Materialized
Views..................................................................................................................................... 3-17
Setting the Retention Period for Materialized View Refresh Statistics ............................ 3-18
Preventing the Purging of Materialized View Refresh Statistics ...................................... 3-18
Using Default Materialized View Refresh Statistics Settings for Retention Period......... 3-19
Setting the Retention Period for a Materialized View......................................................... 3-19
Displaying the Database-level Default Settings for Managing Materialized View
Refresh Statistics.................................................................................................................. 3-20
Displaying the Refresh Statistics Settings for a Set of Materialized Views....................... 3-20
Purging Refresh Statistics for a Materialized View.............................................................. 3-21
Purging Refresh Statistics for All Materialized Views......................................................... 3-21
Displaying Basic Statistics for a Materialized View Refresh Operation............................ 3-22
Displaying Materialized Views Based on their Refresh Times.......................................... 3-22
Listing All Materialized Views Refreshed in a Single Refresh Operation........................ 3-23
Viewing the Parameters Specified During a Materialized View Refresh Operation...... 3-23
Displaying Detailed Statistics for a Materialized View Refresh Operation...................... 3-23
Determining if a Refresh Operation Resulted in PMOPs.................................................... 3-24
Displaying the Number of Rows Modified During a Refresh Operation......................... 3-24
Displaying SQL Statements for Each Step in a Refresh Operation.................................... 3-24
Displaying Refresh Statements Used in the Current Refresh of an Materialized View. 3-24
Creating an automatic list partitioned table............................................................................ 4-2
Creating a multicolumn list-partitioned table......................................................................... 4-2
Creating a table with read-only and read-write partitions................................................... 4-3
Using a filtering clause when performing maintenance operations.................................... 4-5
Using the FOR EXCHANGE WITH clause of CREATE TABLE.......................................... 4-6
Using the MODIFY clause of ALTER TABLE to convert online to a partitioned table.... 4-7
Using VALIDATE_CONVERSION and CAST to Handle Data Conversion Errors.......... 5-2
LISTAGG as Aggregate.............................................................................................................. 6-2
LISTAGG with Return String Exceeding the Maximum Permissible Length.................... 6-2
Moving a Table to a New Tablespace in Online Mode.......................................................... 7-2
Moving a Table and Updating the Tables Indexes................................................................ 7-2
Granting System Privileges........................................................................................................ 8-4
Granting Object Privileges......................................................................................................... 8-4
Enabling Low Level Advanced Index Compression During Index Creation.................... 9-2
Enabling High Level Advanced Index Compression During Index Rebuild..................... 9-2
vii
viii
List of Figures
2-1
Displaying Approximate Aggregates Using SQL Functions................................................ 2-4
ix
List of Tables
3-1
5-1
A-1
A-2
A-3
Data Dictionary Views that Store Materialized View Refresh Statistics...........................

Casting Built-In Data Types.......................................................................................................
PURGE_REFRESH_STATS Procedure Parameters................................................................
SET_MVREF_STATS_PARAMS Procedure Parameters.......................................................
SET_SYSTEM_DEFAULT Procedure Parameters..................................................................
3-14
5-3
A-2
A-3
A-5
xi
xii
Preface
This document describes important last-minute features and changes not included in
the Oracle Database Documentation Library for 12c Release 2 (12.2.0.0.2).
Audience (page xiii)
Documentation Accessibility (page xiii)
Related Documents (page xiii)
Conventions (page xiii)
Audience
Oracle Database New Features Guide is intended for all Oracle Database users.
Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle
Accessibility Program website at http://www.oracle.com/pls/topic/lookup?
ctx=acc&id=docacc.
Access to Oracle Support
Oracle customers that have purchased support have access to electronic support
through My Oracle Support. For information, visit http://www.oracle.com/pls/
topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?
ctx=acc&id=trs if you are hearing impaired.
Related Documents
For more information, see the documentation that ships with this release of Oracle
Database.
For information specific to Oracle Database working on your host operating system,
see your operating system-specific Oracle documentation (specific book titles vary by
operating system) and system release bulletins, if available.
Conventions
The following text conventions are used in this document:
xiii
xiv
Convention
Meaning
boldface
Boldface type indicates graphical user interface elements associated

with an action, or terms defined in text or the glossary.
italic
Italic type indicates book titles, emphasis, or placeholder variables for

which you supply particular values.
monospace
Monospace type indicates commands within a paragraph, URLs, code

in examples, text that appears on the screen, or text that you enter.
Part I
Summary
This section contains overview descriptions of certain Database 12.2 features that are
available in Oracle Database Exadata Express Cloud Service Release 1.0.
Oracle Database 12.2 New Features (page 1-1)
1
This chapter contains overview descriptions of all of the features that are new to
Oracle Database 12.2.
Application Development (page 1-1)
Availability (page 1-5)
Big Data and Data Warehousing (page 1-6)
Compression and Archiving (page 1-7)
Database Overall (page 1-7)
1.1 Application Development

Database Development Productivity Tools Enhancements (page 1-1)
Oracle SQL and PL/SQL Improvements (page 1-3)
JSON Support (page 1-5)
1.1.1 Database Development Productivity Tools Enhancements

Application Express 5.0: All New Calendar (page 1-1)
Application Express 5.0: Improved Application Builder Design (page 1-2)
Application Express 5.0: Interactive Reporting (page 1-2)
Application Express 5.0: Mobile Enhancements (page 1-2)
Application Express 5.0: Modal Dialog Pages (page 1-2)
Application Express 5.0: Packaged Applications (page 1-2)
Application Express 5.0: Page Designer (page 1-3)
Application Express 5.0: Universal Theme (page 1-3)
Application Express 5.0: User Interface Enhancements (page 1-3)
1.1.1.1 Application Express 5.0: All New Calendar

The new calendar component includes built-in support for Month, Week, Day, and
Agenda views, and is much easier to customize. The calendar is based on the popular
FullCalendar library and supports drag and drop, time-based events, and is even
responsive. The ability to easily define duration-based events and restyle the
calendars, makes the new calendar very popular with both developers and end-users.
Oracle Database 12.2 New Features 1-1
Application Development
Oracle Application Express release 5.0 calendars now support duration-based events
and are significantly easier to style.
1.1.1.2 Application Express 5.0: Improved Application Builder Design

Oracle Application Express release 5.0 introduces a new user interface that focuses on
improving the user experience through simplicity and the removal of clutter. The new
design uses a beautiful new color palette, carefully crafted icons, and vastly improved
menus and navigation. The new design also provides improved accessibility and
keyboard support, more intuitive page layouts, and many other enhancements.
Oracle Application Express release 5.0 Application Builder is more intuitive and
productive for developers.
1.1.1.3 Application Express 5.0: Interactive Reporting

Interactive reports have been completely rebuilt in Oracle Application Express release
5.0 to enhance both developer and end-user capabilities. New capabilities include the
ability to define multiple reports on a single page, column pivot, fixed headers, and
modernized actions. You can also restyle interactive report regions using Cascading
Style Sheets (CSS) in a similar manner to other regions within Oracle Application
Express.
Oracle Application Express release 5.0 interactive reports enhances both developer
and end-user capabilities.
1.1.1.4 Application Express 5.0: Mobile Enhancements

You can now build reports that display all of your data on any mobile device by using
reflow table or column toggle. Reflow table wraps each column or changes the display
to allow multiple lines on very small screens. Column toggle enables you to specify
the most important columns to view and those columns that should be hidden, as
necessary, on smaller screens. Panels are now incorporated into mobile applications
and are used to display navigation menus.
Oracle Application Express release 5.0 mobile improvements enable the development
of improved mobile-first applications.
1.1.1.5 Application Express 5.0: Modal Dialog Pages

Now you can easily define modal and non-modal pages, complete with the ability to
use standard page processes. You no longer need to manually edit a page using
JavaScript. Instead, set the display type and the appropriate template and let Oracle
Application Express take care of the rest.
Oracle Application Express release 5.0 modal dialog pages make it easy for developers
to display pages modally, as opposed to writing significant amounts of custom code.
1.1.1.6 Application Express 5.0: Packaged Applications

Oracle Application Express release 5.0 includes a broad collection of point solutions
called packaged applications. These are Application Express applications that you can
use out-of-the-box and that are supported by Oracle. Examples include Project
Tracking, Survey Builder, Meeting Minutes, and Group Calendar. There are 19
productivity applications in all. Additionally, there are 16 sample applications that are
used to showcase the features of Oracle Application Express, from Sample Charts to
Sample Data Loading. Release 5.0 even includes a sample application that
demonstrates the powerful spatial capabilities that are present in every Oracle
Database.
1-2 New Features Guide
Oracle Application Express release 5.0 packaged applications are very popular as
point solutions and learning examples.
1.1.1.7 Application Express 5.0: Page Designer

Page Designer is a modern, intuitive, and exceedingly powerful browser-based
Integrated Development Environment (IDE). As a completely new IDE that is
designed to greatly improve developer productivity, Page Designer enables you to
very quickly develop and maintain your Application Express applications. Page
Designer features a better visual representation of your application pages and
provides an entirely new way of quickly developing pages by using intuitive drag and
drop. The enhanced code editor provides SQL and PL/SQL validation with inline
errors, auto completion, syntax highlighting, search and replace with regex support,
complete with undo and redo support.
Oracle Application Express Page Designer greatly improves developer productivity,
provides a cohesive user experience, better visual representation, intuitive drag and
drop, and an enhanced code editor.
1.1.1.8 Application Express 5.0: Universal Theme

Universal Theme is a new user interface for your applications that have been built
from the ground up for Oracle Application Express release 5.0. It is a simpler, yet more
capable theme that eliminates excessive templates and enables customization using
the built-in Theme Roller and Template Options. The Universal Theme enables
developers to build modern, responsive, and sophisticated applications without
requiring expert knowledge of HTML, Cascading Style Sheet (CSS), or JavaScript.
Oracle Application Express Universal Theme provides a number of new capabilities
including Theme Roller, Template Options, responsive design, and accessibility.
1.1.1.9 Application Express 5.0: User Interface Enhancements

With the development of Universal Theme, there are also several enhancements to the
handling of themes and templates. Oracle Application Express release 5.0 includes
features such as Theme Subscriptions, Template Options, and Theme Styles. These
features give you more granular control over your templates and the HTML that the
Application Express engine produces. It is easier to fully control your application user
interface.
Oracle Application Express release 5.0 enables developers to easily build modern,
responsive, and beautiful applications out-of-the-box.
1.1.2 Oracle SQL and PL/SQL Improvements

Enhanced CAST Function With Error Handling (page 1-4)
New SQL Function VALIDATE_CONVERSION (page 1-4)
Enhanced LISTAGG Functionality (page 1-4)
Approximate Query Processing (page 1-4)
Materialized Views: Real-Time Materialized Views (page 1-4)
Materialized Views: Statement-Level Refresh (page 1-4)
1.1.2.1 Enhanced CAST Function With Error Handling

The existing CAST function is enhanced to return a user-specified value in the case of a
conversion error instead of raising an error.
This new functionality provides more robust and simplified code development.
1.1.2.2 New SQL Function VALIDATE_CONVERSION

The new SQL function, VALIDATE_CONVERSION, determines whether a given input
value can be converted to the requested data type.
The VALIDATE_CONVERSION function provides more robust and simplified code
development.
1.1.2.3 Enhanced LISTAGG Functionality

LISTAGG aggregates the values of a column by concatenating them into a single
string. New functionality has been added for managing situations where the length of
the concatenated string is too long.
Developers can now control the process for managing overflowing LISTAGG
aggregates. This increases the productivity and flexibility of this aggregation function.
1.1.2.4 Approximate Query Processing

This release extends the area of approximate query processing by adding approximate
percentile aggregation. With this feature, the processing of large volumes of data is
significantly faster than the exact aggregation. This is especially true for data sets that
have a large number of distinct values with a negligible deviation from the exact
result.
Approximate query aggregation is a common requirement in today's data analysis. It
optimizes the processing time and resource consumption by orders of magnitude
while providing almost exact results. Approximate query aggregation can be used to
speed up existing processing.
1.1.2.5 Materialized Views: Real-Time Materialized Views

Materialized views can be used for query rewrite even if they are not fully
synchronized with the base tables and are considered stale. Using materialized view
logs for delta computation together with the stale materialized view, the database can
compute the query and return correct results in real time.
For materialized views that can be used for query rewrite all of the time, with the
accurate result being computed in real time, the result is optimized and fast query
processing for best performance. This alleviates the stringent requirement of always
having to have fresh materialized views for the best performance.
1.1.2.6 Materialized Views: Statement-Level Refresh

In addition to ON COMMIT and ON DEMAND refresh, materialized join views can
be refreshed when a DML operation takes place, without the need to commit such a
transaction. This is predominantly relevant for star schema deployments.
The new ON STATEMENT refresh capability provides more flexibility for application
developers to take advantage of materialized view rewrite, especially for complex
transactions involving multiple DML statements. It offers built-in refresh capabilities
that can replace customer-written trigger-based solutions, simplifying an application
while offering higher performance.
Availability
1.1.3 JSON Support

JSON Improvements (page 1-5)
1.1.3.1 JSON Improvements

This release incorporates significant support enhancements for storing and querying
JavaScript Object Notation (JSON) documents for Oracle Database. Of particular
interest are:
Improvements to JSON searching:
The JSON path expressions used with simplified syntax for querying JSON now
support navigating to specific members of an array.
JSON path expressions used with JSON_EXISTS condition now support
predicates.
Improvements to JSON search index:
A new, simplified syntax makes it easier to create a JSON search index.
The JSON search index supports RANGE and LIST partitioned tables.
The JSON search index support range-based searching on numeric values.
The JSON search index can now deal with large keys
New capabilities for generating JSON documents directly from SQL queries.
Support for manipulating JSON documents using PL/SQL. This includes the
ability to make incremental modifications to JSON documents.
Support for optimizing the performance for JSON query operations using Oracle
Database In-Memory.
Support for performing spatial-based queries on JSON documents containing
GeoJSON.
A new Oracle data guide feature that facilitates understanding the structure and
content of your JSON documents.
This feature makes it easier to work with JSON documents stored in an Oracle
database and to generate JSON documents from relational data.
1.2 Availability
Online Operations (page 1-5)
1.2.1 Online Operations

Online Conversion of a Nonpartitioned Table to a Partitioned Table (page 1-6)
Online SPLIT Partition and Subpartition (page 1-6)
Online Table Move (page 1-6)
Big Data and Data Warehousing
1.2.1.1 Online Conversion of a Nonpartitioned Table to a Partitioned Table

Nonpartitioned tables can be converted to partitioned tables online. Indexes are
maintained as part of this operation and can be partitioned as well. The conversion has
no impact on the ongoing DML operations.
The online conversion of a nonpartitioned table to a partitioned table enables any
application to adopt partitioning without application downtime. Customers can adopt
partitioning for any system and evolve tables as needed to benefit from the
partitioning for large tables.
1.2.1.2 Online SPLIT Partition and Subpartition

The partition maintenance operations SPLIT PARTITION and SPLIT
SUBPARTITION can now be executed as online operations for heap organized tables,
allowing the concurrent DML operations with the ongoing partition maintenance
operation.
Allowing any partition maintenance operation to become truly online enables the
customers to schedule and execute all of these operations as needed, without having to
plan around periods of query-only windows. This functionality both increases
application availability and simplifies application development.
1.2.1.3 Online Table Move

Nonpartitioned tables can be moved as an online operation without blocking any
concurrent DML operations. A table move operation now also supports automatic
index maintenance as part of the move.
Data maintenance on nonpartitioned tables does not require any maintenance window
since it does not impact any DML or query operation.
1.3 Big Data and Data Warehousing

Dimensional In-Database Analysis (page 1-6)
1.3.1 Dimensional In-Database Analysis

Analytic views provide application developers with the ability to define a dimensional
query and calculation layer over tables and other objects in the database. Analytic
views simplify business intelligence application development, enhance data sets with
dimensional, hierarchical and time series calculations, and allow metadata and
calculation definitions to be centrally defined and maintained in Oracle Database.
Analytic Views (page 1-6)
1.3.1.1 Analytic Views

Analytic views provide a business intelligence layer over a star schema, making it easy
to extend the data set with hierarchies, levels, aggregate data, and calculated
measures. The analytic view feature includes the new DDL statements CREATE
ATTRIBUTE DIMENSION, CREATE HIERARCHY and CREATE ANALYTIC VIEW and
their related ALTER and DROP statements, new calculated measure expression syntax,
and new data dictionary views.
Analytic views allow data warehouse and business intelligence application developers
to extend the star schema with time series and other calculations, making data more
Compression and Archiving
valuable to business users and eliminating the need to define calculations within the
application.
Analytic views can be queried with simple SQL queries, simplifying application
development by eliminating the need for complex SQL generators. Calculations can be
defined in the analytic view and can be selected by including the measure name in the
SQL select list.
Analytic views promote consistency across applications. By defining aggregation and
calculation rules centrally in the database, the risk of inconsistent results in different
reporting tools is reduced or eliminated.
1.4 Compression and Archiving

Index Compression Enhancements (page 1-7)
1.4.1 Index Compression Enhancements

Advanced Index Compression (page 1-7)
1.4.1.1 Advanced Index Compression

Prior to this release, the only form of advanced index compression was low
compression. Now you can also specify high compression. High compression provides
even more space savings than low compression.
Indexes consume a large amount of storage within many databases. The high level of
advanced index compression provides significant space savings while also improving
performance for queries that are executed using indexes. High compression offers the
following advantages over low compression:
Gives higher compression ratios in most cases.
Employs more complex compression algorithms than advanced low compression.
Stores data in a compression unit, which is a special on-disk format.
1.5 Database Overall

Core Database Improvements (page 1-7)
Pluggable Databases Ease of Adoption (page 1-9)
1.5.1 Core Database Improvements

Core database improvements.
Long Identifiers (page 1-8)
Text: Read-Only MDATA Sections (page 1-8)
Text: Sentiment Analysis and Collocates (page 1-8)
Partitioning: Auto-List Partitioning (page 1-8)
Partitioning: Multi-Column List Partitioning (page 1-8)
Partitioning: Read-Only Partitions (page 1-8)
Database Overall
Partitioning: Table Creation for Partition Exchange (page 1-9)

Partitioning: Filtered Partition Maintenance Operations (page 1-9)
Materialized Views: Refresh Statistics History (page 1-9)
1.5.1.1 Long Identifiers

The maximum length of identifiers is increased to 128 bytes for most identifiers, up
from 30 bytes in previous releases.
Providing longer identifiers gives customers greater flexibility in defining their
naming schemes, such as longer and more expressive table names. Having longer
identifiers also enables object name migration between databases with different
character sets, such as Thai to Unicode.
1.5.1.2 Text: Read-Only MDATA Sections

Normal MDATA sections can be updated without reindexing the entire document, but
there is a performance cost for doing so. Now you have the option of specifying
MDATA sections as read-only, which means they can only be changed when the
document is updated and the index is synchronized.
This feature provides better performance for queries because there is no extra cursor
required to handle read-only MDATA sections. Reducing the number of cursors
required may also prevent exceeding the limit of the OPEN_CURSORS system
parameter.
1.5.1.3 Text: Sentiment Analysis and Collocates

Oracle Text supports sentiment analysis and collocates. Sentiment analysis provides
identification of positive and negative trends associated with search terms.
The identification of positive or negative trends associated with search terms allows
the building of richer search applications.
1.5.1.4 Partitioning: Auto-List Partitioning

The database automatically creates a separate (new) partition for every distinct
partition key value of the table.
Auto-list partitioning removes the management burden from the DBAs to manually
maintain a list of partitioned tables for a large number of distinct key values that
require individual partitions. It also automatically copes with the unplanned partition
key values without the need of a DEFAULT partition.
1.5.1.5 Partitioning: Multi-Column List Partitioning

List partitioning functionality is expanded to allow multiple partition key columns.
Use multiple columns to define the partitioning criteria for list partitioned
tables enables new classes of applications to benefit from partitioning.
1.5.1.6 Partitioning: Read-Only Partitions

Partitions and sub-partitions can be individually set to a read-only state. This then
disallows DML operations on these read-only partitions and sub-partitions. This is an
extension to the existing read-only table functionality.
Read-only partitions and subpartitions enables fine-grained control over DML activity.
This enhances the data management capabilities of partitioned tables.
Database Overall
1.5.1.7 Partitioning: Table Creation for Partition Exchange

A new DDL command allows the creation of a table that exactly matches the shape of
a partitioned table and is therefore eligible for a partition or subpartition exchange of a
partitioned table. Note that indexes are not created as part of this command.
Creating a table that qualifies for a partition or subpartition exchange can be a tedious
task for older tables that have had various structural changes and reorganizations.
With this new DDL, the task becomes very simple and straightforward to implement.
It also adds some implicit business context to such an operation, as compared to a
CREATE TABLE AS SELECT command.
1.5.1.8 Partitioning: Filtered Partition Maintenance Operations

Partition maintenance operations can now be combined with data filtering. For
example, a partition can be compressed and moved to a different tablespace, but only
the data satisfying the specific filter criteria is actually moved.
Partition maintenance operations with data filtering combine two of the most common
data maintenance operations. This combination not only makes the partition
maintenance operation more flexible and powerful, but also makes it more performant
and less resource intensive compared to the two separate data management
operations.
1.5.1.9 Materialized Views: Refresh Statistics History

Materialized Views Refresh statistics can be collected in Oracle Database in varying
degrees of granularity to provide historical data for analysis and reporting.
Storing historical Materialized Views Refresh statistics provides insight into how the
materialized view ecosystem (or a single, specific materialized view) has evolved. This
data provides unique insight, both for historical analysis as well as for diagnosis
purposes.
1.5.2 Pluggable Databases Ease of Adoption

Heat Map and Automatic Data Optimization Support for CDBs (page 1-9)
1.5.2.1 Heat Map and Automatic Data Optimization Support for CDBs
Heat Map and Automatic Data Optimization (ADO) now support multitenant
container databases (CDBs).
Heat Map and ADO are now usable in databases that are consolidated using Oracle
Multitenant, providing the benefits of automatic tracking of access patterns at the
block and segment level, and automatic storage and compression tiering of data based
on user-defined policies.
Database Overall
Part II
Oracle Database 12.2 New Features Details
Approximate Query Processing (page 2-1)
Materialized Views (page 3-1)
Partitioning (page 4-1)
Handling Data Errors (page 5-1)
Advanced Aggregates for Analysis (page 6-1)
Moving a Table to a New Segment or Tablespace (page 7-1)
Overview of Analytic Views (page 8-1)
Advanced Index Compression (page 9-1)
Longer Identifier Names (page 10-1)
2
Approximate Query Processing
Approximate query processing obtains approximate results with negligible deviation
from the exact result while saving processing resources and dramatically increasing
the processing of resources.
This chapter describes how to use some of the new features related to approximate
query processing.
About Approximate Query Processing (page 2-2)
Approximate query processing uses SQL functions to provide real-time
responses to explorative queries where approximations are acceptable. A
query containing SQL functions that return approximate results is
referred to as an approximate query.
Running Queries Containing Exact Functions Using SQL Functions that Return
Approximate Values (page 2-2)
Queries containing exact functions can be run by using the
corresponding SQL functions that return approximate results, without
modifying the queries. This enables you to run existing applications,
without modifications, by using the corresponding SQL functions that
return approximate results.
About Approximate Aggregates (page 2-3)
Approximate aggregates are computed using SQL functions that return
approximate results. They are used primarily in data exploration queries
where exact values are not required and approximations are acceptable.
Using Percentile Functions that Return Approximate Results (page 2-5)
Oracle Database provides a set of SQL functions that return approximate
percentile results. These functions can be used to monitor quality, track
social media activity, monitor performance, and search for outliers
within a data set.
Creating Materialized Views Based on Approximate Queries (page 2-7)
A materialized view based on approximate queries uses SQL functions
that return approximate functions in its defining query.
Refreshing Materialized Views Based on Approximate Queries (page 2-7)
Oracle Database performs fast refresh for materialized views that are
defined using approximate queries.
Query Rewrite and Materialized Views Based on Approximate Queries
(page 2-8)
Queries containing SQL functions that return approximate results are
automatically rewritten to use a matching materialized view, if these
queries can be answered using the materialized view.
SQL Language Reference Details for Approximate Query Processing (page 2-10)
Approximate Query Processing 2-1
About Approximate Query Processing
2.1 About Approximate Query Processing

Approximate query processing uses SQL functions to provide real-time responses to
explorative queries where approximations are acceptable. A query containing SQL
functions that return approximate results is referred to as an approximate query.
Business intelligence (BI) applications extensively use aggregate functions, including
analytic functions, to provide answers to common business queries. For some types of
queries, when the data set is extremely large, providing exact answers can be resource
intensive. For example, counting the number of unique customer sessions on a website
or establishing the median house price within each zip code across a state. In certain
scenarios, these types of queries may not require exact answers because you are more
interested in approximate trends or patterns, which can then be used to drive further
analysis. Approximate query processing is primarily used in data discovery
applications to return quick answers to explorative queries. Users typically want to
locate interesting data points within large amounts of data and then drill down to
uncover further levels of detail. For explorative queries, quick responses are more
important than exact values.
Oracle provides a set of SQL functions that enable you to obtain approximate results
with negligible deviation from the exact result. There are additional approximate
functions that support materialized view based summary aggregation strategies. The
functions that provide approximate results are as follows:
APPROX_COUNT_DISTINCT
APPROX_COUNT_DISTINCT_DETAIL
APPROX_COUNT_DISTINCT_AGG
TO_APPROX_COUNT_DISTINCT
APPROX_MEDIAN
APPROX_PERCENTILE
APPROX_PERCENTILE_DETAIL
APPROX_PERCENTILE_AGG
TO_APPROX_PERCENTILE
Approximate query processing can be used without any changes to your existing
code. When you set the appropriate initialization parameters, Oracle Database
replaces exact functions in queries with the corresponding SQL functions that return
approximate results.
2.2 Running Queries Containing Exact Functions Using SQL Functions

that Return Approximate Values
Queries containing exact functions can be run by using the corresponding SQL
functions that return approximate results, without modifying the queries. This enables
you to run existing applications, without modifications, by using the corresponding
SQL functions that return approximate results.
Oracle Database provides the following initialization parameters to indicate that exact
functions must be replaced with the corresponding SQL functions that return
About Approximate Aggregates
approximate results at runtime: approx_for_aggregation,

approx_for_count_distinct, and approx_for_percentile. You can replace
all exact functions at runtime with the corresponding functions that return
approximate results. If you need more fine-grained control over the list of functions
that must be replaced with their corresponding approximate versions, then you can
specify the type of functions that must be replaced at runtime. For example, if a query
contains COUNT(DISTINCT), then setting approx_for_aggregation to TRUE
results in this query being run using APPROX_COUNT_DISTINCT instead of
COUNT(DISTINCT).
To run all queries using the corresponding SQL functions that return approximate
results instead of the specified SQL functions:
Set the approx_for_aggregation initialization parameter to TRUE for the
current session or for the entire database. This parameter acts as an umbrella
parameter for enabling the use of functions that return approximate results. Setting
this is equivalent to setting the APPROX_COUNT_DISTINCT and
APPROX_FOR_PERCENTILE parameters.
The following command sets approx_for_aggregation to true for the current
session:
alter session set approx_for_aggregation = 'TRUE';
To replace only the COUNT(DISTINCT) function in queries with the

APPROX_COUNT_DISTINCT function:
Set the approx_for_count_distinct initialization parameter to TRUE for the
current session or for the entire database.
To replace percentile functions with the corresponding functions that return
approximate results:
Set approx_for_percentile to PERCENTILE_CONT, PERCENTILE_DISC, or
ALL (replaces all percentile functions) for the current session or for the entire
database. The default value of this parameter is NONE.
2.3 About Approximate Aggregates

Approximate aggregates are computed using SQL functions that return approximate
results. They are used primarily in data exploration queries where exact values are not
required and approximations are acceptable.
The APPROX_COUNT_DISTINCT function returns the approximate number of rows
containing a distinct value for a specified expression. The
APPROX_COUNT_DISTINCT_DETAIL and APPROX_COUNT_DISTINCT_AGG functions
enable you to compute varying aggregated levels of approximate distinct value counts
within specified groupings. The result of these aggregations can be stored in tables or
materialized views for further analysis or answering user queries.
The APPROX_COUNT_DISTINCT_DETAIL function creates a base-level summary, in
binary format, containing tuples for all the dimensions listed in the WHERE clause. The
APPROX_COUNT_DISTINCT_AGG function uses the data generated by the
APPROX_COUNT_DISTINCT_DETAIL function to extract the higher level tuples in
binary format. This avoids having to rerun the original calculation (in this case, the
calculation with APPROX_COUNT_DISTINCT). The aggregate data that uses a binary
format is converted into a human-readable format using
TO_APPROX_COUNT_DISTINCT.
About Approximate Aggregates
Figure 2-1 (page 2-4) describes an example of using

APPROX_COUNT_DISTINCT_DETAIL to obtain the approximate number of distinct
products sold each month. The sales data selected from the my_sales table is
aggregated by year and month and stored in the SALES_APPROX_MONTH table using a
query such as the following:
INSERT INTO sales_approx_month
(SELECT year, month, APPROX_COUNT_DISTINCT_DETAIL(prod_id) approx_month
FROM my_sales
GROUP BY year, month);
Notice that the values stored in approx_month are binary values. Use the
TO_APPROX_COUNT_DISTINCT function to display these binary values in human
readable format. To display the distinct number of products sold, aggregated by year
and month, use the TO_APPROX_COUNT_DISTINCT function on the approx_month
column. To display data aggregated by year, use the TO_APPROX_COUNT_DISTINCT
function along with the APPROX_COUNT_DISTINCT_AGG function on the data stored
in the approx_month column.
Figure 2-1
Displaying Approximate Aggregates Using SQL Functions

my_sales table
year
month
prod_id
...
2010
2010
2010
.
.
2010
2010
.
.
2011
2011
2011
2011
.
.
1
1
1
.
.
7
7
.
.
11
12
12
12
.
.
9310
10600
9425
.
.
1490
3690
.
.
24595
270
10885
6365
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
sales_approx_month table
year
month
approx_month=
(approx_count_distinct
_detail(prod_id))
2010
2010
2010
.
.
2011
2011
.
.
1
2
3
.
.
11
12
.
.
101101001011
000110110100
110100110111
.
.
100110110110
011010110101
.
.
Approximate sales data aggregated by

year, month
year
month
to_approx_count_
distinct
(approx_month)
2010
2010
2010
.
.
2011
2011
.
.
1
2
3
.
.
11
12
.
.
40
100
158
.
.
561
89
.
.
Approximate sales data

aggregated by year
year
to_approx_count_distinct
(approx_count_distinct_agg
(approx_month))
2010
2011
.
.
1236
1865
.
.
Another approach to computing the approximate number of distinct products sold

each year could be to use the APPROX_COUNT_DISTINCT_AGG to aggregate the
monthly detail stored in the SALES_APPROX_MONTH table and store the results in a
table or materialized view.
Properties of SQL Functions that Return Approximate Percentile Results
SQL functions that provide approximate percentile results include
APPROX_PERCENTILE, APPROX_PERCENTILE_DETAIL, and
Using Percentile Functions that Return Approximate Results
APPROX_PERCENTILE_AGG. These functions have the following additional

properties:
ERROR_RATE
Indicates the accuracy of the interpolated percentile values by computing the error
rate of the approximate calculation
CONFIDENCE
Indicates the confidence in the accuracy of the error rate (when error rate is
specified)
DETERMINISTIC
Controls the algorithm used to calculate approximations
If you need consistent and repeatable results, then use DETERMINISTIC. This
would typically be the case where results need to be shared with other users
See Also:
APPROX_COUNT_DISTINCT, APPROX_COUNT_DISTINCT_DETAIL,
APPROX_COUNT_DISTINCT_AGG, and TO_APPROX_COUNT_DISTINCT in
SQL Language Reference Details for Approximate Query Processing
(page 2-10)
2.4 Using Percentile Functions that Return Approximate Results

Oracle Database provides a set of SQL functions that return approximate percentile
results. These functions can be used to monitor quality, track social media activity,
monitor performance, and search for outliers within a data set.
The following SQL functions compute and display approximate percentile results:
APPROX_PERCENTILE
Returns an approximate interpolated value that falls into the percentile value with
respect to a sort specification. It can process large amounts of data significantly
faster than the PERCENTILE_CONT with negligible deviation from the exact result.
Calculates approximate percentile information, called a detail, within a set of data
that is specified using a GROUP BY clause. Detail information created with this
function is stored in binary format and is meant to be consumed by both the
TO_APPROX_PERCENTILE and APPROX_PERCENT_DETAIL_AGG functions.
Performs aggregations on the details created using the
APPROX_PERCENTILE_DETAIL function.
TO_APPROX_PECENTILE
Displays the results of detail or aggregation, which are stored as BLOB values, in
human readable format.
The detail and the higher level aggregated data can be stored in tables or materialized
views for further analysis.
Using Percentile Functions that Return Approximate Results
Example: Displaying Approximate Percentile Sales Data Within a Country or

State
This example uses APPROX_PERCENTILE_DETAIL to perform percentile calculations
once, store the results in table, and then perform approximate aggregations based on
the stored data. The TO_APPROX_PERCENTILE function is used to display the results
of the percentile calculations in human-readable format.
1. Use APPROX_PERCENTILE_DETAIL to calculate the approximate percentile of the
amount of sales in each state and store the results in a table called
approx_sales_percentile_detail.
CREATE TABLE approx_sales_percentile_detail AS
SELECT c.country_id country, c.cust_state_province state,
approx_percentile_detail(amount_sold) detail
FROM sales s, customers c
WHERE s.cust_id = c.cust_id
GROUP BY c.country_id, c.cust_state_province;
2. Use TO_APPROX_PERCENTILE to query the detail and aggregate values stored in
the table and display these values in human-readable format.
The following statement uses the APPROX_PERCENTILE_AGG function to further

aggregate the detail data stored in the approx_sales_percentile_detail table.
The TO_APPROX_PERCENTILE function displays the aggregated results in humanreadable format.
SELECT country, to_approx_percentile(approx_percentile_agg(detail),0.5)
median_amt_sold
FROM approx_sales_percentile_detail
GROUP BY country
ORDER BY country;
COUNTRY
---------52769
52770
52771
52772
52773
52774
52775
52776
52777
52778
52779
52782
52785
52786
52787
52788
52789
52790
MEDIAN_AMT_SOLD
--------------33.5
35.92
44.99
35.55
29.61
35.55
42.09
34.67
38.1
38.35
38.67
36.89
22.99
44.99
27.99
27.13
37.79
33.69
18 rows selected.
Creating Materialized Views Based on Approximate Queries
See Also:
APROX_PERCENTILE, APPROX_PERCENTILE_DETAIL,
APPROX_PERCENTILE_AGG, and TO_APPROX_PERCENTILE in SQL
Language Reference Details for Approximate Query Processing (page 2-10)
2.5 Creating Materialized Views Based on Approximate Queries

A materialized view based on approximate queries uses SQL functions that return
approximate functions in its defining query.
You can compute summary and aggregate approximations and store these results in
materialized views for further analysis or querying. The summary approximation,
which computes approximate aggregates for all dimensions within a group of rows,
can be used to perform detailed aggregation. You can further aggregate the summary
data to obtain aggregate approximations that can be used for high-level analysis so
that the Oracle Database does not scan the base tables again to compute higher-level
aggregates. Oracle Database does not scan the base tables again to compute higherlevel aggregates. It just uses the existing aggregated results to compute the higherlevel aggregates. For example, you can create a summary approximation that stores
the approximate number of products sold within each state and within each country.
This aggregate approximation is then used to return the approximate distinct number
of products within each country.
To create a materialized view containing SQL functions that return approximate
results:
Run the CREATE MATERIALIZED VIEW statement, with the defining query
containing the appropriate functions
For example, use the APPROX_PERCENTILE function in the defining query of the
materialized view.
Example 2-1
Creating a Materialized View Based on Approximate Queries
The following example creates a materialized view that stores the approximate
number of distinct products that are sold on each day.
CREATE MATERIALIZED VIEW approx_count_distinct_pdt_mv
ENABLE QUERY REWRITE AS
SELECT t.calendar_year, t.calendar_month_number, t.day_number_in_month,
approx_count_distinct(prod_id) daily_detail
FROM sales s, times t
WHERE s.time_id = t.time_id
GROUP BY t.calendar_year, t.calendar_month_number, t.day_number_in_month;
2.6 Refreshing Materialized Views Based on Approximate Queries

Oracle Database performs fast refresh for materialized views that are defined using
approximate queries.
Approximate queries contain SQL functions that return approximate results.
Refreshing materialized views containing approximate queries depends on the DML
operation that is performed on the base tables of the materialized view.
For insert operations, fast refresh is used for materialized views containing detailed
percentiles.
For delete operations or any DML operation that leads to deletion (such as UPDATE
or MERGE), fast refresh is used for materialized views containing approximate
aggregations only if the materialized view does not contain a WHERE clause.
Materialized view logs must exist on all base tables of a materialized view that needs
to be fast refreshed.
To refresh a materialized view that is based on an approximate query:
Run the DBMS_REFRESH.REFRESH procedure to perform a fast refresh of the
materialized view
Example 2-2
Refreshing Materialized Views Based on Approximate Queries
The following example performs a fast refresh of the materialized view

percentile_per_pdt that is based on an approximate query.
exec DBMS_MVIEW.REFRESH('percentile_per_pdt', method => 'F');
2.7 Query Rewrite and Materialized Views Based on Approximate Queries

Queries containing SQL functions that return approximate results are automatically
rewritten to use a matching materialized view, if these queries can be answered using
the materialized view.
For a query containing SQL functions that return approximate results to be rewritten
using a materialized view that is based on an approximate query, ensure that query
rewrite is enabled for the materialized view. Query rewrite must also be enabled either
at the database level or for the current session.
Consider the materialized view approx_count_distinct_pdt_mv that was
defined as follows:
CREATE MATERIALIZED VIEW approx_count_distinct_pdt_mv
approx_count_distinct_detail(prod_id) daily_detail
When a query that matches the defining query of

approx_count_distinct_pdt_mv is run, and the prerequisites described in this
section are met, the query is automatically rewritten to use this materialized view. The
following query is rewritten to use approx_count_distinct_pdt_mv, as indicated
by the execution plan generated for the query.
approx_count_distinct(prod_id)
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------Plan hash value: 2307354865
-----------------------------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes
| Cost (%CPU)| Time
|
-----------------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT

|
| 1460 | 74460
| 205 (0)| 00:00:01 |
| 1 | MAT_VIEW REWRITE ACCESS FULL| APPROX_COUNT_DISTINCT_PDT_MV | 1460 | 74460
| 205 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------8 rows selected.
The following query is also rewritten to use approx_count_distinct_pdt_mv as

indicated by the execution plan. Note that this query aggregates data to a higher level
than that defined by the defining query of approx_count_distinct_pdt_mv.
SELECT t.calendar_year, t.calendar_month_number, approx_count_distinct(prod_id)
GROUP BY t.calendar_year, t.calendar_month_number;
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------Plan hash value: 827336432
------------------------------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes
| Cost (%CPU)| Time
|
------------------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT
|
|
34 | 1632
| 206 (1)| 00:00:01 |
| 1 | HASH GROUP BY APPROX
|
|
34 | 1632
| 206 (1)| 00:00:01 |
| 2 | MAT_VIEW REWRITE ACCESS FULL| APPROX_COUNT_DISTINCT_PDT_MV | 1460 | 70080
| 205 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------------9 rows selected.
Rewriting Queries with Exact Functions to Use Materialized Views that Contain
Approximate Functions
If you set database initialization parameters that substitute exact functions with the
corresponding SQL functions that return approximate values, then the optimizer can
rewrite queries containing exact functions to use materialized views that are defined
using the approximate versions of the same functions. You need not rewrite the query
to use the corresponding approximate functions.
For example, if the approx_for_count_distinct parameter is set to TRUE, then
the optimizer rewrites the following query to use the materialized view
approx_count_distinct_pdt_mv:
ALTER SESSION SET approx_for_count_distinct = TRUE;
SELECT t.calendar_year, t.calendar_month_number, COUNT (DISTINCT prod_id)
GROUP BY t.calendar_year, t.calendar_month_number;
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------Plan hash value: 827336432
------------------------------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost (%CPU)|
Time
|
------------------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT
|
|
34 |
1632 |
206
(1)| 00:00:01 |
|
|
34 |
1632 |
206 (1)| 00:00:01 |
| 2 | MAT_VIEW REWRITE ACCESS FULL| APPROX_COUNT_DISTINCT_PDT_MV |
1460 |
70080 |
205 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------------9 rows selected.
Observe that the above execution plan is the same as the execution plan that was
generated when the query uses the approx_count_distinct in the previous
example.
2.8 SQL Language Reference Details for Approximate Query Processing

This section describes the SQL functions that enable you to perform approximate
query processing.
APPROX_COUNT_DISTINCT_AGG (page 2-10)
APPROX_COUNT_DISTINCT_DETAIL (page 2-11)
APPROX_MEDIAN (page 2-14)
APPROX_PERCENTILE (page 2-17)
APPROX_PERCENTILE_AGG (page 2-20)
APPROX_PERCENTILE_DETAIL (page 2-20)
TO_APPROX_COUNT_DISTINCT (page 2-24)
TO_APPROX_PERCENTILE (page 2-25)
2.8.1 APPROX_COUNT_DISTINCT_AGG
Syntax
APPROX_COUNT_DISTINCT_AGG
detail
Purpose
APPROX_COUNT_DISTINCT_AGG takes as its input a column of details containing
information about approximate distinct value counts, and enables you to perform
aggregations of those counts.
For detail, specify a column of details created by the

APPROX_COUNT_DISTINCT_DETAIL function or the
APPROX_COUNT_DISTINCT_AGG function. This column is of data type BLOB.
You can specify this function in a SELECT statement with a GROUP BY clause to
aggregate the information contained in the details within each group of rows and
return a single detail for each group.
This function returns a BLOB value, called a detail, which contains information about
the count aggregations in a special format. You can store details returned by this
function in a table or materialized view, and then again use the
APPROX_COUNT_DISTINCT_AGG function to further aggregate those details, or use
the TO_APPROX_COUNT_DISTINCT function to convert the detail values to humanreadable NUMBER values.
See Also:

Examples
Refer to APPROX_COUNT_DISTINCT_AGG: Examples (page 2-12) for examples of
using the APPROX_COUNT_DISTINCT_AGG function in conjunction with the
APPROX_COUNT_DISTINCT_DETAIL and TO_APPROX_COUNT_DISTINCT functions.
2.8.2 APPROX_COUNT_DISTINCT_DETAIL
Syntax
APPROX_COUNT_DISTINCT_DETAIL
expr
Purpose
APPROX_COUNT_DISTINCT_DETAIL calculates information about the approximate
number of rows that contain a distinct value for expr and returns a BLOB value, called
a detail, which contains that information in a special format.
For expr, you can specify a column of any scalar data type other than BFILE, BLOB,
CLOB, LONG, LONG RAW, or NCLOB. This function ignores rows for which the value of
expr is null.
This function is commonly used with the GROUP BY clause in a SELECT statement.
When used in this way, it calculates approximate distinct value count information for
expr within each group of rows and returns a single detail for each group.
The details returned by APPROX_COUNT_DISTINCT_DETAIL can be used as input to
the APPROX_COUNT_DISTINCT_AGG function, which enables you to perform
aggregations of the details, or the TO_APPROX_COUNT_DISTINCT function, which
converts a detail to a human-readable distinct count value. You can use these three
functions together to perform resource-intensive approximate count calculations once,
store the resulting details, and then perform efficient aggregations and queries on
those details. For example:
1.
Use the APPROX_COUNT_DISTINCT_DETAIL function to calculate approximate

distinct value count information and store the resulting details in a table or
materialized view. These could be highly-granular details, such as city
demographic counts or daily sales counts.
2.
Use the APPROX_COUNT_DISTINCT_AGG function to aggregate the details

obtained in the previous step and store the resulting details in a table or
materialized view. These could be details of lower granularity, such as state
demographic counts or monthly sales counts.
3.
Use the TO_APPROX_COUNT_DISTINCT function to convert the stored detail

values to human-readable NUMBER values. You can use the
TO_APPROX_COUNT_DISTINCT function to query detail values created by the
APPROX_COUNT_DISTNCT_AGG function.
See Also:
APPROX_COUNT_DISTINCT_AGG (page 2-10)

Examples
The examples in this section demonstrate how to use the
APPROX_COUNT_DISTINCT_DETAIL, APPROX_COUNT_DISTINCT_AGG, and
TO_APPROX_COUNT_DISTINCT functions together to perform resource-intensive
approximate count calculations once, store the resulting details, and then perform
efficient aggregations and queries on those details.
APPROX_COUNT_DISTINCT_DETAIL: Example
The following statement queries the tables sh.times and sh.sales for the
approximate number of distinct products sold each day. The
APPROX_COUNT_DISTINCT_DETAIL function returns the information in a detail,
called daily_detail, for each day that products were sold. The returned details are
stored in a materialized view called daily_prod_count_mv.
CREATE MATERIALIZED VIEW daily_prod_count_mv AS
SELECT t.calendar_year year,
t.calendar_month_number month,
t.day_number_in_month day,
APPROX_COUNT_DISTINCT_DETAIL(s.prod_id) daily_detail
FROM times t, sales s
WHERE t.time_id = s.time_id
APPROX_COUNT_DISTINCT_AGG: Examples
The following statement uses the APPROX_COUNT_DISTINCT_AGG function to read
the daily details stored in daily_prod_count_mv and create aggregated details that
contain the approximate number of distinct products sold each month. These
aggregated details are stored in a materialized view called
monthly_prod_count_mv.
CREATE MATERIALIZED VIEW monthly_prod_count_mv AS
SELECT year,
month,
APPROX_COUNT_DISTINCT_AGG(daily_detail) monthly_detail
FROM daily_prod_count_mv
GROUP BY year, month;
The following statement is similar to the previous statement, except it creates

aggregated details that contain the approximate number of distinct products sold each
year. These aggregated details are stored in a materialized view called
annual_prod_count_mv.
CREATE MATERIALIZED VIEW annual_prod_count_mv AS
SELECT year,
APPROX_COUNT_DISTINCT_AGG(daily_detail) annual_detail
GROUP BY year;
TO_APPROX_COUNT_DISTINCT: Examples
The following statement uses the TO_APPROX_COUNT_DISTINCT function to query
the daily detail information stored in daily_prod_count_mv and return the
approximate number of distinct products sold each day:
SELECT year,
month,
day,
TO_APPROX_COUNT_DISTINCT(daily_detail) "NUM PRODUCTS"
ORDER BY year, month, day;
YEAR
MONTH
DAY NUM PRODUCTS
---------- ---------- ---------- -----------1998
1
1
24
1998
1
2
25
1998
1
3
11
1998
1
4
34
1998
1
5
10
1998
1
6
8
1998
1
7
37
1998
1
8
26
1998
1
9
25
1998
1
10
38
. . .

the monthly detail information stored in monthly_prod_count_mv and return the
approximate number of distinct products sold each month:
SELECT year,
month,
TO_APPROX_COUNT_DISTINCT(monthly_detail) "NUM PRODUCTS"
FROM monthly_prod_count_mv
ORDER BY year, month;
YEAR
MONTH NUM PRODUCTS
---------- ---------- -----------1998
1
57
1998
2
56
1998
3
55
1998
4
49
1998
5
49
1998
6
48
1998
7
54
1998
1998
1998
8
9
10
56
55
57
. . .

the annual detail information stored in annual_prod_count_mv and return the
approximate number of distinct products sold each year:
SELECT year,
TO_APPROX_COUNT_DISTINCT(annual_detail) "NUM PRODUCTS"
FROM annual_prod_count_mv
ORDER BY year;
YEAR NUM PRODUCTS
---------- -----------1998
60
1999
72
2000
72
2001
71
2.8.3 APPROX_MEDIAN
Syntax
ERROR_RATE
CONFIDENCE
,
DETERMINISTIC
APPROX_MEDIAN
expr
Purpose
APPROX_MEDIAN is an approximate inverse distribution function that assumes a
continuous distribution model. It takes a numeric or datetime value and returns an
approximate middle value or an approximate interpolated value that would be the
middle value once the values are sorted. Nulls are ignored in the calculation.
This function provides an alternative to the MEDIAN function, which returns the exact
middle value or interpolated value. APPROX_MEDIAN processes large amounts of data
significantly faster than MEDIAN, with negligible deviation from the exact result.
For expr, specify the expression for which the approximate median value is being
calculated. The acceptable data types for expr, and the return value data type for this
function, depend on the algorithm that you specify with the DETERMINISTIC clause.
DETERMINISTIC
This clause lets you specify the type of algorithm this function uses to calculate the
approximate median value.
If you specify DETERMINISTIC, then this function calculates a deterministic
approximate median value. In this case, expr must evaluate to a numeric value, or
to a value that can be implicitly converted to a numeric value. The function returns
the same data type as the numeric data type of its argument.
If you omit DETERMINSTIC, then this function calculates a nondeterministic
approximate median value. In this case, expr must evaluate to a numeric or
datetime value, or to a value that can be implicitly converted to a numeric or
datetime value. The function returns the same data type as the numeric or datetime
data type of its argument.
ERROR_RATE | CONFIDENCE
These clauses let you determine the accuracy of the value calculated by this function. If
you specify one of these clauses, then instead of returning the approximate median
value for expr, the function returns a decimal value from 0 to 1, inclusive, which
represents one of the following values:
If you specify ERROR_RATE, then the return value represents the error rate for the
approximate median value calculation for expr.
If you specify CONFIDENCE, then the return value represents the confidence level
for the error rate that is returned when you specify ERROR_RATE.
Examples
The following query returns the deterministic approximate median salary for each
department in the hr.employees table:
SELECT department_id "Department",
APPROX_MEDIAN(salary DETERMINISTIC) "Median Salary"
FROM employees
GROUP BY department_id
ORDER BY department_id;
Department Median Salary
---------- ------------10
4400
20
6000
30
2765
40
6500
50
3100
60
4800
70
10000
80
9003
90
17000
100
7739
110
8300
7000
The following query returns the error rates for the approximate median salaries that
were returned by the previous query:
APPROX_MEDIAN(salary DETERMINISTIC, 'ERROR_RATE') "Error Rate"
FROM employees
Department
---------10
20
30
40
50
60
70
80
Error Rate
---------.002718282
.021746255
.021746255
.002718282
.019027973
.019027973
.002718282
.021746255
90 .021746255
100 .019027973
110 .019027973
.002718282
The following query returns the confidence levels for the error rates that were
returned by the previous query:
APPROX_MEDIAN(salary DETERMINISTIC, 'CONFIDENCE') "Confidence Level"
FROM employees
Department Confidence Level
---------- ---------------10
.997281718
20
.999660215
30
.999660215
40
.997281718
50
.999611674
60
.999611674
70
.997281718
80
.999660215
90
.999660215
100
.999611674
110
.999611674
.997281718
The following query returns the nondeterministic approximate median hire date for
each department in the hr.employees table:
APPROX_MEDIAN(hire_date) "Median Hire Date"
FROM employees
Department Median Hire Date
---------- ---------------10
17-SEP-03
20
17-FEB-04
30
24-JUL-05
40
07-JUN-02
50
15-MAR-06
60
05-FEB-06
70
07-JUN-02
80
23-MAR-06
90
17-JUN-03
100
28-SEP-05
110
07-JUN-02
24-MAY-07
2.8.4 APPROX_PERCENTILE
Syntax
ERROR_RATE
CONFIDENCE
,
DETERMINISTIC
APPROX_PERCENTILE
expr
DESC
ASC
WITHIN
GROUP
ORDER
BY
expr
Purpose
APPROX_PERCENTILE is an approximate inverse distribution function. It takes a
percentile value and a sort specification, and returns the value that would fall into that
percentile value with respect to the sort specification. Nulls are ignored in the
calculation
This function provides an alternative to the PERCENTILE_CONT and
PERCENTILE_DISC functions, which returns the exact results. APPROX_PERCENTILE
processes large amounts of data significantly faster than PERCENTILE_CONT and
PERCENTILE_DISC, with negligible deviation from the exact result.
The first expr is the percentile value, which must evaluate to a numeric value
between 0 and 1.
The second expr, which is part of the ORDER BY clause, is a single expression over
which this function calculates the result. The acceptable data types for expr, and the
return value data type for this function, depend on the algorithm that you specify with
the DETERMINISTIC clause.
DETERMINISTIC
This clause lets you specify the type of algorithm this function uses to calculate the
return value.
If you specify DETERMINISTIC, then this function calculates a deterministic result.
In this case, the ORDER BY clause expression must evaluate to a numeric value, or
to a value that can be implicitly converted to a numeric value, in the range
-2,147,483,648 through 2,147,483,647. The function rounds numeric input to the
closest integer. The function returns the same data type as the numeric data type of
the ORDER BY clause expression. The return value is not necessarily one of the
values of expr
If you omit DETERMINSTIC, then this function calculates a nondeterministic result.
In this case, the ORDER BY clause expression must evaluate to a numeric or
datetime value, or to a value that can be implicitly converted to a numeric or
datetime value. The function returns the same data type as the numeric or datetime
data type of the ORDER BY clause expression. The return value is one of the values
of expr.
These clauses let you determine the accuracy of the result calculated by this function.
If you specify one of these clauses, then instead of returning the value that would fall
into the specified percentile value for expr, the function returns a decimal value from
0 to 1, inclusive, which represents one of the following values:
If you specify ERROR_RATE, then the return value represents the error rate for
calculating the value that would fall into the specified percentile value forexpr.
for the error rate that is returned when you specify ERROR_RATE.
DESC | ASC
Specify the sort specification for the calculating the value that would fall into the
specified percentile value. Specify DESC to sort the ORDER BY clause expression values
in descending order, or ASC to sort the values in ascending order. ASC is the default.
Examples
The following query returns the deterministic approximate 25th percentile, 50th
percentile, and 75th percentile salaries for each department in the hr.employees
table. The salaries are sorted in ascending order for the interpolation calculation.
APPROX_PERCENTILE(0.25 DETERMINISTIC)
WITHIN GROUP (ORDER BY salary ASC) "25th Percentile Salary",
WITHIN GROUP (ORDER BY salary ASC) "75th Percentile Salary"
FROM employees
Department 25th Percentile Salary 50th Percentile Salary 75th Percentile Salary
---------- ---------------------- ---------------------- ---------------------10
4400
4400
4400
20
6000
6000
13000
30
2633
2765
3100
40
6500
6500
6500
50
2600
3100
3599
60
4800
4800
6000
70
10000
10000
10000
80
7400
9003
10291
90
17000
17000
24000
100
7698
7739
8976
110
8300
8300
12006
7000
7000
7000
The following query returns the error rates for the approximate 25th percentile salaries
that were calculated in the previous query:
APPROX_PERCENTILE(0.25 DETERMINISTIC, 'ERROR_RATE')
WITHIN GROUP (ORDER BY salary ASC) "Error Rate"
FROM employees
Department
---------10
20
Error Rate
---------.002718282
.021746255
30
40
50
60
70
80
90
100
110
.021746255
.002718282
.019027973
.019027973
.002718282
.021746255
.021746255
.019027973
.019027973
.002718282
The following query returns the confidence levels for the error rates that were
calculated in the previous query:
APPROX_PERCENTILE(0.25 DETERMINISTIC, 'CONFIDENCE')
WITHIN GROUP (ORDER BY salary ASC) "Confidence"
FROM employees
Department
---------10
20
30
40
50
60
70
80
90
100
110
Confidence
---------.997281718
.999660215
.999660215
.997281718
.999611674
.999611674
.997281718
.999660215
.999660215
.999611674
.999611674
.997281718
The following query returns the nondeterministic approximate 25th percentile, 50th
percentile, and 75th percentile salaries for each department in the hr.employees
table. The salaries are sorted in ascending order for the interpolation calculation.
APPROX_PERCENTILE(0.25)
WITHIN GROUP (ORDER BY salary ASC) "75th Percentile Salary"
FROM employees
Department 25th Percentile Salary 50th Percentile Salary 75th Percentile Salary
---------- ---------------------- ---------------------- ---------------------10
4400
4400
4400
20
6000
6000
13000
30
2600
2800
3100
40
6500
6500
6500
50
2600
3100
3600
60
4800
4800
6000
70
10000
10000
10000
80
7300
8800
10000
90
100
110
17000
7700
8300
7000
17000
7800
8300
7000
24000
9000
12008
7000
2.8.5 APPROX_PERCENTILE_AGG
Syntax
expr
Purpose
APPROX_PERCENTILE_AGG takes as its input a column of details containing
approximate percentile information, and enables you to perform aggregations of that
information.
For detail, specify a column of details created by the APPROX_PERCENT_DETAIL
function or the APPROX_PERCENTILE_AGG function. This column is of data type
BLOB.
You can specify this function in a SELECT statement with a GROUP BY clause to
aggregate the information contained in the details within each group of rows and
return a single detail for each group.
This function returns a BLOB value, called a detail, which contains approximate
percentile information in a special format. You can store details returned by this
function in a table or materialized view, and then again use the
APPROX_PERCENTILE_AGG function to further aggregate those details, or use the
TO_APPROX_PERCENTILE function to convert the details to specified percentile
values.
Examples
Refer to APPROX_PERCENTILE_AGG: Examples (page 2-22) for examples of using
the APPROX_PERCENTILE_AGG function in conjunction with the
APPROX_PERCENTILE_DETAIL and TO_APPROX_PERCENTILE functions.
2.8.6 APPROX_PERCENTILE_DETAIL
Syntax
DETERMINISTIC
expr
Purpose
APPROX_PERCENTILE_DETAIL calculates approximate percentile information for the
values of expr and returns a BLOB value, called a detail, which contains that
information in a special format.
The acceptable data types for expr depend on the algorithm that you specify with the
DETERMINISTIC clause. Refer to the DETERMINISTIC (page 2-21) clause for more
information.
This function is commonly used with the GROUP BY clause in a SELECT statement. It
calculates approximate percentile information for expr within each group of rows and
returns a single detail for each group.
The details returned by APPROX_PERCENTILE_DETAIL can be used as input to the
APPROX_PERCENTILE_AGG function, which enables you to perform aggregations of
the details, or the TO_APPROX_PERCENTILE function, which converts a detail to a
specified percentile value. You can use these three functions together to perform
resource-intensive approximate percentile calculations once, store the resulting details,
and then perform efficient aggregations and queries on those details. For example:
1.
Use the APPROX_PERCENTILE_DETAIL function to perform approximate

percentile calculations and store the resulting details in a table or materialized
view. These could be highly-granular percentile details, such as income percentile
information for cities.
2.
Use the APPROX_PERCENTILE_AGG function to aggregate the details obtained in

the previous step and store the resulting details in a table or materialized view.
These could be details of lower granularity, such as income percentile information
for states.
3.
Use the TO_APPROX_PERCENTILE function to convert the stored detail values to

percentile values. You can use the TO_APPROX_PERCENTILE function to query
detail values created by the APPROX_PERCENTILE_DETAIL function or the
APPROX_PERCENTILE_AGG function.
DETERMINISTIC
This clause lets you control the type of algorithm used to calculate the approximate
percentile values.
If you specify DETERMINISTIC, then this function calculates deterministic
approximate percentile information. In this case, expr must evaluate to a numeric
value, or to a value that can be implicitly converted to a numeric value.
If you omit DETERMINSTIC, then this function calculates nondeterministic
approximate percentile information. In this case, expr must evaluate to a numeric
or datetime value, or to a value that can be implicitly converted to a numeric or
datetime value.
See Also:

TO_APPROX_PERCENTILE (page 2-25)
Examples
The examples in this section demonstrate how to use the
APPROX_PERCENTILE_DETAIL, APPROX_PERCENTILE_AGG, and
TO_APPROX_PERCENTILE functions together to perform resource-intensive
approximate percentile calculations once, store the resulting details, and then perform
efficient aggregations and queries on those details.
APPROX_PERCENTILE_DETAIL: Example
The following statement queries the tables sh.customers and sh.sales for the
monetary amounts for products sold to each customer. The
APPROX_PERCENTILE_DETAIL function returns the information in a detail, called

city_detail, for each city in which customers reside. The returned details are
stored in a materialized view called amt_sold_by_city_mv.
CREATE MATERIALIZED VIEW amt_sold_by_city_mv
SELECT c.country_id country,
c.cust_state_province state,
c.cust_city city,
APPROX_PERCENTILE_DETAIL(s.amount_sold) city_detail
FROM customers c, sales s
WHERE c.cust_id = s.cust_id
GROUP BY c.country_id, c.cust_state_province, c.cust_city;
APPROX_PERCENTILE_AGG: Examples
The following statement uses the APPROX_PERCENTILE_AGG function to read the
details stored in amt_sold_by_city_mv and create aggregated details that contain
the monetary amounts for products sold to customers in each state. These aggregated
details are stored in a materialized view called amt_sold_by_state_mv.
CREATE MATERIALIZED VIEW amt_sold_by_state_mv AS
SELECT country,
state,
APPROX_PERCENTILE_AGG(city_detail) state_detail
FROM amt_sold_by_city_mv
GROUP BY country, state;
The following statement is similar to the previous statement, except it creates

aggregated details that contain the approximate monetary amounts for products sold
to customers in each country. These aggregated details are stored in a materialized
view called amt_sold_by_country_mv.
CREATE MATERIALIZED VIEW amt_sold_by_country_mv AS
SELECT country,
APPROX_PERCENTILE_AGG(city_detail) country_detail
GROUP BY country;
TO_APPROX_PERCENTILE: Examples
The following statement uses the TO_APPROX_PERCENTILE function to query the
details stored in amt_sold_by_city_mv and return approximate 25th percentile,
50th percentile, and 75th percentile values for monetary amounts for products sold to
customers in each city:
SELECT country,
state,
city,
TO_APPROX_PERCENTILE(city_detail, .25, 'NUMBER') "25th Percentile",
TO_APPROX_PERCENTILE(city_detail, .50, 'NUMBER') "50th Percentile",
TO_APPROX_PERCENTILE(city_detail, .75, 'NUMBER') "75th Percentile"
ORDER BY country, state, city;
COUNTRY
------52769
52769
52769
52769
STATE
-----------Kuala Lumpur
Penang
Penang
Selangor
CITY
25th Percentile 50th Percentile 75th Percentile
-------------- --------------- --------------- --------------Kuala Lumpur
19.29
38.1
53.84
Batu Ferringhi
21.51
42.09
57.26
Georgetown
19.15
33.25
56.12
Klang
18.08
32.06
51.29
52769 Selangor
. . .
Petaling Jaya
19.29
35.43
60.2

details stored in amt_sold_by_state_mv and return approximate 25th percentile,
50th percentile, and 75th percentile values for monetary amounts for products sold to
customers in each state:
SELECT country,
state,
TO_APPROX_PERCENTILE(state_detail, .25, 'NUMBER') "25th Percentile",
TO_APPROX_PERCENTILE(state_detail, .50, 'NUMBER') "50th Percentile",
TO_APPROX_PERCENTILE(state_detail, .75, 'NUMBER') "75th Percentile"
FROM amt_sold_by_state_mv
ORDER BY country, state;
COUNTRY
------52769
52769
52769
52770
52770
. . .
STATE
25th Percentile 50th Percentile 75th Percentile
------------ --------------- --------------- --------------Kuala Lumpur
19.29
38.1
53.84
Penang
20.19
36.84
56.12
Selangor
16.97
32.41
52.69
Drenthe
16.76
31.7
53.89
Flevopolder
20.38
39.73
61.81

details stored in amt_sold_by_country_mv and return approximate 25th
percentile, 50th percentile, and 75th percentile values for monetary amounts for
products sold to customers in each country:
SELECT country,
TO_APPROX_PERCENTILE(country_detail, .25, 'NUMBER') "25th Percentile",
TO_APPROX_PERCENTILE(country_detail, .50, 'NUMBER') "50th Percentile",
TO_APPROX_PERCENTILE(country_detail, .75, 'NUMBER') "75th Percentile"
FROM amt_sold_by_country_mv
ORDER BY country;
COUNTRY 25th Percentile 50th Percentile 75th Percentile
--------- --------------- --------------- --------------52769
19.1
35.43
52.78
52770
19.29
38.99
59.58
52771
11.99
44.99
561.47
52772
18.08
33.72
54.16
52773
15.67
29.61
50.65
. . .
APPROX_PERCENTILE_AGG takes as its input a column of details containing

approximate percentile information, and enables you to perform aggregations of that
information. The following statement demonstrates how approximate percentile
details can interpreted by APPROX_PERCENTILE_AGG to provide an input to the
TO_APPROX_PERCENTILE function. Like the previous example, this query returns
approximate 25th percentile values for monetary amounts for products sold to
customers in each country. Note that the results are identical to those returned for the
25th percentile in the previous example.
SELECT country,
TO_APPROX_PERCENTILE(APPROX_PERCENTILE_AGG(city_detail), .25, 'NUMBER') "25th
Percentile"
GROUP BY country
ORDER BY country;
COUNTRY 25th Percentile
---------- --------------52769
19.1
52770
19.29
52771
11.99
52772
18.08
52773
15.67
. . .
Query Rewrite and Materialized Views Based on Approximate Queries: Example

In APPROX_PERCENTILE_DETAIL: Example (page 2-21), the ENABLE QUERY
REWRITE clause is specified when creating the materialized view
amt_sold_by_city_mv. This enables queries that contain approximation functions,
such as APPROX_MEDIAN or APPROX_PERCENTILE, to be rewritten using the
materialized view.
For example, ensure that query rewrite is enabled at either the database level or for the
current session, and run the following query:
SELECT c.country_id country,
APPROX_MEDIAN(s.amount_sold) amount_median
FROM customers c, sales s
WHERE c.cust_id = s.cust_id
GROUP BY c.country_id;
Explain the plan by querying DBMS_XPLAN:

SET LINESIZE 300
SET PAGESIZE 0
COLUMN plan_table_output FORMAT A150
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(format=>'BASIC'));
As shown in the following plan, the optimizer used the materialized view
amt_sold_by_city_mv for the query:
EXPLAINED SQL STATEMENT:
-----------------------SELECT c.country_id country, APPROX_MEDIAN(s.amount_sold)
amount_median FROM customers c, sales s WHERE c.cust_id = s.cust_id
GROUP BY c.country_id
Plan hash value: 2232676046
------------------------------------------------------------| Id | Operation
| Name
|
------------------------------------------------------------| 0 | SELECT STATEMENT
|
|
|
|
| 2 | MAT_VIEW REWRITE ACCESS FULL| AMT_SOLD_BY_CITY_MV |
-------------------------------------------------------------
2.8.7 TO_APPROX_COUNT_DISTINCT
Syntax
TO_APPROX_COUNT_DISTINCT
detail
Purpose
TO_APPROX_COUNT_DISTINCT takes as its input a detail containing information
about an approximate distinct value count, and converts it to a NUMBER value.
For detail, specify a detail of type BLOB, which was created by the
APPROX_COUNT_DISTINCT_AGG function.
See Also:

Examples
Refer to TO_APPROX_COUNT_DISTINCT: Examples (page 2-13) for examples of
using the TO_APPROX_COUNT_DISTINCT function in conjunction with the
APPROX_COUNT_DISTINCT_DETAIL and APPROX_COUNT_DISTINCT_AGG
functions.
2.8.8 TO_APPROX_PERCENTILE
Syntax
TO_APPROX_PERCENTILE
DESC
ASC
ERROR_RATE
CONFIDENCE
detail
expr
datatype
Purpose
TO_APPROX_PERCENTILE takes as its input a detail containing approximate
percentile information, a percentile value, and a sort specification, and returns an
approximate interpolated value that would fall into that percentile value with respect
to the sort specification.
For detail, specify a detail of type BLOB, which was created by the
APPROX_PERCENTILE_DETAIL function or the APPROX_PERCENTLE_AGG function.
For expr, specify a percentile value, which must evaluate to a numeric value between
0 and 1. If you specify the ERROR_RATE or CONFIDENCE clause, then the percentile
value does not apply. In this case, for expr you must specify null or a numeric value
between 0 and 1. However, the value will be ignored.
For datatype, specify the data type of the approximate percentile information in the
detail. This is the data type of the expression supplied to the
APPROX_PERCENTILE_DETAIL function that originated the detail. Valid data types
are NUMBER, BINARY_FLOAT, BINARY_DOUBLE, DATE, TIMESTAMP, INTERVAL YEAR
TO MONTH, and INTERVAL DAY TO SECOND.
DESC | ASC
Specify the sort specification for the interpolation. Specify DESC for a descending sort
order, or ASC for an ascending sort order. ASC is the default.
These clauses let you determine the accuracy of the percentile evaluation of the detail.
If you specify one of these clauses, then instead of returning the approximate
interpolated value, the function returns a decimal value from 0 to 1, inclusive, which
represents one of the following values:
If you specify ERROR_RATE, then the return value represents the error rate of the
percentile evaluation for the detail.
for the error rate returned when you specify ERROR_RATE.
If you specify ERROR_RATE or CONFIDENCE, then the percentile value expr is
ignored.
See Also:
APPROX_PERCENTILE_DETAIL (page 2-20)

Examples
Refer to APPROX_PERCENTILE_AGG: Examples (page 2-22) for examples of using
the TO_APPROX_PERCENTILE function in conjunction with the
APPROX_PERCENTILE_DETAIL and APPROX_PERCENTILE_AGG functions.
3
Materialized Views
Materialized views precompute expensive, potentially common SQL expressions in
advance and reuses these precomputed results transparently to answer subsequent
statements. This significantly increases processing and saves resources (compute once
- use often).
This chapter describes how to use some of the new features related to materialized
views.
About ON STATEMENT Refresh for Materialized Views (page 3-2)
A materialized view that uses the ON STATEMENT refresh mode is
automatically refreshed every time a DML operation is performed on
any of the materialized views base tables.
Restrictions on Materialized Views with ON STATEMENT Refresh (page 3-2)
Some restrictions apply when using the ON STATEMENT mode for
refreshing materialized views.
Using Real-time Materialized Views (page 3-3)
Real-time materialized views provide fresh data to user queries even
when the materialized view is marked as stale.
Creating Real-time Materialized Views (page 3-5)
To create a real-time materialized view, use the ON QUERY
COMPUTATION clause in the CREATE MATERIALIZED VIEW statement.
Converting an Existing Materialized View into a Real-time Materialized View
(page 3-7)
If the prerequisites for a real-time materialized view are met, then an
existing materialized view can be converted into a real-time materialized
view by altering its definition and enabling on-query computation.
Listing Real-time Materialized Views (page 3-7)
The ON_QUERY_COMPUTATION column in the data dictionary views
ALL_MVIEWS, DBA_MVIEWS, and USER_MVIEWS indicates if a
materialized view is a real-time materialized view.
Enabling Query Rewrite to Use Real-time Materialized Views (page 3-8)
For the query rewrite mechanism to rewrite a user query to use real-time
materialized views, query rewrite must be enabled for the real-time
materialized view.
Using Real-time Materialized Views During Query Rewrite (page 3-8)
Query rewrite can use a real-time materialized view to provide results to
user queries, even if the real-time materialized view is stale, if query
rewrite is enabled for the real-time materialized view. A nested real-time
materialized view is eligible for query rewrite only if all its base realtime materialized views are fresh.
Materialized Views 3-1
About ON STATEMENT Refresh for Materialized Views
Using Real-time Materialized Views for Direct Query Access (page 3-10)
You can access a real-time materialized view directly by referencing the
name of the real-time materialized view in a query.
Monitoring Materialized View Refresh Operations (page 3-12)
This chapter describes how to use refresh statistics to monitor the
performance of materialized view refresh operations.
3.1 About ON STATEMENT Refresh for Materialized Views

A materialized view that uses the ON STATEMENT refresh mode is automatically
refreshed every time a DML operation is performed on any of the materialized views
base tables.
With the ON STATEMENT refresh mode, any changes to the base tables are
immediately reflected in the materialized view. There is no need to commit the
transaction or maintain materialized view logs on the base tables. If the DML
statements are subsequently rolled back, then the corresponding changes made to the
materialized view are also rolled back.
To use the ON STATEMENT refresh mode, a materialized view must be fast refreshable.
An index is automatically created on ROWID column of the fact table to improve fast
refresh performance.
The advantage of the ON STATEMENT refresh mode is that the materialized view is
always synchronized with the data in the base tables, without the overhead of
maintaining materialized view logs. However, this mode may increase the time taken
to perform a DML operation because the materialized view is being refreshed as part
of the DML operation.
Example 3-1
Creating a Materialized View with ON STATEMENT Refresh
This example creates a materialized view sales_mv_onstat that uses the ON

STATEMENT refresh mode and is based on the sh.sales, sh.customers, and
sh.products tables. The materialized view is automatically refreshed when a DML
operation is performed on any of the base tables. No commit is required after the DML
operation to refresh the materialized view.
CREATE MATERIALIZED VIEW sales_mv_onstat
REFRESH FAST ON STATEMENT USING TRUSTED CONSTRAINT
AS
SELECT s.rowid sales_rid, c.cust_first_name first_name, c.cust_last_name last_name,
p.prod_name prod_name,
s.quantity_sold quantity_sold, s.amount_sold amount_sold
FROM sh.sales s, sh.customers c, sh.products p
WHERE s.cust_id = c.cust_id and s.prod_id = p.prod_id;
3.2 Restrictions on Materialized Views with ON STATEMENT Refresh

Some restrictions apply when using the ON STATEMENT mode for refreshing
materialized views.
This mode can be used only with materialized views that are fast refreshable.
The ON STATEMENT refresh mode must be used with the REFRESH FAST option.
The base tables referenced in the materialized views defining query must be
connected in a join graph that uses the star schema or snowflake schema model.
The query must contain exactly one centralized fact table and one or more
Using Real-time Materialized Views
dimension tables, with all pairs of joined tables being related using primary keyforeign key constraints.
There is no restriction on the depth of the snowflake model.
The constraints can be in RELY mode. However, you must include the USING
TRUSTED CONSTRAINT clause while creating the materialized view to use the
RELY constraint.
The materialized views defining query must include the ROWID column of the fact
table.
The materialized views defining query cannot include any of the following:
invisible columns, ANSI join syntax, complex query, inline view as base table,
composite primary key, LONG columns, and LOB columns.
You cannot alter the definition of an existing materialized view that uses the ON
STATEMENT refresh mode.
You cannot alter an existing materialized view and enable ON STATEMENT refresh
for it.
The following operations cause a materialized view with ON STATEMENT refresh
to become unusable:
UPDATE operations on one or more dimension tables on which the materialized
view is based
PMOP and TRUNCATE operations on any base table
However, a materialized view with the ON STATEMENT refresh mode can be
partitioned.
3.3 Using Real-time Materialized Views

Real-time materialized views provide fresh data to user queries even when the
materialized view is marked as stale.
Overview of Real-time Materialized Views (page 3-3)
A real-time materialized view is a type of materialized view that
provides fresh data to user queries even when the materialized view is
not in sync with its base tables because of data changes.
3.3.1 Overview of Real-time Materialized Views

A real-time materialized view is a type of materialized view that provides fresh data
to user queries even when the materialized view is not in sync with its base tables
because of data changes.
Unless a SQL session is set to stale tolerated mode, a materialized view that is marked
stale cannot be used for query rewrite. Organizations that require real-time data
typically use the ON COMMIT refresh mode to ensure that the materialized view is
updated with changes made to the base tables. However, when DML changes to the
base tables are huge and very frequent, this mode may result in resource contention
and reduced refresh performance. Real-time materialized views provide a lightweight
solution for obtaining fresh data from stale materialized views by recomputing the
data on the fly.
Using Real-time Materialized Views
Real-time materialized views can use any available out-of-place refresh method
including log-based or PCT based refresh. They can be used either with on demand or
scheduled automatic refresh, but not with automatic refresh specified using the ON
COMMIT clause.
Advantages of Real-time Materialized Views
Provides improved availability for materialized views
Provides fresh data for user queries that access a materialized view that may be
stale
How Do Real-time Materialized Views Work?
Real-time materialized views use a technique called on-query computation to provide
fresh data with stale materialized views. When a query accesses a real-time
materialized view, Oracle Database first checks if the real-time materialized view is
marked as stale. If it is not stale, then the required data is provided using the real-time
materialized view as it is. If the real-time materialized view is marked as stale, then
the on-query computation technique is used to generate the fresh data and return the
correct query result.
Real-time materialized views use a technique that is similar log-based refresh to
provide fresh data with stale materialized view. They combine the existing data with
the changes that are recorded in change logs to obtain the latest data. However, unlike
log-based refresh, real-time materialized views do not use the materialized view logs
to update the data in the real-time materialized view. Instead, when a query accesses a
stale real-time materialized view, the data that is recomputed using on-query
computation is used directly to answer the query.
A real-time materialized view is created by using the ON QUERY COMPUTATION
clause in the materialized view definition.
Restrictions on Using Real-time Materialized Views (page 3-4)
Using real-time materialized views is subject to certain restrictions.
Improving Real-time Materialized Views Performance (page 3-5)
To obtain better performance for user queries that use a real-time
materialized view, you can follow certain guidelines.
About Accessing Real-time Materialized Views (page 3-5)
As with materialized views, multiple methods exist to access data stored
in real-time materialized views.
3.3.1.1 Restrictions on Using Real-time Materialized Views

Using real-time materialized views is subject to certain restrictions.
Real-time materialized views cannot be used when:
one or more materialized view logs created on the base tables are either
unusable or nonexistent.
out-of-place, log-based or PCT refresh is not feasible for the change scenarios.
automatic refresh is specified using the ON COMMIT clause.
If a real-time materialized view is a nested materialized view that is defined on top
of one or more base materialized views, then query rewrite occurs only if all the
Creating Real-time Materialized Views
base materialized views are fresh. If one or more base materialized views are stale,
then query rewrite is not performed using this real-time materialized view.
The cursors of queries that directly access real-time materialized views are not shared.
3.3.1.2 Improving Real-time Materialized Views Performance

To obtain better performance for user queries that use a real-time materialized view,
you can follow certain guidelines.
Use the following guidelines with real-time materialized views:
Frequently refresh real-time materialized views to enhance the performance of
queries that may use these real-time materialized views.
Since real-time materialized views work by combining the delta changes to the base
tables with the existing materialized view data, query response time is enhanced
when the delta changes to be computed are small. With more outstanding DML
operations, on-query computation can become more complex (and expensive), up
to the point where direct base table access can become more efficient (in case of
query rewrite).
Collect statistics for the base tables, the real-time materialized view, and the
materialized view logs to enable the optimizer to accurately determine the cost of a
query.
For query rewrite, the cost-based rewrite mechanism uses the optimizer to
determine whether the rewritten query should be used. The optimizer uses
statistics to determine the cost.
3.3.1.3 About Accessing Real-time Materialized Views

As with materialized views, multiple methods exist to access data stored in real-time
materialized views.
Data stored in real-time materialized views can be accessed in one of the following
ways:
Query rewrite
A user query that is similar to the real-time materialized view definition is
rewritten to use the real-time materialized view.
Direct access of real-time materialized views
A user query directly references the real-time materialized view by using its name.
In both scenarios, the content of a real-time materialized view can be accessed as stale
data or can trigger an on-query computation of the correct result. Whether or not onquery computation is triggered depends on the environment and the actual SQL
statement.
The output of the EXPLAIN PLAN statement contains messages indicating if on-query
computation was used for a particular user query.
3.4 Creating Real-time Materialized Views

To create a real-time materialized view, use the ON QUERY COMPUTATION clause in
the CREATE MATERIALIZED VIEW statement.
Creating Real-time Materialized Views
You can create real-time materialized views even if they are not applicable for onquery computation for all change scenarios. The minimum requirement to create a
real-time materialized view is that it supports out-of-place refresh for INSERT
operations. If other change scenarios, such as mixed DML operations, are encountered,
then on-query computation may not be feasible for all types of real-time materialized
views.
Real-time materialized view must use an out-of-place log-based refresh mechanism
(including PCT refresh). The ON COMMIT refresh mode cannot be used for real-time
materialized views.
To create a real-time materialized view:
1. Ensure that materialized view logs exist on all the base tables of the real-time
materialized view.
2. Create materialized view logs for all the tables on which the real-time materialized
view is based.
3. Create the real-time materialized view by including the ENABLE ON QUERY
COMPUTATION clause in the CREATE MATERIALIZED VIEW statement.
Example 3-2
Creating a Real-time Materialized View
This example creates a real-time materialized view called SUM_SALES_RTMV which is

based on data aggregated from the SALES and PRODUCTS tables in the SH schema.
Before you create the real-time materialized view ensure that the required
prerequisites are met.
1.
Create materialized view logs on the base tables SALES and PRODUCTS.
The following command creates a materialized view log on the SALES table:
CREATE MATERIALIZED VIEW LOG ON sales
WITH SEQUENCE, ROWID
(prod_id, quantity_sold, amount_sold)
INCLUDING NEW VALUES;
The following command creates a materialized view log on the PRODUCTS table.
CREATE MATERIALIZED VIEW LOG ON products
WITH ROWID
(prod_id, prod_name, prod_category, prod_subcategory)
2.
Create a real-time materialized view by including the ON QUERY COMPUTATION

clause in the CREATE MATERIALIZED VIEW statement. The fast refresh method
is used for this real-time materialized view and the ENABLE QUERY REWRITE
clause indicates that query rewrite must be enabled.
CREATE MATERIALIZED VIEW sum_sales_rtmv
REFRESH FAST ON DEMAND
ENABLE QUERY REWRITE
ENABLE ON QUERY COMPUTATION
AS
SELECT prod_name, SUM(quantity_sold) AS sum_qty, COUNT(quantity_sold) AS
cnt_qty, SUM(amount_sold) AS sum_amt,
COUNT(amount_sold) AS cnt_amt, COUNT(*) AS cnt_star
FROM sales, products
WHERE sales.prod_id = products.prod_id
GROUP BY prod_name;
Converting an Existing Materialized View into a Real-time Materialized View
After the SUM_SALES_RTMV real-time materialized view is created, assume that the
following query is run.
SELECT prod_name, SUM(quantity_sold), SUM(amount_sold)
FROM sales, products
WHERE sales.prod_id = products.prod_id
GROUP BY prod_name;
If SUM_SALES_RTMV is not stale, then the query result is returned using the data
stored in this real-time materialized view. However, if SUM_SALES_RTMV is stale and
the cost of rewriting the query using the materialized view with on-query
computation is lower than the base table access, then the query is answered by
combining the delta changes in the materialized view logs on the SALES and
PRODUCTS tables with the data in the real-time materialized view SUM_SALES_RTMV.
3.5 Converting an Existing Materialized View into a Real-time Materialized

View
If the prerequisites for a real-time materialized view are met, then an existing
materialized view can be converted into a real-time materialized view by altering its
definition and enabling on-query computation.
To convert a materialized view into a real-time materialized view:
Modify the materialized view definition and enable on-query computation by
using the ON QUERY COMPUTATION clause in the ALTER MATERIALIZED VIEW
statement.
You can convert a real-time materialized view into a regular materialized view by
disabling on-query computation using the DISABLE ON QUERY COMPUTATION
clause in the ALTER MATERIALIZED VIEW statement.
Example 3-3
Converting a Materialized View into a Real-time Materialized View
The materialized view SALES_RTMV is based on the SALES, TIMES, and PRODUCTS
tables and uses fast refresh. Materialized view logs exist on all three base tables. You
want to modify this materialized view and convert it into a real-time materialized
view.
1.
Modify the materialized view definition and include the ON QUERY

COMPUTATION clause to change it into a real-time materialized view.
ALTER MATERIALIZED VIEW sales_rtmv ENABLE ON QUERY COMPUTATION;
2.
Query the DBA_MVIEWS view to determine if on-query computation is enabled for

SALES_RTMV.
SELECT mview_name, on_query_computation
FROM dba_mviews
WHERE mview_name = 'SALES_RTMV';
3.6 Listing Real-time Materialized Views

The ON_QUERY_COMPUTATION column in the data dictionary views ALL_MVIEWS,
DBA_MVIEWS, and USER_MVIEWS indicates if a materialized view is a real-time
materialized view.
A value of Y in the ON_QUERY_COMPUTATION column indicates a real-time
materialized view.
Enabling Query Rewrite to Use Real-time Materialized Views
To list all real-time materialized views in your user schema:

Query the USER_MVIEWS view and display details of the materialized view with
the ON_QUERY_COMPUTATION column set to Y.
Example 3-4
Listing Real-time Materialized Views in the Current Users Schema
SELECT owner, mview_name, rewrite_enabled, staleness

FROM user_mviews
WHERE on_query_computation = 'Y';
OWNER
-----SH
SH
SH
SH
MVIEW_NAME
REWRITE_ENABLED
-----------------------------SALES_RTMV
N
MAV_SUM_SALES
Y
MY_SUM_SALES_RTMV Y
NEW_SALES_RTMV
Y
STALENESS
-----------FRESH
FRESH
FRESH
STALE
3.7 Enabling Query Rewrite to Use Real-time Materialized Views

For the query rewrite mechanism to rewrite a user query to use real-time materialized
views, query rewrite must be enabled for the real-time materialized view.
You can enable query rewrite for a real-time materialized view either at creation time
or subsequently, by modifying the definition of the real-time materialized view. The
ENABLE QUERY REWRITE clause is used to enable query rewrite.
To enable query rewrite for an existing real-time materialized view:
Run the ALTER MATERIALIZED VIEW command and include the ENABLE QUERY
REWRITE clause.
Example 3-5
Enabling Query Rewrite for Real-time Materialized Views
The real-time materialized view my_rtmv uses the fast refresh mechanism. You want
to modify the definition of this real-time materialized view and specify that the query
rewrite mechanism must consider this real-time materialized view while rewriting
queries.
The following command enables query rewrite for my_rtmv:
ALTER MATERIALIZED VIEW my_rtmv ENABLE QUERY REWRITE;
3.8 Using Real-time Materialized Views During Query Rewrite

Query rewrite can use a real-time materialized view to provide results to user queries,
even if the real-time materialized view is stale, if query rewrite is enabled for the realtime materialized view. A nested real-time materialized view is eligible for query
rewrite only if all its base real-time materialized views are fresh.
When a user query is run, query rewrite first checks if a fresh materialized view is
available to provide the required data. If a suitable materialized view does not exist,
then query rewrite looks for a real-time materialized view that can be used to rewrite
the user query. A fresh materialized view is preferred over a real-time materialized
view because some overhead is incurred in computing fresh data for real-time
materialized view. Next, the cost based optimizer determines the cost of the SQL
query with on-query computation and then decides if the real-time materialized view
will be used to answer this user query.
If the QUERY_REWRITE_INTEGRITY mode of the current SQL session is set to
STALE_TOLERATED, then on-query computation will not be used during query
Using Real-time Materialized Views During Query Rewrite
rewrite. The STALE_TOLERATED rewrite mode indicates that fresh results are not
required to satisfy a query, so on-query computation is not necessary.
For query rewrite to use a real-time materialized view:
1. Ensure that QUERY_REWRITE_INTEGRITY is set to either ENFORCED or TRUSTED
mode. QUERY_REWRITE_INTEGRITY mode should not be set to

STALE_TOLERATED mode
2. Run a user query that matches the SQL query that was used to define the real-time
materialized view.
Any query that can be rewritten to take advantage of a real-time materialized view
will use the real-time materialized view with on-query computation.
Use EXPLAIN PLAN to verify that the query was rewritten using the real-time
materialized view.
Example 3-6
Using Real-time Materialized Views During Query Rewrite
This example creates a real-time materialized view with query rewrite enabled and
then demonstrates that it was used by query rewrite to provide data for a user query.
1.
Create a materialized view log on the SALES table, which is the base table for the
real-time materialized view being created.
2.
Create a real-time materialized view mav_sum_sales with query rewrite

enabled.
CREATE MATERIALIZED VIEW mav_sum_sales
REFRESH FAST ON DEMAND
AS
SELECT prod_id, sum(quantity_sold) as sum_qty, count(quantity_sold) as cnt_qty,
sum(amount_sold) sum_amt, count(amount_sold) cnt_amt, count(*) as cnt_star
FROM sales
GROUP BY prod_id;
3.
Run the following query:

SELECT prod_id, sum(quantity_sold), sum(amount_sold)
FROM sales
WHERE prod_id < 1000
GROUP BY prod_id;
Observe that the query is similar to the one used to define the real-time
materialized view mav_sum_sales. Because no other materialized view with a
definition that is similar to the query exists, query rewrite can use the
mav_sum_sales real-time materialized view to determine the query result. You
can verify that query rewrite has taken place by checking the SQL cursor cache
(for example, with DBMS_XPLAN), using SQL Monitor, or using EXPLAIN PLAN.
The internally rewritten query that uses mav_sum_sales is analogous to the
following statement:
SELECT prod_id, sum_qty, sum_amt
FROM mav_sum_sales
WHERE prod_id < 1000;
4.
Verify that the real-time materialized view was used to provide the query result.
Use the EXPLAIN PLAN statement to view the execution plan for the query.
Using Real-time Materialized Views for Direct Query Access
The following execution plan shows direct access to the real-time materialized
view. If the materialized view is stale, then the execution plan will become more
complex and include access to other objects (for example, the materialized view
logs), depending on the outstanding DML operations.
EXPLAIN PLAN for SELECT prod_id, sum(quantity_sold), sum(amount_sold) FROM sales
WHERE prod_id < 1000 GROUP BY prod_id;
SELECT plan_table_output FROM
table(dbms_xplan.display('plan_table',null,'serial'));
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------Plan hash value: 13616844
---------------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost (%CPU) |
Time
|
---------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT
|
| 92
| 3588 | 3 (0)
|
00:00:01 |
| *1 | MAT_VIEW ACCESS FULL | MAV_SUM_SALES | 92
| 3588 | 3 (0)
|
00:00:01 |
---------------------------------------------------------------------------------------------Predicate Information (identified by operation id):
--------------------------------------------------1 - filter("PROD_ID"<1000)
Note
----- dynamic statistics used: dynamic sampling (level=2)
17 rows selected.
3.9 Using Real-time Materialized Views for Direct Query Access

You can access a real-time materialized view directly by referencing the name of the
real-time materialized view in a query.
If the real-time materialized view specified in a user query is fresh, then the required
data is directly fetched from the real-time materialized view. If the real-time
materialized view is stale, then you must use the FRESH_MV hint to perform on-query
computation and obtain fresh data. Oracle Database does not automatically perform
on-query computation for a real-time materialized view that is accessed directly in a
user query.
To obtain fresh data from a stale real-time materialized view when directly accessing
the real-time materialized view:
Use the FRESH_MV hint in the user query to indicate that on-query computation
must be performed.
Example 3-7
Creating a Real-Time Materialized View and Using it in Queries
This example creates a real-time materialized view MY_RTMV that is based on the
SALES_NEW table. The SALES_NEW table is created as a copy of the SH.SALES table. A
row is inserted into the base table after the real-time materialized view is created. Next
the fresh_mv hint is used to access fresh data from the real-time materialized view by
using the materialized view name in a user query.
Using Real-time Materialized Views for Direct Query Access
1.
Create a materialized view log on the base table sales_new.

Materialized view logs on the base table are mandatory for creating real-time
materialized views.
CREATE MATERIALIZED VIEW LOG on sales_new
WITH sequence, ROWID (prod_id, cust_id, time_id, channel_id, promo_id,
quantity_sold, amount_sold)
2.
Create a real-time materialized view called my_rtmv with sales_new as the base
table.
The ON QUERY COMPUTATION clause indicates that a real-time materialized view
is created. The refresh mode specified is log-based fast refresh. Query rewrite is
enabled for the real-time materialized view.
CREATE MATERIALIZED VIEW my_rtmv
REFRESH FAST
AS
SELECT prod_id, cust_id, channel_id, sum(quantity_sold) sum_q,
count(quantity_sold) cnt_q, avg(quantity_sold) avg_q,
sum(amount_sold) sum_a, count(amount_sold) cnt_a, avg(amount_sold) avg_a
FROM sales_new
GROUP BY prod_id, cust_id, channel_id;
3.
Insert a row into sales_new, the base table of the real-time materialized view
and commit this change.
INSERT INTO sales_new (prod_id, cust_id, time_id, channel_id, promo_id,
quantity_sold, amount_sold)
VALUES (116,100450, sysdate,9,9999,10,350);
COMMIT;
4.
Query the real-time materialized view directly to display data for the row that
was added to the real-time materialized views base table in the previous step.
SELECT * from my_rtmv
WHERE prod_id = 116 AND cust_id=100450 AND channel_id = 9;
PROD_ID
AVG_A
-----------116
11.99
CUST_ID
CHANNEL_ID
SUM_Q
CNT_Q
AVG_Q
SUM_A
CNT_A
-------
----------
-----
-----
-----
-----
-----
100450
11.99
Note that the query result does not display the updated value for this data. This is
because the real-time materialized view has not yet been refreshed with the
changes made to its base table.
5.
Include the FRESH_MV hint while querying the real-time materialized view to
display the row updated in the base table.
SELECT /*+ fresh_mv */ * FROM my_rtmv
WHERE prod_id = 116 AND cust_id=100450 AND channel_id = 9;
PROD_ID
CUST_ID
CHANNEL_ID SUM_Q
CNT_Q
AVG_Q
SUM_A
CNT_A
AVG_A
Monitoring Materialized View Refresh Operations
------116
180.995
------100450
---------- ----9
11
----2
----5.5
----361.99
----2
------
Notice that this time the updated row is displayed. This is because the FRESH_MV
hint triggers on-query computation for the real-time materialized view and
recomputed the fresh data.
3.10 Monitoring Materialized View Refresh Operations

This chapter describes how to use refresh statistics to monitor the performance of
materialized view refresh operations.
About Materialized View Refresh Statistics (page 3-13)
Oracle Database collects and stores statistics about materialized view
refresh operations. These statistics are accessible using data dictionary
views.
Overview of Managing Materialized View Refresh Statistics (page 3-13)
Oracle Database manages the collection and retention of materialized
view refresh statistics based on the defined database settings. By default,
the database collects and stores basic statistics about materialized view
refresh operations for the entire database.
About Data Dictionary Views that Store Materialized View Refresh Statistics
(page 3-14)
Oracle Database stores materialized view refresh statistics in the data
dictionary. Setting the collection level for materialized view refresh
controls the detail level of refresh statistics collected.
Collecting Materialized View Refresh Statistics (page 3-15)
Oracle Database collects basic statistics about materialized view refresh
operations. These statistics are stored in the data dictionary and can be
used to analyze the performance of materialized view refresh operations.
Retaining Materialized View Refresh Statistics (page 3-17)
Oracle Database stores the collected materialized view refresh statistics
for a period of time specified by the retention period.
Viewing Materialized View Refresh Statistics Settings (page 3-19)
Data dictionary views store both the default settings and materialized
view-specific settings that manage materialized view refresh statistics.
Purging Materialized View Refresh Statistics (page 3-20)
The DBMS_MVIEW_STATS.PURGE_REFRESH_STATS procedure enables
you to explicitly purge materialized view refresh statistics that are older
than a specified period from the data dictionary.
Viewing Materialized View Refresh Statistics (page 3-21)
You can view both current and historical statistics for materialized view
refresh operations by querying the data dictionary views that store
refresh statistics.
Analyzing Materialized View Refresh Performance Using Refresh Statistics
(page 3-25)
Materialized view refresh statistics that are stored in data dictionary
views can be used to analyze the refresh performance of materialized
views.
3.10.1 About Materialized View Refresh Statistics

Oracle Database collects and stores statistics about materialized view refresh
operations. These statistics are accessible using data dictionary views.
Statistics for both current and historical materialized view refresh operations are
stored in the database. Historical materialized view refresh statistics enable you to
understand and analyze materialized view refresh performance over time in your
database. Refresh statistics can be collected at varying levels of granularity.
Maintaining materialized view refresh statistics provides the following:
Reporting capabilities for materialized view refresh operations
Display both current and historical statistics for materialized view refresh
operations
Display statistics on actual refresh execution times
Track the performance of materialized view refresh over time using statistics on
actual refresh execution times
Diagnostic capabilities for materialized view refresh performance
Detailed current and historical statistics can be used to quickly analyze the
performance of materialized view refresh operations. For example, if a materialized
view takes a long time to refresh, you can use refresh statistics to determine if the
slowdown is due to increased system load or vastly varying change data.
3.10.2 Overview of Managing Materialized View Refresh Statistics

Oracle Database manages the collection and retention of materialized view refresh
statistics based on the defined database settings. By default, the database collects and
stores basic statistics about materialized view refresh operations for the entire
database.
Managing materialized view refresh statistics comprises of the defining policies that
control the following:
Level of details for materialized view refresh statistics
Retention period of materialized view refresh statistics
Use the following techniques to define policies that manage materialized view refresh
statistics:
Define default settings that are applicable to the entire database
The DBMS_MVIEW_STATS.SET_SYSTEM_DEFAULT procedure defines default
settings that manage the collection and retention of materialized view refresh
statistics for the entire database.
Define collection and retention policies for individual materialized views
The DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS procedure provides more
fine-grained control over materialized view refresh statistics by managing the
collection and retention of statistics at the level in individual materialized views.
Settings made at the materialized view level override the database-level settings.
Note:
Collecting Materialized View Refresh Statistics (page 3-15)

Retaining Materialized View Refresh Statistics (page 3-17)
3.10.3 About Data Dictionary Views that Store Materialized View Refresh Statistics
Oracle Database stores materialized view refresh statistics in the data dictionary.
Setting the collection level for materialized view refresh controls the detail level of
refresh statistics collected.
Each materialized view refresh operation is identified using a unique refresh ID. A
single refresh operation could refresh multiple materialized views. For example, when
the REFRESH_DEPENDENT procedure is used to refresh a single materialized view, all
materialized views that are dependent on the specified materialized view are also
refreshed as part of the same refresh operation. Thus, all the materialized views
refreshed as part of this operation will have the same refresh ID.
Table 3-1
Data Dictionary Views that Store Materialized View Refresh Statistics
View Name
Description
DBA_MVREF_STATS
Stores basic statistics for a materialized view refresh

such as the refresh ID and basic timing statistics for
the refresh operation.
This view contains the following information about
each materialized view for which refresh statistics
are collected:
name of the materialized view
refresh method used
number of rows in the materialized view at the
beginning and end of the refresh operation
number of steps used to refresh the materialized
view
DBA_MVREF_RUN_STATS
Stores detailed information about each materialized

view refresh operation including the following:
parameters specified when running the refresh
operation such as list of materialized views,
refresh method, purge option, and so on.
number of materialized views refreshed in the
refresh operation.
detailed timing statistics for the refresh
operation including start time, end time, and
elapsed time.
DBA_MVREF_CHANGE_STATS
Contains change data load information for the base

tables associated with a materialized view refresh
operation.
The details include base table names, materialized
view names, number of rows inserted, number of
rows updated, number of rows deleted, number of
direct-load inserts, PMOPs details, and number of
rows at the beginning of the refresh operation.
Table 3-1
Statistics
(Cont.) Data Dictionary Views that Store Materialized View Refresh
View Name
Description
DBA_MVREF_STMT_STATS
Contains information related to each refresh

statement that is part of a single materialized view
refresh operation.
This includes information such as materialized view
name, refresh ID, the refresh statement, SQLID of
the refresh statement, and execution plan of the
statement.
3.10.4 Collecting Materialized View Refresh Statistics

Oracle Database collects basic statistics about materialized view refresh operations.
These statistics are stored in the data dictionary and can be used to analyze the
performance of materialized view refresh operations.
About Collecting Materialized View Refresh Statistics (page 3-15)
By default, Oracle Database collects basic refresh statistics for all
materialized views refresh operations.
Specifying Default Settings for Collecting Materialized View Refresh Statistics
(page 3-16)
The DBMS_MVIEW_STATS.SET_SYSTEM_DEFAULT procedure enables
you to set defaults for managing the collection of materialized view
refresh statistics at the database level.
Modifying the Collection Level for Materialized View Refresh Statistics
(page 3-16)
You can modify the settings that manage the collection of materialized
view refresh statistics by using the
DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS procedure.
3.10.4.1 About Collecting Materialized View Refresh Statistics

By default, Oracle Database collects basic refresh statistics for all materialized views
refresh operations.
Oracle Database enables you to control the granularity and level at which materialized
view refresh statistics are collected. Statistics can be collected for all materialized
views in the database or for a specific set of materialized views. If you are interested in
monitoring only some materialized views in the database, then you can collect
statistics at the materialized view level. Collecting refresh statistics for a selected set of
materialized views is useful because refresh patterns of materialized views can vary
widely.
The collection level defines the amount of statistics that the database collects for
materialized view refresh operations. You can either collect basic statistics or more
detailed information such as the parameters used and the SQL statements run during
the materialized view refresh operation.
Use the procedures in the DBMS_MVIEW_STATS package to set the
COLLECTION_LEVEL parameter, which specifies the collection level for materialized
view refresh statistics. The values that can be set for the COLLECTION_LEVEL
parameter are:
NONE
No statistics are collected for materialized view refresh operations.
TYPICAL
Only basic refresh statistics are collected for materialized view refresh operations.
This is the default setting.
ADVANCED
Detailed statistics, including the parameters used in the refresh operation and the
SQL statements that are run, are collected for materialized view refresh operations.
3.10.4.2 Specifying Default Settings for Collecting Materialized View Refresh

Statistics
The DBMS_MVIEW_STATS.SET_SYSTEM_DEFAULT procedure enables you to set
defaults for managing the collection of materialized view refresh statistics at the
database level.
You can override the system defaults by specifying different settings at the individual
materialized view level. Materialized views for which the default settings are not
overridden will use the system default settings.
By default, Oracle Database collects and stores basic statistics about materialized view
refresh operations for the entire database. You can disable statistics collection or
change the default setting by modifying the statistics collection level.
To set the default collection level for materialized view refresh statistics at the
database level:
Run the DBMS_MVIEW_STATS.SET_SYSTEM_DEFAULT procedure and set the
COLLECTION_LEVEL parameter.
Example 3-8
Database
Setting Materialized View Refresh Statistics Collection Level for the
This example sets the default collection level for materialized view refresh statistics to
ADVANCED indicating that detailed statistics about materialized view refresh
operations will be collected and stored.
DBMS_MVIEW_STATS.SET_SYSTEM_DEFAULT ('COLLECTION_LEVEL','ADVANCED');
Example 3-9
Disabling Statistics Collection for Materialized View Refresh
This example sets the default collection level for materialized view refresh statistics to
NONE thereby disabling statistics collection.
DBMS_MVIEW_STATS.SET_SYSTEM_DEFAULT ('COLLECTION_LEVEL','NONE');
See Also:
SET_SYSTEM_DEFAULT Procedure (page A-4)
3.10.4.3 Modifying the Collection Level for Materialized View Refresh Statistics
You can modify the settings that manage the collection of materialized view refresh
statistics by using the DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS procedure.
You can modify the statistics collection behavior either for the entire database or for
one or more materialized views. The new collection settings override the default
settings made at the database level or previous settings made for the specified
materialized views. For example, the system default for COLLECTION_LEVEL is set to
TYPICAL for the database. You then use the
DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS procedure to modify the
collection level for the materialized views MV1 and MV2 to ADVANCED. The
remaining materialized views in the database will continue to use the TYPICAL
collection level.
To modify the collection level for materialized view refresh statistics, either at the
database level or materialized view level:
Run the DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS procedure and set
the COLLECTION_LEVEL parameter to the required value
Example 3-10
Database
Setting the Materialized View Statistics Collection Level for the Entire
The following example modifies the collection level for materialized view refresh
statistics at the database level to TYPICAL. Specifying NULL instead of one or more
materialized view names indicates that this setting is for the entire database.
DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS (NULL, 'TYPICAL');
Example 3-11 Setting the Materialized View Statistics Collection Level for Multiple
Materialized Views
This example sets the collection level for the materialized views SALES_2013_MV and
SALES_2014_MV in the SH schema to ADVANCED. The retention period is set to 60
days. This setting overrides any default settings that may have been specified at the
database level.
DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS ('SH.SALES_2013_MV,
SH.SALES_2014_MV','ADVANCED',60);
See Also:
SET_MVREF_STATS_PARAMS Procedure (page A-3)
3.10.5 Retaining Materialized View Refresh Statistics

Oracle Database stores the collected materialized view refresh statistics for a period of
time specified by the retention period.
About Retaining Materialized View Refresh Statistics (page 3-18)
The retention period defines the duration, in days, for which
materialized view refresh statistics are stored in the data dictionary.
Collected statistics are automatically purged after the retention period is
reached.
Specifying the Default Retention Period for Materialized View Refresh Statistics
(page 3-18)
The DBMS_MVIEW_STATS.SET_SYSTEM_DEFAULT procedure sets
defaults for managing the retention of materialized view refresh
statistics at the database level.
Modifying the Retention Period for Materialized View Refresh Statistics

(page 3-19)
The DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS procedure
enables you to modify the retention period set for materialized view
refresh statistics.
3.10.5.1 About Retaining Materialized View Refresh Statistics

The retention period defines the duration, in days, for which materialized view refresh
statistics are stored in the data dictionary. Collected statistics are automatically purged
after the retention period is reached.
The retention period for materialized view refresh statistics can be set either at the
database level or the materialized view level. The RETENTION_PERIOD parameter in
DBMS_MVIEW_STATS.SET_SYSTEM_DEFAULT or
DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS enables you to specify the
duration for which materialized view refresh statistics must be retained in the data
dictionary.
3.10.5.2 Specifying the Default Retention Period for Materialized View Refresh
Statistics
The DBMS_MVIEW_STATS.SET_SYSTEM_DEFAULT procedure sets defaults for
managing the retention of materialized view refresh statistics at the database level.
By default, Oracle Database retains materialized view refresh statistics for 365 days
from the date of collection. After the retention period is reached, the statistics are
purged from the data dictionary. You can override the system default setting by
specifying different settings at the individual materialized view level. Materialized
views for which the default settings are not overridden will continue to use the system
default settings.
You can specify that refresh statistics must never be purged from the database by
setting the retention period to -1.
To specify a new default retention period for the entire database:
Set the RETENTION_PERIOD parameter of the
DBMS_MVIEW_STATS.SET_SYSTEM_DEFAULT procedure to the required number
of days
Example 3-12
Setting the Retention Period for Materialized View Refresh Statistics
This example sets the default retention period for materialized view refresh statistics
for the entire database to 60 days.
DBMS_MVIEW_STATS.SET_SYSTEM_DEFAULT ('RETENTION_PERIOD',60);
Example 3-13
Preventing the Purging of Materialized View Refresh Statistics
This example sets the retention period for materialized view refresh statistics to -1
thereby ensuring that refresh statistics are not automatically purged when the default
retention period is reached. When you use this setting, refresh statistics will need to be
explicitly purged from the data dictionary using the
DBMS_MVIEW_STATS.PURGE_REFRESH_STATS procedure.
DBMS_MVIEW_STATS.SET_SYSTEM_DEFAULT ('RETENTION_PERIOD',1);
See Also:
3.10.5.3 Modifying the Retention Period for Materialized View Refresh Statistics
The DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS procedure enables you to
modify the retention period set for materialized view refresh statistics.
You can modify the retention period either for the entire database or for one or more
materialized views. When you modify the retention period only for specific
materialized views, the remaining materialized views in the database continue to use
their existing retention period.
Suppose that your system default setting is to collect basic materialized view refresh
statistics and retain them for 60 days. However, for a particular set of materialized
views, you want to collect detailed statistics and retain these statistics for 45 days. In
this case, for the specific set of materialized views, you set COLLECTION_LEVEL to
ADVANCED and RETENTION_PERIOD to 45.
To modify the retention period for materialized view refresh statistics either at the
database level to materialized view level:
Run the DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS procedure and set
the RETENTION_PERIOD parameter to the required value
Example 3-14 Using Default Materialized View Refresh Statistics Settings for
Retention Period
This example sets the collection level for the materialized view SALES_MV in the SH
schema to TYPICAL. Since NULL is used for the retention period, the system-wide
default setting for retention period is used for this materialized view.
DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS ('SH.SALES_MV','TYPICAL',NULL);
Example 3-15
Setting the Retention Period for a Materialized View
This example sets the collection level for the SH.SALES_MV to ADVANCED and the
retention period to 45 days. This overrides the existing retention period set for this
materialized view.
DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS ('SH.SALES_MV','ADVANCED',45);
See Also:
3.10.6 Viewing Materialized View Refresh Statistics Settings

Data dictionary views store both the default settings and materialized view-specific
settings that manage materialized view refresh statistics.
To view the database-level default settings for collecting and retaining materialized
view refresh statistics:
Query the parameter_name and value columns in the
DBA_MVREF_STATS_SYS_DEFAULTS view
To view the collection and retention settings for refresh statistics of one or more
materialized views:
Query the parameter_name and value columns in the
DBA_MVREF_STATS_PARAMS view by filtering data using the mv_owner and
mv_name columns
Example 3-16 Displaying the Database-level Default Settings for Managing
Materialized View Refresh Statistics
The following query displays the database level default settings for managing
materialized view refresh statistics:
SELECT parameter_name, value from DBA_MVREF_STATS_SYS_DEFAULTS;
PARAMETER_NAME
--------------COLLECTION_LEVEL
RETENTION_PERIOD
Example 3-17
Views
VALUE
-------TYPICAL
45
Displaying the Refresh Statistics Settings for a Set of Materialized
The following query displays the refresh statistics settings for all the materialized view
owned by the SH schema:
SELECT mv_name,collection_level,retention_period
FROM DBA_MVREF_STATS_PARAMS
WHERE mv_owner = 'SH';
MV_NAME
COLLECTION_LEVEL
RETENTION_PERIOD
--------------------------------------MY_RTMV
ADVANCED
60
NEW_SALES_RTMV
ADVANCED
45
MY_SUM_SALES_RTMV
TYPICAL
31
SALES_RTMV
TYPICAL
-1
CAL_MONTH_SALES_MV
TYPICAL
45
5 rows selected.
3.10.7 Purging Materialized View Refresh Statistics

The DBMS_MVIEW_STATS.PURGE_REFRESH_STATS procedure enables you to
explicitly purge materialized view refresh statistics that are older than a specified
period from the data dictionary.
By default, materialized view refresh statistics are removed from the data dictionary
after the specified retention period. Depending on your settings, the purging may be
performed for the entire database or for a set of specified materialized views. You can
use the DBMS_MVIEW_STATS.PURGE_REFRESH_STATS procedure to explicitly purge
refresh statistics that are older than a specified time without altering the set retention
period. Explicit purging of refresh statistics overrides the current setting for retention
period but does not alter the setting.
To purge materialized view refresh statistics stored in the database:
Run the DBMS_MVIEW_STATS.PURGE_REFRESH_STATS procedure.
Specify the materialized views for which statistics must be purged and the
duration beyond which statistics must be purged.
Example 3-18
Purging Refresh Statistics for a Materialized View
Assume that the retention period for refresh statistics of the materialized view
SALES_MV is 60 days. At any given time, the refresh statistics for the previous 60 days
are available. However, because of space constraints, you want to purge the statistics
for the last 30 days. Use the DBMS_MVIEW_STATS.PURGE_REFRESH_STATS
procedure to do this.
Note that the retention period set for SALES_MV remains unaltered. The purge is a
one-time operation.
DBMS_MVIEW_STATS.PURGE_REFRESH_STATS (SH.SALES_MV,30);
Example 3-19
Purging Refresh Statistics for All Materialized Views
This example purges materialized view refresh statistics that are older than 20 days for
all materialized views in the database. Specifying NULL instead of one or more
materialized views indicates that this setting is for the entire database.
DBMS_MVIEW_STATS.PURGE_REFRESH_STATS (NULL,20);
See Also:
PURGE_REFRESH_STATS Procedure (page A-2)
3.10.8 Viewing Materialized View Refresh Statistics

You can view both current and historical statistics for materialized view refresh
operations by querying the data dictionary views that store refresh statistics.
Depending on the collection level setting, materialized view refresh statistics are
stored in one or more of the following views: DBA_MVREFS_STATS,
DBA_MVREF_RUN_STATS, DBA_MVREF_CHANGE_STATS, and
DBA_MVREF_STMT_STATS. There are corresponding USER_ versions for all these
views. The views contain a REFRESH_ID column that can be used to join one or more
views, when required.
The following sections contain information about viewing various materialized view
refresh statistics:
Viewing Basic Refresh Statistics for a Materialized View (page 3-22)
Use the DBA_MVREF_STATS view to display basic statistics about
materialized view refresh operations.
Viewing Detailed Statistics for Each Materialized View Refresh Operation
(page 3-22)
The DBA_MVREF_RUN_STATS view stores detailed statistics about
materialized view refresh operation. When a refresh operation affects
multiple materialized views, detailed statistics are available for all
affected materialized views.
Viewing Change Data Statistics During Materialized View Refresh Operations
(page 3-23)
The DBA_MVREF_CHANGE_STATS view stores detailed change data
statistics for materialized view refresh operations. This includes the base
tables that were refreshed, the number of rows inserted, number of rows
updated, number of rows deleted, and partition maintenance operations
(PMOPs) details.
Viewing the SQL Statements Associated with A Materialized View Refresh

Operation (page 3-24)
Query the DBA_MVREF_STMT_STATS view to display information about
all the SQL statements used in a materialized view refresh operation.
3.10.8.1 Viewing Basic Refresh Statistics for a Materialized View

Use the DBA_MVREF_STATS view to display basic statistics about materialized view
refresh operations.
Each materialized view refresh operation is identified using a unique refresh ID. The
DBA_MVREF_STATS view stores the refresh ID, refresh method, names of materialized
views refreshed, basic execution times, and the number of steps in the refresh
operation.
To view basic refresh statistics for materialized view refresh operations:
Query the DBA_MVREF_STATS view with list of required columns and use
conditions to filter the required data
Example 3-20
Displaying Basic Statistics for a Materialized View Refresh Operation
The following query displays some refresh statistics for refresh operations on the
SH.NEW_SALES_RTMV materialized view. Information includes the refresh method,
refresh time, number of rows in the materialized view at the start of the refresh
operation, and number of rows at the end of the refresh operation.
SELECT refresh_id, refresh_method, elapsed_time, initial_num_rows, final_num_rows
FROM dba_mvref_stats
WHERE mv_name = 'NEW_SALES_RTMV' and mv_owner = 'SH';
REFRESH_ID
---------49
61
81
REFRESH_METHOD
-------------FAST
FAST
FAST
ELAPSED_TIME
------------0
1
1
INITIAL_NUM_ROWS
---------------766
788
788
FINAL_NUM_ROWS
---------------788
788
798
3 rows selected.
Example 3-21
Displaying Materialized Views Based on their Refresh Times
The following example displays the names of materialized views whose refresh
operations took more than 10 minutes. Since elapsed_time is specified in seconds,
we use 600 in the query.
SELECT mv_owner, mv_name, refresh_method
FROM dba_mvref_stats
WHERE elapsed_time > 600;
3.10.8.2 Viewing Detailed Statistics for Each Materialized View Refresh Operation
The DBA_MVREF_RUN_STATS view stores detailed statistics about materialized view
refresh operation. When a refresh operation affects multiple materialized views,
detailed statistics are available for all affected materialized views.
Materialized views can be refreshed using one of the following procedures in the
DBMS_MVIEW package: REFRESH, REFRESH_DEPENDENT, or REFRESH_ALL. Each
procedure contains different parameters that specify how the refresh must be
performed. The DBA_MVREF_RUN_STATS view contains information about the
parameters specified for the refresh operation, the number of materialized views
refreshed, execution times, and log purge time.
To view detailed refresh statistics for materialized view refresh operations:
Query the DBA_MVREF_RUN_STATS view with the list of required columns and use
conditions to filter the required data
Example 3-22
Operation
Listing All Materialized Views Refreshed in a Single Refresh
The following example displays the materialized views and refresh times for
materialized views that were refreshed as part of the specified refresh ID.
SELECT mviews, elapsed_time, complete_stats_available
FROM dba_mvref_run_stats
WHERE refresh_id = 100;
MVIEWS
-------"SH"."SALES_RTMV"
Example 3-23
Operation
ELAPSED_TIME
-----------1
COMPLETE_STATS_AVAIALBE
------------------------Y
Viewing the Parameters Specified During a Materialized View Refresh
The following example displays the list of refreshed materialized views and some of
the parameters specified during the refresh operation for refresh ID 81.
SELECT mviews, refresh_after_errors, purge_option, parallelism, nested
FROM dba_mvref_run_stats
WHERE run_owner = 'SH' and refresh_id=81;
MVIEWS
-----"SH"."SALES_RTMV"
Example 3-24
Operation
R
N
PURGE_OPTION
-----------0
N
PARALLELISM NESTED
------------ -------
Displaying Detailed Statistics for a Materialized View Refresh
The following example displays detailed statistics for the refresh operation with
refresh ID 156. The details include the number of materialized views refreshed, the
owner and names of materialized views, and the time taken for the refresh.
SELECT num_mvs, mv_owner, mv_name, r.elapsed_time
FROM dba_mvref_stats s, dba_mvref_run_stats r
WHERE s.refresh_id = r.refresh_id and refresh_id = 156;
NUM_MVS
-------1
MV_OWNER
-------SH
MV_NAME
-------SALES_RTMV
ELAPSED_TIME
----------5
3.10.8.3 Viewing Change Data Statistics During Materialized View Refresh Operations
The DBA_MVREF_CHANGE_STATS view stores detailed change data statistics for
materialized view refresh operations. This includes the base tables that were refreshed,
the number of rows inserted, number of rows updated, number of rows deleted, and
partition maintenance operations (PMOPs) details.
You can join the DBA_MVREF_CHANGE_STATS view with other views that contain
materialized view refresh statistics to provide more complete statistics.
To view detailed change data statistics for materialized view refresh operations:
Query the DBA_MVREF_CHANGE_STATS view with the list of required columns

and use conditions to filter the required data
Example 3-25
Determining if a Refresh Operation Resulted in PMOPs
The following example displays the base table names and PMOP details for the refresh
operation with refresh ID 1876. The query output contains one record for each base
table of the materialized view.
SELECT tbl_name, mv_name, pmops_occurred, pmop_details
FROM dba_mvref_change_stats
WHERE refresh_id =1876;
TBL_NAME
--------MY_SALES
Example 3-26
MV_NAME
PMOPS_OCCURRED
--------------------SALES_RTMV
N
PMOP_DETAILS
------------
Displaying the Number of Rows Modified During a Refresh Operation
This example displays the following details about each base table in a refresh
operation on the SH.MY_SALES materialized view: number of rows in the tables,
number of rows inserted, number of rows updates, number of rows deleted, number
of direct load inserts, and details of PMOP operations.
SELECT tbl_name, num_rows, num_rows_ins, num_rows_upd, num_rows_del,
num_rows_dl_ins, pmops_occurred, pmop_details
FROM dba_mvref_change_stats
WHERE mv_name = 'MY_SALES' and mv_owner = 'SH';
3.10.8.4 Viewing the SQL Statements Associated with A Materialized View Refresh
Operation
Query the DBA_MVREF_STMT_STATS view to display information about all the SQL
statements used in a materialized view refresh operation.
Each refresh operation can consist of multiple steps, each of which is performed using
a SQL statement. For each step in a refresh operation, you can view the step number
and the SQL statement.
To view the SQL statements associated with materialized view refresh operations:
Query the DBA_MVREF_STMT_STATS view with the list of required columns and
use conditions to filter the required data
Example 3-27
Displaying SQL Statements for Each Step in a Refresh Operation
The following example displays the materialized view names, SQL statements used to
refresh the materialized view, and execution time for the materialized view refresh
operation with refresh ID is 1278.
SELECT mv_name, step, stmt, execution_time
FROM dba_mvref_stmt_stats
WHERE refresh_id = 1278;
Example 3-28 Displaying Refresh Statements Used in the Current Refresh of an

Materialized View
This example displays the individual SQL statements that are used to the refresh the
MY_SALES materialized view. A single refresh operation may consist of multiple steps,
each of which executes a SQL statement. The details displayed in this example include
the step number, SQL ID of the SQL statement, the SQL statement that is executed,
and the execution time for the SQL statement.
SELECT step, sqlid, stmt, execution_time

FROM DBA_MVREF_STATS M, DBA_MVREF_STMT_STATS S
WHERE M.refresh_id = S.refresh_id and M.mv_name = 'MY_SALES'
ORDER BY step;
3.10.9 Analyzing Materialized View Refresh Performance Using Refresh Statistics

Materialized view refresh statistics that are stored in data dictionary views can be used
to analyze the refresh performance of materialized views.
Refresh statistics provide detailed information that enables you to understand and
analyze materialized view refresh operations and their performance. Typically, you
analyze refresh statistics for critical or long running materialized view refresh
operations. If a materialized view takes longer to refresh than it does normally, then
you can analyze its past refresh times and change data to identify any differences that
may account for the increased time (for example, 5 times more data that needs to be
refreshed this time).
To analyze materialized view refresh performance:
1. Set the collection level and retention period for the materialized view to collect
refresh statistics over a period of time.
You can set these at the database level or at the materialized view level.
2. Identify the materialized views whose refresh performance needs to be analyzed.
Typically, you would be interested in analyzing the refresh performance of a

specific set of materialized views in the database. In this case, you can modify the
refresh statistics settings for these materialized views as per your requirement.
3. Where multiple refresh operations take place over a period of time (for the
materialized views you want to analyze), Oracle Database collects the desired
refresh statistics.
4. Query the data dictionary views that store refresh statistics and analyze the refresh
behavior of materialized views of interest over time to understand refresh

behavior.
The database stores both historical and current statistics which can be analyzed to
understand refresh behavior.
4
Partitioning
Partitioning allows the break down of tables and indexes into smaller physical pieces
while keeping the logical view of a single object. Partitioning improves the
performance, manageability, and availability of large objects in the database by
enabling processing and data management to happen on the smaller physical pieces
called partitions.
This chapter describes how to use some of the new features related to partitioning.
About Creating List-Partitioned Tables (page 4-1)
Creating a Table with Read-Only Partitions or Subpartitions (page 4-3)
Filtering Maintenance Operations (page 4-4)
Creating a Table for Exchange With a Partitioned Table (page 4-5)
About Splitting Partitions and Subpartitions (page 4-6)
Converting a Non-Partitioned Table to a Partitioned Table (page 4-7)
4.1 About Creating List-Partitioned Tables

The semantics for creating list partitions are very similar to those for creating range
partitions. However, to create list partitions, you specify a PARTITION BY LIST
clause in the CREATE TABLE statement, and the PARTITION clauses specify lists of
literal values, which are the discrete values of the partitioning columns that qualify
rows to be included in the partition. For list partitioning, the partitioning key can be
one or multiple column names from the table.
Available only with list partitioning, you can use the keyword DEFAULT to describe
the value list for a partition. This identifies a partition that accommodates rows that do
not map into any of the other partitions.
As with range partitions, optional subclauses of a PARTITION clause can specify
physical and other attributes specific to a partition segment. If not overridden at the
partition level, partitions inherit the attributes of their parent table.
Creating an Automatic List-Partitioned Table (page 4-1)
Creating a Multi-column List-Partitioned Table (page 4-2)
4.1.1 Creating an Automatic List-Partitioned Table

The automatic list partitioning method enables list partition creation on demand. An
auto-list partitioned table is similar to a regular list partitioned table, except that this
partitioned table is easier to manage. You can create an auto-list partitioned table
using only the partitioning key values that are known. As data is loaded into the table,
the database automatically creates a new partition if the loaded partitioning key value
Partitioning 4-1
About Creating List-Partitioned Tables
does not correspond to any of the existing partitions. Because partitions are
automatically created on demand, the auto-list partitioning method is conceptually
similar to the existing interval partitioning method.
Automatic list partitioning on data types whose value changes very frequently are less
suitable for this method unless you can adjust the data. For example, a SALES_DATE
field with a date value, when the format is not stripped, would increase every second.
Each of the SALES_DATE values, such as 05-22-2016 08:00:00, 05-22-2016
08:00:01, and so on, would generate its own partition. To avoid the creation of a
very large number of partitions, you must be aware of the data that would be entered
and adjust accordingly. As an example, you can truncate the SALES_DATE date value
to a day or some other time period, depending on the number of partitions required.
The CREATE and ALTER TABLE SQL statements are updated with an additional clause
to specify AUTOMATIC or MANUAL list partitioning. An automatic list-partitioned table
must have at least one partition when created. Because new partitions are
automatically created for new, and unknown, partition key values, an automatic list
partition cannot have a DEFAULT partition.
Example 4-1 (page 4-2) is an example of the CREATE TABLE statement using the
AUTOMATIC keyword for auto-list partitioning on the sales_state field. The SQL
statement creates at least one partition as required.
Example 4-1
Creating an automatic list partitioned table
CREATE TABLE sales_auto_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) AUTOMATIC
(PARTITION P_CAL VALUES ('CALIFORNIA')
);
You can check the AUTOLIST column of the *_PART_TABLES view to determine
whether a table is automatic list-partitioned.
4.1.2 Creating a Multi-column List-Partitioned Table

Multi-column list partitioning enables you to partition a table based on list values of
multiple columns. Similar to single-column list partitioning, individual partitions can
contain sets containing lists of values.
Multi-column list partitioning is supported on a table using the PARTITION BY LIST
clause on multiple columns of a table. For example:
PARTITION BY LIST (column1,column2)
A multi-column list-partitioned table can only have one DEFAULT partition.

The following is an example of the CREATE TABLE statement using multi-column
partitioning on the state and channel columns.
Example 4-2
Creating a multicolumn list-partitioned table
CREATE TABLE sales_by_region_and_channel

(deptno
NUMBER,
deptname
VARCHAR2(20),
Creating a Table with Read-Only Partitions or Subpartitions
quarterly_sales NUMBER(10,2),
state
VARCHAR2(2),
channel
VARCHAR2(1)
)
PARTITION BY LIST (state, channel)
(
PARTITION q1_northwest_direct VALUES (('OR','D'), ('WA','D')),
PARTITION q1_northwest_indirect VALUES (('OR','I'), ('WA','I')),
PARTITION q1_southwest_direct VALUES (('AZ','D'),('UT','D'),('NM','D')),
PARTITION q1_ca_direct VALUES ('CA','D'),
PARTITION rest VALUES (DEFAULT)
);
4.2 Creating a Table with Read-Only Partitions or Subpartitions

You can set tables, partitions, and subpartitions to read-only status to protect data
from unintentional DML operations by any user or trigger. Any attempt to update
data in a partition or subpartition that is set to read only results in an error, while
updating data in partitions or subpartitions that are set to read write succeeds.
The CREATE TABLE and ALTER TABLE SQL statements provide a read-only clause for
partitions and subpartitions. The values of the read-only clause can be READ ONLY or
READ WRITE. READ WRITE is the default value. A higher level setting of the read-only
clause is applied to partitions and subpartitions unless the read-only clause has been
explicitly set for a partition or subpartition.
The following is an example of a creating a composite range-list partitioned table with
both read-only and read-write status. The orders_read_write_only is explicitly
specified as READ WRITE, so the default attribute of the table is read write. The default
attribute of partition order_p1 is specified as read only, so the subpartitions
ord_p1_northwest and order_p1_southwest inherit read only status from
partition order_p1. Subpartitions ord_p2_southwest and order_p3_northwest
are explicitly specified as read only, overriding the default read write status.
Example 4-3
Creating a table with read-only and read-write partitions
CREATE TABLE orders_read_write_only (

order_id NUMBER (12),
order_date DATE CONSTRAINT order_date_nn NOT NULL,
state VARCHAR2(2)
) READ WRITE
PARTITION BY RANGE (order_date)
SUBPARTITION BY LIST (state)
( PARTITION order_p1 VALUES LESS THAN (TO_DATE ('01-DEC-2015','DD-MON-YYYY'))
READ ONLY
( SUBPARTITION order_p1_northwest VALUES ('OR', 'WA'),
SUBPARTITION order_p1_southwest VALUES ('AZ', 'UT', 'NM')
),
PARTITION order_p2 VALUES LESS THAN (TO_DATE ('01-MAR-2016','DD-MON-YYYY'))
( SUBPARTITION order_p2_northwest VALUES ('OR', 'WA'),
SUBPARTITION order_p2_southwest VALUES ('AZ', 'UT', 'NM') READ ONLY
),
PARTITION order_p3 VALUES LESS THAN (TO_DATE ('01-JUL-2016','DD-MON-YYYY'))
(
SUBPARTITION order_p3_northwest VALUES ('OR', 'WA') READ ONLY,
SUBPARTITION order_p3_southwest VALUES ('AZ', 'UT', 'NM')
)
);
Partitioning 4-3
Filtering Maintenance Operations
You can check the read-only status with the DEF_READ_ONLY column of the
*_PART_TABLES view, the READ_ONLY column of the *_TAB_PARTITIONS view,
and the READ_ONLY column of the *_TAB_SUBPARTITIONS view. Note that only
physical segments, partitions for single-level partitioning and subpartitions for
composite partitioning, have a status. All other levels are logical and only have a
default status.
SQL> SELECT PARTITION_NAME, READ_ONLY FROM USER_TAB_PARTITIONS WHERE TABLE_NAME
='ORDERS_READ_WRITE_ONLY';
PARTITION_NAME
READ
------------------------------- ---ORDER_P1
YES
ORDER_P2
NONE
ORDER_P3
NONE
SQL> SELECT PARTITION_NAME, SUBPARTITION_NAME, READ_ONLY FROM USER_TAB_SUBPARTITIONS
WHERE TABLE_NAME ='ORDERS_READ_WRITE_ONLY';
PARTITION_NAME
SUBPARTITION_NAME
REA
------------------------------ ----------------------------- --ORDER_P1
ORDER_P1_NORTHWEST
YES
ORDER_P1
ORDER_P1_SOUTHWEST
YES
ORDER_P2
ORDER_P2_NORTHWEST
NO
ORDER_P2
ORDER_P2_SOUTHWEST
YES
ORDER_P3
ORDER_P3_NORTHWEST
YES
ORDER_P3
ORDER_P3_SOUTHWEST
NO
4.3 Filtering Maintenance Operations

Partition maintenance operations support the addition of data filtering, enabling the
combination of partition and data maintenance. A filtered partition maintenance
operation only preserves the data satisfying the data filtering as part of the partition
maintenance. The capability of data filtering applies to MOVE PARTITION, MERGE
PARTITION, and SPLIT PARTITION .
Example 4-4 (page 4-5) shows the use of the ALTER TABLE statement to move a
partition while removing all orders that are not open (closed orders).
The filtering predicate must be on the partitioned table. All partition maintenance
operations that can be performed online (MOVE and SPLIT) can also be performed as
filtered partition maintenance operations. With ONLINE specified, DML operations on
the partitions being maintained are allowed.
Filtered partition maintenance operations performed in online mode do not enforce
the filter predicate on concurrent ongoing DML operations. The filter condition is only
applied one time at the beginning of the partition maintenance operation.
Consequently, any subsequent DML succeeds, but is ignored from a filtering
perspective. Records that do not match the filter condition when the partition
maintenance started are not preserved, regardless of any DML operation. Newly
inserted records are inserted if they match the partition key criteria, regardless of
whether they satisfy the filter condition of the partition maintenance operation. Filter
conditions are limited to the partitioned table itself and do not allow any reference to
other tables, such as a join or subquery expression.
Consider the following scenarios when the keyword ONLINE is specified in the SQL
statement of Example 4-4 (page 4-5).
An existing order record in partition q1_2016 that is updated to status='open'
after the partition maintenance operation has started is not be preserved in the
partition.
Creating a Table for Exchange With a Partitioned Table
A new order record with status='closed' can be inserted in partition q1_2016

after the partition maintenance operation has started and while the partition
maintenance operation is ongoing.
Example 4-4
Using a filtering clause when performing maintenance operations
ALTER TABLE orders_move_part

MOVE PARTITION q1_2016 TABLESPACE open_orders COMPRESS ONLINE
INCLUDING ROWS WHERE order_state = 'open';
See Also:
Oracle Database SQL Language Reference for the exact syntax of the partitioning
clauses for creating and altering partitioned tables and indexes, any
restrictions on their use, and specific privileges required for creating and
altering tables
4.4 Creating a Table for Exchange With a Partitioned Table

Tables can be created with the FOR EXCHANGE WITH clause to exactly match the shape
of a partitioned table and be eligible for a partition exchange command, except that
indexes are not created as an operation of this command. Because the FOR EXCHANGE
WITH clause of CREATE TABLE provides an exact match between a non-partitioned
and partitioned table, this is an improvement over the CREATE TABLE AS SELECT
statement.
The following list is a summary of the effects of the CREATE TABLE FOR EXCHANGE
WITH DDL operation:
The use case of this DDL operation is to facilitate creation of a table to be used for
exchange partition DDL.
The operation creates a clone of the for exchange table in terms of column ordering
and column properties.
Columns cannot be renamed. The table being created inherits the names from the
for exchange table.
The only logical property that can be specified during the DDL operation is the
partitioning specification of the table.
The partitioning clause is only relevant for the exchange with a partition of a
composite-partitioned table. In this case, a partition with n subpartitions is
exchanged with a partitioned table with n partitions matching the subpartitions.
You are responsible for the definition of the partitioning clause for this exchange in
this scenario.
The subpartitioning can be asymmetrical across partitions. The partitioning clause
has to match exactly the subpartitioning of the partition to being exchanged.
The physical properties which can be specified are primarily table segment
attributes.
Column properties copied with this DDL operation include, but are not limited to,
the following: unusable columns, invisible columns, virtual expression columns,
functional index expression columns, and other internal settings and attributes.
Partitioning 4-5
About Splitting Partitions and Subpartitions
The following is an example of the CREATE TABLE statement using the FOR EXCHANGE
WITH clause to create the sales_exchange table to mimic the shape of the sales
table in terms of column ordering and properties.
Example 4-5
Using the FOR EXCHANGE WITH clause of CREATE TABLE
CREATE TABLE sales_exchange

TABLESPACE my_sales_tblspace
FOR EXCHANGE WITH TABLE sales;
4.5 About Splitting Partitions and Subpartitions

The SPLIT PARTITION clause of the ALTER TABLE or ALTER INDEX statement is
used to redistribute the contents of a partition into two new partitions. Consider doing
this when a partition becomes too large and causes backup, recovery, or maintenance
operations to take a long time to complete or it is felt that there is simply too much
data in the partition. You can also use the SPLIT PARTITION clause to redistribute the
I/O load. This clause cannot be used for hash partitions or subpartitions.
If the partition you are splitting contains any data, then indexes may be marked
UNUSABLE as explained in the following table:
Table Type
Index Behavior
Regular (Heap)
Unless you specify UPDATE INDEXES as part of the ALTER TABLE

statement:
The database marks UNUSABLE the new partitions (there are two) in
each local index.
Any global indexes, or all partitions of partitioned global indexes,
are marked UNUSABLE and must be rebuilt.
Index-organized
The database marks UNUSABLE the new partitions (there are two) in
each local index.
All global indexes remain usable.
You cannot split partitions or subpartitions in a reference-partitioned table except for

the parent table. When you split partitions or subpartitions in the parent table then the
split is cascaded to all descendant tables. However, you can use the DEPENDENT
TABLES clause to set specific properties for dependent tables when you issue the
SPLIT statement on the master table to split partitions or subpartitions.
Partition maintenance with SPLIT operations are supported as online operations with
the keyword ONLINE for heap organized tables, enabling concurrent DML operations
while a partition maintenance operation is ongoing.
For ONLINE operations, split indexes are always updated by default, regardless
whether you specify the UPDATE INDEXES clause.
In the following example, the sales_q4_2016 partition of theORDERS table is split
into separate partitions for each month. The ONLINE keyword is specified to enable
concurrent DML operations while a partition maintenance operation is ongoing. If
there were any indexes on the ORDERS table, then those would be maintained
automatically as part of the online split.
CREATE TABLE orders
(prod_id
NUMBER(6),
cust_id
NUMBER,
time_id
DATE,
channel_id
CHAR(1),
Converting a Non-Partitioned Table to a Partitioned Table
promo_id
NUMBER(6),
quantity_sold NUMBER(3),
amount_sold NUMBER(10,2)
)
PARTITION BY RANGE (time_id)
(PARTITION sales_q1_2016 VALUES
PARTITION sales_q2_2016 VALUES
);
LESS
LESS
LESS
LESS
THAN
THAN
THAN
THAN
(TO_DATE('01-APR-2016','dd-MON-yyyy')),
(TO_DATE('01-JUL-2016','dd-MON-yyyy')),
(TO_DATE('01-OCT-2016','dd-MON-yyyy')),
(TO_DATE('01-JAN-2017','dd-MON-yyyy'))
ALTER TABLE orders

SPLIT PARTITION sales_q4_2016 INTO
(PARTITION sales_oct_2016 VALUES LESS THAN (TO_DATE('01-NOV-2016','dd-MON-yyyy')),
PARTITION sales_nov_2016 VALUES LESS THAN (TO_DATE('01-DEC-2016','dd-MON-yyyy')),
PARTITION sales_dec_2016
)
ONLINE;
4.6 Converting a Non-Partitioned Table to a Partitioned Table

A non-partitioned table can be converted to a partitioned table with a MODIFY clause
added to the ALTER TABLE SQL statement. In addition, the keyword ONLINE can be
specified, enabling concurrent DML operations while the conversion is ongoing.
The following is an example of the ALTER TABLE statement using the ONLINE
keyword for an online conversion to a partitioned table.
Example 4-6 Using the MODIFY clause of ALTER TABLE to convert online to a
partitioned table
ALTER TABLE employees_convert MODIFY
PARTITION BY RANGE (employee_id) INTERVAL (100)
( PARTITION P1 VALUES LESS THAN (100),
PARTITION P2 VALUES LESS THAN (500)
) ONLINE
UPDATE INDEXES
( IDX1_SALARY LOCAL,
IDX2_EMP_ID GLOBAL PARTITION BY RANGE (employee_id)
( PARTITION IP1 VALUES LESS THAN (MAXVALUE))
);
Considerations When Using the UPDATE INDEXES Clause

When using the UPDATE INDEXES clause, note the following.
This clause can be used to change the partitioning state of indexes and storage
properties of the indexes being converted.
The specification of the UPDATE INDEXES clause is optional.
Indexes are maintained both for the online and offline conversion to a partitioned
table.
This clause cannot change the columns on which the original list of indexes are
defined.
This clause cannot change the uniqueness property of the index or any other index
property.
Partitioning 4-7
Converting a Non-Partitioned Table to a Partitioned Table
If you do not specify the tablespace for any of the indexes, then the following
tablespace defaults apply.
Local indexes after the conversion collocate with the table partition.
Global indexes after the conversion reside in the same tablespace of the original
global index on the non-partitioned table.
If you do not specify the INDEXES clause or the INDEXES clause does not specify
all the indexes on the original non-partitioned table, then the following default
behavior applies for all unspecified indexes.
Global partitioned indexes remain the same and retain the original partitioning
shape.
Non-prefixed indexes become global nonpartitioned indexes.
Prefixed indexes are converted to local partitioned indexes.
Prefixed means that the partition key columns are included in the index
definition, but the index definition is not limited to including the partitioning
keys only.
Bitmap indexes become local partitioned indexes, regardless whether they are
prefixed or not.
Bitmap indexes must always be local partitioned indexes.
The conversion operation cannot be performed if there are domain indexes.
5
Handling Data Errors
Unlike logical errors, data rule violations are not usually anticipated by the load or
transformation process. Such unexpected data rule violations (also known as data
errors) that are not handled from an operation cause the operation to fail. Data rule
violations are error conditions that happen inside the database and cause a statement
to fail. Examples of this are data type conversion errors or constraint violations.
In the past, SQL did not offer a way to handle data errors on a row level as part of its
bulk processing. The only way to handle data errors inside the database was to use
PL/SQL. Now, however, you can handle data conversion errors using SQL functions.
This chapter describes how to use some of the new features related to handling data
errors.
Handling Data Errors with SQL (page 5-1)
External data that is used during the data transformation process may
sometimes be inaccurate thereby causing data conversion errors. Certain
SQL functions can be used to handle data conversion errors.
SQL Language Reference Details for Handling Data Errors (page 5-2)
5.1 Handling Data Errors with SQL

External data that is used during the data transformation process may sometimes be
inaccurate thereby causing data conversion errors. Certain SQL functions can be used
to handle data conversion errors.
The COMPATIBLE parameter must be set to 12.2 to use SQL functions that handle data
conversion errors.
The following strategies are available to handle data conversion errors with SQL
functions:
Explicit filtering of either valid or invalid data
The VALIDATE_CONVERSION function identifies problem data that cannot be
converted to the required data type. It returns 1 if a given expression can be
converted to the specified data type, else it returns 0.
Error handling within SQL data type conversion functions
The CAST, TO_NUMBER, TO_BINARY_FLOAT, TO_BINARY_DOUBLE, TO_DATE,
TO_TIMESTAMP, TO_TIMESTAMP_TZ, TO_DSINTERVAL, and TO_YMINTERVAL
functions can return a user-specified value, instead of an error, when data type
conversion errors occur. This reduces failures during an ETL process.
The user-specified value is returned only if an error occurs while converting the
expression, not when evaluating the expression. The CAST function also allows
format strings and NLS parameter strings as arguments for certain data types.
Handling Data Errors 5-1
SQL Language Reference Details for Handling Data Errors
Example 5-1
Errors
Using VALIDATE_CONVERSION and CAST to Handle Data Conversion
Assume that data is loaded into the PRODUCTS table from the TMP_PRODUCTS table.
The number and names of columns in both tables are the same, but the data type of
the prod_id column is different. The prod_id column in the PRODUCTS table is of
data type NUMBER. Although the data in the prod_id column in the TMP_PRODUCTS
table is numeric, its data type is VARCHAR2. While loading data into the PRODUCTS
table, you can handle data type conversion errors on the prod_id column by either
filtering out the rows containing incorrect prod_id values or assigning a default
value for prod_id values that cannot be converted to NUMBER.
The following command loads data from the TMP_PRODUCTS table into PRODUCTS
table. Only rows where tmp_products.prod_id can be successfully converted into
a numeric value are inserted.
INSERT INTO PRODUCTS
(SELECT prod_id, prod_name, prod_desc, prod_category_id, prod_category_name,
prod_category_desc, prod_list_price
FROM tmp_products
WHERE VALIDATE_CONVERSION(prod_id AS NUMBER)=1);
You can use the CAST function to handle prod_id values that cause data type
conversion errors. The following INSERT command loads data from the
TMP_PRODUCTS table into the PRODUCTS table. The CAST function used with
prod_id ensures that the default value of 0 is assigned to prod_id when a data type
conversion error occurs. This ensures that the load operation does not fail because of
data type conversion errors.
INSERT INTO PRODUCTS
(SELECT CAST(prod_id AS NUMBER DEFAULT 0 ON CONVERSION ERROR), prod_name,
prod_desc, prod_category_id, prod_category_name, prod_category_desc,
prod_list_price
FROM tmp_products);
See Also:
SQL Language Reference Details for Handling Data Errors (page 5-2) for
more information about the CAST and VALIDATE_CONVERSION functions
and their supported data types
5.2 SQL Language Reference Details for Handling Data Errors

This section describes the SQL functions that enable you to handle data conversion
errors.
CAST (page 5-3)
TO_BINARY_DOUBLE (page 5-8)
TO_BINARY_FLOAT (page 5-9)
TO_DATE (page 5-11)
TO_DSINTERVAL (page 5-13)
TO_NUMBER (page 5-15)
TO_TIMESTAMP (page 5-16)
TO_TIMESTAMP_TZ (page 5-17)

TO_YMINTERVAL (page 5-18)
VALIDATE_CONVERSION (page 5-20)
5.2.1 CAST
Syntax
expr
CAST
AS
MULTISET
subquery
type_name
,
DEFAULT
return_value
ON
CONVERSION
ERROR
nlsparam
fmt
)
Purpose
CAST lets you convert built-in data types or collection-typed values of one type into
another built-in data type or collection type. You can cast an unnamed operand (such
as a date or the result set of a subquery) or a named collection (such as a varray or a
nested table) into a type-compatible data type or named collection. The type_name
must be the name of a built-in data type or collection type and the operand must be a
built-in data type or must evaluate to a collection value.
For the operand, expr can be either a built-in data type, a collection type, or an
instance of an ANYDATA type. If expr is an instance of an ANYDATA type, then CAST
tries to extract the value of the ANYDATA instance and return it if it matches the cast
target type, otherwise, null will be returned. MULTISET informs Oracle Database to
take the result set of the subquery and return a collection value. Table 5-1 (page 5-3)
shows which built-in data types can be cast into which other built-in data types. (CAST
does not support LONG, LONG RAW, or the Oracle-supplied types.)
CAST does not directly support any of the LOB data types. When you use CAST to
convert a CLOB value into a character data type or a BLOB value into the RAW data
type, the database implicitly converts the LOB value to character or raw data and then
explicitly casts the resulting value into the target data type. If the resulting value is
larger than the target type, then the database returns an error.
When you use CAST ... MULTISET to get a collection value, each select list item in the
query passed to the CAST function is converted to the corresponding attribute type of
the target collection element type.
Table 5-1
Casting Built-In Data Types
Destination
Data Type
from
BINARY_F
LOAT,
BINARY_D
OUBLE
from
CHAR,
VARCHAR
2
from
NUMBER/
INTEGER
from
DATETIME
/
INTERVAL
(Note 1)
from RAW
from
ROWID,
UROWID
(Note 2)
from
NCHAR,
NVARCHAR
2
to
BINARY_FLO
AT,
BINARY_DO
UBLE
X (Note 3)
X (Note 3)
X (Note 3)
--
--
--
X (Note 3)
Table 5-1
(Cont.) Casting Built-In Data Types
Destination
Data Type
from
BINARY_F
LOAT,
BINARY_D
OUBLE
from
CHAR,
VARCHAR
2
from
NUMBER/
INTEGER
from
DATETIME
/
INTERVAL
(Note 1)
from RAW
from
ROWID,
UROWID
(Note 2)
from
NCHAR,
NVARCHAR
2
to CHAR,
VARCHAR2
--
to NUMBER/
INTEGER
X (Note 3)
X (Note 3)
X (Note 3)
--
--
--
X (Note 3)
to
DATETIME/
INTERVAL
--
X (Note 3)
--
X (Note 3)
--
--
--
to RAW
--
--
--
--
--
to ROWID,
UROWID
--
--
--
--
--
to NCHAR,
NVARCHAR
2
--
Note 1: Datetime/interval includes DATE, TIMESTAMP, TIMESTAMP WITH TIMEZONE,

TIMESTAMP WITH LOCAL TIME ZONE, INTERVAL DAY TO SECOND, and INTERVAL
YEAR TO MONTH.
Note 2: You cannot cast a UROWID to a ROWID if the UROWID contains the value of a
ROWID of an index-organized table.
Note 3: You can specify the DEFAULT return_value ON CONVERSION ERROR clause
for this type of conversion. You can specify the fmt and nlsparam clauses for this
type of conversion with the following exceptions: you cannot specify fmt when
converting to INTERVAL DAY TO SECOND, and you cannot specify fmt or nlsparam
when converting to INTERVAL YEAR TO MONTH.
If you want to cast a named collection type into another named collection type, then
the elements of both collections must be of the same type.
MULTISET
If the result set of subquery can evaluate to multiple rows, then you must specify the
MULTISET keyword. The rows resulting from the subquery form the elements of the
collection value into which they are cast. Without the MULTISET keyword, the
subquery is treated as a scalar subquery.
Restriction on MULTISET
If you specify the MULTISET keyword, then you cannot specify the DEFAULT
return_value ON CONVERSION ERROR, fmt, or nlsparam clauses.
DEFAULT return_value ON CONVERSION ERROR
This clause allows you to specify the value returned by this function if an error occurs
while converting expr to type_name. This clause has no effect if an error occurs
while evaluating expr.
This clause is valid if expr evaluates to a character string of type CHAR, VARCHAR2,
NCHAR, or NVARCHAR2, and type_name is BINARY_DOUBLE, BINARY_FLOAT, DATE,
INTERVAL DAY TO SECOND, INTERVAL YEAR TO MONTH, NUMBER, TIMESTAMP,
TIMESTAMP WITH TIME ZONE, or TIMESTAMP WITH LOCAL TIME ZONE.
The return_value can be a string literal, null, constant expression, or a bind
variable, and must evaluate to null or a character string of type CHAR, VARCHAR2,
NCHAR, or NVARCHAR2. If return_value cannot be converted to type_name, then
the function returns an error.
fmt and nlsparam
The fmt argument lets you specify a format model and the nlsparam argument lets
you specify NLS parameters. If you specify these arguments, then they are applied
when converting expr and return_value, if specified, to type_name.
You can specify fmt and nlsparam if type_name is one of the following data types:
BINARY_DOUBLE
If you specify BINARY_DOUBLE, then the optional fmt and nlsparam arguments
serve the same purpose as for the TO_BINARY_DOUBLE function. Refer to
TO_BINARY_DOUBLE (page 5-8) for more information.
BINARY_FLOAT
If you specify BINARY_FLOAT, then the optional fmt and nlsparam arguments
serve the same purpose as for the TO_BINARY_FLOAT function. Refer to
TO_BINARY_FLOAT (page 5-9) for more information.
DATE
If you specify DATE, then the optional fmt and nlsparam arguments serve the
same purpose as for the TO_DATE function. Refer to TO_DATE (page 5-11) for
more information.
NUMBER
If you specify NUMBER, then the optional fmt and nlsparam arguments serve the
same purpose as for the TO_NUMBER function. Refer to TO_NUMBER (page 5-15)
for more information.
TIMESTAMP
If you specify TIMESTAMP, then the optional fmt and nlsparam arguments serve
the same purpose as for the TO_TIMESTAMP function. If you omit fmt, then expr
must be in the default format of the TIMESTAMP data type, which is determined
explicitly by the NLS_TIMESTAMP_FORMAT parameter or implicitly by the
NLS_TERRITORY parameter. Refer to TO_TIMESTAMP (page 5-16) for more
information.
TIMESTAMP WITH TIME ZONE
If you specify TIMESTAMP WITH TIME ZONE, then the optional fmt and nlsparam
arguments serve the same purpose as for the TO_TIMESTAMP_TZ function. If you
omit fmt, then expr must be in the default format of the TIMESTAMP WITH TIME
ZONE data type, which is determined explicitly by the
NLS_TIMESTAMP_TZ_FORMAT parameter or implicitly by the NLS_TERRITORY
parameter. Refer to TO_TIMESTAMP_TZ (page 5-17) for more information.
TIMESTAMP WITH LOCAL TIME ZONE
If you specify TIMESTAMP WITH LOCAL TIME ZONE then the optional fmt and
nlsparam arguments serve the same purpose as for the TO_TIMESTAMP function.
If you omit fmt, then expr must be in the default format of the TIMESTAMP data
type, , which is determined explicitly by the NLS_TIMESTAMP_FORMAT parameter
or implicitly by the NLS_TERRITORY parameter. Refer to TO_TIMESTAMP
(page 5-16) for more information.
Built-In Data Type Examples
The following examples use the CAST function with scalar data types. The first
example converts text to a timestamp value by applying the format model provided in
the session parameter NLS_TIMESTAMP_FORMAT. If you want to avoid dependency
on this NLS parameter, then you can use the TO_DATE as shown in the second
example.
SELECT CAST('22-OCT-1997'
AS TIMESTAMP WITH LOCAL TIME ZONE)
FROM DUAL;
SELECT CAST(TO_DATE('22-Oct-1997', 'DD-Mon-YYYY')
AS TIMESTAMP WITH LOCAL TIME ZONE)
FROM DUAL;
In the preceding example, TO_DATE converts from text to DATE, and CAST converts
from DATE to TIMESTAMP WITH LOCAL TIME ZONE, interpreting the date in the
session time zone (SESSIONTIMEZONE).
SELECT product_id, CAST(ad_sourcetext AS VARCHAR2(30)) text
FROM print_media
ORDER BY product_id;
The following examples return a default value if an error occurs while converting the
specified value to the specified data type. In these examples, the conversions occurs
without error.
SELECT CAST(200
AS NUMBER
DEFAULT 0 ON CONVERSION ERROR)
FROM DUAL;
SELECT CAST('January 15, 1989, 11:00 A.M.'
AS DATE
DEFAULT NULL ON CONVERSION ERROR,
'Month dd, YYYY, HH:MI A.M.')
FROM DUAL;
SELECT CAST('1999-12-01 11:00:00 -8:00'
AS TIMESTAMP WITH TIME ZONE
DEFAULT '2000-01-01 01:00:00 -8:00' ON CONVERSION ERROR,
'YYYY-MM-DD HH:MI:SS TZH:TZM',
'NLS_DATE_LANGUAGE = American')
FROM DUAL;
In the following example, an error occurs while converting 'N/A' to a NUMBER value.
Therefore, the CAST function returns the default value of 0.
SELECT CAST('N/A'
AS NUMBER
DEFAULT '0' ON CONVERSION ERROR)
FROM DUAL;
Collection Examples
The CAST examples that follow build on the cust_address_typ found in the sample
order entry schema, oe.
CREATE TYPE address_book_t AS TABLE OF cust_address_typ;
/
CREATE TYPE address_array_t AS VARRAY(3) OF cust_address_typ;
/
CREATE TABLE cust_address (
custno
NUMBER,
street_address
VARCHAR2(40),
postal_code
VARCHAR2(10),
city
VARCHAR2(30),
state_province
VARCHAR2(10),
country_id
CHAR(2));
CREATE TABLE cust_short (custno NUMBER, name VARCHAR2(31));
CREATE TABLE states (state_id NUMBER, addresses address_array_t);
This example casts a subquery:

SELECT s.custno, s.name,
CAST(MULTISET(SELECT ca.street_address,
ca.postal_code,
ca.city,
ca.state_province,
ca.country_id
FROM cust_address ca
WHERE s.custno = ca.custno)
AS address_book_t)
FROM cust_short s
ORDER BY s.custno;
CAST converts a varray type column into a nested table:

SELECT CAST(s.addresses AS address_book_t)
FROM states s
WHERE s.state_id = 111;
The following objects create the basis of the example that follows:
CREATE TABLE projects
(employee_id NUMBER, project_name VARCHAR2(10));
CREATE TABLE emps_short
(employee_id NUMBER, last_name VARCHAR2(10));
CREATE TYPE project_table_typ AS TABLE OF VARCHAR2(10);
/
The following example of a MULTISET expression uses these objects:

SELECT e.last_name,
CAST(MULTISET(SELECT p.project_name
FROM projects p
WHERE p.employee_id = e.employee_id
ORDER BY p.project_name)
AS project_table_typ)
FROM emps_short e
ORDER BY e.last_name;
5.2.2 TO_BINARY_DOUBLE
Syntax
DEFAULT
TO_BINARY_DOUBLE
expr
nlsparam
return_value
ON
CONVERSION
ERROR
fmt
)
Purpose
TO_BINARY_DOUBLE converts expr to a double-precision floating-point number.
expr can be any expression that evaluates to a character string of type CHAR,
VARCHAR2, NCHAR, or NVARCHAR2, a numeric value of type NUMBER,
BINARY_FLOAT, or BINARY_DOUBLE, or null. If expr is BINARY_DOUBLE, then
the function returns expr. If expr evaluates to null, then the function returns null.
Otherwise, the function converts expr to a BINARY_DOUBLE value.
The optional DEFAULT return_value ON CONVERSION ERROR clause allows you
to specify the value returned by this function if an error occurs while converting
expr to BINARY_DOUBLE. This clause has no effect if an error occurs while
evaluating expr. The return_value can be an expression or a bind variable, and
must evaluate to a character string of type CHAR, VARCHAR2, NCHAR, or
NVARCHAR2, a numeric value of type NUMBER, BINARY_FLOAT, or
BINARY_DOUBLE, or null. The function converts return_value to
BINARY_DOUBLE in the same way it converts expr to BINARY_DOUBLE. If
return_value cannot be converted to BINARY_DOUBLE, then the function
returns an error.
The optional 'fmt' and 'nlsparam' arguments serve the same purpose as for the
TO_NUMBER function. If you specify these arguments, then expr and
return_value, if specified, must each be a character string or null. If either is a
character string, then the function uses the fmt and nlsparam arguments to
convert the character string to a BINARY_DOUBLE value.
If expr or return_value evaluate to the following character strings, then the
function converts them as follows:
The case-insensitive string 'INF' is converted to positive infinity.
The case-insensitive string '-INF' is converted to negative identity.
The case-insensitive string 'NaN' is converted to NaN (not a number).
You cannot use a floating-point number format element (F, f, D, or d) in a character
string expr.
Conversions from character strings or NUMBER to BINARY_DOUBLE can be inexact,
because the NUMBER and character types use decimal precision to represent the
numeric value, and BINARY_DOUBLE uses binary precision.
Conversions from BINARY_FLOAT to BINARY_DOUBLE are exact.
Examples
The examples that follow are based on a table with three columns, each with a
different numeric data type:
CREATE TABLE float_point_demo
(dec_num NUMBER(10,2), bin_double BINARY_DOUBLE, bin_float BINARY_FLOAT);
INSERT INTO float_point_demo
VALUES (1234.56,1234.56,1234.56);
SELECT * FROM float_point_demo;
DEC_NUM BIN_DOUBLE BIN_FLOAT
---------- ---------- ---------1234.56 1.235E+003 1.235E+003
The following example converts a value of data type NUMBER to a value of data type
BINARY_DOUBLE:
SELECT dec_num, TO_BINARY_DOUBLE(dec_num)
FROM float_point_demo;
DEC_NUM TO_BINARY_DOUBLE(DEC_NUM)
---------- ------------------------1234.56
1.235E+003
The following example compares extracted dump information from the dec_num and
bin_double columns:
SELECT DUMP(dec_num) "Decimal",
DUMP(bin_double) "Double"
Decimal
Double
--------------------------- --------------------------------------------Typ=2 Len=4: 194,13,35,57 Typ=101 Len=8: 192,147,74,61,112,163,215,10
The following example returns the default value of 0 because the specified expression
cannot be converted to a BINARY_DOUBLE value:
SELECT TO_BINARY_DOUBLE('2oo' DEFAULT 0 ON CONVERSION ERROR) "Value"
FROM DUAL;
Value
---------0
5.2.3 TO_BINARY_FLOAT
Syntax
DEFAULT
TO_BINARY_FLOAT
,
,
return_value
ON
CONVERSION
ERROR
expr
nlsparam
fmt
)
Purpose
TO_BINARY_FLOAT converts expr to a single-precision floating-point number.
VARCHAR2, NCHAR, or NVARCHAR2, a numeric value of type NUMBER,
BINARY_FLOAT, or BINARY_DOUBLE, or null. If expr is BINARY_FLOAT, then the
function returns expr. If expr evaluates to null, then the function returns null.
Otherwise, the function converts expr to a BINARY_FLOAT value.
The optional DEFAULT return_value ON CONVERSION ERROR clause allows you
to specify the value returned by this function if an error occurs while converting
expr to BINARY_FLOAT. This clause has no effect if an error occurs while
evaluating expr. The return_value can be an expression or a bind variable, and
must evaluate to a character string of type CHAR, VARCHAR2, NCHAR, or
NVARCHAR2, a numeric value of type NUMBER, BINARY_FLOAT, or
BINARY_DOUBLE, or null. The function converts return_value to
BINARY_FLOAT in the same way it converts expr to BINARY_FLOAT. If
return_value cannot be converted to BINARY_FLOAT, then the function returns
an error.
The optional 'fmt' and 'nlsparam' arguments serve the same purpose as for the
TO_NUMBER function. If you specify these arguments, then expr and
return_value, if specified, must each be a character string or null. If either is a
character string, then the function uses the fmt and nlsparam arguments to
convert the character string to a BINARY_FLOAT value.
If expr or return_value evaluate to the following character strings, then the
function converts them as follows:
The case-insensitive string 'INF' is converted to positive infinity.
The case-insensitive string '-INF' is converted to negative identity.
The case-insensitive string 'NaN' is converted to NaN (not a number).
You cannot use a floating-point number format element (F, f, D, or d) in a character
string expr.
Conversions from character strings or NUMBER to BINARY_FLOAT can be inexact,
because the NUMBER and character types use decimal precision to represent the
numeric value and BINARY_FLOAT uses binary precision.
Conversions from BINARY_DOUBLE to BINARY_FLOAT are inexact if the
BINARY_DOUBLE value uses more bits of precision than supported by the
BINARY_FLOAT.
Examples
Using table float_point_demo created for TO_BINARY_DOUBLE (page 5-8), the
following example converts a value of data type NUMBER to a value of data type
BINARY_FLOAT:
SELECT dec_num, TO_BINARY_FLOAT(dec_num)
DEC_NUM TO_BINARY_FLOAT(DEC_NUM)
---------- -----------------------1234.56
1.235E+003
cannot be converted to a BINARY_FLOAT value:
SELECT TO_BINARY_FLOAT('2oo' DEFAULT 0 ON CONVERSION ERROR) "Value"
FROM DUAL;
Value
---------0
5.2.4 TO_DATE
Syntax
DEFAULT
TO_DATE
,
,
return_value
ON
CONVERSION
ERROR
char
nlsparam
fmt
)
Purpose
TO_DATE converts char to a value of DATE data type.
For char, you can specify any expression that evaluates to a character string of CHAR,
VARCHAR2, NCHAR, or NVARCHAR2 data type.
Note:
This function does not convert data to any of the other datetime data types.
For information on other datetime conversions, refer to TO_TIMESTAMP
(page 5-16), TO_TIMESTAMP_TZ (page 5-17), TO_DSINTERVAL
(page 5-13), and TO_YMINTERVAL (page 5-18).
The optional DEFAULT return_value ON CONVERSION ERROR clause allows you to
specify the value this function returns if an error occurs while converting char to
DATE. This clause has no effect if an error occurs while evaluating char. The
return_value can be an expression or a bind variable, and it must evaluate to a
character string of CHAR, VARCHAR2, NCHAR, or NVARCHAR2 data type, or null. The
function converts return_value to DATE using the same method it uses to convert
char to DATE. If return_value cannot be converted to DATE, then the function
returns an error.
The fmt is a datetime model format specifying the format of char. If you omit fmt,
then char must be in the default date format. The default date format is determined
implicitly by the NLS_TERRITORY initialization parameter or can be set explicitly by
the NLS_DATE_FORMAT parameter. If fmt is J, for Julian, then char must be an
integer.
Caution:
It is good practice always to specify a format mask (fmt) with TO_DATE, as

shown in the examples in the section that follows. When it is used without a
format mask, the function is valid only if char uses the same format as is
determined by the NLS_TERRITORY or NLS_DATE_FORMAT parameters.
Furthermore, the function may not be stable across databases unless the
explicit format mask is specified to avoid dependencies.
The 'nlsparam' argument specifies the language of the text string that is being
converted to a date. This argument can have this form:
'NLS_DATE_LANGUAGE = language'
Do not use the TO_DATE function with a DATE value for the char argument. The first
two digits of the returned DATE value can differ from the original char, depending on
fmt or the default date format.
This function does not support CLOB data directly. However, CLOBs can be passed in
as arguments through implicit data conversion.
Examples
The following example converts a character string into a date:
SELECT TO_DATE(
'January 15, 1989, 11:00 A.M.',
'Month dd, YYYY, HH:MI A.M.',
FROM DUAL;
TO_DATE('
--------15-JAN-89
The value returned reflects the default date format if the NLS_TERRITORY parameter
is set to 'AMERICA'. Different NLS_TERRITORY values result in different default date
formats:
ALTER SESSION SET NLS_TERRITORY = 'KOREAN';
SELECT TO_DATE(
'January 15, 1989, 11:00 A.M.',
'Month dd, YYYY, HH:MI A.M.',
FROM DUAL;
TO_DATE(
-------89/01/15
The following example returns the default value because the specified expression
cannot be converted to a DATE value, due to a misspelling of the month:
SELECT TO_DATE('Febuary 15, 2016, 11:00 A.M.'
DEFAULT 'January 01, 2016 12:00 A.M.' ON CONVERSION ERROR,
'Month dd, YYYY, HH:MI A.M.') "Value"
FROM DUAL;
Value
--------01-JAN-16
5.2.5 TO_DSINTERVAL
Syntax
sql_format
TO_DSINTERVAL
ds_iso_format
DEFAULT
return_value
ON
CONVERSION
ERROR
)
sql_format::=
+
.
days
hours
minutes
frac_secs
seconds
ds_iso_format::=
days
.
hours
minutes
seconds
frac_secs
S
Note:
In earlier releases, the TO_DSINTERVAL function accepted an optional

nlsparam clause. This clause is still accepted for backward compatibility, but
has no effect.
Purpose
TO_DSINTERVAL converts its argument to a value of INTERVAL DAY TO SECOND data
type.
For the argument, you can specify any expression that evaluates to a character string
of CHAR, VARCHAR2, NCHAR, or NVARCHAR2 data type.
TO_DSINTERVAL accepts argument in one of the two formats:
SQL interval format compatible with the SQL standard (ISO/IEC 9075:2003)
ISO duration format compatible with the ISO 8601:2004 standard
In the SQL format, days is an integer between 0 and 999999999, hours is an integer
between 0 and 23, and minutes and seconds are integers between 0 and 59.
frac_secs is the fractional part of seconds between .0 and .999999999. One or more
blanks separate days from hours. Additional blanks are allowed between format
elements.
In the ISO format, days, hours, minutes and seconds are integers between 0 and
999999999. frac_secs is the fractional part of seconds between .0 and .999999999. No
blanks are allowed in the value. If you specify T, then you must specify at least one of
the hours, minutes, or seconds values.
specify the value this function returns if an error occurs while converting the
argument to an INTERVAL DAY TO SECOND type. This clause has no effect if an error
occurs while evaluating the argument. The return_value can be an expression or a
bind variable, and it must evaluate to a character string of CHAR, VARCHAR2, NCHAR,
or NVARCHAR2 data type. It can be in either the SQL format or ISO format, and need
not be in the same format as the function argument. If return_value cannot be
converted to an INTERVAL DAY TO SECOND type, then the function returns an error.
Examples
The following example uses the SQL format to select from the hr.employees table
the employees who had worked for the company for at least 100 days on November 1,
2002:
SELECT employee_id, last_name FROM employees
WHERE hire_date + TO_DSINTERVAL('100 00:00:00')
<= DATE '2002-11-01'
ORDER BY employee_id;
EMPLOYEE_ID
----------102
203
204
205
206
LAST_NAME
--------------De Haan
Mavris
Baer
Higgins
Giet
The following example uses the ISO format to display the timestamp 100 days and 5
hours after the beginning of the year 2009:
SELECT TO_CHAR(TIMESTAMP '2009-01-01 00:00:00' + TO_DSINTERVAL('P100DT05H'),
'YYYY-MM-DD HH24:MI:SS') "Time Stamp"
FROM DUAL;
Time Stamp
------------------2009-04-11 05:00:00
cannot be converted to an INTERVAL DAY TO SECOND value:
SELECT TO_DSINTERVAL('1o 1:02:10'
DEFAULT '10 8:00:00' ON CONVERSION ERROR) "Value"
FROM DUAL;
Value
----------------------------+000000010 08:00:00.000000000
5.2.6 TO_NUMBER
Syntax
DEFAULT
TO_NUMBER
,
,
return_value
ON
CONVERSION
ERROR
expr
nlsparam
fmt
)
Purpose
TO_NUMBER converts expr to a value of NUMBER data type.
VARCHAR2, NCHAR, or NVARCHAR2, a numeric value of type NUMBER, BINARY_FLOAT,
or BINARY_DOUBLE, or null. If expr is NUMBER, then the function returns expr. If
expr evaluates to null, then the function returns null. Otherwise, the function
converts expr to a NUMBER value.
If you specify an expr of CHAR, VARCHAR2, NCHAR, or NVARCHAR2 data type, then
you can optionally specify the format model fmt.
If you specify an expr of BINARY_FLOAT or BINARY_DOUBLE data type, then you
cannot specify a format model because a float can be interpreted only by its internal
representation.
The 'nlsparam' argument in this function has the same purpose as it does in the
TO_CHAR function for number conversions.
Examples
The following examples convert character string data into a number:
UPDATE employees SET salary = salary +
TO_NUMBER('100.00', '9G999D99')
WHERE last_name = 'Perkins';
SELECT TO_NUMBER('-AusDollars100','L9G999D99',
' NLS_NUMERIC_CHARACTERS = '',.''
NLS_CURRENCY
= ''AusDollars''
') "Amount"
FROM DUAL;
Amount
----------100
cannot be converted to a NUMBER value:
SELECT TO_NUMBER('2,00' DEFAULT 0 ON CONVERSION ERROR) "Value"
FROM DUAL;
Value
-------0
5.2.7 TO_TIMESTAMP
Syntax
DEFAULT
TO_TIMESTAMP
char
nlsparam
return_value
ON
CONVERSION
ERROR
fmt
)
Purpose
TO_TIMESTAMP converts char to a value of TIMESTAMP data type.
TIMESTAMP. This clause has no effect if an error occurs while evaluating char. The
return_value can be an expression or a bind variable, and it must evaluate to a
character string of CHAR, VARCHAR2, NCHAR, or NVARCHAR2 data type, or null. The
function converts return_value to TIMESTAMP using the same method it uses to
convert char to TIMESTAMP. If return_value cannot be converted to TIMESTAMP,
then the function returns an error.
The optional fmt specifies the format of char. If you omit fmt, then char must be in
the default format of the TIMESTAMP data type, which is determined by the
NLS_TIMESTAMP_FORMAT initialization parameter. The optional 'nlsparam'
argument has the same purpose in this function as in the TO_CHAR function for date
conversion.
Examples
The following example converts a character string to a timestamp. The character string
is not in the default TIMESTAMP format, so the format mask must be specified:
SELECT TO_TIMESTAMP ('10-Sep-02 14:10:10.123000', 'DD-Mon-RR HH24:MI:SS.FF')
FROM DUAL;
TO_TIMESTAMP('10-SEP-0214:10:10.123000','DD-MON-RRHH24:MI:SS.FF')
--------------------------------------------------------------------------10-SEP-02 02.10.10.123000000 PM
The following example returns the default value of NULL because the specified
expression cannot be converted to a TIMESTAMP value, due to an invalid month
specification:
SELECT TO_TIMESTAMP ('10-Sept-02 14:10:10.123000'

'DD-Mon-RR HH24:MI:SS.FF',
'NLS_DATE_LANGUAGE = American') "Value"
FROM DUAL;
5.2.8 TO_TIMESTAMP_TZ
Syntax
DEFAULT
TO_TIMESTAMP_TZ
,
,
return_value
ON
CONVERSION
ERROR
char
nlsparam
fmt
)
Purpose
TO_TIMESTAMP_TZ converts char to a value of TIMESTAMP WITH TIME ZONE data
type.
Note:
This function does not convert character strings to TIMESTAMP WITH LOCAL
TIME ZONE. To do this, use a CAST function, as shown in CAST (page 5-3).
TIMESTAMP WITH TIME ZONE. This clause has no effect if an error occurs while
evaluating char. The return_value can be an expression or a bind variable, and it
must evaluate to a character string of CHAR, VARCHAR2, NCHAR, or NVARCHAR2 data
type, or null. The function converts return_value to TIMESTAMP WITH TIME ZONE
using the same method it uses to convert char to TIMESTAMP WITH TIME ZONE. If
return_value cannot be converted to TIMESTAMP WITH TIME ZONE, then the
function returns an error.
The optional fmt specifies the format of char. If you omit fmt, then char must be in
the default format of the TIMESTAMP WITH TIME ZONE data type. The optional
'nlsparam' has the same purpose in this function as in the TO_CHAR function for
date conversion.
Examples
The following example converts a character string to a value of TIMESTAMP WITH
TIME ZONE:
SELECT TO_TIMESTAMP_TZ('1999-12-01 11:00:00 -8:00',
'YYYY-MM-DD HH:MI:SS TZH:TZM') FROM DUAL;
TO_TIMESTAMP_TZ('1999-12-0111:00:00-08:00','YYYY-MM-DDHH:MI:SSTZH:TZM')
-------------------------------------------------------------------01-DEC-99 11.00.00.000000000 AM -08:00
The following example casts a null column in a UNION operation as TIMESTAMP WITH
LOCAL TIME ZONE using the sample tables oe.order_items and oe.orders:
SELECT order_id, line_item_id,
CAST(NULL AS TIMESTAMP WITH LOCAL TIME ZONE) order_date
FROM order_items
UNION
SELECT order_id, to_number(null), order_date
FROM orders;
ORDER_ID LINE_ITEM_ID ORDER_DATE
---------- ------------ ----------------------------------2354
1
2354
2
2354
3
2354
4
2354
5
2354
6
2354
7
2354
8
2354
9
2354
10
2354
11
2354
12
2354
13
2354
14-JUL-00 05.18.23.234567 PM
2355
1
2355
2
. . .
The following example returns the default value of NULL because the specified
expression cannot be converted to a TIMESTAMP WITH TIME ZONE value, due to an
invalid month specification:
SELECT TO_TIMESTAMP_TZ('1999-13-01 11:00:00 -8:00'
'YYYY-MM-DD HH:MI:SS TZH:TZM') "Value"
FROM DUAL;
5.2.9 TO_YMINTERVAL
Syntax
+
years
TO_YMINTERVAL
months
ym_iso_format
DEFAULT
return_value
ON
CONVERSION
ERROR
)
ym_iso_format::=
years
months
days
.
hours
minutes
seconds
frac_secs
S
Purpose
TO_YMINTERVAL converts its argument to a value of INTERVAL MONTH TO YEAR data
type.
For the argument, you can specify any expression that evaluates to a character string
of CHAR, VARCHAR2, NCHAR, or NVARCHAR2 data type.
TO_YMINTERVAL accepts argument in one of the two formats:
SQL interval format compatible with the SQL standard (ISO/IEC 9075:2003)
ISO duration format compatible with the ISO 8601:2004 standard
In the SQL format, years is an integer between 0 and 999999999, and months is an
integer between 0 and 11. Additional blanks are allowed between format elements.
In the ISO format, years and months are integers between 0 and 999999999. Days,
hours, minutes, seconds, and frac_secs are non-negative integers, and are ignored,
if specified. No blanks are allowed in the value. If you specify T, then you must specify
at least one of the hours, minutes, or seconds values.
specify the value this function returns if an error occurs while converting the
argument to an INTERVAL MONTH TO YEAR type. This clause has no effect if an error
occurs while evaluating the argument. The return_value can be an expression or a
bind variable, and it must evaluate to a character string of CHAR, VARCHAR2, NCHAR,
or NVARCHAR2 data type. It can be in either the SQL format or ISO format, and need
not be in the same format as the function argument. If return_value cannot be
converted to an INTERVAL MONTH TO YEAR type, then the function returns an error.
Examples
The following example calculates for each employee in the sample hr.employees
table a date one year two months after the hire date:
SELECT hire_date, hire_date + TO_YMINTERVAL('01-02') "14 months"
FROM employees;
HIRE_DATE
--------17-JUN-03
21-SEP-05
13-JAN-01
20-MAY-08
21-MAY-07
14 months
--------17-AUG-04
21-NOV-06
13-MAR-02
20-JUL-09
21-JUL-08
. . .
The following example makes the same calculation using the ISO format:
SELECT hire_date, hire_date + TO_YMINTERVAL('P1Y2M') FROM employees;
cannot be converted to an INTERVAL MONTH TO YEAR value:
SELECT TO_YMINTERVAL('1x-02'
DEFAULT '00-00' ON CONVERSION ERROR) "Value"
FROM DUAL;
Value
------------+000000000-00
5.2.10 VALIDATE_CONVERSION
Syntax
,
,
VALIDATE_CONVERSION
expr
AS
nlsparam
fmt
type_name
Purpose
VALIDATE_CONVERSION determines whether expr can be converted to the specified
data type. If expr can be successfully converted, then this function returns 1;
otherwise, this function returns 0. If expr evaluates to null, then this function returns
1. If an error occurs while evaluating expr, then this function returns the error.
For expr, specify a SQL expression. The acceptable data types for expr, and the
purpose of the optional fmt and nlsparam arguments, depend on the data type you
specify for type_name.
For type_name, specify the data type to which you want to convert expr. You can
specify the following data types:
BINARY_DOUBLE
If you specify BINARY_DOUBLE, then expr can be any expression that evaluates to
a character string of CHAR, VARCHAR2, NCHAR, or NVARCHAR2 data type, or a
numeric value of type NUMBER, BINARY_FLOAT, or BINARY_DOUBLE. The optional
fmt and nlsparam arguments serve the same purpose as for the
TO_BINARY_DOUBLE function. Refer to TO_BINARY_DOUBLE (page 5-8) for more
information.
BINARY_FLOAT
If you specify BINARY_FLOAT, then expr can be any expression that evaluates to a
character string of CHAR, VARCHAR2, NCHAR, or NVARCHAR2 data type, or a
fmt and nlsparam arguments serve the same purpose as for the
TO_BINARY_FLOAT function. Refer to TO_BINARY_FLOAT (page 5-9) for more
information.
DATE
If you specify DATE, then expr can be any expression that evaluates to a character
string of CHAR, VARCHAR2, NCHAR, or NVARCHAR2 data type. The optional fmt and
nlsparam arguments serve the same purpose as for the TO_DATE function. Refer
to TO_DATE (page 5-11) for more information.
INTERVAL DAY TO SECOND

If you specify INTERVAL DAY TO SECOND, then expr can be any expression that
evaluates to a character string of CHAR, VARCHAR2, NCHAR, or NVARCHAR2 data
type, and must contain a value in either the SQL interval format or the ISO
duration format. The optional fmt and nlsparam arguments do not apply for this
data type. Refer to TO_DSINTERVAL (page 5-13) for more information on the SQL
interval format and the ISO duration format.
INTERVAL YEAR TO MONTH
If you specify INTERVAL YEAR TO MONTH, then expr can be any expression that
type, and must contain a value in either the SQL interval format or the ISO
duration format. The optional fmt and nlsparam arguments do not apply for this
data type. Refer to TO_YMINTERVAL (page 5-18) for more information on the SQL
interval format and the ISO duration format.
NUMBER
If you specify NUMBER, then expr can be any expression that evaluates to a
character string of CHAR, VARCHAR2, NCHAR, or NVARCHAR2 data type, or a
fmt and nlsparam arguments serve the same purpose as for the TO_NUMBER
function. Refer to TO_NUMBER (page 5-15) for more information.
If expr is a value of type NUMBER, then the VALIDATE_CONVERSION function
verifies that expr is a legal numeric value. If expr is not a legal numeric value,
then the function returns 0. This enables you to identify corrupt numeric values in
your database.
TIMESTAMP
If you specify TIMESTAMP, then expr can be any expression that evaluates to a
character string of CHAR, VARCHAR2, NCHAR, or NVARCHAR2 data type. The
optional fmt and nlsparam arguments serve the same purpose as for the
TO_TIMESTAMP function. If you omit fmt, then expr must be in the default format
of the TIMESTAMP data type, which is determined by the
NLS_TIMESTAMP_FORMAT initialization parameter. Refer to TO_TIMESTAMP
TIMESTAMP WITH TIME ZONE
If you specify TIMESTAMP WITH TIME ZONE, then expr can be any expression that
type. The optional fmt and nlsparam arguments serve the same purpose as for
the TO_TIMESTAMP_TZ function. If you omit fmt, then expr must be in the
default format of the TIMESTAMP WITH TIME ZONE data type, which is determined
by the NLS_TIMESTAMP_TZ_FORMAT initialization parameter. Refer to
TO_TIMESTAMP_TZ (page 5-17) for more information.
TIMESTAMP WITH LOCAL TIME ZONE
If you specify TIMESTAMP, then expr can be any expression that evaluates to a
character string of CHAR, VARCHAR2, NCHAR, or NVARCHAR2 data type. The
optional fmt and nlsparam arguments serve the same purpose as for the
TO_TIMESTAMP function. If you omit fmt, then expr must be in the default format
of the TIMESTAMP data type, which is determined by the
NLS_TIMESTAMP_FORMAT initialization parameter. Refer to TO_TIMESTAMP
Examples
In each of the following statements, the specified value can be successfully converted
to the specified data type. Therefore, each of these statements returns a value of 1.
SELECT VALIDATE_CONVERSION(1000 AS BINARY_DOUBLE)
FROM DUAL;
SELECT VALIDATE_CONVERSION('1234.56' AS BINARY_FLOAT)
FROM DUAL;
SELECT VALIDATE_CONVERSION('July 20, 1969, 20:18' AS DATE,
'Month dd, YYYY, HH24:MI', 'NLS_DATE_LANGUAGE = American')
FROM DUAL;
SELECT VALIDATE_CONVERSION('200 00:00:00' AS INTERVAL DAY TO SECOND)
FROM DUAL;
SELECT VALIDATE_CONVERSION('P1Y2M' AS INTERVAL YEAR TO MONTH)
FROM DUAL;
SELECT VALIDATE_CONVERSION('$100,00' AS NUMBER,
'$999D99', 'NLS_NUMERIC_CHARACTERS = '',.''')
FROM DUAL;
SELECT VALIDATE_CONVERSION('29-Jan-02 17:24:00' AS TIMESTAMP,
'DD-MON-YY HH24:MI:SS')
FROM DUAL;
SELECT VALIDATE_CONVERSION('1999-12-01 11:00:00 -8:00'
AS TIMESTAMP WITH TIME ZONE, 'YYYY-MM-DD HH:MI:SS TZH:TZM')
FROM DUAL;
SELECT VALIDATE_CONVERSION('11-May-16 17:30:00'
AS TIMESTAMP WITH LOCAL TIME ZONE, 'DD-MON-YY HH24:MI:SS')
FROM DUAL;
The following statement returns 0, because the specified value cannot be converted to
BINARY_FLOAT:
SELECT VALIDATE_CONVERSION('$29.99' AS BINARY_FLOAT)
FROM DUAL;
The following statement returns 1, because the specified number format model enables
the value to be converted to BINARY_FLOAT:
SELECT VALIDATE_CONVERSION('$29.99' AS BINARY_FLOAT, '$99D99')
FROM DUAL;
6
Advanced Aggregates for Analysis
This chapter describes how to use some of the new features related to advanced
aggregates for analysis.
LISTAGG Function (page 6-1)
The LISTAGG function orders data within each group based on the
ORDER BY clause and then concatenates the values of the measure
column.
LISTAGG as Aggregate (page 6-2)
SQL Language Reference Details for Advanced Aggregates (page 6-4)
6.1 LISTAGG Function

The LISTAGG function orders data within each group based on the ORDER BY clause
and then concatenates the values of the measure column.
In releases prior to Oracle Database 12c Release 2 (12.2), if the concatenated value
returned by the LISTAGG function exceeds the maximum length supported for the
return data type, then the following error is returned:
ORA-01489: result of string concatenation is too long
Starting with Oracle Database 12c Release 2 (12.2), you can truncate the return string to
fit within the maximum length supported for the return data type and display a
truncation literal to indicate that the return value was truncated. The truncation is
performed after the last complete data value thereby ensuring that no incomplete data
value is displayed.
The syntax of the LISTAGG function is as follows:
LISTAGG ( [ALL] <measure_column> [,<delimiter>] [ON OVERFLOW TRUNCATE
[truncate_literal] | ON OVERFLOW ERROR [WITH | WITHOUT COUNT]])
WITHIN GROUP (ORDER BY <oby_expression_list>)
measure_column can be a column, constant, bind variable, or an expression

involving them.
When the return string does not fit within the maximum length supported for the data
type, you can either display an error or truncate the return string and display a
truncation literal. The default is ON OVERFLOW ERROR, which displays an error when
truncation occurs.
truncate_literal can be NULL, a string literal, or constant expression. It is
appended to the end of the list of values, after the last delimiter, when LISTAGG
returns a value that is larger than the maximum length supported for the return data
type. The default value is an ellipsis (...).
Advanced Aggregates for Analysis 6-1
LISTAGG as Aggregate
WITH COUNT displays the number of data values that were truncated from the
LISTAGG output because the maximum length supported for the return data type was
exceeded. This is the default option. Use WITHOUT COUNT to omit displaying a count
at the end of the LISTAGG function when the string is truncated.
delimiter can be NULL (default value), a string literal, bind variable, or constant
expression. This is a mandatory parameter. If no delimiter is specified, then NULL is
used as the delimiter.
oby_expression_list can be a list of expressions with optional ordering options to
sort in ascending or descending order (ASC or DESC), and to control the sort order of
NULLs (NULLS FIRST or NULLS LAST). ASCENDING and NULLS LAST are the
defaults.
See Also:
Oracle Database SQL Language Reference for information about the maximum
length supported for the VARCHAR2 data type
6.2 LISTAGG as Aggregate

You can use the LISTAGG function as an aggregate.
Example 6-1
The following example illustrates using LISTAGG as an aggregate.

SELECT prod_id, LISTAGG(cust_first_name||' '||cust_last_name, '; ')
WITHIN GROUP (ORDER BY amount_sold DESC) cust_list
FROM sales, customers
WHERE sales.cust_id = customers.cust_id AND cust_gender = 'M'
AND cust_credit_limit = 15000 AND prod_id BETWEEN 15 AND 18
AND channel_id = 2 AND time_id > '01-JAN-01'
GROUP BY prod_id;
PROD_ID
------15
16
17
18
CUST_LIST
----------------------------------------------Hope Haarper; Roxanne Crocker; ... Mason Murray
Manvil Austin; Bud Pinkston; ... Helga Nickols
Opal Aaron; Thacher Rudder; ... Roxanne Crocker
Boyd Lin; Bud Pinkston; ... Erik Ready
The output has been modified for readability. In this case, the ellipsis indicate that
some values before the last customer name have been omitted from the output.
Example 6-2
Length
LISTAGG with Return String Exceeding the Maximum Permissible
This example orders data within each group specified by the GROUP BY clause and
concatenates the values in the cust_first_name and cust_last_name columns. If
the list of concatenated names exceeds the maximum length supported for the
VARCHAR2 data type, then the list is truncated to the last complete name. At the end of
the list, the overflow literal of ... is appended followed by the number of values that
were truncated.
SELECT country_region,
LISTAGG(s.CUST_FIRST_NAME||' '|| s.CUST_LAST_NAME, ';' ON OVERFLOW TRUNCATE WITH
COUNT) WITHIN GROUP (ORDER BY s.cust_id) AS customer_names
FROM countries c, customers s
WHERE c.country_id = s.country_id

GROUP BY c.country_region
ORDER BY c.country_region;
COUNTRY_REGION
-------------------CUSTOMER_NAMES
-------------------------------------------------------------------------------Africa
Laurice Lincoln;Kirsten Newkirk;Verna Yarborough;Chloe Dwyer;Betty Sampler;Terry
Hole;Waren Parkburg;Uwe Feldman;Douglas Hanson;Woodrow Lazar;Alfred Doctor;Stac
.
.
Zwolinsky;Buzz Milenova;Abbie Venkayala
COUNTRY_REGION
-------------------CUSTOMER_NAMES
-------------------------------------------------------------------------------Americas
Linette Ingram;Vida Puleo;Gertrude Atkins;Sibil Haul;Raina Cassidy;Kaula Daley;G
abriela Sean;Dolores Moore;Erica Vandermark;Madallyn Ladd;Carolyn Hinkle;Leonora
.
.
emphill;Urban Smyth;Murry Ivy;Steven Lauers;...(21482)
COUNTRY_REGION
-------------------CUSTOMER_NAMES
-------------------------------------------------------------------------------Asia
Harriett Charles;Willa Fitz;Faith Fischer;Gay Nance;Maggie Cain;Neda Clatterbuck
;Justa Killman;Penelope Oliver;Mandisa Grandy;Marette Overton;Astrid Rice;Poppy
.
.
ob Gentile;Lynn Hardesty;Mabel Barajas;...(1648)
COUNTRY_REGION
-------------------CUSTOMER_NAMES
-------------------------------------------------------------------------------Europe
Abigail Kessel;Anne Koch;Buick Emmerson;Frank Hardy;Macklin Gowen;Rosamond Kride
r;Raina Silverberg;Gloria Saintclair;Macy Littlefield;Yuri Finch;Bertilde Sexton
.
.
el Floyd;Lincoln Sean;Morel Gregory;Kane Speer;...(30284)
COUNTRY_REGION
-------------------CUSTOMER_NAMES
-------------------------------------------------------------------------------Middle East
Dalila Rockwell;Alma Elliott;Cara Jeffreys;Joy Sandstrum;Elizabeth Barone;Whitby
Burnns;Geoffrey Door;Austin Dutton;Tobin Newcomer;Blake Overton;Lona Kimball;Lo
.
.
edy;Brandon Moy;Sydney Fenton
COUNTRY_REGION
--------------------
SQL Language Reference Details for Advanced Aggregates
CUSTOMER_NAMES
-------------------------------------------------------------------------------Oceania
Fredericka Umstatt;Viola Nettles;Alyce Reagan;Catherine Odenwalld;Mauritia Linde
green;Heidi Schmidt;Ray Wade;Cicily Graham;Myrtle Joseph;Joan Morales;Brenda Obr
.
.
;Fredie Elgin;Gilchrist Lease;Guthrey Cain;...(793)
6 rows selected.
6.3 SQL Language Reference Details for Advanced Aggregates

This section describes the SQL functions that enable you to perform advanced
aggregations.
LISTAGG (page 6-4)
6.3.1 LISTAGG
Syntax
ALL
LISTAGG
listagg_overflow_clause
)
OVER
WITHIN
delimiter
measure_expr
GROUP
order_by_clause
query_partition_clause
listagg_overflow_clause::=
ON
OVERFLOW
ERROR
WITH
COUNT
ON
OVERFLOW
truncationindicator
WITHOUT
TRUNCATE
Purpose
For a specified measure, LISTAGG orders data within each group specified in the
ORDER BY clause and then concatenates the values of the measure column.
As a single-set aggregate function, LISTAGG operates on all rows and returns a
single output row.
As a group-set aggregate, the function operates on and returns an output row for
each group defined by the GROUP BY clause.
As an analytic function, LISTAGG partitions the query result set into groups based
on one or more expression in the query_partition_clause.
The arguments to the function are subject to the following rules:
The ALL keyword is optional and is provided for semantic clarity.
The measure_expr is the measure column and can be any expression. Null values
in the measure column are ignored.
The delimiter designates the string that is to separate the measure column
values. This clause is optional and defaults to NULL.
If measure_expr is of type RAW, then the delimiter must be of type RAW. You can
achieve this by specifying the delimiter as a character string that can be implicitly
converted to RAW, or by explicitly converting the delimiter to RAW, for example,
using the UTL_RAW.CAST_TO_RAW function.
The order_by_clause determines the order in which the concatenated values
are returned. The function is deterministic only if the ORDER BY column list
achieved unique ordering.
If the measure column is of type RAW, then the return data type is RAW. Otherwise, the
return data type is VARCHAR2.
The maximum length of the return data type depends on the value of the
MAX_STRING_SIZE initialization parameter. If MAX_STRING_SIZE = EXTENDED,
then the maximum length is 32767 bytes for the VARCHAR2 and RAW data types. If
MAX_STRING_SIZE = STANDARD, then the maximum length is 4000 bytes for the
VARCHAR2 data type and 2000 bytes for the RAW data type. A final delimiter is not
included when determining if the return value fits in the return data type.
listagg_overflow_clause
This clause controls how the function behaves when the return value exceeds the
maximum length of the return data type.
ON OVERFLOW ERROR If you specify this clause, then the function returns an
ORA-01489 error. This is the default.
ON OVERFLOW TRUNCATE If you specify this clause, then the function returns a
truncated list of measure values.
The truncation_indicator designates the string that is to be appended to the
truncated list of measure values. If you omit this clause, then the truncation
indicator is an ellipsis (...).
If measure_expr is of type RAW, then the truncation indicator must be of type
RAW. You can achieve this by specifying the truncation indicator as a character
string that can be implicitly converted to RAW, or by explicitly converting the
truncation indicator to RAW, for example, using the UTL_RAW.CAST_TO_RAW
function.
If you specify WITH COUNT, then after the truncation indicator, the database
appends the number of truncated values, enclosed in parentheses. In this case, the
database truncates enough measure values to allow space in the return value for a
final delimiter, the truncation indicator, and 24 characters for the number value
enclosed in parentheses.
If you specify WITHOUT COUNT, then the database omits the number of truncated
values from the return value. In this case, the database truncates enough measure
values to allow space in the return value for a final delimiter and the truncation
indicator.
If you do not specify WITH COUNT or WITHOUT COUNT, then the default is WITH
COUNT.
Aggregate Examples
The following single-set aggregate example lists all of the employees in Department 30
in the hr.employees table, ordered by hire date and last name:
SELECT LISTAGG(last_name, '; ')
WITHIN GROUP (ORDER BY hire_date, last_name) "Emp_list",
MIN(hire_date) "Earliest"
FROM employees
WHERE department_id = 30;
Emp_list
Earliest
------------------------------------------------------------ --------Raphaely; Khoo; Tobias; Baida; Himuro; Colmenares
07-DEC-02
The following group-set aggregate example lists, for each department ID in the
hr.employees table, the employees in that department in order of their hire date:
SELECT department_id "Dept.",
LISTAGG(last_name, '; ') WITHIN GROUP (ORDER BY hire_date) "Employees"
FROM employees
Dept. Employees
------ -----------------------------------------------------------10 Whalen
20 Hartstein; Fay
30 Raphaely; Khoo; Tobias; Baida; Himuro; Colmenares
40 Mavris
50 Kaufling; Ladwig; Rajs; Sarchand; Bell; Mallin; Weiss; Davie
s; Marlow; Bull; Everett; Fripp; Chung; Nayer; Dilly; Bissot
; Vollman; Stiles; Atkinson; Taylor; Seo; Fleaur; Matos; Pat
el; Walsh; Feeney; Dellinger; McCain; Vargas; Gates; Rogers;
Mikkilineni; Landry; Cabrio; Jones; Olson; OConnell; Sulliv
an; Mourgos; Gee; Perkins; Grant; Geoni; Philtanker; Markle
60 Austin; Hunold; Pataballa; Lorentz; Ernst
70 Baer
. . .
The following example is identical to the previous example, except it contains the ON
OVERFLOW TRUNCATE clause. For the purpose of this example, assume that the
maximum length of the return value is an artificially small number of 200 bytes.
Because the list of employees for department 50 exceeds 200 bytes, the list is truncated
and appended with a final delimiter '; ', the specified truncation indicator '...', and
the number of truncated values '(23)'.
SELECT department_id "Dept.",
LISTAGG(last_name, '; ' ON OVERFLOW TRUNCATE '...')
WITHIN GROUP (ORDER BY hire_date) "Employees"
FROM employees
Dept. Employees
------ -----------------------------------------------------------10 Whalen
20 Hartstein; Fay
30 Raphaely; Khoo; Tobias; Baida; Himuro; Colmenares
40 Mavris
50 Kaufling; Ladwig; Rajs; Sarchand; Bell; Mallin; Weiss; Davie
s; Marlow; Bull; Everett; Fripp; Chung; Nayer; Dilly; Bissot

; Vollman; Stiles; Atkinson; Taylor; Seo; Fleaur; ... (23)
70 Baer
. . .
Analytic Example
The following analytic example shows, for each employee hired earlier than
September 1, 2003, the employee's department, hire date, and all other employees in
that department also hired before September 1, 2003:
SELECT department_id "Dept", hire_date "Date", last_name "Name",
LISTAGG(last_name, '; ') WITHIN GROUP (ORDER BY hire_date, last_name)
OVER (PARTITION BY department_id) as "Emp_list"
FROM employees
WHERE hire_date < '01-SEP-2003'
ORDER BY "Dept", "Date", "Name";
Dept
----30
30
40
50
50
70
90
90
100
100
110
110
Date
--------07-DEC-02
18-MAY-03
07-JUN-02
01-MAY-03
14-JUL-03
07-JUN-02
13-JAN-01
17-JUN-03
16-AUG-02
17-AUG-02
07-JUN-02
07-JUN-02
Name
--------------Raphaely
Khoo
Mavris
Kaufling
Ladwig
Baer
De Haan
King
Faviet
Greenberg
Gietz
Higgins
Emp_list
--------------------------------------------Raphaely; Khoo
Raphaely; Khoo
Mavris
Kaufling; Ladwig
Kaufling; Ladwig
Baer
De Haan; King
De Haan; King
Faviet; Greenberg
Faviet; Greenberg
Gietz; Higgins
Gietz; Higgins
7
Moving a Table to a New Segment or
Tablespace
This chapter describes how to use some of the new features related to moving a table
to a new segment or tablespace.
About Moving a Table to a New Segment or Tablespace (page 7-1)
The ALTER TABLE...MOVE [PARTITION|SUBPARTITION] statement
enables you to move a table, partition, or subpartition to change any
physical storage attribute, such as compression, or the tablespace,
assuming you have the appropriate quota in the target tablespace.
Moving a Table (page 7-2)
Use the ALTER TABLE...MOVE statement to move a table to a new
segment or tablespace.
7.1 About Moving a Table to a New Segment or Tablespace

The ALTER TABLE...MOVE [PARTITION|SUBPARTITION] statement enables you
to move a table, partition, or subpartition to change any physical storage attribute,
such as compression, or the tablespace, assuming you have the appropriate quota in
the target tablespace.
ALTER TABLE...MOVE statements support the ONLINE keyword, which enables data
manipulation language (DML) operations to run uninterrupted on the table, partition,
or subpartition that is being moved. The following statements move a table, partition,
or subpartition online:
ALTER TABLE ... MOVE ... ONLINE
ALTER TABLE ... MOVE PARTITION ... ONLINE
ALTER TABLE ... MOVE SUBPARTITION ... ONLINE
Moving a table changes the rowids of the rows in the table. If you move a table and
include the ONLINE keyword and the UPDATE INDEXES clause, then the indexes
remain usable during the move operation. If you include the UPDATE INDEXES clause
but not the ONLINE keyword, then the indexes are usable immediately after the move
operation. The UPDATE INDEXES clause can only change the storage properties for
the global indexes on the table or storage properties for the index partitions of any
global partitioned index on the table. If you do not include the UPDATE INDEXES
clause, then the changes to the rowids cause the indexes on the table to be marked
UNUSABLE, and DML accessing the table using these indexes receive an ORA-01502
error. In this case, the indexes on the table must be dropped or rebuilt.
A move operation causes any statistics for the table to become invalid, and new
statistics should be collected after moving the table.
Moving a Table to a New Segment or Tablespace 7-1
Moving a Table
If the table includes LOB column(s), then this statement can be used to move the table
along with LOB data and LOB index segments (associated with this table) that are
explicitly specified. If not specified, then the default is to not move the LOB data and
LOB index segments.
7.2 Moving a Table

Use the ALTER TABLE...MOVE statement to move a table to a new segment or
tablespace.
When you use the ONLINE keyword with this statement, data manipulation language
(DML) operations can continue to run uninterrupted on the table that is being moved.
If you do not include the ONLINE keyword, then concurrent DML operations are not
possible on the data in the table during the move operation.
To move a table:
1.
In SQL*Plus, connect as a user with the necessary privileges to alter the table.
See Oracle Database SQL Language Reference for information about the privileges
required to alter a table.
2.
Run the ALTER TABLE ... MOVE statement.
Example 7-1
Moving a Table to a New Tablespace in Online Mode
The following statement moves the hr.jobs table online to a new segment and
tablespace, specifying new storage parameters. The ONLINE keyword means that
DML operations can run on the table uninterrupted during the move operation. The
hr_tbs tablespace must exist.
ALTER TABLE hr.jobs MOVE ONLINE
STORAGE ( INITIAL 20K
NEXT 40K
MINEXTENTS 2
MAXEXTENTS 20
PCTINCREASE 0 )
TABLESPACE hr_tbs;
Example 7-2
Moving a Table and Updating the Tables Indexes
Assume the following statements created a table and its indexes:

CREATE TABLE dept_exp (
DEPTNO NUMBER (2) NOT NULL,
DNAME VARCHAR2 (14),
LOC VARCHAR2 (13))
TABLESPACE tbs_1;
CREATE INDEX i1_deptno ON dept_exp(deptno) TABLESPACE tbs_1;
CREATE INDEX i2_dname ON dept_exp(dname) TABLESPACE tbs_1;
The following statement moves the table to a new tablespace (tbs_2) and compresses
the table. It also moves index i2_dbname to tablespace tbs_2 and specifies that both
the i1_deptno index and the i2_dname index are usable after the move operation.
ALTER TABLE dept_exp MOVE
COMPRESS TABLESPACE tbs_2
UPDATE INDEXES
(i1_deptno TABLESPACE tbs_1,
i2_dname TABLESPACE tbs_2);
Moving a Table
Notice that this statement does not include the ONLINE keyword. However, the
ONLINE keyword is supported if DML operations must be able to run on the table
uninterrupted during the move operation, or if the indexes must be usable during the
move operation.
Before running these statements, the tbs_1 and tbs_2 tablespaces must exist.
Moving a Table to a New Segment or Tablespace 7-3
Moving a Table
8
Overview of Analytic Views
General considerations of analytic views are described in the following topics.
What Are Analytic Views? (page 8-1)
Analytic views provide a fast and efficient way to create analytic queries
of data stored in existing database tables and views.
Privileges for Analytic Views (page 8-3)
Describes the system and object privileges available for analytic views,
attribute dimensions, and hierarchies.
Application Programming Interfaces for Analytic Views (page 8-4)
The application programming interfaces for analytic views consist of
SQL DDL statements, PL/SQL procedures and functions, and data
dictionary views.
Compilation States of Analytic Views (page 8-7)
When you create or alter an attribute dimension, a hierarchy, or an
analytic view, Oracle Database ascertains the internal validity of the
objects metadata.
Classifications for Analytic Views (page 8-7)
Classifications provide descriptive metadata for attribute dimensions,
hierarchies, and analytic view objects, and for components of them such
as attribute dimension keys, attributes, levels, and measures.
Share Analytic Views with Application Containers (page 8-8)
You can share analytic views with application containers.
8.1 What Are Analytic Views?

Analytic views provide a fast and efficient way to create analytic queries of data stored
in existing database tables and views.
Analytic views organize data using a dimensional model. They allow you to easily
add aggregations and calculations to data sets and to present data in views that can be
queried with relatively simple SQL.
Like standard relational views, analytic views:
Are metadata objects (that is, they do not store data)
Can be queried using SQL
Can access data from other database objects such as tables, views, and external
tables
Can join multiple tables into a single view
Analytic views also:
Overview of Analytic Views 8-1
What Are Analytic Views?
Organize data using a rich business model that has dimensional and hierarchical
concepts
Include system-generated columns with hierarchical data
Automatically aggregate data
Include embedded measure calculations that are easily defined using syntax based
on the business model
Include presentation metadata
The definition of an analytic view includes navigation, join, aggregation, and
calculation rules, thus eliminating the need to include these rules in queries. Rather
than having simple tables and complex SELECT statements that express joins,
aggregations, and measure calculations, you can use simple SQL to query smart
analytic views. This approach has several benefits, including:
Simplified and faster application development; it is much easier to define
calculations within analytic views than it is to write or generate complex SELECT
statements
Calculation rules can be defined once in the database and then be re-used by any
number of applications; this provides end-users with greater freedom of choice in
their use of reporting tools without concern for inconsistent results
Analytic views are especially useful for the following users:
Data warehouse architect or designer
Business Intelligence application developer
Database analyst
For a data warehouse architect, analytic views are a tool for presenting data in a data
warehouse to application developers and business users. Tools provided by the BI
application generate a query, get the data, and present the result.
Components of Analytic Views
Analytic view component objects consist of the following:.
Attribute dimensions, which are metadata objects that reference tables or views
and organize columns into higher-level objects such as attributes and levels. Most
metadata related to dimensions and hierarchies is defined in the attribute
dimension object.
Hierarchies, which are a type of view that reference attribute dimension objects and
that organize data using hierarchical relationships. Data related to dimensions and
hierarchies is selected from hierarchies.
Analytic view objects, which are a type of view that presents fact data. Analytic
views reference both fact tables and hierarchies. You can select both hierarchy and
measure data from analytic views.
Data dictionary views, such as ALL_ANALYTIC_VIEW_COLUMNS, contain the
metadata and other information for the analytic view component objects.
The DBMS_HIERARCHY PL/SQL package contains functions for validating analytic
view and hierarchy objects and a procedure that creates a table that you can use for
logging messages generated by the validation functions.
Privileges for Analytic Views
Data Sources for Analytic Views

Attribute dimensions and analytic views typically use star schema dimension and fact
tables as data sources. For larger data sets, tables in the in-memory column store can
offer the best query performance with analytic views. Analytic views can also be used
with external tables and remote tables.
You specify the data source with the using_clause in the attribute dimension or
analytic view definition. You may specify an alias for the data source.
A database user who has the privileges required for access to the data sources can
create analytic view objects. The creator defines the business model, which specifies
how the data is queried, and implements the model by creating attribute dimensions,
hierarchies, and analytic views.
Materialized Views and Analytic Views
Creating a materialized view over queries of an analytic view or a hierarchy is not
supported. You may use a materialized view in a MEASURE_GROUP phrase of a
cache_clause of an analytic view.
Constraints for Analytic View Objects
For optimal query performance in queries of an analytic view, you should use the
same constraints that you would typically use for querying a star schema. An attribute
dimension or analytic view does not require that the source table or view have any
particular constraints defined or enabled. Also, defining an attribute dimension or
analytic view does not introduce any additional constraints on those tables or views.
The PL/SQL functions VALIDATE_HIERARCHY and VALIDATE_ANALYTIC_VIEW are
available for validating that the data in a table or view used by an attribute dimension
in a hierarchy or used by an analytic view conforms to the logical constraints inherent
in the metadata definitions.
Naming Conventions for Analytic Views
The naming conventions for attribute dimensions, hierarchies, and analytic views, and
components of them such as attributes, levels, and measures, follow standard database
identifier rules. Double-quotes may be used to enclose identifiers, including extended
characters and mixed-case; otherwise, the standard upper-case and limited character
rules apply.
8.2 Privileges for Analytic Views

Describes the system and object privileges available for analytic views, attribute
dimensions, and hierarchies.
System Privileges
The following system privileges allow the user to create, alter, or drop analytic view
component objects.
System Privilege
Description
CREATE ANALYTIC VIEW
Create an analytic view in the grantee's schema.
CREATE ANY ANALYTIC VIEW
Create analytic views in any schema.
CREATE ATTRIBUTE DIMENSION
Create an attribute dimension in the grantee's

schema.
CREATE ANY ATTRIBUTE DIMENSION
Create attribute dimensions in any schema.
Application Programming Interfaces for Analytic Views
System Privilege
Description
CREATE HIERARCHY
Create a hierarchy in the grantee's schema.
CREATE ANY HIERARCHY
Create hierarchies in any schema.
ALTER ANY ANALYTIC VIEW
Rename analytic views in any schema.
ALTER ANY ATTRIBUTE DIMENSION
Rename attribute dimensions in any schema.
ALTER ANY HIERARCHY
Rename hierarchies in any schema.
DROP ANY ANALYTIC VIEW
Drop analytic views in any schema.
DROP ANY ATTRIBUTE DIMENSION
Drop attribute dimensions in any schema.
DROP ANY HIERARCHY
Drop hierarchies in any schema.
SELECT ANY TABLE
Query or view any analytic view or hierarchy in

any schema.
Object Privileges
The following object privileges allow the user to query or rename analytic view
component objects.
Object Privilege
Operations Authorized
ALTER
Rename the analytic view, attribute

dimension, or hierarchy.
READ
Query the object with the SELECT statement.
SELECT
Query the object with the SELECT statement.
Example 8-1
Granting System Privileges
The following statements grant the CREATE system privilege to the user av_user.
GRANT
GRANT
GRANT
GRANT
CREATE
CREATE
CREATE
SELECT
Example 8-2
ATTRIBUTE DIMENSION TO av_user;

HIERARCHY TO av_user;
ANALYTIC VIEW TO av_user;
ANY TABLE TO av_user;
Granting Object Privileges
The following statements grant all object privileges to the user av_user2 and then
revoke the ALTER privilege.
GRANT ALL ON "AV_USER".SALES_AV TO "AV_USER2";
REVOKE ALTER ON "AV_USER".SALES_AV FROM "AV_USER2";
8.3 Application Programming Interfaces for Analytic Views

The application programming interfaces for analytic views consist of SQL DDL
statements, PL/SQL procedures and functions, and data dictionary views.
These interfaces are listed in the following topics:
SQL DDL Statements for the Creation and Management of Analytic Views
(page 8-5)
PL/SQL Package for Analytic Views (page 8-5)
Data Dictionary Views for Analytic Views (page 8-5)
SQL DDL Statements for the Creation and Management of Analytic Views
You create and manage analytic view objects with the following SQL DDL statements:
CREATE ANALYTIC VIEW
CREATE ATTRIBUTE DIMENSION
CREATE HIERARCHY
ALTER ANALYTIC VIEW
ALTER ATTRIBUTE DIMENSION
ALTER HIERARCHY
DROP ANALYTIC VIEW
DROP ATTRIBUTE DIMENSION
DROP HIERARCHY
PL/SQL Package for Analytic Views
You can validate the data for analytic view and hierarchy objects with the following
procedures in the DBMS_HIERARCHY package:
CREATE_VALIDATE_LOG_TABLE procedure
VALIDATE_ANALYTIC_VIEW function
VALIDATE_CHECK_SUCCESS function
VALIDATE_HIERARCHY function
For details about the DBMS_HIERARCHY package, see Oracle Database PL/SQL Packages
and Types Reference.
Data Dictionary Views for Analytic Views
The following data dictionary views contain information about analytic view objects.
Only the views with the prefix ALL are listed. Each view also has a corresponding DBA
and USER version.
Analytic View Views
ALL_ANALYTIC_VIEW_ATTR_CLASS
ALL_ANALYTIC_VIEW_BASE_MEAS
ALL_ANALYTIC_VIEW_CALC_MEAS
ALL_ANALYTIC_VIEW_CLASS
ALL_ANALYTIC_VIEW_COLUMNS
ALL_ANALYTIC_VIEW_DIM_CLASS
ALL_ANALYTIC_VIEW_DIMENSIONS
ALL_ANALYTIC_VIEW_HIER_CLASS
ALL_ANALYTIC_VIEW_HIERS
ALL_ANALYTIC_VIEW_KEYS
ALL_ANALYTIC_VIEW_LEVEL_CLASS
ALL_ANALYTIC_VIEW_LEVELS
ALL_ANALYTIC_VIEW_LVLGRPS
ALL_ANALYTIC_VIEW_MEAS_CLASS
ALL_ANALYTIC_VIEWS
Attribute Dimension Views
ALL_ATTRIBUTE_DIM_ATTR_CLASS
ALL_ATTRIBUTE_DIM_ATTRS
ALL_ATTRIBUTE_DIM_CLASS
ALL_ATTRIBUTE_DIM_JOIN_PATHS
ALL_ATTRIBUTE_DIM_KEYS
ALL_ATTRIBUTE_DIM_LEVEL_ATTRS
ALL_ATTRIBUTE_DIM_LEVELS
ALL_ATTRIBUTE_DIM_LVL_CLASS
ALL_ATTRIBUTE_DIM_ORDER_ATTRS
ALL_ATTRIBUTE_DIM_TABLES
ALL_ATTRIBUTE_DIMENSIONS
Hierarchy Views
ALL_HIER_CLASS
ALL_HIER_COLUMNS
ALL_HIER_HIER_ATTR_CLASS
ALL_HIER_HIER_ATTRIBUTES
ALL_HIER_JOIN_PATHS
ALL_HIER_LEVEL_ID_ATTRS
ALL_HIER_LEVELS
ALL_HIERARCHIES
Compilation States of Analytic Views
8.4 Compilation States of Analytic Views

When you create or alter an attribute dimension, a hierarchy, or an analytic view,
Oracle Database ascertains the internal validity of the objects metadata.
The SQL DDL CREATE and ALTER statements for analytic views have FORCE and
NOFORCE options, with NOFORCE as the default. The verification of metadata that
depends on another object is optional and is determined by the FORCE and NOFORCE
options.
If you specify NOFORCE and the compilation fails, then the CREATE or ALTER
operation fails and an error is raised. If you specify FORCE, the CREATE or ALTER
succeeds even if the compilation fails.
You can explicitly invoke a compilation by specifying the COMPILE keyword; a
compilation is implicitly invoked as needed during a query. A query returns an error
if an object is not compiled and cannot implicitly be compiled.
The compilation state is recorded in the COMPILE_STATE column in the
ALL_ATTRIBUTE_DIMENSIONS, ALL_HIERARCHIES, and ALL_ANALYTIC_VIEWS
data dictionary views (and the corresponding DBA and USER views). The state may be
one of the following:
Value
Description
VALID
The object has been compiled without error.
INVALID
Some change requires recompilation or the object has been compiled and
errors have occurred.
A SQL DDL operation on the analytic views object causes the state of dependent
objects to change to INVALID. For example, a change to an attribute dimension causes
any hierarchies that use that attribute dimension, and analytic views dimensioned by
the attribute dimension, to change state to INVALID. Also, DDL changes to the tables
or views used by attribute dimensions and analytic views cause the state for those
objects to change to INVALID.
The ALL_OBJECTS data dictionary view has a STATUS column that may be VALID or
INVALID. For attribute dimensions, hierarchies, and analytic views, the STATUS value
correlates to the COMPILE_STATE. When COMPILE_STATE is VALID, the STATUS
value is VALID. When COMPILE_STATE is INVALID, STATUS is INVALID.
8.5 Classifications for Analytic Views

Classifications provide descriptive metadata for attribute dimensions, hierarchies, and
analytic view objects, and for components of them such as attribute dimension keys,
attributes, levels, and measures.
Applications can use classifications to present information about hierarchies and
analytic views. Classifications are similar to comments on tables and columns, but a
comment is a single value. You can specify any number of classifications for the same
object. You can vary the values by language. A classification value is always a text
literal and can have maximum length of 4000 bytes.
Classifications play no role in SQL queries, but are available in the data dictionary
views for use by tools or applications. The CAPTION and DESCRIPTION classifications
have DDL shortcuts for all objects that support classifications.
Share Analytic Views with Application Containers
You may specify a language for a classification value. If you do not specify a language,
then the language value for the classification is NULL. The language value must either
be NULL or a valid NLS_LANGUAGE value.
The DDL shortcuts for CAPTION and DESCRIPTION apply only to the NULL language.
To specify a CAPTION and DESCRIPTION classification for a particular language, you
must use the full CLASSIFICATION syntax.
SQL tools can interpret a NULL language value as a default. For example, suppose a
tool is looking for the CAPTION for an attribute dimension. The tool might first look
for the CAPTION having a language that matches the current NLS_LANGUAGE. If it
finds one, it uses that CAPTION value. If not, it then looks for a CAPTION having a
NULL language value and uses that. The SQL logic is up to the user, tool, or
application.
To provide descriptive metadata that varies by language for a member of a hierarchy,
use the hierarchical attributes MEMBER_NAME, MEMBER_CAPTION, and
MEMBER_DESCRIPTION.
8.6 Share Analytic Views with Application Containers

You can share analytic views with application containers.
In the definition of analytic view objects, you can use the SHARING clause to share
attribute dimension, hierarchy, or analytic view metadata or objects with application
containers. The values for the clause are the following:
Value
Description
NONE
Do not share; this is the default value.
METADATA
Share metadata only.
OBJECT
Share the object, including data.
If you specify METADATA, then only the definition of the object is shared with
application containers.
If you specify OBJECT, then the attribute dimension, hierarchy, or analytic view object,
including the data sources of the object, is shared with the application container.
9
Advanced Index Compression
This chapter describes how to use some of the new features related to advanced index
compression.
Creating an Index Using Advanced Index Compression (page 9-1)
Advanced index compression works well on all supported indexes,
including those that are not good candidates for prefix compression.
Creating an index using advanced index compression can reduce the
size of all unique and non-unique indexes and improves the
compression ratio significantly, while still providing efficient access to
the indexes.
About Tablespaces with Default Compression Attributes (page 9-2)
When you create a tablespace, you can specify the default compression
of data for all tables and indexes created in the tablespace. The default
compression level also applies to the partitions that comprise the
tablespace. Compressing this data can reduce disk use.
Tablespaces with Default Compression Attributes (page 9-3)
When you create a tablespace, you can specify that all tables and
indexes, or their partitions, created in a tablespace are compressed by
default.
Creating Tablespaces with Default Compression Attributes (page 9-3)
When you create a tablespace, you can specify the type of table
compression using the DEFAULT keyword, followed by the table
compression clause including the compression type. You can also
specify the type of index compression using the DEFAULT keyword,
followed by index compression clause and the index compression type.
9.1 Creating an Index Using Advanced Index Compression

Advanced index compression works well on all supported indexes, including those
that are not good candidates for prefix compression. Creating an index using
advanced index compression can reduce the size of all unique and non-unique indexes
and improves the compression ratio significantly, while still providing efficient access
to the indexes.
For a partitioned index, you can specify the compression type on a partition by
partition basis. You can also specify advanced index compression on index partitions
even when the parent index is not compressed.
Advanced index compression works at the block level to provide the best compression
for each block.
You can enable advanced index compression using the COMPRESS ADVANCED clause
and can specify the following compression levels:
Advanced Index Compression 9-1
About Tablespaces with Default Compression Attributes
LOW: This level provides lower compression ratio at minimal CPU overhead. Before
enabling COMPRESS ADVANCED LOW, the database must be at 12.1.0 or higher
compatibility level.
HIGH: This level, the default, provides higher compression ratio at some CPU
overhead. Before enabling COMPRESS ADVANCED HIGH, the database must be at
12.2.0 or higher compatibility level.
When a CREATE INDEX DDL statement is executed, a block is filled with rows. At
high compression level, when the block is full, it is compressed with advanced
index compression if enough space is saved to insert the next row. When a block
becomes full, the block might be recompressed using advanced index compression
to avoid splitting the block if enough space is saved to insert the incoming key.
The COMPRESSION column in the ALL_INDEXES view shows whether an index is
compressed, and, if it is compressed, the type of compression enabled for the index.
The possible values for the COMPRESSION column are ADVANCED HIGH, ADVANCED
LOW, DISABLED, or ENABLED. The COMPRESSION column in the
ALL_IND_PARTITIONS and ALL_IND_SUBPARTITIONS views indicates whether
index compression is ENABLED or DISABLED for the partition or subpartition.
Note:
Advanced index compression is not supported for bitmap indexes or

index-organized tables.
When low level advanced index compression is enabled, advanced index
compression cannot be specified on a single column unique index. This
restriction does not apply when high level advanced index compression is
enabled.
Example 9-1
Creation
Enabling Low Level Advanced Index Compression During Index
For example, the following statement enables low level advanced index compression
during the creation of the hr.emp_mndp_ix index:
CREATE INDEX hr.emp_mndp_ix ON hr.employees(manager_id, department_id)
COMPRESS ADVANCED LOW;
Example 9-2
Rebuild
Enabling High Level Advanced Index Compression During Index
You can also specify the COMPRESS ADVANCED clause during an index rebuild. For
example, during rebuild, you can enable high level advanced index compression for
the hr.emp_manager_ix index as follows:
ALTER INDEX hr.emp_manager_ix REBUILD COMPRESS ADVANCED HIGH;
9.2 About Tablespaces with Default Compression Attributes

When you create a tablespace, you can specify the default compression of data for all
tables and indexes created in the tablespace. The default compression level also
applies to the partitions that comprise the tablespace. Compressing this data can
reduce disk use.
Tablespaces with Default Compression Attributes
9.3 Tablespaces with Default Compression Attributes

When you create a tablespace, you can specify that all tables and indexes, or their
partitions, created in a tablespace are compressed by default.
9.4 Creating Tablespaces with Default Compression Attributes

When you create a tablespace, you can specify the type of table compression using the
DEFAULT keyword, followed by the table compression clause including the
compression type. You can also specify the type of index compression using the
DEFAULT keyword, followed by index compression clause and the index compression
type.
The following statement indicates that all tables and partitions created in the
tablespace are to use advanced row compression, unless otherwise specified:
CREATE TABLESPACE ... DEFAULT ROW STORE COMPRESS ADVANCED ... ;
You can override the default tablespace compression specification when you create a
table or partition in that tablespace.
The following statement indicates that all indexes created in the tablespace are to use
high level advanced index compression, unless otherwise specified:
CREATE TABLESPACE ... DEFAULT INDEX COMPRESS ADVANCED HIGH ... ;
You can override the default tablespace compression specification when you create an
index in that tablespace.
Advanced Index Compression 9-3
Creating Tablespaces with Default Compression Attributes
10
Longer Identifier Names
Starting with Oracle Database 12c Release 2 (12.2), the maximum length of identifier
names for most types of database objects has been increased to 128 bytes.
This chapter describes how to use some of the new features related to longer identifier
names.
Database Object Naming Rules (page 10-1)
10.1 Database Object Naming Rules

Every database object has a name. In a SQL statement, you represent the name of an
object with a quoted identifier or a nonquoted identifier.
A quoted identifier begins and ends with double quotation marks ("). If you name a
schema object using a quoted identifier, then you must use the double quotation
marks whenever you refer to that object.
A nonquoted identifier is not surrounded by any punctuation.
You can use either quoted or nonquoted identifiers to name any database object.
However, database names, global database names, database link names, disk group
names, and pluggable database (PDB) names are always case insensitive and are
stored as uppercase. If you specify such names as quoted identifiers, then the
quotation marks are silently ignored.
Note:
Oracle does not recommend using quoted identifiers for database object
names. These quoted identifiers are accepted by SQL*Plus, but they may not
be valid when using other tools that manage database objects.
The following list of rules applies to both quoted and nonquoted identifiers unless
otherwise indicated:
1.
The maximum length of identifier names depends on the value of the

COMPATIBLE initialization parameter.
If COMPATIBLE is set to a value of 12.2 or higher, then names must be from
1 to 128 bytes long with these exceptions:
Names of databases are limited to 8 bytes.
Names of disk groups, pluggable databases (PDBs), rollback segments, and
tablespaces are limited to 30 bytes.
Longer Identifier Names 10-1
Database Object Naming Rules
If an identifier includes multiple parts separated by periods, then each

attribute can be up to 128 bytes long. Each period separator, as well as any
surrounding double quotation marks, counts as one byte. For example,
suppose you identify a column like this:
"schema"."table"."column"
The schema name can be 128 bytes, the table name can be 128 bytes, and the
column name can be 128 bytes. Each of the quotation marks and periods is a
single-byte character, so the total length of the identifier in this example can be
up to 392 bytes.
If COMPATIBLE is set to a value lower than 12.2, then names must be from 1
to 30 bytes long with these exceptions:
Names of databases are limited to 8 bytes.
Names of database links can be as long as 128 bytes.
If an identifier includes multiple parts separated by periods, then each
attribute can be up to 30 bytes long. Each period separator, as well as any
surrounding double quotation marks, counts as one byte. For example,
suppose you identify a column like this:
"schema"."table"."column"
The schema name can be 30 bytes, the table name can be 30 bytes, and the
column name can be 30 bytes. Each of the quotation marks and periods is a
single-byte character, so the total length of the identifier in this example can be
up to 98 bytes.
2.
Nonquoted identifiers cannot be Oracle SQL reserved words. Quoted identifiers

can be reserved words, although this is not recommended.
Depending on the Oracle product you plan to use to access a database object,
names might be further restricted by other product-specific reserved words.
Note:
The reserved word ROWID is an exception to this rule. You cannot use the
uppercase word ROWID, either quoted or nonquoted, as a column name.
However, you can use the uppercase word as a quoted identifier that is not a
column name, and you can use the word with one or more lowercase letters
(for example, "Rowid" or "rowid") as any quoted identifier, including a
column name.
3.
The Oracle SQL language contains other words that have special meanings. These
words include data types, schema names, function names, the dummy system
table DUAL, and keywords (the uppercase words in SQL statements, such as
DIMENSION, SEGMENT, ALLOCATE, DISABLE, and so forth). These words are not
reserved. However, Oracle uses them internally in specific ways. Therefore, if you
use these words as names for objects and object parts, then your SQL statements
may be more difficult to read and may lead to unpredictable results.
In particular, do not use words beginning with SYS_ or ORA_ as schema object
names, and do not use the names of SQL built-in functions for the names of
schema objects or user-defined functions.
4.
You should use characters from the ASCII repertoire in database names, global
database names, and database link names, because these characters provide
optimal compatibility across different platforms and operating systems. You must
use only characters from the ASCII repertoire in names of common users and
common roles in a multitenant container database (CDB).
5.
You can include multibyte characters in passwords.
6.
Nonquoted identifiers must begin with an alphabetic character from your

database character set. Quoted identifiers can begin with any character.
7.
Nonquoted identifiers can contain only alphanumeric characters from your

database character set and the underscore (_), dollar sign ($), and pound sign (#).
Database links can also contain periods (.) and "at" signs (@).
Quoted identifiers can contain any characters and punctuations marks as well as
spaces. However, neither quoted nor nonquoted identifiers can contain double
quotation marks or the null character (\0).
8.
Within a namespace, no two objects can have the same name.

The following schema objects share one namespace:
Packages
Private synonyms
Sequences
Stand-alone procedures
Stand-alone stored functions
Tables
User-defined operators
User-defined types
Views
Each of the following schema objects has its own namespace:
Clusters
Constraints
Database triggers
Dimensions
Indexes
Materialized views (When you create a materialized view, the database creates
an internal table of the same name. This table has the same namespace as the
other tables in the schema. Therefore, a schema cannot contain a table and a
materialized view of the same name.)
Private database links
Because tables and sequences are in the same namespace, a table and a sequence
in the same schema cannot have the same name. However, tables and indexes are
in different namespaces. Therefore, a table and an index in the same schema can
have the same name.
Each schema in the database has its own namespaces for the objects it contains.
This means, for example, that two tables in different schemas are in different
namespaces and can have the same name.
Each of the following nonschema objects also has its own namespace:
Editions
Parameter files (PFILEs) and server parameter files (SPFILEs)
Profiles
Public database links
Public synonyms
Tablespaces
User roles
Because the objects in these namespaces are not contained in schemas, these
namespaces span the entire database.
9.
Nonquoted identifiers are not case sensitive. Oracle interprets them as uppercase.
Quoted identifiers are case sensitive.
By enclosing names in double quotation marks, you can give the following names
to different objects in the same namespace:
"employees"
"Employees"
"EMPLOYEES"
Note that Oracle interprets the following names the same, so they cannot be used
for different objects in the same namespace:
employees
EMPLOYEES
"EMPLOYEES"
10. When Oracle stores or compares identifiers in uppercase, the uppercase form of
each character in the identifiers is determined by applying the uppercasing rules

of the database character set. Language-specific rules determined by the session
setting NLS_SORT are not considered. This behavior corresponds to applying the
SQL function UPPER to the identifier rather than the function NLS_UPPER.
The database character set uppercasing rules can yield results that are incorrect
when viewed as being in a certain natural language. For example, small letter
sharp s (""), used in German, does not have an uppercase form according to the
database character set uppercasing rules. It is not modified when an identifier is
converted into uppercase, while the expected uppercase form in German is the
sequence of two characters capital letter S ("SS"). Similarly, the uppercase form of
small letter i, according to the database character set uppercasing rules, is capital
letter I. However, the expected uppercase form in Turkish and Azerbaijani is
capital letter I with dot above.
The database character set uppercasing rules ensure that identifiers are
interpreted the same in any linguistic configuration of a session. If you want an
identifier to look correctly in a certain natural language, then you can quote it to
preserve the lowercase form or you can use the linguistically correct uppercase
form whenever you use that identifier.
11. Columns in the same table or view cannot have the same name. However,
columns in different tables or views can have the same name.
12. Procedures or functions contained in the same package can have the same name,
if their arguments are not of the same number and data types. Creating multiple
procedures or functions with the same name in the same package with different
arguments is called overloading the procedure or function.
Part III
Summary
Oracle Database 12.1 New Features (page 11-1)
11
This chapter contains overview descriptions of all of the features that are new to
Oracle Database 12.1.
Application Development (page 11-1)
11.1 Application Development

Oracle SQL and PL/SQL Improvements (page 11-1)
11.1.1 Oracle SQL and PL/SQL Improvements

JDBC Support for PL/SQL Data Types as Parameters (page 11-1)
Native Client API Support for PL/SQL Package Types and Boolean Types as
Parameters (page 11-1)
Precompilers Support for SQL Plan Management (page 11-1)
SQLJ Support for SQL Plan Management (page 11-2)
11.1.1.1 JDBC Support for PL/SQL Data Types as Parameters

The ability for Java and JDBC applications to bind PL/SQL package types and boolean
types as parameters is available in this release.
This feature improves ease-of-use, seamless mapping and exchange of PL/SQL types
with Java types, and increases Java developer productivity.
11.1.1.2 Native Client API Support for PL/SQL Package Types and Boolean Types as
Parameters
This feature allows database client APIs (for example, OCI and JDBC) to natively
describe and bind PL/SQL package types and boolean types. Java and C-based
applications can now easily bind and execute PL/SQL functions or procedures with
PL/SQL package types or boolean types as parameters.
This feature reduces the complexity of executing PL/SQL functions or procedures
from client-side applications.
11.1.1.3 Precompilers Support for SQL Plan Management

There are new command-line options for the generation of plan baseline SQL
statements providing control of the name and format of generated SQL files and log
files.
This support avoids performance regression of SQL statement execution and provides
easier upgrade of precompiler applications.
11.1.1.4 SQLJ Support for SQL Plan Management

The following are new features in this release for SQLJ support for SQL plan
management (SPM):
Command line and property file options for the generation of plan baseline SQL
statements.
Generation of a SQL file containing the statements for creating SPM plans.
Control in the naming of generated log files and Java files.
This new support helps make the upgrade of SQLJ applications easier and helps to
avoid performance regression of SQL statement execution.
A
DBMS_MVIEW_STATS
DBMS_MVIEW_STATS package provides an interface to manage the collection and
retention of statistics for materialized view refresh operations.
Using DBMS_MVIEW_STATS (page A-1)
Summary of DBMS_MVIEW_STATS Subprograms (page A-2)
See Also:
Oracle Database Data Warehousing Guide for information about managing and
using materialized view refresh statistics
A.1 Using DBMS_MVIEW_STATS

This section contains topics which relate to using the DBMS_MVIEW_STATS package.
DBMS_MVIEW_STATS Overview (page A-1)
You can use the procedures contained in the DBMS_MVIEW_STATS
package to manage the collection and retention of statistics for
materialized view refresh operations. This includes the level and
granularity at which these statistics are collected and the duration for
which they are retained in the database.
DBMS_MVIEW_STATS Security Model (page A-1)
Refer to the Usage Notes section in each subprogram for information
about the privileges required to use the subprogram.
A.1.1 DBMS_MVIEW_STATS Overview

You can use the procedures contained in the DBMS_MVIEW_STATS package to manage
the collection and retention of statistics for materialized view refresh operations. This
includes the level and granularity at which these statistics are collected and the
duration for which they are retained in the database.
You can also set database level system defaults for the parameters that control
statistics collection.
A.1.2 DBMS_MVIEW_STATS Security Model

Refer to the Usage Notes section in each subprogram for information about the
privileges required to use the subprogram.
DBMS_MVIEW_STATS A-1
Summary of DBMS_MVIEW_STATS Subprograms
A.2 Summary of DBMS_MVIEW_STATS Subprograms

The following topics contain detailed information about the DBMS_MVIEW_STATS
subprograms:
PURGE_REFRESH_STATS Procedure (page A-2)
This procedure purges refresh statistics that are older than the specified
retention period for the specified materialized views.
This procedure sets the collection level and retention period for
materialized view refresh statistics. You can set these properties either
for individual materialized views or for all materialized views in the
database.
This procedure sets system-wide defaults that manage the collection and
retention of materialized view refresh statistics. All newly-created
materialized views use these defaults until the parameters are reset
explicitly using the SET_MVREF_STATS_PARAMS procedure.
A.2.1 PURGE_REFRESH_STATS Procedure

This procedure purges refresh statistics that are older than the specified retention
period for the specified materialized views.
This procedure forces a purge of refresh statistics without altering the retention period
defined for the specified materialized views.
Syntax
DBMS_MVIEW_STATS.PURGE_REFRESH_STATISTICS (
mv_list
IN
VARACHAR2,
retention_period
IN
NUMBER);
Parameters
Table A-1
PURGE_REFRESH_STATS Procedure Parameters
Parameter
Description
mv_list
The fully-qualified name of an existing materialized view in the

form of schema_name.mv_name. Use a comma-separated list to
specify multiple materialized views.
Specify NULL to purge materialized view refresh statistics for all
materialized views in the database.
A-2 New Features Guide
Table A-1
(Cont.) PURGE_REFRESH_STATS Procedure Parameters
Parameter
Description
retention_period
The number of days for which refresh statistics must be preserved

in the data dictionary. Statistics for materialized view refresh
operations that are older than the retention period are purged from
the data dictionary.
The retention period specified in this procedure overrides the
retention period that may have been set previously either at the
database level or for specified materialized views.
Specify NULL to use the purging policy defined by the automatic
statistics purge. Specify 1 to purge all refresh statistics.
Usage Notes
To invoke this procedure, you need either the SYSDBA privilege or privileges on every
materialized view that is specified in mv_list.
A.2.2 SET_MVREF_STATS_PARAMS Procedure

This procedure sets the collection level and retention period for materialized view
refresh statistics. You can set these properties either for individual materialized views
or for all materialized views in the database.
Syntax
DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS (
mv_list
IN
VARACHAR2,
collection_level IN
VARCHAR2 DEFAULT NULL,
retention_period IN
NUMBER DEFAULT NULL);
Parameters
Table A-2
SET_MVREF_STATS_PARAMS Procedure Parameters
Parameter
Description
mv_list
The fully-qualified name of an existing materialized view in the

form of schema_name.mv_name. Use a comma-separated list to
specify multiple materialized views.
Specify NULL to set properties for all existing materialized views in
the database.
Table A-2
(Cont.) SET_MVREF_STATS_PARAMS Procedure Parameters
Parameter
Description
collection_level
Specifies the level of detail used when collecting refresh statistics

for the materialized views specified in mv_list.
Set one of the following values for collection_level:
NONE: No materialized view refresh statistics are collected.
TYPICAL: Only basic refresh statistics are collected and stored
for the materialized views specified in mv_list.
ADVANCED: Detailed refresh statistics are collected and
stored for materialized view specified in mv_list.
If this parameter is set to NULL, then the system default value for
collection_level (set using SET_SYSTEM_DEFAULT) is used.
retention_period
Specifies the retention period, in days, for the refresh statistics of

the materialized views specified in mv_list. Statistics that are
older than the retention period are automatically purged from the
data dictionary.
Valid values are between 1 and 1365000.
If this parameter is set to NULL, then the system default value for
retention_period (set using SET_SYSTEM_DEAFULT) is used.
Set retention_period to -1 to specify that refresh statistics for
the materialized views in mv_list must never be purged.
Usage Notes
To set the collection level or retention period of one or more materialized views, you
must have privileges on those materialized views. To set the collection level or
retention period for all materialized views in the database, you must have either the
SYSDBA privilege or privileges on every materialized view in the database.
To set the system-level default values for statistics collection level and retention
period, use the SET_SYSTEM_DEAFULT procedure.
Use the DBA_MVREF_STATS_PARAMS view to determine the currently-set retention
period and collection level for materialized view statistics collection.
To disable refresh statistics collection for all materialized views in the database, use
the following:
DBMS_MVIEW_STATS.SET_MVREF_STATS_PARAMS (NULL, NONE, NULL);
Note that the parameters set using SET_MVREF_STATS_PARAMS only affect
materialized views that exist in the database at the time the procedure is run. Any new
materialized views created after this procedure is run will use the system default
values for collection_level and retention_period.
A.2.3 SET_SYSTEM_DEFAULT Procedure

This procedure sets system-wide defaults that manage the collection and retention of
materialized view refresh statistics. All newly-created materialized views use these
defaults until the parameters are reset explicitly using the
SET_MVREF_STATS_PARAMS procedure.
Syntax
DBMS_MVIEW_STATS.SET_SYSTEM_DEFAULT (
parameter_name
IN VARCHAR2,
value
IN VARCHAR2 DEFAULT NULL);
Parameters
Table A-3
SET_SYSTEM_DEFAULT Procedure Parameters
Parameter
Description
parameter_name
The name of the materialized view refresh statistics parameter

whose system default value is being set.
The parameters that can be set are:
COLLECTION_LEVEL: Specifies the level of detail for collecting
materialized view refresh statistics.
RETENTION_PERIOD: Specifies the duration, in days, for
which refresh statistics are retained in the data dictionary
value
The value of the materialized view refresh statistics parameter.

The valid values for COLLECTION_LEVEL are:
NONE: No refresh statistics are collected for the refresh
operation.
TYPICAL: Only basic refresh statistics are collected for the
refresh operation. This is the default setting.
ADVANCED: Detailed refresh statistics are collected for the
refresh operation.
The valid values for RETENTION_PERIOD are:
-1
Numbers between 1 and 1365000
The default value for retention_period is 31.
If you specify NULL for any of the parameters, then the system
default setting for that parameter is used.
Usage Notes
You must have SYSDBA privilege to invoke this procedure.
Use the DBA_MVREF_STATS_SYS_DEFAULTS view to display the current default
settings for materialized view refresh statistics collection.
Index
A
about
refresh statistics, 3-13
accessing
real-time materialized views, 3-5
advanced index compression, 9-1
ALTER TABLE statement
MOVE clause, 7-1, 7-2
analytic views
APIs, 8-4
compilation states, 8-7
described, 8-1
privileges for, 8-3
sharing with application containers, 8-8
application containers, sharing analytic views with,
8-8
APPROX_COUNT_DISTINCT_AGG function, 2-10

APPROX_COUNT_DISTINCT_DETAIL function, 2-11
APPROX_MEDIAN function, 2-14
APPROX_PERCENTILE function, 2-17
APPROX_PERCENTILE_AGG function, 2-20
APPROX_PERCENTILE_DETAIL function, 2-20
approximate aggregations, 2-3
approximate query processing, 2-2
approximate values
percentile functions, 2-5
attribute dimensions
privileges for, 8-3
automatic list partitioning
creating tables using, 4-1
C
CAPTION classification, 8-7
CAST function, 5-3
character sets
multibyte characters, 10-3
classifications
analytic view, 8-7
collection-typed values
converting to data types, 5-3
compilation states
compilation states (continued)

of analytic views, 8-7
compression
indexes
advanced compression, 9-1
tablespaces, 9-3
creating
materialized views with approximate queries, 2-7
D
data error handling
using SQL, 5-1
data types
converting to collection-typed values, 5-3
converting to other data types, 5-3
databases
namespaces, 10-4
DBMS_MVIEW_STATS Overview, A-1
DBMS_MVIEW_STATS package, A-1
DBMS_MVIEW_STATS security model, A-1
DESCRIPTION classification, 8-7
displaying
DUAL dummy table, 10-2
F
filtering
maintenance operations on partitions, 4-4
floating-point numbers
converting to, 5-8, 5-9
functions
LISTAGG function, 6-1
naming rules, 10-5
H
hierarchies
privileges for, 8-3
Index-1
I
indexes
advanced index compression, 9-1
K
keywords
in object names, 10-2
L
list partitioning
list-partitioned tables
creating, 4-1
LISTAGG function, 6-1, 6-4
M
maintenance operations on partitions
filtering, 4-4
managing
refresh statistics, 3-13
materialized views
ON STATEMENT refresh, 3-2
multi-column list partitioning
MULTISET keyword
of CAST function, 5-3
N
namespaces
and object naming rules, 10-3
database, 10-4
for nonschema objects, 10-4
for schema objects, 10-3
non-partitioned tables
converting to partitioned tables, 4-7
nonschema objects
namespaces, 10-4
O
ON STATEMENT refresh
restrictions, 3-2
P
PARTITION BY LIST clause, 4-1
PARTITION clause
for list partitions, 4-1
partitioned tables
converting to from non-partitioned tables, 4-7
creating automatic list partitions, 4-1
Index-2
partitioned tables (continued)

creating list partitions, 4-1
creating multi-column list partitions, 4-2
filtering maintenance operations, 4-4
FOR EXCHANGE WITH, 4-5
marking indexes UNUSABLE, 4-6
read-only status, 4-3
splitting partitions, 4-6
percentile functions
approximate results, 2-5
procedures
naming rules, 10-5
PURGE_REFRESH_STATS procedure, A-2
Q
queries
running with approximate functions, 2-2
query rewrite
materialized view with approximate queries, 2-8
R
read-only status
tables, partitions, and subpartitions, 4-3
real-time materialized views
accessing, 3-5
creating, 3-5
displaying, 3-7
for direct query access, 3-10
guidelines, 3-5
query rewrite, 3-8
restrictions, 3-4
refresh statistics
about, 3-13, 3-15, 3-18
analyzing, 3-25
collecting, 3-15, 3-16
data dictionary views, 3-14
managing, 3-13
modifying collection level, 3-16
modifying retention period, 3-19
purging, 3-20
retaining, 3-18
retention period, 3-18
setting defaults, 3-16, 3-18
SQL statements, 3-24
understanding, 3-25
viewing basic, 3-22
viewing change data, 3-23
viewing detailed, 3-22
viewing settings, 3-19
refreshing
materialized views based on approximate queries,
2-7
reserved words, 10-2
S
schema objects
namespaces, 10-3
naming
rules, 10-1
SET_MVREF_STATS_PARAMS procedure, A-3
SET_SYSTEM_DEFAULT Procedure, A-4
SPLIT PARTITION clause, 4-6
splitting partitions and subpartitions, 4-6
SQL functions
APPROX_COUNT_DISTINCT_AGG, 2-10
APPROX_COUNT_DISTINCT_DETAIL, 2-11
APPROX_MEDIAN, 2-14
APPROX_PERCENTILE, 2-17
APPROX_PERCENTILE_AGG, 2-20
APPROX_PERCENTILE_DETAIL, 2-20
CAST, 5-3
LISTAGG, 6-4
TO_APPROX_COUNT_DISTINCT, 2-24
TO_APPROX_PERCENTILE, 2-25
TO_BINARY_DOUBLE, 5-8
TO_BINARY_FLOAT, 5-9
TO_DATE, 5-11
TO_DSINTERVAL, 5-13
TO_NUMBER, 5-15
TO_TIMESTAMP, 5-16
TO_TIMESTAMP_TZ, 5-17
TO_YMINTERVAL, 5-18
VALIDATE_CONVERSION, 5-20
SQL functions (continued)

Summary of DBMS_MVIEW_STATS Subprograms,
A-2
T
tables
moving, 7-1
tables for exchange
with partitioned tables, 4-5
tablespaces
compressed, 9-3
TO_APPROX_COUNT_DISTINCT function, 2-24
TO_APPROX_PERCENTILE function, 2-25
TO_BINARY_DOUBLE function, 5-8
TO_BINARY_FLOAT function, 5-9
TO_DATE function, 5-11
TO_DSINTERVAL function, 5-13
TO_NUMBER function, 5-15
TO_TIMESTAMP function, 5-16
TO_TIMESTAMP_TZ function, 5-17
TO_YMINTERVAL function, 5-18
U
Using DBMS_MVIEW_STATS, A-1
V
VALIDATE_CONVERSION function, 5-20
Index-3
Index-4

Oracle® Database New Features Guide 12c Release 2 (12.2)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle® Database New Features Guide 12c Release 2 (12.2)

Uploaded by

Copyright:

Available Formats

Oracle Database

New Features Guide

Oracle Database New Features Guide, 12c Release 2 (12.2)

Documentation Accessibility ...................................................................................................................

Oracle Database 12.2 New Features

Oracle Database 12.2 New Features Summary

Application Development ..............................................................................................................

Database Development Productivity Tools Enhancements...........................................

Oracle SQL and PL/SQL Improvements..........................................................................

Online Operations ................................................................................................................

Big Data and Data Warehousing ...................................................................................................

Dimensional In-Database Analysis....................................................................................

Compression and Archiving ..........................................................................................................

Index Compression Enhancements ...................................................................................

Core Database Improvements ............................................................................................

Pluggable Databases Ease of Adoption.............................................................................

Oracle Database 12.2 New Features Details

Approximate Query Processing

Approximate Values ...........................................................................................................................

About Approximate Aggregates ...................................................................................................

Using Percentile Functions that Return Approximate Results .................................................

Creating Materialized Views Based on Approximate Queries .................................................

Refreshing Materialized Views Based on Approximate Queries .............................................

Query Rewrite and Materialized Views Based on Approximate Queries ..............................

APPROX_MEDIAN ........................................................................................................... 2-14

APPROX_PERCENTILE_AGG ........................................................................................ 2-20

TO_APPROX_COUNT_DISTINCT ................................................................................. 2-24

TO_APPROX_PERCENTILE ............................................................................................ 2-25

About ON STATEMENT Refresh for Materialized Views ........................................................

Restrictions on Materialized Views with ON STATEMENT Refresh ......................................

Using Real-time Materialized Views ............................................................................................

Overview of Real-time Materialized Views .....................................................................

Creating Real-time Materialized Views........................................................................................

Converting an Existing Materialized View into a Real-time Materialized View ...................

Listing Real-time Materialized Views...........................................................................................

Enabling Query Rewrite to Use Real-time Materialized Views................................................

Using Real-time Materialized Views During Query Rewrite ...................................................

Monitoring Materialized View Refresh Operations ............................................................... 3-12

About Materialized View Refresh Statistics ................................................................. 3-13

Overview of Managing Materialized View Refresh Statistics ................................... 3-13

Collecting Materialized View Refresh Statistics .......................................................... 3-15

Retaining Materialized View Refresh Statistics ........................................................... 3-17

Viewing Materialized View Refresh Statistics Settings .............................................. 3-19

Purging Materialized View Refresh Statistics.............................................................. 3-20

Viewing Materialized View Refresh Statistics ............................................................. 3-21

About Creating List-Partitioned Tables........................................................................................

Creating an Automatic List-Partitioned Table .................................................................

Creating a Multi-column List-Partitioned Table..............................................................

Creating a Table with Read-Only Partitions or Subpartitions ..................................................

Filtering Maintenance Operations.................................................................................................

Creating a Table for Exchange With a Partitioned Table...........................................................

About Splitting Partitions and Subpartitions ..............................................................................

Converting a Non-Partitioned Table to a Partitioned Table .....................................................

Handling Data Errors

Handling Data Errors with SQL ....................................................................................................

SQL Language Reference Details for Handling Data Errors.....................................................

TO_DATE ........................................................................................................................... 5-11

TO_DSINTERVAL ............................................................................................................ 5-13

TO_NUMBER ..................................................................................................................... 5-15

TO_TIMESTAMP .............................................................................................................. 5-16

TO_TIMESTAMP_TZ ....................................................................................................... 5-17

TO_YMINTERVAL ........................................................................................................... 5-18

VALIDATE_CONVERSION .......................................................................................... 5-20

Advanced Aggregates for Analysis