Skip Headers
Oracle® XML DB Developer's Guide
11g Release 1 (11.1)

Part Number B28369-01
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

1 Introduction to Oracle XML DB

This chapter introduces the features and architecture of Oracle XML DB. It contains these topics:

Features of Oracle XML DB

Oracle XML DB is the name for a set of Oracle Database technologies related to high-performance XML storage and retrieval. It provides native XML support by encompassing both SQL and XML data models in an interoperable manner.

Oracle XML DB includes the following features:

Oracle XML DB can be used in conjunction with Oracle XML Developer's Kit (XDK) to build applications that run in the middle tier in either Oracle Application Server or Oracle Database.

Oracle XML DB Architecture

Figure 1-1 and Figure 1-2 show the software architecture of Oracle XML DB. The two main features are:

Figure 1-1 XMLType Storage and Oracle XML DB Repository

Description of Figure 1-1 follows
Description of "Figure 1-1 XMLType Storage and Oracle XML DB Repository"

Figure 1-2 XMLType Storage

Description of Figure 1-2 follows
Description of "Figure 1-2 XMLType Storage"

XMLType Storage

Figure 1-2 shows XMLType storage in Oracle XML DB.

When XML schemas are registered with Oracle XML DB, a set of default tables are created and used to store XML instance documents associated with the XML schema. These documents can be viewed and accessed in Oracle XML DB Repository.

Data in XMLType views can be stored in local or remote tables. Remote tables can be accessed through database links.

XMLType tables and views can be indexed using XMLIndex, B-tree, function-based, and Oracle Text indexes.

You can access data in Oracle XML DB Repository using any of the following:

  • HTTP(S), through the HTTP protocol handler

  • WebDAV and FTP, through the WebDAV and FTP protocol server

  • SQL, through Oracle Net Services, including Java Database Connectivity (JDBC)

Oracle XML DB supports XML data messaging using Oracle Streams Advanced Queuing (AQ) and Web Services.

APIs for XML

Table 1-1 lists the reference documentation for the PL/SQL, C, and C++ Application Programming Interfaces (APIs) that you can use to manipulate XML documents and data. The main reference for PL/SQL, C, and C++ APIs is Oracle Database PL/SQL Packages and Types Reference.

See Also:

Oracle Database XML Java API Reference for information about Java APIs for XML

Table 1-1 APIs Related to XML

API Documentation Description


Oracle Database PL/SQL Packages and Types Reference, Chapter "XMLType", Oracle Database XML C API Reference, and Oracle Database XML C++ API Reference

PL/SQL, C, and C++ APIs with XML operations on XMLType data – validation, transformation.

Database URI types

Oracle Database PL/SQL Packages and Types Reference, Chapter "Database URI TYPEs"

Functions used for various URI types.


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_METADATA"

PL/SQL API for retrieving metadata from the database dictionary as XML, or retrieving creation DDL and submitting the XML to re-create the associated object.


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_RESCONFIG"

PL/SQL API to operate on a resource configuration list, and to retrieve listener information for a resource.


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_XDB"

PL/SQL API for managing Oracle XML DB Repository resources, ACL-based security, and configuration sessions.


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_XDB_ADMIN"

PL/SQL API for managing miscellaneous features of Oracle XML DB, including the XMLIndex index on the Oracle XML DB Repository.


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_XDBRESOURCE"

PL/SQL API to operate on repository resource metadata.> and contents


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_XDBT"

PL/SQL API for creation of text indexes on repository resources.


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_XDB_VERSION"

PL/SQL API for version management of repository resources.


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_XDBZ"

Oracle XML DB Repository ACL-based security.


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_XEVENT"

PL/SQL API providing event-related types and supporting interface..


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_XMLDOM"

PL/SQL implementation of the DOM API for XMLType.


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_XMLGEN"

PL/SQL API for transformation of SQL query results into canonical XML format.


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_XMLINDEX

PL/SQL API for XMLIndex.


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_XMLPARSER"

PL/SQL implementation of the DOM Parser API for XMLType.


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_XMLQUERY"

PL/SQL API providing database-to-XMLType functionality. (Where possible, use DBMS_XMLGEN instead.)


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_XMLSAVE"

PL/SQL API providing XML- to-database type functionality.


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_XMLSCHEMA

PL/SQL API for managing XML schemas within Oracle Database – schema registration, deletion.


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_XMLSTORE"

PL/SQL API for storing XML data in relational tables.


Oracle Database PL/SQL Packages and Types Reference, Chapter "DBMS_XSLPROCESSOR"

PL/SQL implementation of an XSLT processor.

Catalog Views Related to XML

Table 1-2 lists the catalog views related to XML. Information about a given view can be obtained by using the SQL command DESCRIBE. Example:


Table 1-2 Catalog Views Related to XML

Schema Description

Registered XML schemas owned by the current user


Registered XML schemas usable by the current user


Registered XML schemas in Oracle XML DB


XMLType tables owned by the current user


XMLType tables usable by the current user


XMLType tables in Oracle XML DB


XMLType table columns owned by the current user


XMLType table columns usable by the current user


XMLType table columns in Oracle XML DB


XMLType views owned by the current user


XMLType views usable by the current user


XMLType views in Oracle XML DB


XMLType view columns owned by the current user


XMLType view columns usable by the current user


XMLType view columns in Oracle XML DB


Oracle XML DB views RESOURCE_VIEW and PATH_VIEW provide SQL access to data in Oracle XML DB Repository through protocols such as FTP and WebDAV. View PATH_VIEW has one row for each unique path in the repository; view RESOURCE_VIEW has one row for each resource in the repository.

The Oracle XML DB resource API for PL/SQL, DBMS_XDB, provides query and DML functions. It is based on RESOURCE_VIEW and PATH_VIEW.

See Also:

Overview of Oracle XML DB Repository

Oracle XML DB Repository is a component of Oracle Database that is optimized for handling XML data. The Oracle XML DB repository contains resources, which can be either folders (directories, containers) or files. Each resource has these properties:

  • It is identified by a path and name.

  • It has content (data), which can be XML data but need not be.

  • It has a set of system-defined metadata (properties), such as Owner and CreationDate, in addition to its content. Oracle XML DB uses this information to manage the resource.

  • It might also have user-defined metadata: information that is not part of the content, but is associated with it.

  • It has an associated access control list that determines who can access the resource, and for what operations.

Although Oracle XML DB Repository treats XML content specially, you can use Oracle XML DB Repository to store other kinds of data, besides XML; you can use the repository to access any data that is stored in Oracle Database.

See Also:

Accessing and Manipulating XML in the Oracle XML DB Repository

You can access data in Oracle XML DB Repository in the following ways (see Figure 1-1):

  • Using SQL, through views RESOURCE_VIEW and PATH_VIEW

  • Using PL/SQL, through the DBML_XDB API

  • Using Java, through the Oracle XML DB resource API for Java

XML Services

Besides supporting APIs that access and manipulate data, Oracle XML DB Repository provides APIs for the following services:

  • Versioning – Oracle XML DB uses the DBMS_XDB_VERSION PL/SQL package for versioning resources in Oracle XML DB Repository. Subsequent updates to a resource create a new version (the data corresponding to previous versions is retained). Versioning support is based on the IETF WebDAV standard.

  • ACL Security – Oracle XML DB resource security is based on access control lists (ACLs). Each resource in Oracle XML DB has an associated ACL that lists its privileges. Whenever resources are accessed or manipulated, the ACLs determine if the operation is legal. An ACL is an XML document that contains a set of access control entries (ACEs). Each ACE grants or revokes a set of permissions to a particular user or group (database role). This access control mechanism is based on the WebDAV specification.

  • Foldering – Oracle XML DB Repository manages a persistent hierarchy of folder (directory) resources that contain other resources (files or folders). Oracle XML DB modules, such as protocol servers, the schema manager, and the Oracle XML DB RESOURCE_VIEW API, use foldering to map path names to resources.

Oracle XML DB Repository Architecture

Figure 1-3 describes the Oracle XML DB Repository architecture. You can access the repository in SQL, for example, using the RESOURCE_VIEW API. In addition to the resource information, the RESOURCE_VIEW also contains a Path column, which holds the paths to each resource.

Figure 1-3 Oracle XML DB Repository Architecture

Description of Figure 1-3 follows
Description of "Figure 1-3 Oracle XML DB Repository Architecture"

How Does Oracle XML DB Repository Work?

The relational model table-row-column metaphor, is accepted as an effective mechanism for managing structured data. The model is not as effective for managing semi-structured and unstructured data, such as document- or content-oriented XML. For example, a book is not easily represented as a set of rows in a table. It is more natural to represent a book as a hierarchy, book:chapter:section:paragraph, and to represent the hierarchy as a set of folders and subfolders.

  • A hierarchical metaphor manages document-centric XML content. Relational databases are traditionally poor at managing hierarchical structures and traversing a path or URL. Oracle XML DB provides a hierarchically organized repository that can be queried and through which document-centric XML content can be managed.

  • A hierarchical repository index speeds up folder and path traversals. Oracle XML DB includes a patented hierarchical index that speeds up folder and path traversals in Oracle XML DB Repository. The hierarchical repository index is transparent to end users, and lets Oracle XML DB perform folder and path traversals at speeds comparable to or faster than conventional file systems.

  • You can access XML documents in Oracle XML DB Repository using standard connect-access protocols such as FTP, HTTP(S), and WebDAV, in addition to languages SQL, PL/SQL, Java, and C. The repository provides content authors and editors direct access to XML content stored in Oracle Database.

  • A resource in this context is a file or folder, identified by a URL. WebDAV is an IETF standard that defines a set of extensions to the HTTP protocol. It lets an HTTP server act as a file server for a DAV-enabled client. For example, a WebDAV-enabled editor can interact with an HTTP/WebDAV server as if it were a file system. The WebDAV standard uses the term resource to describe a file or a folder. Each resource managed by a WebDAV server is identified by a URL. Oracle XML DB adds native support to Oracle Database for these protocols. The protocols were designed for document-centric operations. By providing support for these protocols, Oracle XML DB lets Windows Explorer, Microsoft Office, and products from vendors such as Altova, Macromedia, and Adobe work directly with XML content stored in Oracle XML DB Repository. Figure 1-4 shows the root-level directory of the repository as seen from Microsoft Web Folder.

Figure 1-4 Microsoft Web Folder View of Oracle XML DB Repository

Description of Figure 1-4 follows
Description of "Figure 1-4 Microsoft Web Folder View of Oracle XML DB Repository"

Hence, WebDAV clients such as Microsoft Windows Explorer can connect directly to Oracle XML DB Repository. No additional Oracle Database or Microsoft-specific software or other complex middleware is needed. End users can work directly with Oracle XML DB Repository using familiar tools and interfaces.

Oracle XML DB Protocol Architecture

One key feature of the Oracle XML DB architecture is that HTTP(S), WebDAV, and FTP protocols are supported using the same architecture used to support Oracle Data Provider for .NET (ODP.NET) in a shared server configuration. The Listener listens for HTTP(S) and FTP requests in the same way that it listens for ODP.NET service requests. When the Listener receives an HTTP(S) or FTP request, it hands it off to an Oracle Database shared server process which services it and sends the appropriate response back to the client.You can use the TNS Listener command, lsnrctl status, to verify that HTTP(S) and FTP support has been enabled – see Example 1-1.

Example 1-1 Listener Status with FTP and HTTP(S) Protocol Support Enabled

LSNRCTL for 32-bit Windows: Version - Production on 20-AUG-2007 16:02:34
Copyright (c) 1991, 2007, Oracle.  All rights reserved.
Alias                          LISTENER
Version                        TNSLSNR for 32-bit Windows: Version - Beta
Start Date                     20-JUN-2007 15:35:40
Uptime                         0 days 16 hr. 47 min. 42 sec
Trace Level                    off
Security                       ON: Local OS Authentication
SNMP                           OFF
Listener Parameter File        C:\oracle\product\11.1.0\db_1\network\admin\listener.ora
Listener Log File              c:\oracle\diag\tnslsnr\quine-pc\listener\alert\log.xml
Listening Endpoints Summary... 
             (PORT=21))(Presentation=FTP)(Session=RAW)) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(
Services Summary...
Service "" has 1 instance(s).
  Instance "orcl", status READY, has 1 handler(s) for this service...
Service "" has 1 instance(s).
  Instance "orcl", status READY, has 1 handler(s) for this service...
Service "" has 1 instance(s).
  Instance "orcl", status READY, has 1 handler(s) for this service...
The command completed successfully

Programmatic Access to Oracle XML DB (Java, PL/SQL, and C)

All Oracle XML DB functionality is accessible from C, PL/SQL, and Java. These are the most popular ways to build Web-based applications:

  • Using servlets and Java Server Pages (JSP). A typical API accesses data using Java Database Connectivity (JDBC).

  • Using Extensible Stylesheet Language (XSL) plus XML Server Pages (XSP). A typical API accesses data in the form of XML documents that are processed using a Document Object Model (DOM) API implementation.

Oracle XML DB supports both of these styles of application development. It provides Java, PL/SQL, and C implementations of the DOM API.Applications that use JDBC, such as those based on servlets, need prior knowledge of the data structure they are processing. Oracle JDBC drivers allow you to access and update XMLType tables and columns, and call PL/SQL procedures that access Oracle XML DB Repository.Applications that use DOM, such as those based on XSLT transformations, typically require less knowledge of the data structure. DOM-based applications use string names to identify pieces of content, and must dynamically walk through the DOM tree to find the required information. For this, Oracle XML DB supports the use of the DOM API to access and update XMLType columns and tables. Programming to a DOM API is more flexible than programming through JDBC, but it may require more resources at run time.

Oracle XML DB Features

Any database used for managing XML must be able to persist XML documents. Oracle XML DB is capable of much more than this. It provides standard database features such as transaction control, data integrity, replication, reliability, availability, security, and scalability., while also allowing for efficient indexing, querying, updating, and searching of XML documents in an XML-centric manner.

The hierarchical nature of XML presents the traditional relational database with a number of challenges:

Oracle XML DB addresses these challenges by introducing new SQL functions and methods that allow the use of XML-centric metaphors, such as XQuery and XPath expressions for querying and updating XML Documents. These are the major features of Oracle XML DB:

XMLType Data Type

XMLType is a native data type for XML data. It provides methods that allow operations such as XML schema validation and XSL transformation on XML content. You can use XMLType as you would any other data type. For example, you can use XMLType when you do any of the following:

  • Creating a column in a relational table

  • Declaring PL/SQL variables

  • Defining and calling PL/SQL procedures and functions

XMLType is an object type, so you can also create a table of XMLType instances. By default, an XMLType table or column can contain any well-formed XML document.

XMLType Tables and Columns Can Conform to an XML Schema

XMLType tables or columns can be constrained to conform to an XML schema. This has several advantages:

  • The database ensures that only XML documents that validate against the XML schema are stored in the column or table.

  • Since the contents of the table or column conform to a known XML structure, Oracle XML DB can use the information contained in the XML schema to provide optimized query and update processing of the XML.

  • You have the option of storing the XML document content using structured storage. This decomposes the document and stores it as a set of object-relational objects. The object-relational model used to store the document is derived from the XML schema.


Data type XMLType provides the following:

  • Constructors, which you can use to create an XMLType instance from a VARCHAR, CLOB, BLOB, or BFILE value.

  • XML-specific methods that operate on XMLType instances. These include the following:

    • extract()– Extract a subset of nodes contained in the XMLType instance.

    • existsNode() – Check whether or not a particular node exists in the XMLType instance.

    • schemaValidate() – Validate the content of the XMLType instance against an XML schema.

    • transform() – Perform an XSL transformation on the content of an XMLType instance.

XML Schema Support

Support for the Worldwide Web Consortium (W3C) XML Schema Recommendation is a key feature in Oracle XML DB. XML Schema specifies the structure, content, and certain semantics of a set of XML documents. It is described in detail at

XML Schema Unifies Document Modeling and Data Modeling

In Oracle XML DB, you can use XML Schema to automatically create database tables and data types for storing XML data. You can thus use a standard data model for all of your data, whether the data is structured, unstructured, or semi-structured.

Create XMLType Tables and Columns, Ensure DOM Fidelity

You can create XML schema-based XMLType tables and columns and optionally specify that they conform to pre-registered XML schemas, maintaining DOM fidelity.

Use XMLType Views to Wrap Relational Data

You can also choose to wrap existing relational and object-relational data into XML format using XMLType views. You can store an XMLType object as an XML object that is based on an XML schema or not based on an XML schema:

  • XML schema-based objects. These are stored in Oracle XML DB tables, columns, or views using binary XML storage, CLOB storage, or object-relational storage.

  • Non-schema-based objects. These are stored in Oracle XML DB as LOBs only.

You can map from incoming XML documents to XMLType storage. The mapping is specified in an XML schema, which you register with Oracle XML DB. After it is registered, the XML schema can be referenced using its URL.

W3C Schema for Schemas

The W3C Schema Working Group publishes an XML schema, often referred to as the "schema for schemas". This XML schema provides the definition, or vocabulary, of the XML Schema language. An XML schema definition (XSD) is an XML document, that is compliant with the vocabulary defined by the schema for schemas. An XML schema uses vocabulary defined by W3C XML Schema Working Group to create a collection of type definitions and element declarations that declare a shared vocabulary for describing the contents and structure of a new class of XML documents.

XML Schema Base Set of Data Types Can be Extended

The XML Schema language provides strong typing of elements and attributes. It defines numerous scalar data types. This base set of data types can be extended to define more complex types, using object-oriented techniques such as inheritance and extension. The XML Schema vocabulary also includes constructs that you can use to define complex types, substitution groups, repeating sets, nesting, ordering, and so on. Oracle XML DB supports all of the constructs defined by the XML Schema Recommendation, except for redefines.

XML schemas are commonly used as a mechanism for checking (validating) whether XML instance documents conform with their specifications. Oracle XML DB includes XMLType methods and SQL functions that you can use to validate XML documents against an XML schema.


This manual uses the term XML schema (lower-case "s") to reference any XML schema that conforms to the W3C XML Schema (upper-case "S") Recommendation. Since an XML schema is used to define a class of XML documents, the term instance document is often used to describe an XML document that conforms to a particular XML schema.

See Also:

Chapter 6, "XML Schema Storage and Query: Basic" for more information about using XML schemas with Oracle XML DB

XMLType Storage Models

XMLType is an abstract data type that provides different storage models to best fit your data and your use of it. As an abstract data type, your applications and database queries gain in flexibility: the same interface is available for all XMLType operations. Because different storage (persistence) models are available, you can tailor performance and functionality to best fit the kind of XML data you have and the pattern of its use. One key decision to make when using Oracle XML DB for persisting XML data as XMLType is thus which storage model to use for which XML data.

You can change XMLType storage from one model to another, using database import/export (see Chapter 36, "Exporting and Importing XMLType Tables"); your application code does not need to change. You can change XML storage options when tuning your application.

XMLType tables and columns can be stored in these ways:

  • Structured storage – XMLType data is stored as a set of objects. This is also referred to as object-relational storage and object-based persistence.

  • Unstructured storage – XMLType data is stored in Character Large Object (CLOB) instances. This is also referred to as CLOB storage and text-based persistence.

  • Binary XML storage – XMLType data is stored in a post-parse, binary format specifically designed for XML data. Binary XML is compact, post-parse, XML schema-aware XML. This is also referred to as post-parse persistence.

Unstructured and binary XML storage each provide two LOB storage options, SecureFile and BasicFile.

See Also:

You can mix storage models, using one model for one part of an XML document and a different model for another part. The mixture of structured and unstructured storage is sometimes called hybrid storage. What is true about structured storage is true about the structured part of hybrid storage. What is true about unstructured storage is true about the unstructured part of hybrid storage.

XMLType has multiple storage models, and some models can be configured in more than one way. Each model has its advantages, depending on the context. Each model has one or more types of index that are appropriate for it.

The first thing to consider, when choosing an XMLType storage model, is the nature of your XML data and the ways you use it. A spectrum exists, with data-centric use of highly structured data at one end, and document-centric use of highly unstructured data at the other. The first question to ask yourself is this: Is your use case primarily data-centric or document-centric?

  • Data-centric – Your data is, in general, highly structured, with relatively static and predictable structure, and your applications take advantage of this structure. Your data conforms to an XML schema.

  • Document-centric – Two cases:

    • If your data is relatively structured, your applications do not take advantage of that structure. That is, you treat the data as if it were without structure.

    • Your data is generally without structure or of variable structure. Document structure can vary over time (evolution). Content is mixed (semi-structured): many elements contain both text nodes and child elements. Many XML elements can be absent or can appear in different orders. Documents might or might not conform to an XML schema.


Please be aware of the context, so as not to confuse discussion of storage options with discussion of the structure of the XML content to be stored. In this book, "structured" and "unstructured" generally refer to XMLType storage options; they refer less often to the nature of your data. "Hybrid" refers to object-relational storage with some embedded CLOB storage. "Semi-structured" refers to XML content, regardless of storage. Unstructured storage is CLOB-based storage, and structured storage is object-relational storage.

Once you've located the data-centric or document-centric half of the spectrum that is appropriate for your use case and data, consider whether your case is at an end of the spectrum or closer to the middle. That is, just how data-centric or document-centric is your case?

  • Employ object-relational (structured) storage for purely data-centric uses. A typical example of this use case would be an employee record (fields employee number, name, address, and so on). Use B-tree indexing with object-relational storage.

  • Employ hybrid storage if your data is composed primarily of invariable XML structures, but it does contain some variable data; that is, it contains a predictably few mixed-content elements. A typical example of this use case would be an employee record that includes a free-form resume. Index the structured and unstructured parts of your data separately, using appropriate indexes for each part.

  • Employ binary XML storage or CLOB-based (unstructured) storage for all document-centric use cases. In terms of indexing, we can distinguish two use cases:

    • If your data contains some predictable, fixed structures that you query frequently, then you can employ function-based indexes on those parts. A typical example of this use case would be a free-form specification, with author, date, and title fields.

    • Otherwise, for general indexing of document-centric XML data, use XMLIndex indexing. A typical example of this use case would be an XML Web document or a book chapter.

    In all document-centric cases, you can additionally use Oracle Text indexing for full-text queries.

These considerations are summarized in Figure 1-5. The figure shows the spectrum of use cases, from most data-centric, at the left, to most document-centric, at the right. The table in the figure classifies use cases and shows the corresponding storage models and indexing methods.

Figure 1-5 XML Use Cases and XMLType Storage Models

Description of Figure 1-5 follows
Description of "Figure 1-5 XML Use Cases and XMLType Storage Models"

See Chapter 5, "Indexing XMLType Data" for more information about indexing XML data. In particular, note that some types of indexing are complementary or orthogonal, so you can use them together.

The following list and Table 1-3 outline some of the advantages of each storage model.

  • Structured (object-relational) storage advantages over unstructured storage include optimized memory management, reduced storage requirements, B-tree indexing, and in-place updates. These advantages are at a cost of increased processing overhead during ingestion and retrieval of XML data, and reduced flexibility in the structure of the XML that can be managed by a given XMLType table or column. Structural flexibility is reduced, because data and metadata (such as column names) are separated in object-relational storage; instance structures cannot vary easily. Structured storage is particularly appropriate for highly structured data whose structure does not vary, if this maps to a manageable number of database tables and joins.

  • Unstructured (CLOB) storage enables higher throughput than structured storage when inserting and retrieving entire XML documents. No data conversion is needed, so the same format can be used outside the database. Unstructured storage also provides greater flexibility than structured storage in the structure of the XML that can be stored. Unstructured storage is particularly appropriate for document-centric use cases. These advantages can come at the expense of certain aspects of intelligent processing: in the absence of indexing, there is little that the database can do to optimize queries or updates on XML data that is stored in a CLOB instance. In particular, the cost of XML parsing (often implicit) can significantly impact query performance. Indexing with XMLIndex can improve the performance of queries against unstructured storage.

  • Binary XML storage provides more efficient database storage, updating, indexing, and fragment extraction than unstructured storage. It can provide better query performance than unstructured storage — it does not suffer from the XML parsing bottleneck (it is a post-parse persistence model). Like structured storage, binary XML storage is aware of XML Schema data types and can take advantage of native database data types. Like unstructured storage, no data conversion is needed during database insertion or retrieval. Like structured storage, binary XML storage allows for piecewise updates. Because binary XML data can also be used outside the database, it can serve as an efficient XML exchange medium, and you can off load work from the database to increase overall performance in many cases. Like unstructured storage, binary XML data is kept in document order. Like structured storage, data and metadata can, using binary storage, be separated at the database level, for efficiency. Like unstructured storage, however, binary XML storage allows for intermixed data and metadata, which lets instance structures vary. Binary XML storage allows for very complex and variable data, which in the structured-storage model could necessitate using many database tables. Unlike the other XMLType storage models, you can use binary storage for XML schema-based data even if the XML schema is not known beforehand, and you can store multiple XML schemas in the same table and query across common elements.

    Binary XML storage is the closest thing to a universal storage model for XML data — you can use it effectively for a very wide range of use cases, from document-centric to data-centric.

Table 1-3 XMLType Storage Models: Relative Advantages

Quality Structured (Object-Relational) Storage Unstructured (CLOB) Storage Binary XML Storage


XML decomposition can result in reduced throughput when ingesting retrieving the entire content of an XML document.

+ High throughput when ingesting and retrieving the entire content of an XML document.

++ High throughput. Fast DOM loading.

Space efficiency (disk)

++ Extremely space-efficient.

Consumes the most disk space, due to insignificant whitespace and repeated tags.

+ Space-efficient.

Data flexibility

Limited flexibility. Only documents that conform to the XML schema can be stored in the XMLType table or column.

+ Flexibility in the structure of the XML documents that can be stored in an XMLType column or table.

+ Flexibility in the structure of the XML documents that can be stored in an XMLType column or table.

XML schema flexibility

Relatively inflexible. Data and metadata are stored separately. Cannot use multiple XML schemas for the same XMLType table.

+ Flexible. Data and metadata are stored together. Cannot use multiple XML schemas for the same XMLType table.

++ Flexible. Can store data and metadata together or separately. Can use multiple XML schemas for the same XMLType table.

XML fidelity

DOM fidelity: A DOM created from an XML document that has been stored in the database will be identical to a DOM created from the original document. However, insignificant whitespace may be discarded.

+ Document fidelity: Maintains the original XML data, byte for byte. In particular, all original whitespace is preserved.

DOM fidelity (see structured storage description).

Update operations (DML)

++ In-place, piecewise update.

When any part of the document is updated, the entire document must be written back to disk.

+ In-place, piecewise update for SecureFile LOB storage.

XPath-based queries

++ XPath operations can often be evaluated using XPath rewrite, leading to significantly improved performance, particularly with large collections of documents.

XPath operations are evaluated by constructing a DOM from the CLOB data and using functional evaluation. Expensive when performing operations on large documents or large collections of documents.

XMLIndex indexing can improve performance of XPath-based queries.

+ Streaming XPath evaluation avoids DOM construction and allows evaluation of multiple XPath expressions in a single pass. Navigational XPath evaluation is significantly faster than with unstructured storage.

XMLIndex indexing can improve performance of XPath-based queries.

SQL constraint support

+ SQL constraints are supported.

SQL constraints are not available.

+ SQL constraints are supported.

Support for SQL scalar data types

+ Yes


+ Yes

Indexing support

B-tree, Oracle Text, and function-based indexes.

XMLIndex, function-based, and Oracle Text indexes.

XMLIndex, function-based, and Oracle Text indexes.

Optimized memory management

+ XML operations can be optimized to reduce memory requirements.

XML operations on the document require creating a DOM from the document.

+ XML operations can be optimized to reduce memory requirements.

Validation upon insert

XML data is partially validated when it is inserted.

XML schema-based data is partially validated when it is inserted.

+ XML schema-based data is fully validated when it is inserted.


When you insert XML schema-based data into binary XMLType columns or tables, the data is fully validated against the XML schema. Insertion fails if the data is invalid.

When XMLType is stored object-relationally, the XMLType instances contain hidden columns that store information about the XML data that does not fit into the SQL object model.

XML/SQL Duality

A key objective of Oracle XML DB is to provide XML/SQL duality. XML programmers can leverage the power of the relational model when working with XML content and SQL programmers can leverage the flexibility of XML when working with relational content. This lets you use the most appropriate tools for a particular business problem.

XML/SQL duality means that the same data can be exposed as rows in a table and manipulated using SQL or exposed as nodes in an XML document and manipulated using techniques such as DOM and XSL transformation. Access and processing techniques are independent of the underlying storage format.

These features provide simple solutions to common business problems. For example:

  • You can use Oracle XML DB SQL functions to generate XML data directly from a SQL query. You can then transform the XML data into other formats, such as HTML, using the database-resident XSLT processor.

  • You can access XML content without converting between different data formats, using SQL queries, on-line analytical processing (OLAP), and business-intelligence/data warehousing operations.

  • You can perform text, spatial data, and multimedia operations on XML content.

SQL/XML INCITS Standard SQL Functions

Oracle XML DB provides the SQL functions defined in the SQL/XML standard. This standard is defined by specifications prepared by the International Committee for Information Technology Standards (INCITS) Technical Committee H2. INCITS is the main standards body for developing standards for the syntax and semantics of database languages, including SQL.

The SQL/XML standard is evolving, so the syntax and semantics of its functions are subject to change in the future. The Oracle XML DB implementation of SQL/XML functions will evolve accordingly.

SQL/XML functions fall into two categories:

  • Functions that you can use to query and access XML content as part of normal SQL operations.

  • Functions that you can use to generate XML data from the result of a SQL query.

With SQL/XML functions you can address XML content in any part of a SQL statement. These functions use XQuery or XPath expressions to traverse the XML structure and identify the nodes on which to operate. The ability to embed XQuery and XPath expressions in SQL statements greatly simplifies XML access.

See Also:

Rewriting of XQuery and XPath Expressions

SQL/XML functions and their corresponding XMLType methods use XQuery or XPath expressions to search collections of XML documents and to access a subset of the nodes contained within an XML document. In many cases, Oracle XML DB is able to rewrite such expressions to code that executes directly against the underlying database objects.

See Also:

"Generating XML Using SQL Functions" for information about SQL/XML functions

How XPath Expressions Are Evaluated by Oracle XML DB

Oracle XML DB provides the following ways of evaluating XPath expressions that operate on XMLType columns and tables, depending on the XML storage method used:

  • Structured storage – Oracle XML DB attempts to translate the XPath expression in a SQL/XML function into an equivalent SQL query. The SQL query references the object-relational data structures that underpin a schema-based XMLType. This process is referred to as XPath rewrite. It can occur when performing queries and UPDATE operations. In addition, function-based indexes, and B-tree indexes on the underlying object-relational tables, can be used to evaluate XPath expressions for structured storage.

  • Unstructured storage – Function-based indexes can be used to evaluate XPath expressions for unstructured storage. In addition:

    • In the absence of an XMLIndex index, Oracle XML DB evaluates the XPath expression using functional evaluation. Functional evaluation builds a DOM tree for each XML document, and then resolves the XPath programmatically using the methods provided by the DOM API. If the operation involves updating the DOM tree, the entire XML document must be written back to disk when the operation is completed.

    • If an XMLIndex can be used, then it is used instead of functional evaluation.

  • Binary XML storage – Oracle XML DB can evaluate XPath expressions in different ways: using a function-based index, using XMLIndex, and using single-pass streaming. Single-pass streaming means evaluating a set of XPath expressions in a single scan of binary XML data. During query compilation, the cost-based optimizer picks the fastest combination of the methods.

Rewriting SQL Code That Contains XQuery and XPath Expressions

For XML data that is stored object-relationally, Oracle XML DB can rewrite SQL statements that contain XQuery and XPath expressions to purely relational SQL statements, which are then processed in an optimal manner. In this way, Oracle XML DB insulates the database optimizer from needing to understand the XQuery and XPath languages and the XML data model. The database optimizer processes a rewritten SQL statement the same way it processes other SQL statements. The general term applied to this rewriting process is XPath rewrite.

This means that the database optimizer can derive an execution plan based on conventional relational algebra. This in turn means that Oracle XML DB can leverage all of the features of the database, and ensure that SQL statements containing XQuery and XPath expressions are executed in a highly performant and efficient manner. There is little overhead with this rewriting, and Oracle XML DB executes XQuery-based and XPath-based queries at near-relational speed, while preserving the XML abstraction.

When Can XPath Rewrite Occur?

XPath rewrite is possible when all of the following conditions are met:

  • An XMLType column or table uses structured storage techniques to provide the underlying storage model.

  • An XMLType column or table is associated with a registered XML schema.

  • A SQL statement contains SQL/XML functions or XMLType methods that use XPath expressions to refer to one or more nodes within a set of XML documents.

  • The nodes referenced by an XPath expression can be mapped, using the XML schema, to attributes of the underlying SQL object model.

What is the XPath-Rewrite Process?

XPath rewrite performs the following tasks:

  1. Identify the set of XPath expressions included in the SQL statement.

  2. Translate each XPath expression into an object relational SQL expression that references the tables, types, and attributes of the underlying SQL: 1999 object model.

  3. Rewrite the original SQL statement into an equivalent object relational SQL statement.

  4. Pass the new SQL statement to the database optimizer for plan generation and query execution.

In certain cases, XPath rewrite is not possible. This normally occurs when there is no SQL equivalent of the XPath expression. In this situation, Oracle XML DB performs a functional evaluation of the XPath expressions.

In general, functional evaluation of a SQL statement is more expensive than XPath rewrite, particularly if the number of documents that needs to be processed is large. The advantage of functional evaluation is that it is always possible, regardless of whether the XMLType data is stored using structured storage and regardless of the complexity of the XPath expression.

Understanding the concept of XPath rewrite, and the conditions under which it can take place, is a key step in developing Oracle XML DB applications that will deliver the required levels of scalability and performance.

Oracle XML DB Benefits

The following sections describe several benefits of using Oracle XML DB. Figure 1-6 outlines these benefits.

Figure 1-6 Oracle XML DB Benefits

Description of Figure 1-6 follows
Description of "Figure 1-6 Oracle XML DB Benefits"

Unifying Data and Content

Most application data and Web content is stored in a relational database, a file system, or both. XML data is often used for data exchange, and it can be generated from a relational database or a file system. As the volume of XML data exchanged grows, the cost of regenerating this data grows, and these storage methods become less effective at accommodating XML content.

Figure 1-7 Unifying Data and Content: Some Common XML Architectures

Description of Figure 1-7 follows
Description of "Figure 1-7 Unifying Data and Content: Some Common XML Architectures"

Organizations often manage their structured data and unstructured data differently:

  • Unstructured data, in tables, makes document access transparent and table access complex.

  • Structured data, often in binary large objects (such as in BLOB instances), makes access more complex and table access transparent.

With Oracle XML DB, you can store and manage data that is structured, unstructured, and semi-structured using a standard data model and standard SQL and XML. You can perform SQL operations on XML documents and XML operations on object-relational (such as table) data.

Exploiting Database Capabilities

Oracle Database has strong XML support with the following key capabilities:

  • Indexing and search – Applications use queries such as "find all the product definitions created between March and April 2002", a query that is typically supported by a B-tree index on a date column. Oracle XML DB can enable efficient structured searches on XML data, saving content-management vendors the need to build proprietary query APIs to handle such queries. See Chapter 4, "XMLType Operations", Chapter 11, "Full-Text Search Over XML Data", and Chapter 17, "Generating XML Data from the Database".

  • Updates and transaction processing – Commercial relational databases use fast updates of subparts of records, with minimal contention between users trying to update. As traditionally document-centric data participate in collaborative environments through XML, this requirement becomes more important. File or CLOB storage cannot provide the granular concurrency control that Oracle XML DB does. See Chapter 4, "XMLType Operations".

  • Managing relationships – Data with any structure typically has foreign-key constraints. XML data stores generally lack this feature, so you must implement any constraints in application code. Oracle XML DB enables you to constrain XML data according to XML schema definitions, and hence achieve control over relationships that structured data has always enjoyed. See Chapter 6, "XML Schema Storage and Query: Basic" and the purchase-order examples in Chapter 4, "XMLType Operations".

  • Multiple views of data – Most enterprise applications need to group data together in different ways for different modules. This is why relational views are necessary—to allow for these multiple ways to combine data. By allowing views on XML, Oracle XML DB creates different logical abstractions on XML for, say, consumption by different types of applications. See Chapter 19, "XMLType Views".

  • Performance and scalability – Users expect data storage, retrieval, and query to be fast. Loading a file or CLOB value, and parsing, are typically slower than relational data access. Oracle XML DB dramatically speeds up XML storage and retrieval. See Chapter 2, "Getting Started with Oracle XML DB" and Chapter 3, "Using Oracle XML DB".

  • Ease of development – Databases are foremost an application platform that provides standard, easy ways to manipulate, transform, and modify individual data elements. While typical XML parsers give standard read access to XML data they do not provide an easy way to modify and store individual XML elements. Oracle XML DB supports a number of standard ways to store, modify, and retrieve data: using XML Schema, XQuery, XPath, DOM, and Java.

Exploiting XML Capabilities

If the drawbacks of XML file storage force you to break down XML into database tables and columns, there are several XML advantages you have left:

Efficient Storage and Retrieval of Complex XML Documents

Users today face a performance barrier when storing and retrieving complex, large, or many XML documents. Oracle XML DB provides high performance and scalability for XML operations. The major performance features are:

Integrate Applications

Oracle XML DB enables data from disparate systems to be accessed through gateways and combined into one common data model. This reduces the complexity of developing applications that must deal with data from different stores.

Use XMLType Views If Your Data Is Not XML

XMLType views provide a way for you wrap existing relational and object-relational data in XML format. This is especially useful if, for example, your legacy data is not in XML format but you need to migrate to XML format. Using XMLType views, you do not need to alter your application code.

To use XMLType views, you must first register an XML schema with annotations that represent a bidirectional mapping between XML Schema data types and either SQL data types or binary XML encoding types. You can then create an XMLType view conforming to this mapping, by providing an underlying query that constructs instances of the appropriate types.

Searching XML Data Using Oracle Text

Oracle Database enables special indexing on XML data, including Oracle Text indexes for section searching, special SQL functions to process XML, aggregation of XML, and special optimization of queries involving XML. SQL functions hasPath and inPath are designed to optimize XML data searches where you can search within XML text for substring matches.

Oracle XML DB also provides:

Building Messaging Applications using Oracle Streams Advanced Queuing

Oracle Streams Advanced Queuing supports the use of:

Requirements for Running Oracle XML DB

Oracle XML DB is available with Oracle9i release 2 (9.2) and higher.

See Also:

Standards Supported by Oracle XML DB

Oracle XML DB supports all major XML, SQL, Java, and Internet standards:

See Also:

Oracle XML DB Technical Support

Besides your regular channels of support through your customer representative or consultant, technical support for Oracle Database XML-enabled technologies is available free through the Discussions option on Oracle Technology Network (OTN):

Oracle XML DB Examples Used in This Manual

This manual contains examples that illustrate the use of Oracle XML DB and XMLType. The examples are based on a number of database schema, sample XML documents, and sample XML schema.

Further Oracle XML DB Case Studies and Demonstrations

Visit OTN to view Oracle XML DB examples, white papers, case studies, and demonstrations.

Oracle XML DB Examples and Tutorials

You can peruse more Oracle XML DB examples on OTN:

Comprehensive XML classes on how to use Oracle XML DB are also available. See the Oracle University link on OTN.

Oracle XML DB Case Studies and Demonstrations

Several detailed Oracle XML DB case studies are available on OTN and include the following: