XML Store 6.5 Administration Guide

EMC® Documentum®
XML Store
Version 6.5
Installation and Administration Guide

P/N 300007555A01
EMC Corporation
Corporate Headquarters:
Hopkinton, MA 01748‑9103
1‑508‑435‑1000
www.EMC.com
Copyright © 2008 EMC Corporation. All rights reserved.
Published July 2008
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change
without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO REPRESENTATIONS
OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY
DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
For the most up‑to‑date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.
All other trademarks used herein are the property of their respective owners.
Preface
This manual contains information and instructions for installing and administering an XML store,
and includes information on migrating content to the XML store. The role of EMC Documentum
Administrator is described as well the role of the GUI‑based XML store adminclient utility. Basic
administration tasks such as backup and restore, error message interpretation, and troubleshooting
are also described.
Intended audience
This manual is written for system administrators. The system administrator is the person who
generally installs and owns a Documentum installation. Readers of this document should be familiar
with network operations, database principles, command line interfaces, and basic XML constructs
(XQuery, DTDs and schemas). In addition, they should know and understand the Windows and
UNIX operating systems.
Revision history
The following changes have been made to this document.
Revision Date Description

July 2008 Initial publication
EMC Documentum XML Store Version 6.5 Installation and Administration Guide 3
Preface
4 EMC Documentum XML Store Version 6.5 Installation and Administration Guide
Chapter 1
Introduction
The XML store optimizes performance with XML content files and provides access to XML content
using XQuery. The XML store works seamlessly with all other Content Server features (versioning,
security, lifecycle, and so forth), including XML applications, to provide the following additional
functionality with XML content files.
• The ability to write (valid or well‑formed) XML content to an XML‑specific storage type.
• Search and retrieval of XML content and Documentum attributes through XQuery syntax using a
new XQuery interface
• A new XML store administrator interface to improve search performance by creating XML indexes
and controlling the creation of segments and file/segment mappings
XML store architecture

The XML store involves changes to the following areas in the underlying platform architecture (Figure
1, page 6 ).
• A new (modified) Content Server external store plug‑in that communicates with a new XML
store servlet.
• A new XML store servlet that communicates with the XML store
• A new DFC interface to query the XML store and fetch results.
• A new external storage type, the XML store, to store XML content.
The external store plug‑in communicates with Content Server’s Weblogic application server using
HTTP transactions. The XML store servlet is hosted by the application server and communicates with
the external store plug‑in. The XML store servlet communicates with the XML store through the
XML store API.
Introduction
Figure 1. High level XML store architecture
The XML store expands current functionality of the external store plug‑in to enable writable operations
and the ability to query the storage area. The following new attributes are added to the external
store plug‑in:
• is_writable – A value of ʺT” indicates that content is pushed to the XML store. By default, this
attribute is set to ʺF”.
• storage_class – A simple identifier indicating what purpose the store is used for. A value of ʺxml”
identifies the external store as an XML store.
• a_storage_param_name – Contains the name of the following repeating name/value pairs:
— a_storage_param_name[0] = app_server_url
— a_storage_param_name[1] = store_location
• a_storage_param_value – Contains the value of the following repeating name/value pairs:
— a_storage_param_value[0] = http://<host>:<JMS port>/XhiveConnector/servlet/
XhiveConnectorServlet
— a_storage_param_value[1] = user‑specified directory containing contents of the store
XML store file system

A Documentum installation is associated with a single XML store federation. The federation consists
of one or more databases grouped together (Figure 2, page 7 ).
Introduction
Figure 2. Detailed XML store architecture
The federation defines the included databases and the federation super user. A federation of databases
has one super user, with username=superuser. The super user has the right to create and delete
databases, and to perform administrative operations like setting the license key and backing up the
database. The super user cannot access regular data like libraries and documents.
Each repository that is configured with an XML store creates its own XML store database within the
federation. A database can contain:
• Users and user lists
• Groups and group lists
• Indexes and index lists
• Libraries
• Documents
• Catalogs
Each database contains multiple libraries under a root library. The root library is automatically created
during database creation. A library is a logical means of storing documents or other libraries and is
similar to the nested structure of directories or folders within your file system. The libraries contain
stored documents, cataloged DTDs and schemas, and indexes for documents and libraries.
Libraries represent physical disk segments where documents are stored. The first library is created
when the first document is imported into the XML store and the root library is automatically created
by the Content Server installer.
Note: The XML store can handle both valid (that is, conforming to a structure defined in a DTD or
XML Schema) and well‑formed XML documents. In the current release DTD’s are not stored in XML
store since they are not well formed XML documents.
Introduction
XML store data transactions

Data stored in the XML store must follow the same transactional rules as any other Documentum
storage area:
• Data can be added from within a Documentum transaction.
• Data added within a Documentum transaction is not visible by other sessions until the transaction
commits but is visible by the current session.
• Data added within a failed or aborted Documentum transaction is effectively removed from
the system:
— it cannot be discovered through any Documentum API
— it will not be returned from any XQuery
Note: Documentum does not support any objects created manually in the XML store.
Unsupported features
The following features are not supported in the XML store:
• compression
• encryption
• content duplication
• content hashing
• retention
• direct file‑system path access
• MIGRATE_CONTENT
• migration policies
Introduction
Reference documents
• The Documentum Object Reference contains information about the dm_extern_store type.
• Content Server Installation Guide contains instructions for installing an initial XML store.
• Content Server Administration Guide has a complete description of the storage area options.
• Documentum Administrator User Guide and Online Help provides instructions on creating and
configuring external (XML) stores.
Introduction
Chapter 2
Installing and Configuring XML Stores
The configuration program of the Content Server installer provides the option to install an initial XML
store if one does not already exist (see Content Server Installation Guide). Documentum Administrator
can be used to create and configure additional XML stores (Creating and configuring additional
XML stores, page 12).
Note: Installing XML stores requires a separate license.
When installing an initial XML store as part of the Content Server installation, the installer does the
following:
• deploys the XML store servlet in the Content Server’s Java Method Server Weblogic instance.
• creates an XML store federation, if one does not exist.
• creates an XML store database, if one does not exist, and associates it with a repository.
During installation, the installer sets the following values for the external store plug‑in of the first
XML store:
• storage class = xml
• writable = T
• app server URL = http://<host>:<JMS port>/XhiveConnector/servlet/XhiveConnectorServlet
• store location = $DOCUMENTUM/data/xhive_store
None of these attributes, except the app server URL should be changed. The app server URL can be
modified if the application server has changed location or if the user wants to host the XML store
database in a different application server.
Note: XML documents must be configured, with an assignment policy, in order to be saved in
an XML store. They do not get saved in the XML store by default. The Documentum Administrator
User Guide or Online Help provides instructions on setting up assignment policies associated with
an external (XML) file store.
During a Content Server upgrade, the initial XML store (if one exists) is upgraded with a new external
store plug‑in, but no additional XML stores are created.
During repository deletion, the Content Server configuration program deletes the associated XML
store database and segments. The XML store federation is not deleted, even if none of the remaining
repositories have an enabled XML store.
Installing and Configuring XML Stores
Creating and configuring additional XML stores

Additional XML stores can be setup manually in the Storage Administration area of Documentum
Administrator (see Documentum Administrator User Guide or Online Help). When setting up additional
XML stores, the storage class attribute should be set to ʺxml” and the writable attribute should be
set to ʺT”.
Installing the backup and restore scripts

After completing the Content Server installation, install the backup and restore utilities as follows:
1. Download the Documentum Content Server for <platform>, Version 6.5 xhive_backup_restore file.
2. Extract the XHBackup and XHRestore batch files.
3. Copy the XHBackup and XHRestore batch files to the $DM_HOME/bin directory.
Chapter 3
Migrating Content
Using DQL to migrate content
You can migrate XML files from an existing Documentum file store to an XML store, between XML
stores, and out of an XML store using an update DQL query. To migrate:
• Run DQL Query as UPDATE dm_sysobject OBJECTS set a_storage_type = ’xhive_store_01’ where
a_storage_type = ’filestore_01’ and a_content_type = ’xml’
Caution: Using DQL to migrate your content only migrates the current version of the document
and it changes the modify date of the migrated document to the current date.
Migrating Content
Chapter 4
Using the adminclient
The XML store provides the adminclient utility to perform many actions on the XML store database
through a GUI‑based interface. The adminclient works through the XML store API, so everything that
can be done with the adminclient can also be done in a Java program with the API.
Caution: The adminclient provides an administrator with many different capabilities. Adding
indexes and running XQueries are the only actions supported in this release.
Through the adminclient, you can do the following:

• Adding indexes, page 17
• Running XQueries, page 19
Starting the adminclient

To start the XML store adminclient:
1. Execute the command XHAdmin in the $DM_HOME/bin directory of the installation.
This starts the XML store adminclient.
Note: The font.properties messages that this may cause on a UNIX platform can be ignored.
2. Select "Database>Connect". The Connect to a database window is displayed.
3. Enter the database name, user name, and password for a valid user.
The adminclient (Figure 3, page 16) is a database explorer which displays a tree view of database
information in the left pane and details of the selected node in the right pane.
Note: Most operations are accessible by right clicking on nodes in the tree view (Figure 3, page 16).
Figure 3. adminclient menu options
Note: The status bar in the bottom right corner of the adminclient is a memory usage indicator; by
clicking the trash can in the right corner you can force a garbage collection on the adminclient.
Note: A number of preferences are automatically stored (like the last query executed and the last
database connected to). Theses preferences are stored in a file named .xhive.admin.properties
in your home directory (on MS Windows 2000, this is the directory c:\Documents and
Settings\username by default). You may remove this file if you want to reset the settings of the
adminclient program.
There are four main nodes in the tree:
• The Database info node, for database information such as segments, container pools and cluster
rules.
• The Groups and Users node, for viewing, adding, and removing users and groups.
• The root‑library node, which contains all other libraries and documents.
The hierarchy of libraries, and their contents, is nested under the root library (Figure 4, page 17).
Special types of ’folders’ are also nested under the root library. Folders with a ’C’ in them represent a
(local) catalog of the library and contain artifacts such as DTDs and XML schemas. Folders with a
’V’ in them contain versioning information for documents in that library. Versioned documents
display a small ’v’ in their icon. In the example below, the ’V’ folder ’briefing.xml’ contains version
information for the ’briefing.xml’ document.
Figure 4. Example library hierarchy
Note: You must right‑click on items in the tree view to execute actions on them.
For categories of information (e.g. users or libraries) you can add new items of that category. For
specific items in the tree (e.g. a specific user), you can change which properties appear in the
right‑click menu.
There are a couple of actions that are not accessible through the right‑click menus of the various nodes
in the database tree view, but are in the regular menu of the adminclient window. These are:
• Creating and deleting databases (in the create database dialog, a default configuration will work
for most applications).
• Change the super user password (in the settings menu).
• Enter a new license key (in the settings menu).
Adding indexes
For libraries (it is also possible for documents but that is less common), the right panel of the
adminclient holds an ’Indexes’ tab (Figure 5, page 18), where the list of indexes for a library can be
viewed and changed. Adding an index creates and maintains an index for all data contained within
the sub‑libraries of a library.
Figure 5. Adding indexes
Indexing enables faster access to parts of a library or document and increases the performance and
scalability of XML store applications. Indexes are essential to query performance when dealing with
large data sets. An index stores key‑value pairs. In XML store, the index key is a string or (for value
indexes only) a number type and its value a node set. Indexes can only be created by a privileged user.
XML store supports several different indexing methods:
• Library indexes
• Id attribute indexes
• Element name indexes
• Value indexes
• Full text indexes
• Path indexes
Each XML store indexing method has certain characteristics:
• An index can be defined on library or document level and is maintained automatically for all
descendants (id attribute, value, library, element name and full text indexes) or for all children
(library indexes) of that level.
• Library name and library id indexes can only be defined on libraries, all other indexes on both
libraries and documents (in most cases, you will want to place indexes on the libraries).
An index is either accessible or inaccessible through an index list (XhiveIndexListIf). All index types
have a common interface (XhiveIndexIf). These indexes are created with the following default
properties:
• The index does not keep the keys sorted.
• The index is stored in a separate storage container and therefore not locked with its owner library
or document. This way, concurrent access to the index is improved.
• The key type of value indexes is XhiveIndexIf.TYPE_STRING.
Indexes are very scalable: the number of keys and values of an index can grow without limitations.
Especially in case of Id attribute, element name and value indexes, values (node sets) can become
very large.
Running XQueries
The adminclient supports XQuery only. On libraries and documents, the ’Execute XQuery’ menu‑item
in the right‑click menu opens an XQuery pane at the bottom of the screen (Figure 6, page 20). You can
open multiple panes and still use the adminclient to inspect documents. The library or document, for
which a panel was opened, determines the initial context against which queries are executed.
Caution: Though adminclient can be used for running Xquery against the XML store, it is not
a recommended interface for normal users. An administrator may use it for Xquery testing
purposes only but the following risks must be taken into consideration.
• The Documentum ACL security verification cannot be enforced through adminclient.
• The adminclient cannot be used to run DQL queries through XQuery using the local:dql()
function.
Caution: The ʺExecute Update XQueryʺ function is not supported in this release. Unlike ʺExecute
XQueryʺ, which uses a read‑only transaction to execute the query, ʺExecute Update XQueryʺ uses
a read‑write transaction. Content Server will be unaware of any content or metadata changes
affected through use of this function.
Figure 6. Running XQueries
In the XQuery panel, there are four tabs:

• The ’Query’ tab allows for the entry of queries. It is possible to load and save queries, and the
last query executed is remembered.
The lowest button to the left of the input screen allows for automatic addition of setoption
commands to debug output of the query engine before the query‑text. Figure 6, page 20 shows a
query where debugging has been turned on.
A query can be run with the >> run‑button.
• The ’Result tree’ tab shows the result of a query run in a tree view. If the query involves the
original nodes (not created through element constructors), they may be deleted from the tree
(and will be deleted in the original database).
While the tree is opened, a transaction is kept opened so that the tree view can be live. However,
that also means old versions of the data are kept around. Therefore (in a very active federation),
you may want to disable or clear the result tree tab. The ’Do not use result tree’ button causes
the query transaction to be closed immediately after execution of the query, while keeping the
result viewable in the ’Result text’ tab.
This tab and the button are disabled for update queries. They are always committed immediately
after execution.
• The ’Result text’ tab holds results of executed queries, as serialized to text.
• The ’Query debug’ tab holds debug information from the query, if the debug options were set in
the query. Here is an example of such output, for when an value index can be used to execute the
query //chapter[@number < 3] (format of actual output may change over time):
Creating query plan on node /UN Charter for expression .../
descendantorself::node()/child::chapter[@number < ...]
Looking for value index on chapter/@number (sorted) (type=INTEGER)
Found index "Value index"
Looking up "3" in index "Value index"
Using query plan: index(Value index)
Supported options and extension expressions

XML store supports a set of options. Those can be set globally in the query prologue using the syntax:
declare option QName "Value";
If you just want to set an option for a specific part of you query, you can use an extension expression.
Extension expressions are specified using the syntax:
(# QName Value #)
{ expr }
where the option identified by QName is set for the whole inner expression. Quotes around Value are
optional. Multiple options can be set at once by writing multiple (# #) parts before the curly braces.
Currently supported options are:
• xhive:indexdebug ‑ allows you to check if an index is used in a query. When its value is different
from the empty string, the query evaluator prints a message to an output stream whenever a value
is looked up in an index selected by the optimizer.
You can set the output stream using XhiveXQueryQueryIf.setDebugStream(), by default
messages are printed to System.out.
• xhive:queryplandebug ‑ works like index‑debug but shows how the query is divided into
parts (and in what order the parts are executed), and shows what indexes (with what options)
are looked for.
• xhive:pathexprdebug ‑ works like index‑debug but shows what low level expressions within
the XQuery are executed, and in what order.
• xhive:ignoreindexes ‑ provides a comma separated list of indexes that should not be used
to optimize accesses.
• xhive:ftsanalyzerclass ‑ sets a fully specified classname of the Analyzer that is to be used in
the xhive:fts function when no indexes are present.
• xhive:timer ‑ sets up a timer for the encapsulated expression. The second parameter is used as a
label for the timer. The timer values can be accessed via XhiveXQueryQueryIf.getTimings().
• xhive:maxtailrecursiondepth ‑ sets the maximum recursion depth for tail recursive
functions. The default is 10000.
• xhive:implicittimezone ‑ sets the implicit timezone, used by functions and operations on the
various date types (xs:date, ...) if no explicit timezone is given. The default implicit timezone
is set to the local timezone.
• xhive:ftsimplicitconjunction ‑ sets the implicit conjunction operator for full text search.
The only valid values are ʺANDʺ and ʺORʺ. The default implicit conjunction operator is ʺORʺ.
The following provides some examples:
declare option xhive:indexdebug "true";
doc("/products")//product[@product_id = "42"]
(# xhive:indexdebug "true" #) {
(# xhive:queryplandebug "true" #)
(# xhive:pathexprdebug "true" #) {
declare option implicittimezone 'PT10H';

adjustdateTimetotimezone(xs:dateTime("20020307T10:00:0007:00"))
(# xhive:ftsimplicitconjunction 'AND' #) {
document("/manual")//paragraph[xhive:fts(.,"long list of words")]/text()
Chapter 5
Creating and Restoring Backups
Creating a backup
You need to backup an XML store federation so that it can be restored in case of an emergency.
Online (hot) backups

If any XML store code is running, you cannot use regular file backup utilities to backup your
federation. Because the data is being modified concurrently, you could backup and restore an
inconsistent version of the data. You can create backups using the API or with the XHBackup tool
(The XHBackup tool, page 24).
To create a backup of your federation you need the backup() method of XhiveFederationIf. This
sends the backup to a java.nio.channels.WritableByteChannel.
XhiveSessionIf session = XhiveDriverFactory.getDriver().createSession();
session.connect("superuser", "password", null);
XhiveFederationIf federation = session.getFederation();
FileOutputStream out = new FileOutputStream("backupfile");
federation.backup(out.getChannel(), 0);
Incremental backups
Incremental backups only store data that has been modified since the most recent (full or incremental)
backup. This is done by storing the federation log in the backup file. By default, any log files no longer
needed for transaction rollback or recovery are automatically deleted. To allow incremental backups
to be created, you must first turn on the keep‑log‑files option of the federation before creating the
initial full backup. You can do this:
• With the setKeepLogFiles() method of XhiveFederationIf.
• With the adminclient, only if no XML store code is running, by editing the bootstrap file by hand.
— Set the keeplogfiles attribute of the log element to true. After you have set this option,
obsolete log files will only be removed when a backup is created.
— Incremental backups can be created using the BACKUP_INCREMENTAL option to the backup
method or the incremental flag to XHBackup.
If you create a full backup, the next incremental backup will only be valid relative to that full backup.
There may be reasons to create a full backup without disturbing the sequence of incremental backups.
This is possible by creating a ʺstandaloneʺ backup, which does not affect the next incremental backup,
using the BACKUP_STANDALONE option to the backup method or the standalone flag to XHBackup. It
is not possible to create an incremental backup relative to a standalone backup.
The XHBackup tool

The XHBackup tool (which is a simple wrapper for the API) creates an online backup to a single
backup file (or stdout). To use it on a running server, the server has to listen for remote clients and the
tool must use a remote bootstrap property of the format xhive://host:port. It is called as XHBackup
[options] superUserPassword and has the following command line options:
• help Print usage information and exit.
• verbose Be extra verbose.
• debug Print stack trace on exception.
• version Print version information and exit.
• federation <value> Specify the bootstrap file or remote server.
• file <value> Specify the output file. If not given, output will be sent to standard output.
• incremental Create an incremental backup.
• standalone Create a standalone backup.
• keeplogfiles Do not remove obsolete log files after the backup.
Performance considerations
If you need to backup a lot of data, it will be faster to do so from the same JVM as the XML store
server. This avoids sending all the data over a TCP connection.
Offline (cold) backups

If no XML store code is running, you can backup and restore your federation using any regular
file backup and restore utility. You can still use XHBackup using an in‑JVM server by specifying
the federation bootstrap file as the federation.
You should never make a cold backup when XML store code is running on the federation, even if you
know no transactions are open. The server could still flush dirty pages from the cache to the database
files during the backup, which could result in inconsistent data in the backup files.
Snapshot backups
If you have a low‑level software or hardware method to take snapshots of federation files, you can use
that to create backups. After creating the snapshot, simply use any regular file backup utility to backup
the federation files. You can also use the XML store backup API to create a backup of the snapshot.
If the snapshot is atomic, no special measures are required. The disk image of the federation files is
always in a consistent state (otherwise, crash recovery would not be possible).
If the snapshot is not atomic (e.g., because you have to take snapshots of different files
systems to backup a federation), you can temporarily suspend all XML store write activity to
take a consistent snapshot of the federation. This is possible using the XML store API or the
XHSuspendDiskWrites tool (which is a simple wrapper around the API). To use the API, please
see the API docs for the methods XhiveFederationIf.suspendDiskWrites(int options) and
XhiveFederationIf.resumeDiskWrites.
The XHSuspendDiskWrites tool has the following options:

• federation <value> Specify the bootstrap file or remote server.
• flush Flush all dirty pages in the cache to disk.
• checkpoint Take a (lightweight) checkpoint. If used together with flush the combination is
a heavyweight checkpoint. If creating a backup while disk writes are suspended, this makes
sure that redo recovery is not necessary after restoring the backup. On a replicator, this option
is ignored. Replicators cannot take independent checkpoints.
• sync Flush all files to disk. Useful if you use a low level backup mechanism that bypasses the
operating system when copying the federation files.
• resume Resume disk writes after suspension.
Restoring backups
You can restore backups using the API or the XHRestore tool (The XHRestore tool, page 26). You must
first restore a full backup. Then you can restore any incremental backups in the order they were
created. By default, all files will be restored to the same location they were in when the backup was
made. To avoid accidents, existing files will not be overwritten. You need to delete any existing
database files manually before restoring a federation. It is also possible to restore the federation to a
new location on the same or a different machine.
Caution: You should never start a server for a federation before restoring the last incremental
backup. The unintended interaction between new log records written by the server and old log
records restored afterwards from the incremental backup will corrupt your data.
The following is an example of restoring a federation from a backup file through the API:
XhiveFederationFactoryIf federationFactory =
XhiveDriverFactory.getFederationFactory();
FileInputStream in = new FileInputStream("backupfile");
federationFactory.restoreFederation(in.getChannel(), null, null);
The XHRestore tool

The XHRestore tool (which is a simple wrapper for the API) restores a backup from a single backup
file (or stdin). To restore a full backup and corresponding incremental backups, simply run the tool
multiple times. It is called as XHRestore [options] and has the following command line options:
• federation <value> Specify the new bootstrap file location. If not specified, the federation
will be restored to the same location from which it was read. Any relative paths in the original
bootstrap file will be interpreted relative to the new bootstrap file. Database files specified with
absolute paths will be restored to their original location.
• file <value> Specify the input file. If not given, input will be read from standard input.
Serialization
You can store individual libraries and documents together with associated metadata (indexes, versions
and authority information). This is called serialization. Serialization stores data in an internal binary
format and is unrelated to online backups. Table 1, page 27 compares serialization to online backups.
Table 1. Online backups and serialization
Online backups Serialization

Backs up complete federation Stores individual libraries or documents
Does not use locks or transactions Read locks are taken on serialized data
Fast Less fast
Restores without running server Deserializes with running server
Restores exactly the same federation contents Allows deserialization to different federations,
databases or parent libraries
Serialization and deserialization can be done using API calls.

• XhiveLibraryChildIf.serialize(OutputStream out) to serialize a library child to an output
stream.
• XhiveLibraryIf.deserialize(InputStream in) to deserialize a library child, making it a
child of the calling library.
• XhiveDatabaseIf.deserializeRootLibrary(InputStream in) to deserialize a library, making
it the root library of the calling database. See also the API docs for more information on these
methods.
Chapter 6
Troubleshooting and Error Messages
This chapter contains answers to common troubleshooting questions (Table 2, page 29) and describes
two common error messages (DM_STORAGE_E_EXTSTORE_PLUGIN_ERROR, page 30 and
DM_STORAGE_T_EXTSTORE_TRACE, page 31).
Table 2. Troubleshooting
Question Answer
Can queries be run directly in the XML store to Yes, XQuery can be run directly against the
isolate a problem? XML store using the XML store adminclient.
This can help you isolate the query from the
Documentum interface. However, this bypasses
any Documentum filtering based on security
or DQL metadata processing, so the results of
your XQuery may be different than the results
returned through a Documentum interface.
How can storage failures be traced and Storage failure messages can be found in
debugged? the Documentum session logs located in the
$DOCUMENTUM/dba/log directory. Error
messages are always logged, while trace
messages are only logged if tracing is turned on.
To turn on tracing, please run the

TRACE_EXTSTORE_PLUGIN apply
method: apply,c,NULL,TRACE_EXTSTORE_
PLUGIN,LEVEL,I,1
To turn off tracing, run the same apply

method with the LEVEL argument value
0: apply,c,NULL,TRACE_EXTSTORE_
PLUGIN,LEVEL,I,0
Question Answer
Where is metadata stored in the XML store? All contents in XML store database are stored
How to tell where in XML store database the in a sub library named by the r_object_id of
content for an object is stored? the XML store. All sub libraries are under the
root library in XML store database. Content
is named with a content id (the r_object_id of
the dmr_content object). For example, for a
document with id 0900019f8005210b and its
content 0600019f80050d3d in an XML store
with id 6300019f80000167, will be located at
root_libary/6300019f80000167/0600019f80050d3d
path in the XML store database.
How do I get timing information when writing The session log contains timing information
and reading to and from an XML store? for all trace messages and is located in the
$DOCUMENTUM/dba/log directory.
To turn on tracing, run the TRACE_EXTSTORE_

PLUGIN apply method: apply,c,NULL,TRACE_
EXTSTORE_PLUGIN,LEVEL,I,1
To turn off tracing, run the same apply

method with the LEVEL argument value
0: apply,c,NULL,TRACE_EXTSTORE_
PLUGIN,LEVEL,I,0
DM_STORAGE_E_EXTSTORE_PLUGIN_
ERROR
The DM_STORAGE_E_EXTSTORE_PLUGIN_ERROR message is written to the user session log and
reports the specific error that occurred during external store plugin processing. Any external store
plugin specific errors, such as a failure to connect to the appserver, are reported here.
[DM_STORAGE_E_PLUGIN_INIT_FAILED]error: "dm_create_content API in
C:\Documentum\data\testenv\content_storage_01\0000019f\80\00\91\24.dll
returned a failure code of 0"
[DM_STORAGE_E_EXTSTORE_PLUGIN_ERROR]error: "Session: 0100019f80053907,
Store: 6300019f80000167, message: ERROR: Could not establish HTTP Client connection"
Store: 6300019f80000167, message: ERROR: HttpClient::openConnection: Failed to obtain
socket for host localhost at port 8080"
Store: 6300019f80000167, message: ERROR: HttpClient::waitForEvent: timed out waiting
for socket to be readable/writable"
If the XML store object is not configured properly, such as missing a storage location, an error such as
the following occurs:
[DM_STORAGE_E_PLUGIN_INIT_FAILED]error: "dm_create_content API
in C:\Documentum\data\testenv\content_storage_01\0000019f\80\00\91\24.dll
returned a failure code of 0"
Store: 6300019f80000152, message: ERROR: store_location not defined for HTTP post"
Error messages from the XML store servlet (including specific exceptions and error conditions thrown
by the XML store database) will be captured and returned in this error as well. The following are a
few examples of exceptions thrown by the XML store database:
XQuery syntax error:
IOException occured while processing XQuery results stream:
Store: 6300019f80000167, message: ERROR: HTTP Internal Error 500: dm_query_content
failed to execute query for $i in doc(/6300019f80000167/0600019f80050d3d)
/billing_statements/customer_entry[total_charges < 600 return $i (q00)
due to query:1:107:XQUERY_PARSE_ERROR: mismatched input return expecting ]
Storing a malformed XML document:

Store: 6300019f80000167, message: ERROR: HTTP Internal Error 500: dm_close_content
failed for object 0600019f8005190d due to Runtime exception occured: XML document
structures must start and end within the same entity."
Attempting to perform an XQuery update:

IOException occured while closing XQuery results stream:
[DM_STORAGE_E_EXTSTORE_PLUGIN_ERROR]error: "Session: 0100019f8004d545,
Store: 6300019f80000167, message: ERROR: HTTP Internal Error 500: dm_query_content
failed to execute query for $article in /chapter[@number=3]//article
return xhive:insertafter($article/para, <email>garylee@emc.com</email>)(q00)
due to XhiveException exception code 3905: query:1:53:XQUERY_OPERATION_NOT_ALLOWED:
Query not allowed to perform updates"
DM_STORAGE_T_EXTSTORE_TRACE
When tracing is enabled, this message appears in the user session log and traces the processing of the
operation from the point Content Server calls the entry point to the HTTP processing. The following is
a sample set of trace messages:
Fri Mar 14 16:56:39 2008 742000 [DM_STORAGE_T_EXTSTORE_TRACE]info:
"Session: 0100019f800529dd, Store: 6300019f80000167, message: TRACE: using slot 0"
"Session: 0100019f800529dd, Store: 6300019f80000167,
message: TRACE: HttpClient::HttpClient: WSAStartup initialized socket library successful"
message: TRACE: HttpClient::init: host name: localhost port number: 8080
servlet path: /XhiveConnector/servlet/XhiveConnectorServlet"

message: TRACE: HttpClient::getHostInformation: successfully retrieved host
information for host localhost"
message: TRACE: HttpClient::waitForEvent: socket is readable/writable"
message: TRACE: HttpClient::sendContent: successfully posted to host"
message: TRACE: HttpClient::waitForEvent: socket is readable/writable"
message: TRACE: HttpClient::readContent: recv socket shutdown, set EOF flag to true"
message: TRACE: HttpClient::closeConnection: Successfully disconnected from socket"

XML Store 6.5 Administration Guide

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

XML Store 6.5 Administration Guide

Caricato da

Copyright:

Formati disponibili

EMC® Documentum®

Installation and Administration Guide

Revision Date Description

XML store architecture

Figure 1. High level XML store architecture

XML store ﬁle system

Figure 2. Detailed XML store architecture

XML store data transactions

Creating and conﬁguring additional XML stores

Installing the backup and restore scripts

Through the adminclient, you can do the following:

Starting the adminclient

Figure 3. adminclient menu options

Figure 4. Example library hierarchy

Figure 5. Adding indexes

Figure 6. Running XQueries

In the XQuery panel, there are four tabs:

Supported options and extension expressions

declare option implicit­timezone 'PT10H';

Online (hot) backups

The XHBackup tool

Ofﬂine (cold) backups

The XHSuspendDiskWrites tool has the following options:

The XHRestore tool

Table 1. Online backups and serialization

Online backups Serialization

Serialization and deserialization can be done using API calls.

To turn on tracing, please run the

To turn off tracing, run the same apply

To turn on tracing, run the TRACE_EXTSTORE_

To turn off tracing, run the same apply

Storing a malformed XML document:

Attempting to perform an XQuery update:

servlet path: /XhiveConnector/servlet/XhiveConnectorServlet"

Potrebbero piacerti anche

declare option implicittimezone 'PT10H';