Administering ArcSDE for Oracle ®

®

Copyright Information Copyright © 2008, 2009 ESRI All Rights Reserved. Printed in the United States of America. The information contained in this document is the exclusive property of ESRI and its licensor(s). This work is protected under United States copyright law and the copyright laws of the given countries of origin and applicable international laws, treaties, and/or conventions. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying or recording, or by any information storage or retrieval system, except as expressly permitted in writing by ESRI. All requests should be sent to Attention: Contracts Manager, ESRI, 380 New York Street, Redlands, CA 92373-8100, USA. The information contained in this document is subject to change without notice. U. S. GOVERNMENT RESTRICTED/LIMITED RIGHTS Any software, documentation, and/or data delivered hereunder are subject to the terms of the License Agreement. In no event shall the U.S. Government acquire greater than RESTRICTED/LIMITED RIGHTS. At a minimum, use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in FAR §52.227-14 Alternates I, II, and III (JUN 1987); FAR §52.227-19 (JUN 1987) and/or FAR §12.211/12.212 (Commercial Technical Data/Computer Software); and DFARS §252.227-7015 (NOV 1995) (Technical Data) and/or DFARS §227.7202 (Computer Software), as applicable. Contractor/Manufacturer is ESRI, 380 New York Street, Redlands, CA 92373-8100, USA. @esri.com, 3D Analyst, ACORN, ADF, AML, ArcAtlas, ArcCAD, ArcCatalog, ArcCOGO, ArcData, ArcDoc, ArcEdit, ArcEditor, ArcEurope, ArcExplorer, ArcExpress, ArcGIS, ArcGlobe, ArcGrid, ArcIMS, ARC/INFO, ArcInfo, ArcInfo Librarian, ArcInfo—Professional GIS, ArcInfo—The World's GIS, ArcLessons, ArcLocation, ArcLogistics, ArcMap, ArcNetwork, ArcNews, ArcObjects, ArcOpen, ArcPad, ArcPlot, ArcPress, ArcQuest, ArcReader, ArcScan, ArcScene, ArcSchool, ArcScripts, ArcSDE, ArcSdl, ArcSketch, ArcStorm, ArcSurvey, ArcTIN, ArcToolbox, ArcTools, ArcUSA, ArcUser, ArcView, ArcVoyager, ArcWatch, ArcWeb, ArcWorld, ArcXML, Atlas GIS, AtlasWare, Avenue, Business Analyst Online, BusinessMAP, Community, CommunityInfo, Data Automation Kit, Database Integrator, DBI Kit, EDN, ESRI, ESRI—Team GIS, ESRI—The GIS Company, ESRI—The GIS People, ESRI—The GIS Software Leader, FormEdit, GeoCollector, Geographic Design System, ESRI BIS, Geography Matters, Geography Network, GIS by ESRI, GID Data ReViewer, GIS Day, GIS for Everyone, GISData Server, JTX, MapBeans, MapCafé, MapData, MapObjects, Maplex, MapStudio, ModelBuilder, MOLE, NetEngine, PC ARC/INFO, PC ARCPLOT, PC ARCSHELL, PC DATA CONVERSION, PC STARTER KIT, PC TABLES, PC ARCEDIT, PC NETWORK, PC OVERLAY, PLTS, Rent-a-Tech, RouteMAP, SDE, Site•Reporter, SML, Sourcebook•America, Spatial Database Engine, StreetEditor, StreetMap, Tapestry, the ARC/INFO logo, the ArcAtlas logo, the ArcCAD logo, the ArcCAD WorkBench logo, the ArcCOGO logo, the ArcData logo, the ArcData Online logo, the ArcEdit logo, the ArcEurope logo, the ArcExplorer logo, the ArcExpress logo, the ArcGIS logo, the ArcGIS Explorer logo, the ArcGrid logo, the ArcIMS logo, the ArcInfo logo, the ArcLogistics Route logo, the ArcNetwork logo, the ArcPad logo, the ArcPlot logo, the ArcPress for ArcView logo, the ArcPress logo, the ArcScan logo, the ArcScene logo, the ArcSDE CAD Client logo, the ArcSDE logo, the ArcStorm logo, the ArcTIN logo, the ArcTools logo, the ArcUSA logo, the ArcView 3D Analyst logo, the ArcView Data Publisher logo, the ArcView GIS logo, the ArcView Image Analysis logo, the ArcView Internet Map Server logo, the ArcView logo, the ArcView Network Analyst logo, the ArcView Spatial Analyst logo, the ArcView StreetMap 2000 logo, the ArcView StreetMap logo, the ArcView Tracking Analyst logo, the ArcWorld logo, the Atlas GIS logo, the Avenue logo, the BusinessMAP logo, the Community logo, the Data Automation Kit logo, the Digital Chart of the World logo, the ESRI Data logo, the ESRI globe logo, the ESRI Press logo, The Geographic Advantage, the Geography Network logo, the MapCafé logo, the GIS Day logo, the MapObjects Internet Map Server logo, the

MapObjects logo, the MOLE logo, the NetEngine logo, the PC ARC/INFO logo, the Production Line Tool Set logo, the RouteMAP IMS logo, the RouteMAP logo, the SDE logo, The Geographic Advantage, The World's Leading Desktop GIS, Water Writes, www.esri.com, www.esribis.com, www.geographynetwork.com, www.gis.com, www.gisday.com, and Your Personal Geographic Information System are trademarks, registered trademarks, or service marks of ESRI in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned herein are trademarks or registered trademarks of their respective trademark owners.

Administering ArcSDE® for Oracle®

About this Document This document is provided for your convenience to group topics by database management system (DBMS). Topics are originally created as Web documents, but have been published here to group them together, format them, and make it possible for you to print them all at once. Because these topics are Web help topics, they contain many links. Links to information contained in topics inside this PDF should link to those sections. Links in this topic that point to topics in other help sections or external Web sites, such as the ESRI support site, will launch the external site. Additionally, you will find there are still some topics that mention all the supported databases. This is due to the nature of the particular topic. For example, the content in overview topics generally applies to all databases. Splitting these out by DBMS would introduce a good deal of redundancy into the help system; therefore, this was not done. In those cases, ignore the links or headings that do not apply to the DBMS in which you are interested. Appendices are supplied as supplemental information. These are topics that come from sections in the help not included in the main body of this document.

4

Table Of Contents Chapter 1. Administering ArcSDE geodatabases . . . . . . . . . . . . . . . . . . . . . . . 8 An overview of ArcSDE geodatabase administration . . . . . . . . . . . . . . . . . . . . . 8 What is ArcSDE? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Chapter 2. Installing and upgrading the ArcSDE component . . . . . An overview of installing the ArcSDE component . . . . . . . . . About new installations of the ArcSDE component . . . . . . . . . Installation summary for the ArcSDE component for Oracle . . . . . Sample scripts installed with ArcSDE for Oracle . . . . . . . . . . Managing multiple ArcSDE component installations on the same machine After ArcSDE component installation and geodatabase creation . . . . About upgrading ArcSDE geodatabases . . . . . . . . . . . . . Upgrade summary for ArcSDE geodatabases . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

13 13 13 14 17 18 18 19 20

Chapter 3. Configuring an ArcSDE geodatabase . . . . . . . . . An overview of configuring an ArcSDE geodatabase . . . . . . . DBMS initialization parameter recommendations . . . . . . . . Oracle initialization parameters . . . . . . . . . . . . . . . The giomgr.defs file and the SERVER_CONFIG system table . . . ArcSDE initialization parameters . . . . . . . . . . . . . . . Buffer size initialization parameters . . . . . . . . . . . . . . The services.sde file . . . . . . . . . . . . . . . . . . . . The dbinit.sde file . . . . . . . . . . . . . . . . . . . . . The dbtune file and the DBTUNE table . . . . . . . . . . . . DBTUNE configuration keywords . . . . . . . . . . . . . . Default configuration keywords specific to Oracle . . . . . . . . DBTUNE configuration parameter name-configuration string pairs . Oracle DBTUNE configuration parameters . . . . . . . . . . . About Oracle Spatial DBTUNE storage parameters . . . . . . . Composite configuration keywords . . . . . . . . . . . . . . Making configuration keywords available in ArcGIS . . . . . . . The DATA DICTIONARY keyword . . . . . . . . . . . . . Oracle DATA DICTIONARY keyword . . . . . . . . . . . . The DEFAULTS keyword . . . . . . . . . . . . . . . . . Oracle DEFAULTS keyword . . . . . . . . . . . . . . . . Log file keywords . . . . . . . . . . . . . . . . . . . . . LOGFILE DEFAULTS for Oracle . . . . . . . . . . . . . . Log file configuration options . . . . . . . . . . . . . . . . About data types . . . . . . . . . . . . . . . . . . . . . Oracle data types . . . . . . . . . . . . . . . . . . . . . About geometry storage types . . . . . . . . . . . . . . . . Configuring Oracle Net Services to use ST_Geometry SQL functions Locators in the geodatabase . . . . . . . . . . . . . . . . . Language support in the geodatabase . . . . . . . . . . . . . Language support for Oracle . . . . . . . . . . . . . . . . XML columns in the geodatabase . . . . . . . . . . . . . . . Configuring a database to support XML columns . . . . . . . . Configuring an Oracle database to support XML columns . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

23 23 25 26 31 32 41 43 44 50 56 60 62 63 81 84 86 88 89 90 91 93 94 94 106 107 108 110 113 114 114 115 122 123

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Using multiple geodatabases within a DBMS . . . . . . . . . . . . . . . . . . . . . . . Using multiple geodatabases in Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . Registering tables to be used by ArcGIS Desktop . . . . . . . . . . . . . . . . . . . . . Chapter 4. Creating and administering user accounts An overview of user accounts . . . . . . . . . Adding users to an ArcSDE geodatabase . . . . . Grouping users by access needs . . . . . . . . The ArcSDE administrative account . . . . . . User permissions . . . . . . . . . . . . . . User permissions for geodatabases in Oracle . . . Granting and revoking privileges on datasets . . . Operating system authentication . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

146 146 147 148 149 151 152 156 158

Chapter 5. Connecting to an ArcSDE geodatabase . . . . . An overview of ArcSDE geodatabase connections . . . . . Compatibility between clients and geodatabases . . . . . . ArcSDE connection syntax . . . . . . . . . . . . . . Starting an ArcSDE service . . . . . . . . . . . . . . Stopping an ArcSDE service . . . . . . . . . . . . . Removing ArcSDE service user processes . . . . . . . . Forcing a search of the local services file on Unix systems . . Pausing and resuming an ArcSDE service . . . . . . . . Accessing an ArcSDE service through a firewall . . . . . . Displaying ArcSDE service statistics and session information Troubleshooting the ArcSDE service . . . . . . . . . . Properties of a direct connection to an ArcSDE geodatabase . Setting up clients for a direct connection . . . . . . . . . Setting up a direct connection to Oracle . . . . . . . . . Troubleshooting direct connections to an ArcSDE geodatabase A note about ArcIMS MapService connections . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

160 160 163 165 168 173 175 177 177 179 180 181 191 195 195 197 199

Chapter 6. Maintaining a geodatabase . . . . . . . . . . . . . . . . . An overview of maintaining an ArcSDE geodatabase . . . . . . . . . . . About database backup and recovery . . . . . . . . . . . . . . . . . Oracle backups . . . . . . . . . . . . . . . . . . . . . . . . . . Recovery models for Oracle . . . . . . . . . . . . . . . . . . . . . About compressing a geodatabase . . . . . . . . . . . . . . . . . . Compressing an ArcSDE geodatabase licensed under ArcGIS Server Enterprise About updating geodatabase statistics . . . . . . . . . . . . . . . . . Updating statistics on a geodatabase licensed under ArcGIS Server Enterprise . Updating geodatabase statistics in Oracle databases . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

200 200 202 203 205 206 208 209 211 212

Chapter 7. Tuning an ArcSDE geodatabase . . . An overview of tuning an ArcSDE geodatabase . Recommendations to minimize disk I/O contention Minimize disk I/O contention in Oracle . . . . Recommendations for tuning memory . . . . . Tuning memory in Oracle . . . . . . . . . . Tuning spatial indexes . . . . . . . . . . . Using database views . . . . . . . . . . . Views in Oracle . . . . . . . . . . . . . . Tuning an Oracle instance for XML data storage .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

213 213 214 214 218 219 220 224 226 231

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

130 131 140

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

Appendix A. Creating and moving geodatabases . . . . . . Creating a new geodatabase . . . . . . . . . . . . . . About exporting and importing ArcSDE geodatabases . . . Moving a geodatabase using ArcSDE export files . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

233 233 236 237

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

239 239 240 243 244 249 262 267 267 278 280

Appendix C. Connecting to a geodatabase from ArcGIS Desktop . . . . . . . . . . . . . . . Creating spatial database connections . . . . . . . . . . . . . . . . . . . . . . . . . .

285 285

Appendix D. Multiversioned views . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using multiversioned views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

292 292

Appendix E. ArcSDE geodatabase system tables . . . . . . . . . . . . . . . . . . . . . . System tables of a geodatabase stored in Oracle . . . . . . . . . . . . . . . . . . . . . .

297 297

Appendix B. Data storage in the geodatabase . . . . . . . . . . ArcSDE Compressed Binary storage . . . . . . . . . . . . . The OGC Well-Known Binary representation for geometry . . . . The OGC Well-Known Text representation of spatial reference systems The ST_Geometry storage type . . . . . . . . . . . . . . . ST_Geometry storage in Oracle . . . . . . . . . . . . . . . BLOB data storage in Oracle geodatabases . . . . . . . . . . . The Oracle Spatial geometry and raster types . . . . . . . . . . Using the Oracle Spatial geometry type . . . . . . . . . . . . Using the Oracle Spatial raster type . . . . . . . . . . . . . . Migrating Oracle data from one storage type to another . . . . . .

. . . .

. . . .

. . . .

Administering ArcSDE® for Oracle®

Administering ArcSDE geodatabases

Chapter 1 Administering ArcSDE geodatabases Section 1 An overview of ArcSDE geodatabase administration Note: This topic was updated for 9.3.1. ArcSDE geodatabases allow you to use other ESRI products, such as ArcGIS Desktop, ArcGIS Server, and ArcIMS, as well as custom applications to store, use, and manage all your GIS data in one of the following database management systems (DBMS): IBM DB2, IBM Informix, Microsoft SQL Server, Oracle, or PostgreSQL. ArcSDE geodatabases allow you to store your data in a central database and support the concurrent multiuser editing necessary for most GIS data management workflows. The needs at your site determine what type of ArcSDE geodatabase you use. The main differences between the types of ArcSDE geodatabases are database size and the number of connections that can be made to each. Because of this, each type of ArcSDE geodatabase is suitable for different sizes of organizations. ◦ Individuals or small groups—This includes people working in the field with a replicated geodatabase or a group of two or three people working on the same project. For these you could use the ArcSDE for SQL Server Express installation included with your ArcGIS Desktop (ArcInfo/ArcEditor) or ArcGIS Engine software media. ◦ Medium groups—This includes workgroups or small departments. ArcSDE for SQL Server Express licensed through ArcGIS Server Workgroup allows you to create geodatabases for groups of this size. ◦ Large groups—This includes entities such as utility companies, large civil engineering firms, or a county fire department. These groups are most likely to use ArcSDE geodatabases stored in an enterprise DBMS and created under an ArcGIS Server Enterprise license. As your user base grows, so too can your geodatabase. For instance, you might start by storing your data in two or three ArcSDE geodatabases in SQL Server Express. When you need to store more than 4 GB of data, you could move your data to an ArcSDE geodatabase licensed under ArcGIS Server Enterprise. Scaling your geodatabase to fit your organization's needs is just one of the tasks you would perform as the administrator of an ArcSDE geodatabase. Anytime you have multiple people simultaneously working with data in any database—be it a database of medical records, a work order management database, or a geodatabase—there are a number of administrative tasks that need to be performed to ensure the database works properly. Some general concepts apply to the administration of all types of geodatabases, but often, how you administer your geodatabase depends on the type of DBMS you are using. In this portion of the help system, overview topics cover the basic topics, and database-specific information is provided where appropriate. Geodatabases created with ArcSDE for SQL Server Express use default configuration settings and are accessed through the ArcCatalog user interface. Therefore, the amount of administration for these types of geodatabases is minimal. For this reason, many of the topics in the "Configuring an ArcSDE geodatabase" book of the help system only apply to ArcSDE geodatabases licensed through ArcGIS Server Enterprise. A note is placed at the beginning of topics to help clarify which ones apply strictly to these geodatabases.

8

Administering ArcSDE® for Oracle®

Administering ArcSDE geodatabases

NOTE: ArcSDE geodatabases licensed through ArcGIS Engine also use default configuration settings but are accessed using the ArcObject DataServerManager interface. Because they are accessed through ArcObjects, consult the ArcObjects developer help on the Resource Center for information on administering these geodatabases.

Key administrative tasks Key tasks for the administration of an ArcSDE geodatabase include ◦ Installing software —To create ArcSDE geodatabases for SQL Server Express licensed with ArcGIS Desktop or ArcGIS Server Workgroup, you must install SQL Server Express and ArcGIS Desktop. To create ArcSDE geodatabases licensed through ArcGIS Engine, you must install SQL Server Express and ArcGIS Engine Runtime. The SQL Server Express installation executable comes with the ArcInfo or ArcEditor level of ArcGIS Desktop, ArcGIS Engine, and ArcGIS Server Workgroup. For ArcSDE geodatabases licensed with ArcGIS Server Enterprise, your DBMS and ArcSDE software must be installed separately. If you use a DB2, Informix, Oracle, or SQL Server DBMS to store your geodatabase, you must obtain the DBMS software separately and install it. If you use a PostgreSQL DBMS to store your geodatabase, an executable is provided to install the supported version of PostgreSQL. ◦ Configuring the DBMS —The DBMS is the container for your data. You need to create the container (database) itself and—for ArcSDE geodatabases with ArcGIS Server Enterprise—configure the database. ◦ Creating user accounts —To control access to the geodatabase, you must create or add user accounts with specific permissions. ◦ Creating connections to the geodatabase —To work with the data, connect to the geodatabase from client applications. Connections can be made directly between clients and the database or between clients, an ArcSDE service, and the database. NOTE: ArcSDE services cannot be used with ArcSDE for SQL Server Express. ◦ Maintaining the geodatabase —As the data in the geodatabase changes, the database administrator (DBA) performs tasks such as compressing the database, updating statistics, performing backup and recovery procedures, and altering storage locations to maintain performance levels. ◦ Tuning the geodatabase —Certain settings in the DBMS can be altered to improve memory usage, reduce resource contention, and improve performance of the geodatabase. ◦ Scaling and moving your geodatabase —As the number of users and the complexity and quantity of your data grow, you may need to migrate to a larger geodatabase. There are also times when you may be called on to import a geodatabase provided by a contractor or export a geodatabase to send to a branch office. GIS administrators might load data into the geodatabase or be involved in geodatabase replication. However, since these tasks can be performed by other staff members, such as data owners or editors, they are addressed in other sections of this help system. Populating the geodatabase with data and the proper settings to do this are covered in the "Creating a geodatabase" and "Adding datasets and other geodatabase elements" books inside the "Building geodatabases" book in this help system. See An overview of adding datasets to the geodatabase in the "Adding datasets and other geodatabase elements" section of the help to get you started. Geodatabase replication is discussed in the "Managing distributed data" book inside the "Data management workflows, transactions, and versioning" book in this help system. See Replicas and geodatabases in the "Data management workflows, transactions, and versioning" section of the help for an introduction.

9

Administering ArcSDE® for Oracle®

Administering ArcSDE geodatabases

Who does what When using ArcSDE geodatabases licensed through ArcGIS Server Enterprise, the database administrator (DBA), who manages the DBMS, and the GIS administrator, who manages the GIS, often are not the same person. If such is the case at your organization, it is important that the two individuals (or groups of individuals) coordinate their tasks. The following is a list of some geodatabase management tasks and the corresponding staff person with whom responsibility for that task typically resides. Task

Staff

Management of physical database structures (data files, tables, and indexes)

DBA

Management of logical database constructs (data models, rules, subtypes, networks, locators, and versions)

GIS administrator

Management of users and permissions

DBA (database permissions)

◦ Database permissions ◦ Object permissions

Data owner (object permissions)

Database backup and recovery

DBA

Performance tuning

DBA (database)

◦ Of the database ◦ Of workflows (how users utilize the GIS)

GIS administrator (workflows)

Data distribution (replication/synchronization)

GIS administrator

Geodatabase compression and updating statistics

GIS administrator

Many of these tasks also require the DBA and GIS administrator to coordinate with other IT staff, for example, in the following situations: ◦ Deciding when scripted backups should be run to avoid conflicting with other scheduled processes ◦ Tracking down and fixing the cause of any performance issues encountered ◦ Coordinating network and server permissions with database permissions ◦ Determining the implications for the network, server access, and firewall if data is being transferred between the geodatabase and other enterprise databases or between the geodatabase and Web applications For ArcSDE for SQL Server Express, administration is incorporated into ArcGIS Desktop or ArcGIS Engine Runtime and no outside database administration is performed; therefore, the GIS administrator for the specific database server will likely perform all management tasks listed in the preceding table.

Section 2 What is ArcSDE? Note: This topic was updated for 9.3.1. ArcSDE is ESRI's technology for accessing and managing geospatial data within relational databases. ArcSDE technology supports reading and writing of multiple standards including (among other data storage options) Open Geospatial Consortium, Inc. (OGC), standards for simple features; the International Organization for Standardization (ISO) standard for spatial types; and the Oracle Spatial format. ArcSDE is unique in its support of the following capabilities: NOTE: This applies only to ArcSDE geodatabases licensed through ArcGIS Server Enterprise.

10

Administering ArcSDE® for Oracle®

Administering ArcSDE geodatabases

◦ It is open and interoperable across multiple database management systems (DBMS) (Oracle, SQL Server, DB2, Informix, and PostgreSQL). ◦ It is standards based, using as its native data structure the OGC binary simple features standard and the ISO spatial type (for Oracle, IBM DB2, IBM Informix, and PostgreSQL only). ◦ It supports full, open SQL access to geodatabases stored in Oracle, IBM DB2, IBM Informix, and PostgreSQL. ◦ It fully supports the Oracle format for feature storage (using Oracle Spatial and Oracle Locator). ◦ It provides high performance and scales to a large number of users. ArcSDE geodatabases outperform all other solutions for storage and retrieval of spatial data.

When do you need ArcSDE? When you need a multiuser geodatabase that can be edited and used simultaneously by many users, the ArcSDE geodatabase provides the solution. It adds the ability to manage both a shared, multiuser geodatabase and a number of critical version-based GIS workflows. The ability to leverage an organization's enterprise relational databases is a key advantage of the ArcSDE geodatabase. ArcSDE also supports users who need to manage long transactions and version-based workflows, for example, to manage historical archives, distributed editing, and federated replicas across many DBMS architectures as well as to support multiuser editing scenarios. ArcSDE geodatabases work with a variety of DBMS storage models (IBM DB2, IBM Informix, Oracle, Microsoft SQL Server, and PostgreSQL). ArcSDE geodatabases are used in a wide range of workgroups, departments, and enterprise settings. They take full advantage of their underlying DBMS architecture to support the following: ◦ Extremely large, continuous GIS databases ◦ Many simultaneous users ◦ Long transactions and versioned workflows ◦ Relational database support for GIS data management (providing the benefits of a relational database such as scalability, reliability, security, backup, and integrity) ◦ Standards-based SQL types for Spatial when the DBMS supports this capability Through many large geodatabase implementations, it has been found that DBMSs are efficient at moving the type of large binary objects required for GIS data in and out of tables. In addition, GIS database sizes and the number of supported users can be much larger when using ArcSDE.

How is ArcSDE technology included in ArcGIS? In the past, ArcSDE was sold as a separate ESRI product. Beginning with ArcGIS 9.2, ArcSDE technology is still included in ArcGIS; however, it is no longer a separate product. Instead, ArcSDE technology has been integrated into both the ArcGIS Server and ArcGIS Desktop products. ArcSDE geodatabases readily scale from personal, single-user geodatabases, through workgroup geodatabases, up to extremely large enterprise geodatabases. There are three levels for accessing and using ArcSDE technology in ArcGIS. Geodatabase capabilities are available in the following ESRI software: ArcSDE technology included with ArcGIS Desktop, ArcGIS Engine, and ArcGIS Server Workgroup Beginning at ArcGIS 9.2, ArcEditor, ArcInfo, and ArcGIS Server Workgroup include the Microsoft SQL Server Express database. ArcGIS Desktop software includes ArcSDE capabilities to support ArcSDE geodatabases. Beginning with ArcGIS 9.3, ArcGIS Engine includes the Microsoft SQL Server Express database.

11

Administering ArcSDE® for Oracle®

Administering ArcSDE geodatabases

Within ArcEditor and ArcInfo, the ArcCatalog application provides the ability to fully administer and manage ArcSDE geodatabases stored in SQL Server Express. This provides full ArcSDE geodatabase capabilities for a few users. You set up and manage these ArcSDE geodatabases within ArcCatalog. No extra software or database administration expertise is required. When using ArcGIS Engine, administration and use of the ArcSDE geodatabases stored in SQL Server Express are done through ArcObjects. ArcSDE technology included with ArcGIS Server Enterprise This is the traditional ArcSDE technology that runs on Oracle, SQL Server, IBM DB2, IBM Informix, and (beginning with ArcGIS 9.3) PostgreSQL. It can scale to databases of any size and number of users, running on computers of any size and configuration. Users provide their own DBMS license for this level of ArcSDE use.* The DBMS is typically administered and managed by a database administrator (DBA). The following table further compares the types of ArcSDE geodatabases: Feature

SQL Server Express

Enterprise DBMS

Underlying database

SQL Server Express

DB2, Informix, Oracle, PostgreSQL, or SQL Server

Type of client-to-database connection

Direct connect

Direct connect or ArcSDE application server (ArcSDE service)

Database administration

ArcCatalog or ArcObjects

ArcSDE Administration Commands, DBMS administration software, and ArcCatalog

CPU limit

1

Licensed per CPU or core

Backup/Recovery model

Simple

Dependent on DBMS

User able to alter configuration

No

Yes

Type of user/group logins

Operating system (Windows) authenticated

DBMS or operating system authenticated

Language/Localization

Uses same code page as the server

Customizable; options dependent on DBMS

XML column support

Yes (beginning with 9.3)

Yes

Versioned editing support

Yes

Yes

Archiving support

Yes

Yes

Replication support

Yes

Yes

User-defined views

No

Yes

*Exception: The PostgreSQL DBMS is included with ArcSDE for PostgreSQL.

12

Administering ArcSDE® for Oracle®

Installing and upgrading the ArcSDE component

Chapter 2 Installing and upgrading the ArcSDE component Section 1 An overview of installing the ArcSDE component Note: This topic was updated for 9.3.1. Specific steps for installing the ArcSDE component or upgrading ArcSDE geodatabases vary depending on your database management system (DBMS), operating system (OS), and whether you are installing a new version of the ArcSDE component or a service pack or patch. It is, therefore, very important that you read the installation documentation provided with your software prior to installing or upgrading.

Using the ArcSDE component with ArcGIS Desktop, ArcGIS Engine, or ArcGIS Server and SQL Server Express When you install ArcGIS Desktop, ArcGIS Engine, or ArcGIS Server, the ArcSDE component files are built into those applications. These files are used when you create, connect to, and work with geodatabases in SQL Server Express. The instructions and files for new installations and upgrades for these geodatabases are provided on the ArcInfo and ArcEditor ArcGIS Desktop DVD; the ArcGIS Engine DVD; or, if you are using ArcGIS Server Workgroup, the ArcGIS Server Workgroup media.

Installing the ArcSDE component with ArcGIS Server Enterprise You will find the installation and upgrade files and guides you need on the ArcSDE component DVD in your ArcGIS Server Enterprise media kit. Choose the ArcSDE component installation based on the database type and OS you will be using.

Installing service packs and patches Service packs and patches are downloaded from the ESRI support site. They have their own installation instructions along with a description of the issues addressed and a list of the files that are updated as a result of installing the service pack or patch. To apply a service pack or patch to an ArcSDE geodatabase for SQL Server Express, you apply the service pack or patch to the ArcGIS Desktop, ArcGIS Engine, or ArcGIS Server application. There is no separate ArcSDE service pack or patch to apply.

Section 2 About new installations of the ArcSDE component Note: This topic was updated for 9.3.1. There are two aspects of installing an ArcSDE geodatabase: ◦ Installing and configuring the database management system (DBMS) software ◦ Installing and configuring the ArcSDE component The steps you take to accomplish this vary slightly depending on how the ArcSDE geodatabase is licensed and the DBMS used to store it.

13

Administering ArcSDE® for Oracle®

Installing and upgrading the ArcSDE component

For ArcSDE geodatabases licensed with ArcGIS Server Enterprise, you can utilize one of the following DBMS products: IBM DB2, IBM Informix, Microsoft SQL Server, Oracle, or PostgreSQL. For the first four DBMS products listed, you obtain the installation of the DBMS software separately from the ArcSDE component installation. Therefore, you need to read the setup instructions provided with your DBMS installation media to complete the DBMS installation. For ArcSDE for PostgreSQL, the DBMS installation for certain operating systems is provided as part of the setup, and documentation is also provided. There are three parts to a new installation of the ArcSDE component of ArcGIS Server Enterprise: preinstallation tasks, installing the ArcSDE component of the software, and postinstallation tasks. An overview of the specific tasks you must complete for each of these parts for each supported DBMS can be viewed in the following topics: Installation summary for the ArcSDE component for DB2 Installation summary for the ArcSDE component for Informix Installation summary for the ArcSDE component for Oracle Installation summary for the ArcSDE component for PostgreSQL Installation summary for the ArcSDE component for SQL Server For complete installation instructions, consult the installation guides provided with the ArcGIS Server Enterprise installation media. You can also download portable document format (PDF) versions of the installation guides from the Geodatabase Resource Center . In the case of ArcSDE for SQL Server Express, the DBMS installation executable is included on the ArcGIS Desktop (ArcEditor or ArcInfo), ArcGIS Engine, and ArcGIS Server Workgroup media. You install SQL Server Express and register it to store geodatabases. There is no separate ArcSDE component installation. The files that allow you to create, connect to, and use ArcSDE geodatabases are built into the client software. Once the SQL Server Express instance is created and set to store geodatabases, you add a database server connection in ArcCatalog or use the ArcObjects IDataServerManager interface to create geodatabases, add users, and administer the DBMS and the geodatabase stored in it. See Installing SQL Server Express and enabling it to store ArcSDE geodatabases for a summary of the installation and postinstallation steps for these geodatabases.

Section 3 Installation summary for the ArcSDE component for Oracle Introduction Note: This topic was updated for 9.3.1. You can store ArcSDE geodatabases in Oracle databases. This does not require Oracle Spatial, but use of Oracle Spatial types is supported with ArcSDE geodatabases in Oracle. To see which operating systems and database versions are supported, go to the ESRI support site and navigate to System Requirements for ArcGIS Server. NOTE: If there is no native ArcSDE build for the operating system of the server hosting the Oracle database, then there is no support for SQL access to ST_Geometry. ST_Geometry storage can be used from ArcSDE clients, but SQL access to this data is not supported. The setup, installation, and postinstallation procedures vary slightly between operating systems. The steps in this topic are an overview of the preinstallation, ArcSDE component installation, and postinstallation setups for ArcSDE for Oracle. For complete instructions, including instructions for installing the DBMS and ArcSDE component on separate machines, read the installation guide provided on the ArcSDE component installation media.

14

Administering ArcSDE® for Oracle®

Installing and upgrading the ArcSDE component

Summary steps for creating an ArcSDE geodatabase on Oracle Preinstallation tasks Before you can install the ArcSDE component and set up the geodatabase, there are a few tasks you must complete. On Windows 1. Install and configure the Oracle database management system (DBMS). If you are going to install the ArcSDE component on a server separate from the DBMS, you also need to install the Oracle client on the server where the ArcSDE component is installed. The topics Oracle initialization parameters , Minimize disk I/O contention in Oracle , Tuning memory in Oracle , and Configuring Oracle Net Services to use ST_Geometry SQL functions can help you with this. Also consult your Oracle documentation. 2. Make sure the Windows TEMP environment variable is set to a writable folder. On Linux or UNIX 1. Install and configure the Oracle DBMS. If you are going to install the ArcSDE component on a server separate from the DBMS, you also need to install the Oracle client on the server where the ArcSDE component is installed. The topics Oracle initialization parameters , Minimize disk I/O contention in Oracle , Tuning memory in Oracle , and Configuring Oracle Net Services to use ST_Geometry SQL functions can help you with this. Also consult your Oracle documentation. 2. Create an SDE operating system (OS) account to own the SDEHOME files. 3. Set environment variables. NOTE: Beginning with Oracle 10 g , nonadministrative users do not have access to ORACLE_HOME. Therefore, if your ArcSDE administrator (the sde user) is not an administrator on the server, this user has to install the Oracle client so it gets installed in a location the sde user has permission to access. The Oracle client needs to be installed on whichever server the ArcSDE component is installed on; this is true for local (ArcSDE and Oracle DBMS on the same machine) and remote (ArcSDE and Oracle on different machines) configurations. For information on supported clients and databases, consult the ArcGIS Server system requirements page on the ESRI support site .

Installing the ArcSDE component The installation files for the ArcSDE component are on a separate DVD in the ArcGIS Server media kit. On Windows 1. Insert the installation DVD into the drive. 2. Launch the installation wizard for ArcSDE for Oracle. 3. Follow the instructions in the wizard to install the ArcSDE component of ArcGIS Server. NOTE: You must be a Windows administrator to install any software on the machine. On Linux or UNIX

15

Administering ArcSDE® for Oracle®

Installing and upgrading the ArcSDE component

1. Place the ArcSDE component media into the appropriate drive and mount the drive. 2. Change directories to the appropriate drive. 3. Run the installation command appropriate to the shell you are using to open the command-driven dialog box for the ArcSDE component installation procedure. 4. Follow the instructions in the installation procedure. Tip • New installations of ArcSDE at 9.3 do not create public synonyms for ST functions and operators. That means all ST functions, such as ST_Point, and operators, such as ST_Buffer, must be fully qualified. For example, you would type "sde.ST_Point" or "sde.ST_Buffer" rather than ST_Point or ST_Buffer when executing SQL commands. If you upgrade to ArcSDE 9.3 for Oracle from a previous release of ArcSDE, the public synonyms will still be in your geodatabase and you will not be required to fully qualify ST functions and operators.

Postinstallation tasks The postinstallation tasks ◦ Create the ArcSDE geodatabase system tables. ◦ Create the ArcSDE administrator user if it does not already exist and give it necessary permissions to the database. ◦ Authorize the ArcSDE component. ◦ Set up and start an ArcSDE service (if you plan to use one). In preparing to create the ArcSDE geodatabase system tables, determine if you need to specify storage settings for these system tables and their indexes. These settings are grouped under the DATA_DICTIONARY configuration keyword in the dbtune.sde file. You would need to alter the configuration parameter values prior to creating the geodatabase, then specify the altered dbtune.sde file when the geodatabase is created. If you created a default table space for your SDE user, the system tables and indexes will be created in the SDE user's default table space without you having to alter the DATA_DICTIONARY parameters in the dbtune.sde file. For details on these parameters, see The DATA_DICTIONARY keyword and its related topics The dbtune file and the DBTUNE table , DBTUNE configuration keywords , and DBTUNE configuration parameter nameconfiguration string pairs . To create the geodatabase, the SDE user must have specific privileges. See the required installation privileges listed in User permissions for geodatabases in Oracle . On Windows 1. Grant EXECUTE privilege on DBMS_PIPE and DBMS_LOCK to PUBLIC in the database. 2. Use the ArcSDE for Oracle Post Installation wizard to complete the postinstallation setup. If you do not want to alter any settings in the files in SDEHOME\etc, you can continue with the Post Installation wizard as soon as the installation wizard completes. If you customized any of the files, open the Post Installation wizard from the Start menu (Start > All Programs > ArcGIS > ArcSDE).

16

Administering ArcSDE® for Oracle®

Installing and upgrading the ArcSDE component

The Post Installation wizard lets you select configuration files, creates the geodatabase schema, authorizes the software, and creates and starts an ArcSDE service. 3. Optionally, you can revoke extra privileges (those needed for the setup of the geodatabase) from the SDE user. On Linux or UNIX 1. Create an Oracle SDE user and table space. A script, create_sde_oracle.sql, is installed in the SDEHOME > tools > oracle directory that can be used to create the Oracle SDE user and table space. See Sample scripts installed with ArcSDE for Oracle for details. 2. Modify files in SDEHOME/etc and /etc/services. 3. Run sdesetup to create the geodatabase schema and authorize the software. 4. Grant EXECUTE privilege on DBMS_PIPE and DBMS_LOCK to PUBLIC. 5. Start an ArcSDE service (if you will use one). 6. Optionally, you can revoke extra privileges (those needed for the setup of the geodatabase) from the SDE user. If you are using Real Application Cluster (RAC), you must rename the version_util package, utilize the version_util.no_state_seq.sbp package, and load the correct package by following these steps: 1. Navigate to the SDEHOME/lib (UNIX or Linux) or SDEHOME\bin (Windows) directory. 2. Rename the original version_util.spb file as version_util.seq.spb and rename the version_util.no_state_seq.spb as version_util.spb. 3. Start SQL*Plus in the directory where the files reside and connect as the SDE user. 4. Execute the following command: start version_util.spb sde

5. Ensure there are no errors after this command is executed. If you are utilizing user schema geodatabases in Oracle , you need to do this for the SDE master geodatabase and each geodatabase stored in a user's schema. When you do this for the user's geodatabase, you need to connect to SQL*Plus as the geodatabase owner and, when you execute the command, specify the geodatabase user. For example: start version_util.spd crane

Section 4 Sample scripts installed with ArcSDE for Oracle Note: This topic was updated for 9.3.1. When you install the ArcSDE component of ArcGIS Server Enterprise for the Oracle database management system (DBMS), certain structured query language (SQL) scripts are installed in the SDEHOME > tools > oracle directory. They include the following:

17

Administering ArcSDE® for Oracle®

Installing and upgrading the ArcSDE component

◦ arcsde_database_startup.sql— This script creates a startup trigger that runs whenever the Oracle instance is started. The trigger cleans up any orphaned session information that remains in the ArcSDE system tables following an instance failure. This trigger is optional because ArcSDE eventually cleans up orphaned session information during its normal operation. The startup trigger merely guarantees that orphaned session information is not present following the Oracle instance startup. Run this script as the Oracle SYS user to create the startup trigger. ◦ create_sde_oracle.sql— This script creates the SDE tablespace and ArcSDE administrator user (the SDE user) and grants the SDE user the permissions necessary to install or upgrade an ArcSDE geodatabase. When granting or revoking upgrade privileges to the SDE user, you need to remove the remark notations from the appropriate lines of the script. NOTE: If you use the Post Installation wizard when installing on Windows, the wizard creates the SDE table space and user for you. ◦ xml_lob_block_distribution.sql and xml_lob_cache_size.sql— These two scripts are used to help you configure your Oracle instance to store XML data. For details on these scripts, see Tuning an Oracle instance for XML data storage .

Section 5 Managing multiple ArcSDE component installations on the same machine About managing multiple ArcSDE component installations Note: This topic was updated for 9.3.1. NOTE: Geodatabases created with an ArcGIS Server Enterprise license on Windows only It is possible to install more than one instance of ArcSDE for different database management systems on the same machine. Some ESRI products share the same administrator commands (for example, sdeservice, sdemon). To successfully run more than one ArcSDE component installation for different DBMSs on the same machine, follow the steps below. For information on installing multiple instances of the ArcSDE component for the same type of DBMS on the same machine, see Using multiple geodatabases within a DBMS .

How to manage multiple installations 1. Before running the postinstallation setup, make sure the ArcSDE component installation you want to administer is the ESRI product listed first in your System PATH. 2. Make sure SDEHOME in your PATH is set to your current ArcSDE installation location. NOTE: Steps 1 and 2 above apply whenever administrator commands for ESRI products are run. If you do not change your System PATH, the administrator commands for the wrong product may be run. 3. Run the ArcSDE Post Installation wizard for the chosen DBMS. You can now manage the multiple ArcSDE services/installations by switching back and forth between ArcSDE environments through the System Control Panel or by using the ArcSDE administrative commands with the –H option set to the appropriate SDEHOME location.

Section 6 After ArcSDE component installation and geodatabase creation

18

Administering ArcSDE® for Oracle®

Installing and upgrading the ArcSDE component

Note: This topic was updated for 9.3.1. The installation summary topics for the ArcSDE component for DB2 , Informix , Oracle , PostgreSQL , and SQL Server linked to certain configuration and tuning topics that helped you set up your geodatabase. After the geodatabase is created, there are some other configuration changes you can make. These are covered in An overview of configuring an ArcSDE geodatabase . Once you have completed the configuration you want to do, you need to determine what type of connections you want users and applications to make to the geodatabase. You might want some users to connect using an ArcSDE service and others to connect directly, utilizing the direct connect drivers installed with client applications. Direct connections can often be faster and handle more connections to the geodatabase than an ArcSDE service. See An overview of ArcSDE geodatabase connections to get you started on setting up connections to the geodatabase.

Section 7 About upgrading ArcSDE geodatabases Note: This topic was updated for 9.3.1. The goal of upgrading an ArcSDE geodatabase is to install a newer version of the ArcSDE component, upgrade the ArcSDE and geodatabase system tables, and install updated stored procedures and locators. Installing newer versions of these components allows you to take advantage of new functionality.

Upgrading to a newer release For geodatabases on ArcSDE database servers (ArcSDE for SQL Server Express), the ArcSDE component files are in the client: either ArcGIS Desktop, ArcGIS Engine, or ArcIMS. You do not do a separate ArcSDE component installation; you install a newer version of the client or apply a service pack or patch to the client, then upgrade the geodatabase system tables, stored procedures, and locators. For information on upgrading ArcSDE geodatabases for SQL Server Express, see Upgrading geodatabases on ArcSDE database servers . Upgrades to ArcSDE geodatabases licensed through ArcGIS Server Enterprise take place independently of client software upgrades. This means it is possible to upgrade ArcSDE and not the client software. In some cases, once upgraded, your geodatabase may not be compatible with your client software. If you are unable to keep your ArcSDE and client software at the same version, be sure to check the compatibility matrix on the ESRI support site to be sure your configuration is supported. For an overview of upgrading geodatabases licensed through ArcGIS Server Enterprise, see Upgrade summary for ArcSDE geodatabases . For more complete upgrade information, read the upgrade topics in the installation guides provided on the ArcSDE component installation media.

Service packs and patches Service packs and patches are similar; they are created primarily to fix or improve functionality found in the previous release. You can download service packs and patches from the ESRI support site . You should follow the instructions provided on the support site for applying a service pack or patch. A patch can be a single fix or a set of related fixes in a specific functional area of the software. Once a patch is released, it gets incorporated into subsequent service pack releases. Patches do not add new functionality. A service pack is a collection of fixes and patches. Service packs contain new fixes and all fixes released previously for that release including previous service packs. Service packs are provided as .msp or .tar files based on specific products or platform configuration for ease of use. Service packs are generally made available via the Web and via CD distribution on request on a quarterly schedule. Service packs usually do not add new functionality; however, in rare circumstances, they may.

19

Administering ArcSDE® for Oracle®

Installing and upgrading the ArcSDE component

Applying a service pack or update patch does not update the version number in most cases. You can use the AuthorizationSummary utility to check licensing information for ArcSDE. This utility can be found in %InstallDir%\ArcGIS\Bin. (%InstallDir% is the directory in which the product is installed. For instance, on Windows, this usually would be the Program Files directory.) Applying service packs to multiple ESRI products on the same machine If you have multiple ESRI products installed on the same machine, there may be a particular order in which service packs must be applied. Be sure to read the instructions for the service pack for each product you have installed before installing any of the service packs. Applying service packs to ESRI products on different machines If ArcGIS 9.x product installations are distributed across different machines, ESRI recommends you install the service pack on the clients first. For example, if an ArcIMS server (the client software) connects to an ArcSDE geodatabase, the service pack should be installed on the ArcIMS server first, then the ArcSDE component. NOTE: Be aware that once a service pack is applied to the software, if you decide you don't want it, you can't just uninstall the service pack—you must uninstall and reinstall the software to which it was applied. DBMS patches DBMS vendors also release patches for their database products. ( Note: Informix does not usually supply patches but rather releases fixes in the next version of the software.) If you want to apply a DBMS patch 1. Be sure the prepatch version of the DBMS product you are using is working properly with your ArcSDE geodatabase. This way you know that the database was working prior to applying the patch. 2. Before applying any DBMS patches, make a full backup of the database. 3. Apply the DBMS patch. 4. Test the ArcSDE geodatabase with the patched DBMS. If a patch is applied to the DBMS and the ArcSDE component or geodatabase stops working correctly, it is possible that the patch changed something in the database that the ArcSDE component requires. If this occurs, roll back the patch and test again. If the operations that had stopped working when the patch was applied work after you go back to the final release version of the DBMS, contact your DBMS company representative about the patch and its effects on third-party applications. After the final version of a DBMS release is certified, ESRI will test DBMS patches only when there is a need to do so. After it is determined that the DBMS patches are needed, ESRI advises you to add them to your DBMS as well.

Section 8 Upgrade summary for ArcSDE geodatabases Note: This topic was updated for 9.3.1. Listed below is the general sequence of tasks to install a newer version of the ArcSDE component, upgrade the ArcSDE and geodatabase system tables, and install updated stored procedures and locators for geodatabases licensed with ArcGIS Server Enterprise. For more complete information about upgrading, consult the installation guides provided with the ArcSDE component of ArcGIS Server Enterprise. 1. Back up all databases.

20

Administering ArcSDE® for Oracle®

Installing and upgrading the ArcSDE component

2. If you are using a geodatabase in DB2, you must delete all multiversioned views before upgrading. If you do not, the geodatabase upgrade will fail. The multiversioned views can be re-created after the upgrade completes. Before deleting them, be sure to check the permissions on the views so you can regrant them after they are re-created. 3. Remove any custom functionality you may have added to the ArcSDE geodatabase system tables outside of ArcGIS such as triggers, participation in SQL Server replication, or additional indexes. The upgrade procedure cannot be aware of customizations you make to the system tables. If such customizations prevent the alteration of a system table's schema, the upgrade will fail. 4. If you are using an ArcSDE service, stop (do not pause) the service before uninstalling the ArcSDE component. If you plan to re-create the service after upgrading, go ahead and delete the service as well. 5. Uninstall the earlier version of the ArcSDE component. 6. Install the new release of the ArcSDE component. 7. For most DBMSs, elevated permissions are necessary for the administrative user to upgrade the geodatabase. These permissions are outlined in the ArcSDE installation guide for each DBMS. Be sure the administrative user is granted these permissions before proceeding. In addition, the ArcSDE administrator must have write permission to either the SDEHOME/geocode directory on the server or the directory to which the TEMP environment variable is set. This is because, during an upgrade, ArcSDE attempts to make backups of the locator files in the geocode directory. If that fails, ArcSDE attempts to write the backups to the TEMP directory. If the ArcSDE administrator does not have write permission to either of these directories, a warning is generated and new locators are loaded. 8. Make sure there are no users currently connected to the geodatabase. If there are other connections to the geodatabase when you upgrade, upgrade will fail. 9. Upgrade your geodatabase tables, stored procedures, and locators using the sdesetup –o upgrade command or, on Windows, run the repository setup portion of the Post Installation wizard. Consult the ArcSDE Administration Command Reference provided with the ArcSDE component of ArcGIS Server Enterprise for details on using the sdesetup command. Be aware that if you are using Oracle and have geodatabases in user schemas in addition to the SDE master geodatabase, you must separately run sdesetup to upgrade each of these geodatabases. The upgrade must be run by the owner of the geodatabase. 10. If you received a new license file with the latest version of the ArcGIS Server Enterprise software, update the license key in the geodatabase by running the sdesetup –o update_key command or, on Windows, run the authorization portion of the Post Installation wizard. If you have more than one geodatabase, you need to update the license file in each of the geodatabases. 11. On Windows, re-create and start the ArcSDE service (if used) using the ArcSDE service creation portion of the Post Installation wizard or the sdeservice and sdemon commands. On UNIX or Linux, start an ArcSDE service using the sdemon command. ESRI recommends that you test upgrades of the geodatabase, upgrades of your DBMS, or upgrades to both on a separate development server. After you have tested the upgraded geodatabase on the development server and everything is working as you expected, you can upgrade your production geodatabase. The following is a list of things to keep in mind when you upgrade: ◦ In some cases, older versions of the ArcSDE component software cannot be upgraded directly to newer versions. The upgrade sections of your installation guide will tell you to which versions this applies. ◦ If you are using a direct connection from the client to your ArcSDE geodatabase prior to ArcGIS 9.3, you must maintain both the ArcSDE component and the client software at the same version. However, 21

Administering ArcSDE® for Oracle®

Installing and upgrading the ArcSDE component

beginning with ArcGIS 9.3, you can make a direct connection from a 9.3 ArcGIS client to a 9.3, 9.2, 9.1, or 9.0 ArcSDE geodatabase. To do this, you must install the pre-9.3 geodatabase direct connect drivers. This installation is provided on the client installation media. ◦ DBMS vendors also release new versions of their software from time to time. Upgrades to your DBMS software take place separately from your ArcSDE geodatabase upgrades. If you plan to upgrade your DBMS, be sure the DBMS version you want to use is supported with the version of the ArcSDE component you want to use by checking the system requirements page on the ESRI support site. ◦ ArcIMS applications are not forward compatible with major new releases of ArcSDE. This means older versions of ArcIMS are not tested, certified, or supported with newer major releases of the ArcSDE component. Unlike ArcGIS Desktop, ArcIMS does not check the version of the geodatabase nor ArcSDE. It may be possible to connect to and use a newer version of the ArcSDE component; however, ESRI is not able to offer support for this configuration. ◦ There is no formal mechanism to downgrade an ArcSDE geodatabase to a previous version. As always, before running an ArcSDE component and geodatabase upgrade, perform a full database backup. If after upgrading to a newer version of ArcSDE you want to downgrade the database, restore the old database from the backup. ◦ Upgrades from beta or prerelease versions of the software are not supported.

22

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Chapter 3 Configuring an ArcSDE geodatabase Section 1 An overview of configuring an ArcSDE geodatabase Note: This topic was updated for 9.3.1. Geodatabase configuration is done to customize how data is stored in your geodatabase and how it is accessed. If you use geodatabases created from the Database Servers node in ArcCatalog, you will use predominantly default configurations. The only configuration options you can alter are the name of the geodatabase at the time of creation, the location in which the database files are created, and the initial size of the geodatabase. All these are set on the New Geodatabase dialog box. To learn how to create a new geodatabase on a database server, see Creating a new geodatabase in the help section "Creating a geodatabase." For ArcSDE geodatabases stored in Oracle, DB2, Informix, SQL Server, or PostgreSQL and licensed through ArcGIS Server Enterprise, there are a few configuration settings you might alter depending on the conditions and workflows implemented at your site. These settings can be made in the database management system (DBMS) or in ArcSDE. The sections below summarize some configuration settings. NOTE: Since there are more configuration options available to you with ArcGIS Server Enterprise geodatabases, this book ("Configuring an ArcSDE geodatabase") deals almost exclusively with settings for those geodatabases.

Initial configuration of the DBMS NOTE: Applies to geodatabases created with an ArcGIS Server Enterprise license only As mentioned in the topic About new installations of the ArcSDE component , you typically install and configure your DBMS first. Configuring the DBMS involves setting up storage spaces for the tables, indexes, and files that are stored in the database instance and providing adequate memory allocation. You should give consideration to the names, types, and locations of tables, indexes, and storage spaces you create; how large to make your backup log files; and what size to make the temporary space. As the database administrator, you know the naming conventions used at your site as well as what type of configuration your site requires. However, Recommendations to minimize disk I/O contention and DBMS initialization parameter recommendations offer some specific tips on setting up your DBMS to work more efficiently with ArcSDE. You must also decide in what language your data will be stored. If you want to set up your database to use languages other than the default language of the DBMS, you will need to configure your DBMS for that. To learn more about setting up your DBMS to use different character encoding standards, see Language support in the geodatabase .

ArcSDE configuration In general, to use an ArcSDE geodatabase, the default configuration settings are sufficient. There are exceptions to this: ◦ The settings for default table spaces for data in DB2 Since each site has unique names for the table spaces in its databases, the default dbtune file doesn't contain default table space names. You need to uncomment the lines for table space names under the

23

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

DEFAULTS configuration keyword and specify your table space names. If you do not do this, when data is loaded, it will be loaded into the DBMS default table space, which is usually small. You can set default table space names for data in Oracle too. If you do not, data will be created in the user's default table space. Whether this will have a negative impact on performance depends on the size allotted to the user default table spaces and how much data the user will load. ◦ The service name and port number, if you set up an ArcSDE service using the sdemon administration command If you want to use an ArcSDE service for some or all of the connections to your geodatabase, you need to specify the service name and port number in the services.sde file. This is only true if you have installed ArcSDE on a UNIX machine or if you want to use the sdemon command to start the service on a Windows machine. For more information on the services.sde file, see The services.sde file . NOTE: You will always use this command if running an ArcSDE service on UNIX or Linux, but on Windows, you have the option to use the Windows Services menu instead. If you use the Windows Services menu, you don't have to set the service name and port number. Other configuration setting changes you make depend on how you use the geodatabase. Some of these functions and settings are listed in the table below. What you want to do

Configuration in the geodatabase

Where to find details

Use data stored in an ArcSDE geodatabase Data tables must be registered with a row ID column Registering tables to be used with ArcGIS Desktop. that is maintained by ArcSDE. by ArcGIS Desktop Geocode

Create locators.

Locators in the geodatabase

Use ArcIMS Metadata Services.

Configure your database to use XML columns and text indexing.

XML columns in the geodatabase Configuring a database to support XML columns

Use a nondefault ArcSDE log file configuration.

Alter specific parameters in the SERVER_CONFIG Log file configuration options and DBTUNE tables.

Specify a different ArcSDE log file configuration for a specific user.

Create a user-specific LOGFILE keyword in the DBTUNE table.

Log file keywords

What you affect when you configure ArcSDE When you configure the ArcSDE geodatabase, you are affecting ◦ System tables —These tables control database storage and resource allocation and keep track of all the objects, locks, changes, versions, rules, and relationships in the geodatabase. They also store information that is important to geodatabase functionality such as object IDs and metadata. Tip ▪ You can download the ArcSDE database object model diagram (OMD). The diagram shows the ArcSDE and geodatabase system tables present in the ArcSDE geodatabase schema. The file is in PDF format, so you will need Adobe Acrobat Reader to open it. ArcSDE 9.3 OMD Depending on your implementation, some of the tables or columns in the diagram may not be present in your database. The type of DBMS you use is one factor that would affect this.

24

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

The DBTUNE and SERVER_CONFIG tables are the only system tables you can update directly. Altering the settings in these tables is done using the sdedbtune and sdeconfig commands, respectively. All other system tables should be considered read-only. ◦ User-defined objects —These include the tables and layers users add to the geodatabase. When you configure the geodatabase, you set how and where these are stored by making changes to parameter values in the DBTUNE system table. Oracle, SQL Server, and PostgreSQL DBMSs offer different geometry storage types for you to use. You can set a default geometry type for data storage, and you can specify different geometry types for specific tables or layers when they are created. This is also set in the DBTUNE table. To learn more about the DBTUNE table, see The dbtune file and the DBTUNE table . ◦ Client connections —The type of connections used (ArcSDE service or direct connections) must be configured. Optionally, how each connected client utilizes server and database resources can be configured. How resources are used by connected clients is controlled by settings in the SERVER_CONFIG system table. For more information on the SERVER_CONFIG table, see The giomgr.defs file and the SERVER_CONFIG system table . ◦ Configuration files —For some configuration changes, you will use the configuration files found in the SDEHOME/etc directory. The following table summarizes the names and uses of these files and contains links to further information on them. File name Purpose

Contains

giomgr.defs Populates the Server initialization SERVER_CONFIG repository parameters that define how table ArcSDE uses memory

When read

Altered by

When the For most ArcSDE component SERVER_CONFIG installations, you won't need table is created to alter this file. Before creation of the repository tables, edit the giomgr.defs file with a text editor. After the SERVER_CONFIG table is created, use the sdeconfig administration command to alter parameters.

dbtune.sde Controls table and layer storage, populates the DBTUNE table

services.sde Stores unique name and port number for an ArcSDE instance; only applicable if using an ArcSDE service

dbinit.sde

Configuration strings that When the ArcSDE appends to CREATE DBTUNE table is TABLE and CREATE created INDEX SQL statements

Before creation of the repository, edit the dbtune.sde file in a text editor.

Service name and port number

Edit the file directly in a text editor, then restart the ArcSDE service.

Optional file, used to avoid Environment variables that relying on environment supplement or override the variables that are set when the user's environment variables user logs in

UNIX: Each time the service is started

After the DBTUNE table is created, use sdedbtune to edit the table.

Windows: Only when the service is started from the MS-DOS prompt Each time the ArcSDE service is started

Edit the dbinit.sde file in a text editor.

(Useful mostly on UNIX platforms)

25

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Section 2 DBMS initialization parameter recommendations Note: This topic was updated for 9.3.1. NOTE: Applies to geodatabases created with an ArcGIS Server Enterprise license only Often, your default database management system (DBMS) initialization parameters will work fine with ArcSDE. However, if you have a large number of users accessing the system, there are some DBMS-specific initialization parameter settings you can make to help improve performance with ArcSDE. These recommended settings are listed in the following topics: ◦ DB2 parameters ◦ Informix parameters ◦ Oracle parameters ◦ PostgreSQL parameters ◦ SQL Server parameters

Section 3 Oracle initialization parameters Note: This topic was updated for 9.3.1. ArcSDE does not require that you change your Oracle instance from its default configuration to run. However, for larger systems, you may want to make some changes to the Oracle instance configuration. Whenever you start an Oracle instance, Oracle reads its initialization parameters from either the init.ora file or from the server parameter file, spfile.ora. Both files define the characteristics of the instance, but they are managed differently. The init.ora file is located under the ORACLE_BASE/admin//pfile directory or folder. Commonly, init.ora is a name given to the initialization file of an Oracle database instance, but for any given instance, the file is actually init.ora. For example, if the Oracle system ID (SID) is GIS, the init.ora file for this instance would be initGIS.ora. Changing parameters using the ALTER SYSTEM command will automatically be reflected in the server parameter file if the instance was started by that method. If the instance was started using an init.ora file, you will have to manually edit the file with a text editor if you want changes to system parameters to affect more than the current instance of the database. This section describes some of the parameters that control allocation of shared memory. For a detailed discussion of the Oracle initialization parameters, refer to Oracle Server Tuning for your Oracle release. ◦ OPEN_CURSORS The Oracle initialization parameter OPEN_CURSORS specifies the number of cursors a session can have open at any one time. The default value is 300. If the session attempts to open a new cursor but already has the maximum number of cursors open, the Oracle error -1000 will be returned. ArcSDE holds open frequently executed cursors to improve performance. If your Oracle OPEN_CURSORS parameter is not set high enough, you will encounter the error mentioned above. Oracle's documentation indicates that setting the parameter to a large value has no adverse effects. Therefore, you can set the value extremely large, for example, to 2,000; this effectively removes any limit on the number of open cursors from a practical standpoint but still provides a measure of protection against a rogue process attempting to consume an excessive amount of cursor resources.

26

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

If instead you want to calculate the potential number of cursors a session has open, the following formula, based on your organization's data model, can be used as a guideline: ▪ Various ArcSDE data management cursors (20) + ▪ Various anonymous PL/SQL blocks (20) + ▪ Spatial queries—potential 6 per layer + ▪ Log file queries (11) + ▪ Miscellaneous queries used when editing multiversioned tables—12 per multiversioned table or layer Therefore, an ArcMap application with 10 layers being edited in the document can potentially have 231 cursors open (20 + 20 + 60 + 11 + 120 = 231). If you find you frequently run out of cursors, you can increase the value of the OPEN_CURSORS parameter by increments of 50 or 100. NOTE: Oracle 10 g is preconfigured to generate a server alert when the number of open cursors for the instance exceeds 1,200. Since 1,200 open cursors is not an uncommon condition for the geodatabase, you may want to increase the threshold for this alert to eliminate extraneous warnings in the alert queue. One circumstance in which you might need to lower the parameter's value is when memory resources on the server running the Oracle instance do not have enough memory available for each Oracle dedicated process. Obtaining the size of dedicated process memory requirements requires prototyping the application. Several Oracle parameters and the application's behavior, such as a SQL statement, can affect process memory requirements. ◦ SESSION_CACHED_CURSORS Oracle monitors the SQL statements that are submitted for each session. If it detects the same statement has been submitted multiple times, it moves the statement to the cursor cache and keeps the cursor open for subsequent reuse. The SESSION_CACHED_CURSORS parameter controls the number of cursors allowed in the cursor cache. The default value for SESSION_CACHED_CURSORS varies by Oracle release. If your instance is not configured to cache at least 50 cursors, increase the value of this parameter to 50. ◦ UNDO_MANAGEMENT and UNDO_TABLESPACE Oracle stores multiple copies of data that is currently being modified by a user. While the transaction that modifies data is in progress, a copy of the original data is used to provide a read-consistent view of the database for other sessions. In addition, the modifying users may choose to undo work by issuing a ROLLBACK statement, or their process could crash in the middle of the transaction, requiring Oracle to undo their work in progress to restore the database to a consistent state. To support each of these scenarios, Oracle stores the preedited data in a special data structure, an undo or rollback segment. You can set the UNDO_MANAGEMENT and UNDO_TABLESPACE parameters so Oracle will automatically create and manage undo segments. To enable automatic undo management, first set UNDO_MANAGEMENT to auto. Next, set the UNDO_TABLESPACE to the name of the tablespace that will store the system-managed undo segments.

27

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Be aware that you cannot use any arbitrary tablespace for storing system-managed undo segments. You must designate the tablespace as an undo tablespace at creation time. For more information on monitoring and managing automatic undo behavior, read the Oracle Database Administrator's Guide . ◦ SESSIONS ArcSDE is configured to allow either 48 or 64 simultaneous connections by default, depending on your operating system. If you configure the SDE.SERVER_CONFIG data dictionary table to allow a larger number of connections, you may need to alter the Oracle SESSIONS parameter to accommodate the new setting. The SESSIONS parameter directly limits the total number of concurrent sessions that Oracle will allow. If the default is insufficient to support the number of ArcSDE connections you expect, increase this parameter to the number of anticipated current connections plus a minimum of 10 percent more to support internal Oracle functions. NOTE: If you use the Oracle shared server configuration, the SHARED_SERVER_SESSIONS parameter behaves like the SESSIONS parameter discussed above except that it only applies to shared server connections. All sessions—shared server and dedicated server—are limited by the more general SESSIONS parameter. ◦ PROCESSES You can also limit the maximum number of processes that Oracle can create with the PROCESSES parameter. When using the dedicated server configuration, this process roughly corresponds to the number of concurrent sessions that the database will support. If you increase the number of connections that ArcSDE will allow, ensure that the PROCESSES parameter is at least as large as the number of ArcSDE connections plus 25 for a typical set of Oracle background processes. Parameter that affects Oracle statistics ◦ OPTIMIZER_MODE Keep the default value for the Oracle parameter OPTIMIZER_MODE. For Oracle 10 g and 11 g, the default value is all_rows. This setting works best for most geodatabases and improves the overall scalability of your geodatabase. Parameters that affect memory Care must be taken when setting the initialization parameters that affect memory. Setting these parameters beyond the limits imposed by the physical memory resource of the host machine significantly degrades performance. ◦ LOG_BUFFER The log buffer is a component of the Oracle System Global Area (SGA) that holds uncommitted changes to the database in memory until Oracle background processes have an opportunity to write those changes to permanent storage on disk. Because these writes occur so frequently—at least every three seconds—the log buffer does not require much space and can be configured at less than a megabyte in size. The size of the redo log buffer is controlled by the LOG_BUFFER parameter. The default log buffer size is adequate for most geodatabases. However, for databases with a high degree of write activity, performance may be affected by multiple users attempting to access the log buffer simultaneously. Diagnosing and mitigating this condition requires advanced skills, such as monitoring latches and wait

28

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

events. For detailed information, refer to the Oracle Database Performance Tuning Guide and to the MetaLink Knowledge Base. NOTE: Setting the LOG_BUFFER to a large value to process huge loading transactions may, in fact, result in a performance reduction. Latch contention between transactions may occur if the log buffer is set too large. ◦ SHARED_POOL_SIZE The shared pool is another component of the Oracle SGA that holds both the data dictionary cache and the library cache. The data dictionary cache holds information about data objects, free space, and privileges. The library cache holds the most recently parsed SQL statements. Generally, if the shared pool is large enough to satisfy the resource requirements of the library cache, it is already large enough to hold the data dictionary cache. Beginning with the ArcGIS Server Enterprise 9.2 release, ArcSDE geodatabases can benefit from a larger shared pool than some other Oracle applications, including earlier releases of ArcSDE. ArcSDE maintains a cache of SQL statements in memory submitted by client applications. A large shared pool enables more cursors to remain open, thus reducing cursor management operations and improving performance. The size of the shared pool is controlled by the SHARED_POOL_SIZE parameter. ESRI recommends that you set the SHARED_POOL_SIZE parameter to a multiple of 16 MB to accommodate any system ESRI supports and that you set this parameter to at least 128 MB: shared_pool_size = 128,000,000

Highly active geodatabases supporting volatile utility or parcel editing systems may require the SHARED_POOL_SIZE to be set as high as 250 MB. Of the three SGA buffers, the shared pool is the most important. If the SGA is already as large as it can be given the size of your physical memory, reduce the size of the buffer cache to accommodate a larger shared pool. ◦ DB_CACHE_SIZE The buffer cache is another component of the Oracle SGA that stores the most recently used data blocks. Data blocks are the Oracle atomic unit of data transfer. Oracle reads and writes data blocks to and from the database whenever the user edits or queries it. The size of the buffer cache is controlled by the DB_CACHE_SIZE parameter. Unlike the shared pool and log buffer, there is no recommended minimum size for the buffer cache. Because your goal in sizing the buffer cache is to keep as much of the database in memory as possible, plan to allocate all remaining memory to the buffer cache after accounting for the needs of the rest of the system. To estimate this, follow these steps: ◦ Determine how much physical random access memory (RAM) your server has. ◦ Multiply this number by 0.66 to determine the target size of the SGA. ◦ Deduct the SHARED_POOL_SIZE and LOG_BUFFER to return the amount of memory available to the buffer cache. ◦ Reduce this number by 10 percent to account for Oracle's internal memory usage. ◦ Divide by the database block size to determine the DB_BLOCK_BUFFERS setting.

29

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

For example: memory available to SGA = physical RAM * 2/3 memory available to buffer cache = (memory available to SGA - (shared_pool_size + log_buffer)) * 0.9 db_block_buffers = memory available to buffer cache / db_block_size

◦ PGA_AGGREGATE_TARGET Allocate space for the private global area (PGA) of the Oracle server processes. This space is typically used as a temporary buffer for sorting and merging data during a table join. Set the WORKAREA_SIZE_POLICY to AUTO, then initially set the PGA_AGGREGATE_TARGET to the total physical RAM multiplied by 0.16. Once the application has been in use for some time, tune the PGA_AGGREGATE_TARGET according to the procedure outlined in the Oracle Performance Tuning Guide and Reference . workarea_size_policy = auto pga_aggregate_target = connect / SQL> select default_tablespace from user_users;

or SQL> connect system/ SQL> select default_tablespace from dba_users where username = ;

Obtain a list of default storage parameters for a tablespace by querying USER_TABLESPACES: SQL> connect / SQL> select * from user_tablespaces where tablespace_name = ;

To specify different tablespaces using configuration keywords, you need to uncomment some parameters under the DEFAULTS and other configuration keywords in the dbtune file and edit the associated configuration strings to specify a tablespace name. Commented lines are prefaced with a single pound sign (#). Remove this pound sign and replace the with the name of the correct tablespace. Then import the dbtune file into the DBTUNE table. Users can then specify that keyword (or accept the DEFAULTS) and the tables and indexes of the datasets they create will be stored in the tablespace you specified in the dbtune file. See The dbtune file and the DBTUNE table for specifics on editing the dbtune file and table. The following table is an alphabetic list of all the possible configuration parameters that can be used in a geodatabase in Oracle. Following that is a more in-depth explanation of the parameters grouped by their functionality, followed by a list of parameters that are specific to ArcSDE geodatabases stored in Oracle Spatial . Parameter name

Description

Values

A_INDEX_RASTER

Storage definition for the Adds table raster column index

See your Oracle documentation for CREATE INDEX parameters.

A_INDEX_ROWID

Storage definition for the Adds table object ID column index

See your Oracle documentation for CREATE INDEX parameters.

A_INDEX_SHAPE

Storage definition for the Adds table spatial column index

See your Oracle documentation for CREATE INDEX parameters.

A_INDEX_STATEID

Storage definition for the Adds table sde_state_id column index

See your Oracle documentation for CREATE INDEX parameters.

A_INDEX_USER

Defines storage for the Adds table index See your Oracle documentation for CREATE INDEX parameters.

A_INDEX_XML

Storage definition for the Adds table XML column index

See your Oracle documentation for CREATE INDEX parameters.

A_STORAGE

Defines the storage of the Adds table

See your Oracle documentation for CREATE TABLE parameters.

ATTRIBUTE_BINARY

Indicates storage type for binary attribute (nonspatial) fields)

BLOB or LONGRAW

AUX_INDEX_COMPOSITE

Raster AUX table composite column index storage definition

See your Oracle documentation for CREATE INDEX parameters.

AUX_STORAGE

Raster AUX table storage definition

See your Oracle documentation for CREATE TABLE parameters.

Notes

64

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Parameter name

Description

Values

Notes

B_INDEX_RASTER

Business table raster column index storage definition

See your Oracle documentation for CREATE INDEX parameters.

B_INDEX_ROWID

Business table object ID column index and aster rowid index R_SDE_ROWID_UK storage definition

See your Oracle documentation for CREATE INDEX parameters.

B_INDEX_SHAPE

Business table spatial column index storage definition

See your Oracle documentation for CREATE INDEX parameters.

B_INDEX_TO_DATE

Storage parameter info for creating the See your Oracle documentation for index R_sde_todate, CREATE INDEX parameters. which is used when updating the history table during an archive operation

B_INDEX_USER

Business table user index storage definition

B_INDEX_XML

Business table XML column index table See your Oracle documentation for storage definition CREATE INDEX parameters.

B_STORAGE

Business table and raster attribute table storage definition

See your Oracle documentation for CREATE TABLE parameters.

BLK_INDEX_COMPOSITE

Raster BLK table composite column index storage definition

See your Oracle documentation for CREATE INDEX parameters.

BLK_STORAGE

Raster BLK table storage definition

See your Oracle documentation for CREATE TABLE parameters.

BND_INDEX_COMPOSITE

Raster BND table composite column index storage definition

See your Oracle documentation for CREATE INDEX parameters.

BND_INDEX_ID

Raster BND table RID column index storage definition

See your Oracle documentation for CREATE INDEX parameters.

BND_STORAGE

Raster BND table storage definition

See your Oracle documentation for CREATE TABLE parameters.

COMMENT

Line used for comments

Can place any comment up to 8000 characters

COMPRESS_ROLLBACK_SEGMENT

Version compression rollback segment Name of a rollback segment (only applies to databases that are using manual undo space management)

D_INDEX_DELETED_AT

Deletes table sde_deleted_at column index storage definition

See your Oracle documentation for CREATE INDEX parameters.

D_INDEX_ STATE_ROWID

Deletes table sde_states_id and sde_deletes_row_id column index storage definition

See your Oracle documentation for CREATE INDEX parameters.

D_STORAGE

Deletes table storage definition

See your Oracle documentation for CREATE TABLE parameters.

F_INDEX_AREA

Feature table area column index storage See your Oracle documentation for definition CREATE INDEX parameters.

Binary geometry storage only

F_INDEX_FID

Feature table FID column index storage See your Oracle documentation for definition CREATE INDEX parameters.

Binary geometry storage only

F_INDEX_LEN

Feature table length column index storage definition

See your Oracle documentation for CREATE INDEX parameters.

Binary geometry storage only

F_STORAGE

Feature table storage definition

See your Oracle documentation for CREATE TABLE parameters.

Binary geometry storage only

See your Oracle documentation for CREATE INDEX parameters.

65

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Parameter name

Description

Values

GEOMETRY_STORAGE

Indicates storage data type for spatial column

ST_GEOMETRY , SDEBINARY, SDELOB, OGCWKB, or SDO_GEOMETRY

LD_INDEX_DATA_ID

SDE_LOGFILE_DATA and SDE_LOGPOOL tables' index storage definition

See your Oracle documentation for CREATE INDEX parameters.

LD_INDEX_ROWID

SDE_LOGFILE_DATA and See your Oracle documentation for SDE_LOGPOOL tables' SDE_ROWID CREATE INDEX parameters. column index storage definition

LD_STORAGE

SDE_LOGFILE_DATA and SDE_LOGPOOL_ tables' storage definition

LF_INDEXES

SDE_LOGFILES table column indexes See your Oracle documentation for storage definition CREATE INDEX parameters.

LF_STORAGE

SDE_LOGFILES table storage definition

See your Oracle documentation for CREATE TABLE parameters.

MVTABLES_MODIFIED_INDEX

MVTABLES_MODIFIED index storage definition

See your Oracle documentation for CREATE INDEX parameters.

MVTABLES_MODIFIED_TABLE

MVTABLES_MODIFIED table storage See your Oracle documentation for definition CREATE TABLE parameters.

RAS_INDEX_ID

Raster RAS table RID index storage definition

See your Oracle documentation for CREATE INDEX parameters.

RAS_STORAGE

Raster RAS table storage definition

See your Oracle documentation for CREATE TABLE parameters.

RASTER_STORAGE

Indicates the storage type used for raster BLOB , LONGRAW, or data SDO_GEORASTER

RDT_INDEX_COMPOSITE

Contains the storage information for the See your Oracle documentation for composite index that is created on the CREATE INDEX parameters. SDO_GEORASTER blocks table

Notes

See your Oracle documentation for CREATE TABLE parameters.

Oracle Spatial only

The index is named SDE_RDT__PK, where N is the rastercolumn_id value of the raster column. RDT_STORAGE

Contains the storage information for the See your Oracle documentation for SDO_GEORASTER blocks table CREATE TABLE parameters.

Oracle Spatial only

The blocks table is named sde_rdt_, where N is the rastercolumn_id value for the raster column. S_INDEX_ALL

Spatial index table first index storage definition when using binary geometry storage

See your Oracle documentation for CREATE INDEX parameters.

Binary geometry storage only

S_INDEX_SP_FID

Spatial index table second index storage See your Oracle documentation for definition CREATE INDEX parameters.

Binary geometry storage only

S_STORAGE

Represents the spatial index storage definition

SDO_COMMIT_INTERVAL

Number of rows inserted into the spatial 1000 index table between each database Refer to your Oracle Spatial Users COMMIT. Guide for information about all these This becomes a parameter in the values. CREATE INDEX statement.

See your Oracle documentation for CREATE TABLE parameters. Oracle Spatial only

66

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Parameter name

Description

SDO_DIMNAME_1

The name of each dimension for Oracle The dimension name Spatial geometry types; corresponding Refer to your Oracle Spatial Users values are: Guide for information about all these 1=X values.

SDO_DIMNAME_2 SDO_DIMNAME_3 SDO_DIMNAME_4

Values

Notes Oracle Spatial only

2=Y 3=Z 4=M

SDO_INDEX_SHAPE

The Oracle Spatial geometry types spatial index storage parameters

Various spatial index storage parameters, including and sdo_indx_dims=# (default is 2 ), which specifies how many dimensions should be indexed with an R-tree spatial index

Oracle Spatial only

Refer to your Oracle Spatial Users Guide for information about all these values. SDO_LB_1 SDO_LB_2 SDO_LB_3 SDO_LB_4

SDO_SRID

SDO_TOLERANCE_1 SDO_TOLERANCE_2 SDO_TOLERANCE_3 SDO_TOLERANCE_4

Lower dimension boundary for Oracle a value less than the corresponding Spatial geometry type; units specified in SDO_UB values coordinate system of the data Refer to your Oracle Spatial Users Default values based on extent of data to Guide for information about all these be loaded; for data with geodetic SRID, values. SDO_LB_1 must be 180, and SDO_LB_2 must be 90 Oracle Spatial coordinate reference identifier assigned to the SDO_GEOMETRY column

◦ The distance two ordinates can be apart in the given dimension and still be considered the same ◦ Used by Oracle Spatial functions

Oracle Spatial only

If a coordinate reference system is Oracle provided during the creation of a feature Spatial only class, the SDO_SRID parameter is ignored and not written to the Oracle USER_SDO_GEOM_METADATA view. A value greater than 0 Refer to your Oracle Spatial Users Guide for information about all these values.

Oracle Spatial only

◦ Must be greater than zero ◦ For geodetic data, units are meters; otherwise, units are specified in coordinate system of the data SDO_UB_1 SDO_UB_2

◦ Upper dimension boundary for Oracle Spatial geometry type

A value greater than the corresponding SDO_LB values

SDO_UB_3

◦ Used by Oracle Spatial functions

SDO_UB_4

◦ Must be greater than zero

Refer to your Oracle Spatial Users Guide for information about all these values.

◦ For geodetic data, units are degrees; otherwise, units are specified in coordinate system of the data

Oracle Spatial only

◦ Default value based on extent of data to be loaded SESSION_INDEX

ArcSDE session-based and stand-alone log file indexes storage definition

See your Oracle documentation for CREATE INDEX parameters.

SESSION_STORAGE

ArcSDE session-based and stand-alone log file tables storage definition

See your Oracle documentation for CREATE TABLE parameters.

67

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Parameter name

Description

Values

ST_GEOM_LOB_STORAGE

Controls the storage of the SHAPE.POINTS column for an ST_Geometry object

See your Oracle documentation for ST_Geometry CREATE TABLE and the LOB storage storage only; clause parameters. for more information on storing LOBs, see BLOB data storage in Oracle geodatabases

ST_INDEX_PARTITION_LOCAL

Specifies if a partitioned table's sde.st_spatial_index is created as a global or local index

True or False

FALSE indicates the st_spatial_index will be created as a global index; TRUE specifies the spatial index will be created as a local index. STATES_INDEX

STATES table storage definition

See your Oracle documentation for CREATE INDEX parameters.

STATES_LINEAGES_TABLE

STATE_LINEAGES table storage definition

See your Oracle documentation for CREATE TABLE parameters.

STATES_TABLE

STATES table storage definition

See your Oracle documentation for CREATE TABLE parameters.

UI_NETWORK_TEXT

User interface parameter, which Description up to 8000 characters indicates associated configuration keyword will appear in the ArcGIS user interface; contains description of network configuration

UI_TERRAIN_TEXT

User interface parameter, which Description up to 8000 characters indicates associated configuration keyword will appear in the ArcGIS user interface; contains description of terrain configuration

UI_TEXT

User interface parameter, which Description up to 8000 characters indicates associated configuration keyword will appear in the ArcGIS user interface; contains description of associated noncomposite configuration keyword

UI_TOPOLOGY_TEXT

User interface parameter, which Description up to 8000 characters indicates associated configuration keyword will appear in the ArcGIS user interface; contains description of topoology configuration

UNICODE_STRING

Determines whether Unicode text types TRUE or FALSE will be used or not; If set to TRUE, character fields will be stored in UNICODE compliant data types.

Notes

Only applies to partitioned business tables containing ST_Geometry columns

For example, if the UNICODE_STRING parameter is set to FALSE, a string data type would be VARCHAR2. If UNICODE_STRING is set to TRUE, the data type of the field would be NVARCHAR2. VERSIONS_INDEX

VERSIONS table index storage definition

See your Oracle documentation for CREATE INDEX parameters.

68

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Parameter name

Description

Values

Notes

VERSIONS_TABLE

VERSIONS table storage definition

See your Oracle documentation for CREATE TABLE parameters.

XML_DOC_INDEX

Storage clause for xmldoc_pk and xml_doc_ix indexes on the sde_xml_doc table

See your Oracle documentation for CREATE INDEX parameters.

XML_DOC_LOB_STORAGE

Storage and access information for See your Oracle documentation for LOB For more XML documents in the xml_doc column storage clause parameters. information of the sde_xml_doc table on storing LOBs, see BLOB data storage in Oracle geodatabases .

XML_DOC_MODE

Storage type for XML documents

COMPRESSED or UNCOMPRESSED

XML_DOC_STORAGE

Storage clause for sde_xml_doc table

See your Oracle documentation for CREATE TABLE parameters.

XML_DOC_TEXT_TYPE

Data type for document text column

BLOB or LONGRAW

XML_DOC_UNCOMPRESSED_TYPE

When the XML_DOC_MODE parameter is set to UNCOMPRESSED, the XML_DOC_UNCOMPRESSED_TYPE parameter determines the storage format for XML documents

Since XML_DOC_MODE is set to COMPRESSED by default, the XML_DOC_UNCOMPRESSED_TYPE parameter is not present by default.

XML_DOC_VAL_LOB_STORAGE

Storage and access information for the XML document content in the xml_doc_val column of the sde_xml_doc table

See your Oracle documentation for LOB For more storage clause parameters. information on storing LOBs, see BLOB data storage in Oracle geodatabases .

XML_IDX_INDEX_DOUBLE

Storage clause for the xmlix_db index on the double_tag column of the sde_xml_idx table

See your Oracle documentation for CREATE INDEX parameters.

XML_IDX_INDEX_ID

Storage clause for the xmlix_id index on the ID column of the xml_idx table

See your Oracle documentation for CREATE INDEX parameters.

XML_IDX_INDEX_PK

Storage clause for xmlix_pk index See your Oracle documentation for on the xml_key_column identity column CREATE INDEX parameters. of the sde_xml_idx table

XML_IDX_INDEX_STRING

Storage clause for xmlix_st index on See your Oracle documentation for the string_tag column of the CREATE INDEX parameters. sde_xml_idx table

XML_IDX_INDEX_TAG

Storage clause for the xmlix_tg index on the tag_id column of the sde_xml_idx table

See your Oracle documentation for CREATE INDEX parameters.

XML_IDX_INDEX_TEXT

XML index creation parameters (see Oracle Text Reference )

See your Oracle documentation for CREATE INDEX parameters.

XML_IDX_STORAGE

Storage clause for sde_xml_idx table (the index table of an XML column)

See your Oracle documentation for CREATE TABLE parameters.

Obsolete after ArcSDE release 9.0

Possible values: CLOB or NCLOB

69

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Parameter name

Description

Values

XML_IDX_TEXT_TAG_STORAGE

Storage and access information for the contents of the text_tag column in the sde_xml_idx table (the index table of an XML column); if no value is specified (default) or if DISABLE STORAGE IN ROW is not specified, this LOB data is stored in line.

, ENABLE STORAGE IN ROW, or DISABLE STORAGE IN ROW

XML_IDX_TEXT_UPDATE_MEMORY The amount of memory to use when building and updating the text index, such as "2M" to allocate 2 MB

An integer, greater than 0 but less than the amount of available RAM given in MB (indicated with M); consult your Oracle documentation for recommended settings.

XML_IDX_TEXT_UPDATE_METHOD Oracle Text index change tracking method:

NONE , BUFFERED, or IMMEDIATE

Notes

◦ NONE—Manual update by running Oracle Text package (default) ◦ BUFFERED—ArcSDE updates when stream is closed ◦ IMMEDIATE—ArcSDE updates on row insert or update XML_INDEX_TAGS_INDEX

Storage clause for xml_indextags_pk index of the sde_xml_indexes table

See your Oracle documentation for CREATE INDEX parameters.

XML_INDEX_TAGS_TABLE

Storage clause for sde_xml_index_tags table and the xml_indextags_ix1 and xml_indextags_ix2 indexes on the tag_name and tag_alias columns, respectively

See your Oracle documentation for CREATE TABLE parameters.

NOTE: For the XML parameters, refers to the xml_column_id associated with a specific XML column.

Functional descriptions of parameters ◦ Business table and index storage parameters A business table is any Oracle table created by an ArcSDE client, the sdetable administration command, or the ArcSDE C application programming interface (API) SE_table_create function. Use the DBTUNE table's B_STORAGE parameter to define the storage configuration of a business table. Five index storage parameters exist to support the creation of business table indexes. The B_INDEX_USER parameter holds the storage configuration for user-defined indexes created with the C API function SE_table_create_index and the create_index operation of the sdetable command. The B_INDEX_ROWID parameter holds the storage configuration of the index that ArcSDE creates on a register table's object ID column, commonly referred to as the ROWID or OBJECTID. NOTE: ArcSDE registers all tables that it creates. Tables not created by ArcSDE can also be registered with the sdetable or sdelayer commands. The TABLE_REGISTRY system table maintains a list of the currently registered tables. The B_INDEX_SHAPE parameter holds the storage configuration of the spatial column index that ArcSDE creates when a spatial column is added to a business table. This index is created by the

70

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

ArcSDE C API function SE_layer_create. This function is called by ArcGIS when it creates a feature class and by the add operation of the sdelayer command. The B_INDEX_RASTER parameter holds the storage configuration of the raster column index that ArcSDE creates when a raster column is added to a business table. This index is created by the ArcSDE C API function SE_rastercolumn_create. This function is called by ArcGIS when it creates a feature class and by the add, copy, and import operations of the sderaster command. The B_INDEX_TO_DATE parameter specifies the storage for the index R_sde_todate. This index is created when archiving is enabled on a business table, and is used when updating the history table during an archive operation. ◦ Adds and deletes tables storage parameters Registering a business table as versioned allows multiple users to maintain and edit an object. At appropriate intervals, users merge the changes they have made with the changes made by other users and reconcile any conflicts that arise when the same rows are modified. ArcSDE creates two tables—the adds table and the deletes table—for each table that is registered as versioned. Adds table parameters The A_STORAGE parameter maintains the storage configuration of the adds table. Four other storage parameters hold the storage configuration of the indexes of the adds table. The adds table is named A, where is the registration ID listed in the TABLE_REGISTRY system table. For instance, if the business table ROADS is listed with a registration ID of 10, ArcSDE creates the adds table as A10. The A_INDEX_RASTER parameter specifies the storage configurationof the index that is created on a raster column in the adds table. The index is named SDE_RIX__A. is the raster column ID. The A_INDEX_ROWID parameter holds the storage configuration of the index that ArcSDE creates on the multiversioned object ID column, also referred to as the ROWID. The adds table ROWID index is named A_ROWID_IX1, where is the business table's registration ID with which the adds table is associated. The A_INDEX_STATEID parameter holds the storage configuration of the index that ArcSDE creates on the adds table's SDE_STATE_ID column. The SDE_STATE_ID column index is called A_STATE_IX2, where is the business table's registration ID with which the adds table is associated. The A_INDEX_SHAPE parameter holds the storage configuration of the index that ArcSDE creates on the adds table's spatial column. If the business table contains a spatial column, the column and the index on it are duplicated in the adds table. The adds table's spatial column index is called A_IX1_A, where is the layer ID of the feature class as it is listed in the LAYERS table. The A_INDEX_USER parameter holds the storage configuration of user-defined indexes that ArcSDE creates on the adds table. The user-defined indexes on the business tables are duplicated on the adds table. Deletes table parameters The D_STORAGE parameter holds the storage configuration of the deletes table. Two other storage parameters hold the storage configuration of the indexes that ArcSDE creates on the deletes table. The deletes table is named D, where is the registration ID listed in the TABLE_REGISTRY system table. For instance, if the business table ROADS is listed with a registration ID of 10, ArcSDE creates the deletes table as D10. The D_INDEX_STATE_ROWID parameter holds the storage configuration of the D_IDX1 index that ArcSDE creates on the deletes table's SDE_STATE_ID and SDE_DELETES_ROW_ID columns.

71

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

The D_INDEX_DELETED_AT parameter holds the storage configuration of the D_IDX2 index that ArcSDE creates on the deletes table's SDE_DELETED_AT column. For more information on the structure of adds and deletes tables and how they are used, see Versioned tables in a geodatabase in Oracle . ◦ Spatial index and feature tables parameters A feature class created with ST_Geometry storage adds a spatial index table to the Oracle database. This spatial index table is named S_IDX$, where is the geometry index value. This table is an Oracle Indexed Organized Table (IOT). If you create partitioned business tables that contain an ST_Geometry column, you will also want the spatial index to be partitioned. There are two types of partitioning methods: global and local. By default, global partitioned indexes are created on partitioned business tables. To create a local partitioned index instead, you must add the keyword LOCAL to the end of the CREATE INDEX statement. To enable ArcGIS to add LOCAL to the end of the CREATE INDEX statement for the spatial index, set the parameter ST_INDEX_PARTITION_LOCAL to TRUE under the DEFAULTS keyword. If the business table with the ST_Geometry column is not partitioned, however, and you set ST_INDEX_PARTITION_LOCAL to TRUE, you will get the following error message: ORA-14016: underlying table of a LOCAL partitioned index must be partitioned

A feature class created with an ArcSDE compressed binary storage (LONGRAW or BLOB data type) format adds two tables to the Oracle database—the feature table and the spatial index table. The spatial index table is created as S_, where is the layer ID of the spatial index table's feature class as found in the LAYERS table. Three indexes are created on the feature table, and two indexes are created on the spatial index table. Configuration parameters that apply to spatial indexes usually begin with S_. The storage parameters for these tables and indexes follow the same pattern as the B_STORAGE and B_INDEX_* storage parameters of the business table. The S_STORAGE parameter holds the Oracle CREATE TABLE storage configuration of the spatial index table and its indexes for both ST_Geometry and binary storage. The S_INDEX_ALL parameter only applies to binary storage and holds the Oracle CREATE INDEX storage configuration of the spatial table's first index. The spatial index table is created as S__IX1, where is the layer ID of the index's feature class found in the LAYERS table. The S_INDEX_SP_FID parameter holds the Oracle CREATE INDEX storage configuration of the spatial table's second index if binary storage was used for the feature class. The spatial index table is created as S__IX2, where is the layer ID of the index's feature class found in the LAYERS table. Feature class parameters only apply when using binary storage. These parameters begin with F_; The F_STORAGE parameter holds the Oracle CREATE TABLE storage configuration string of the feature table. The feature table is created as F_, where is the layer ID of the table's feature class as found in the LAYERS table. The F_INDEX_FID parameter holds the Oracle CREATE INDEX storage configuration string of the feature table's spatial column index. The spatial column is created as F_UK1, where is the layer ID of the index's feature class as found in the LAYERS table. The F_INDEX_AREA parameter holds the Oracle CREATE INDEX storage configuration of the feature table's area column index. The spatial column is created as F_AREA_IX2, where is the layer ID of the index's feature class as found in the LAYERS table.

72

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

The F_INDEX_LEN parameter holds the Oracle CREATE INDEX storage configuration of the feature table's length column index. The spatial column is created as F_LEN_IX3, where is the layer ID of the index's feature class as found in the LAYERS table. For information on the structure F and S tables of binary feature classes in Oracle, see Feature classes in a geodatabase in Oracle in the "Geodatabase data storage and schema" section of the help. For information on the available options for feature class geometry storage, see the section in this topic "Geometry storage parameter", and the topic About geometry storage types . ◦ Raster table and index storage parameters A raster column added to a business table is actually a foreign key reference to raster data stored in a schema consisting of four tables and five supporting indexes. The raster table parameters define configuration for the raster tables and indexes. The RAS_STORAGE parameter holds the Oracle CREATE TABLE storage configuration of the RAS table. The RAS_INDEX_ID parameter holds the Oracle CREATE INDEX storage configuration of the RAS table index. The BND_STORAGE parameter holds the Oracle CREATE TABLE storage configuration of the BND table. The BND_INDEX_COMPOSITE parameter holds the Oracle CREATE INDEX storage configuration of the BND table's composite column index. The BND_INDEX_ID storage holds the Oracle CREATE INDEX storage configuration of the BND table's row ID (RID) column index. The AUX_STORAGE parameter holds the Oracle CREATE TABLE storage configuration of the AUX table. The AUX_INDEX_COMPOSITE parameter holds the Oracle CREATE INDEX storage configuration of the AUX table's index. The BLK_STORAGE parameter holds the Oracle CREATE TABLE storage configuration of the BLK table. The BLK_INDEX_COMPOSITE parameter holds the Oracle CREATE TABLE storage configuration of the BLK table's index. The RASTER_STORAGE parameter defines what data type is used to store raster data. ArcSDE provides three raster storage formats for Oracle. The RASTER_STORAGE parameter indicates which geometry storage method is to be used. The RASTER_STORAGE parameter has the following values: ▪ ArcSDE raster stored as a BLOB data type—This is the default raster storage method of ArcSDE for Oracle. Set the RASTER_STORAGE parameter to BLOB if you want to store your raster data in this format. If you want to make this format the default, set the RASTER_STORAGE parameter to BLOB in the DEFAULTS configuration keyword. If the RASTER_STORAGE parameter is not set, the BLOB format is assumed. ▪ ArcSDE raster stored in LONGRAW data type Set the RASTER_STORAGE parameter to LONGRAW if you want to store your raster data in this format. NOTE: It is not recommended you use LONGRAW storage because Oracle has deprecated support for this data type beginning with release 11g.

73

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

▪ Oracle GeoRaster type—This object relational type extends the database model to include an SDO_GEORASTER type in the Oracle DBMS. Set the RASTER_STORAGE parameter to SDO_GEORASTER if you want to store your spatial raster data in this format. If you want most of the raster columns in your database to use the same raster storage format, set the RASTER_STORAGE parameter once in the DEFAULTS configuration keyword. For example, to change the default RASTER_STORAGE from BLOB to SDO_GEORASTER, the following change is made: ## DEFAULTS RASTER_STORAGE "SDO_GEORASTER" END

The RASTER_STORAGE parameter supersedes the RASTER_BINARY_TYPE, which continues to work but is no longer supported. NOTE: If you specify SDO_GEORASTER for the RASTER_STORAGE parameter, you cannot set the GEOMETRY_STORAGE to SDO_GEOMETRY or ST_GEOMETRY. For more information on raster storage in the geodatabase, see Raster datasets and raster catalogs in a geodatabase stored in Oracle in the "Geodatabase data storage and schema" section of the help. There is an additional type of raster table—the raster attribute table. These tables store attribute values based on cell values in the raster. The B_STORAGE parameter defines the storage of these tables. If you need to define a different storage location for these tables than you do for other feature class business tables, be sure to create a raster keyword you can use when creating raster datasets and raster catalogs that specifies different storage information for the raster attribute tables. To learn more about raster attribute tables, see Raster dataset attribute tables in the "Image and raster data management" section of the help. To learn how to create custom configuration keywords, see DBTUNE configuration keywords . ◦ Geometry storage parameters ArcSDE for Oracle provides five spatial data storage formats. The GEOMETRY_STORAGE parameter indicates which geometry storage method is to be used. You should set the GEOMETRY_STORAGE parameter in the DEFAULTS configuration keyword to reflect the geometry storage type with which most of your feature classes will be created. The GEOMETRY_STORAGE parameter has the following possible values: ▪ ST_Geometry for Oracle—This type extends the database to include an ST_GEOMETRY data type. Set the GEOMETRY_STORAGE parameter to ST_GEOMETRY if you want to store your spatial data in this format. (Beginning with ArcSDE 9.3, if the GEOMETRY_STORAGE parameter is not set, ST_GEOMETRY format is assumed.) ▪ ArcSDE compressed binary stored as a BLOB data type—This data type can be replicated through Oracle Advanced Replication. Set the GEOMETRY_STORAGE parameter to SDELOB if you want to store your spatial data in this format. If you want to make this format the default, set the GEOMETRY_STORAGE parameter to SDELOB in the DEFAULTS configuration keyword.

74

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

▪ ArcSDE compressed binary—Set the GEOMETRY_STORAGE parameter to SDEBINARY if you want to store your spatial data in compressed binary format stored as a LONG RAW. NOTE: Oracle has deprecated the LONG RAW storage type. For this reason, it is recommended you not use SDEBINARY storage for new feature classes. To migrate existing feature classes from LONG RAW to BLOB or ST_GEOMETRY, see Migrating Oracle data from one storage type to another in the "Geodatabase data storage and schema" section of the help. ▪ Oracle Spatial geometry type—This object relational type extends the database model to include an SDO_GEOMETRY type in the Oracle DBMS. Set the GEOMETRY_STORAGE parameter to SDO_GEOMETRY if you want to store your spatial data in this format. If you want to make this format the default, set the GEOMETRY_STORAGE parameter to SDO_GEOMETRY in the DEFAULTS configuration keyword. ▪ OGC well-known binary (WKB) geometry type—This type provides a portable representation of a geometry as a contiguous stream of bytes. The OGCWKB representation supports only simple 2D geometries. Set the GEOMETRY_STORAGE parameter to OGCWKB if you want to store your spatial data in this format. If you want to make this format the default, set the GEOMETRY_STORAGE parameter to OGCWKB in the DEFAULTS configuration keyword. See About geometry storage types for more information on geometry storage types in Oracle. NOTE: The ArcSDE for Oracle Windows installation includes several versions of the dbtune file; each specifies a different geometry storage in the DEFAULTS keyword. If you are performing a new installation of ArcSDE for Oracle (not upgrading the database), you can use one of the alternate versions of the file to populate your DBTUNE table during the postinstallation setup if you want your default geometry storage to be a type other than ST_GEOMETRY. ◦ XML parameters NOTE: If you do not use XML columns and XML documents in your geodatabase, you don't need to configure these parameters. An XML column may have two text indexes associated with it: one for the XML document table and one for the XML index table. To successfully create an XML column, the XML_IDX_INDEX_TEXT parameter must have an appropriate value. This value is used in the PARAMETERS clause when creating the XML column's context text indexes. An appropriate value for the XML_IDX_INDEX_TEXT parameter is not the same as the values that are used for other DBTUNE parameters used to create other types of indexes. The value in the PARAMETERS clause controls the storage parameters for the text indexes, the language of linguistic analysis for indexing and searching text in the XML documents, the schedule with which the text indexes are updated, and other settings that are specific to text indexes. X ML documents are stored in as large objects (LOBs) in the XML document table in the XML_DOC and XML_DOC_VAL columns and in the XML index table in the TEXT_TAG column. It is important to configure these columns accurately to achieve the best possible search performance.

75

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

LOBs are stored in line if the LOB data is stored in the same block as the rest of the data in the row. However, in-line storage is only possible if the LOB data is less than 4 KB in size. With out-of-line storage, the data is stored in the LOB segment and only the LOB locator is stored with the rest of the data in the row. You can specify whether LOB data associated with an XML column is stored in line or out of line using the ArcSDE DBTUNE parameters XML_DOC_LOB_STORAGE and XML_DOC_VAL_LOB_STORAGE and XML_IDX_TEXT_TAG_STORAGE. Append the value "DISABLE STORAGE IN ROW" to store the data out of line, or "ENABLE STORAGE IN ROW" to store the data in line. When LOB data is stored out of line for an XML column, by default, ArcSDE places that data in the same tablespace as the XML document table. The LOB data may be moved to a different tablespace than the one containing the XML document table. A typical XML document that contains metadata describing a GIS resource will be greater than 4 KB in size. Tests show XML columns associated with ArcIMS Metadata Services perform best when the LOB data is stored out of line in a separate tablespace from the XML document table. However, a metadata service may contain gazetteer data instead of typical metadata XML documents. Gazetteer data is very small, typically less than 100 bytes in size. Metadata services containing gazetteer data will perform best when the LOB data is stored in line. See Configuring an Oracle database to support XML columns for information on using XML columns in your geodatabase. ◦ Log file parameters Log file tables are used by ArcSDE to maintain sets of selected records. Log file parameters affect log file data tables and indexes. They begin with the letter L or SESSION. The parameters are as follows: LF_STORAGE defines the configuration for the LOGFILES table. LF_INDEXES configures creation of indexes logfiles_pk and logfiles_uk on the LOGFILES table. LD_STORAGE defines configuration for the LOGFILE_DATA and LOGPOOL_ tables. LD_INDEX_ROWID configures creation of the index LOGFILE_DATA_idx1 on the LOGFILE_DATA table and the index LOGPOOL__idx1 on the LOGPOOL_ pools table. LD_INDEX_DATA_ID configures the creation of the LOGFILE_DATA_idx2 index on the LOGFILE_DATA table and of the LOGPOOL__idx1 index on the LOGPOOL_. SESSION_STORAGE defines configuration for the LOGDATA__ stand-alone log table and SESSION_ session table. SESSION_INDEX configures the creation of the LOGDATA____idx1 index for the stand-alone log table and the LOGSESSION__idx1 index on the session table. SESSION_TEMP_TABLE isn't used in Oracle databases. For more information on how log file tables are used in the geodatabase, see Log file configuration options . ◦ User interface parameters User interface parameters begin with UI and indicate whether or not their associated configuration keyword will be available through the ArcGIS user interface. UI_TEXT is used for noncomposite configuration keywords.

76

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

UI_TOPOLOGY_TEXT is used for topology keywords. UI_TERRAIN_TEXT is used for terrain keywords. UI_NETWORK_TEXT is used for network keywords. See Making configuration keywords available in ArcGIS for more information on how to use UI parameters. ◦ COMPRESS_ROLLBACK_SEGMENT parameter Periodically compressing the versioned database’s state tree is a required maintenance procedure. The transactions of the compress operation tend to be large; if you are using the Oracle manual undo method, ESRI recommends that you create a separate, large rollback segment to contain the changes. The COMPRESS_ROLLBACK_SEGMENT storage parameter stores the name of a rollback segment that you have created for this purpose. Add the COMPRESS_ROLLBACK_SEGMENT storage parameter to the DEFAULTS configuration keyword. Beginning with Oracle 10 g , Oracle does not recommend the use of the manual undo method. See the documentation provided with your Oracle 10 g installation for details. ◦ ATTRIBUTE_BINARY parameter ArcSDE defines attribute columns used to store binary data as LONGRAW or as BLOB. The default and recommended setting is BLOB. If the storage parameter is not set in the DEFAULTS configuration keyword when a dbtune file is imported by the sdedbtune administration tool, ArcSDE inserts the ATTRIBUTE_BINARY storage parameter under the DEFAULTS configuration keyword with a configuration string set to BLOB. NOTE: Prior to ArcSDE 9.2, LONGRAW was the default value for the ATTRIBUTE_BINARY parameter. When you upgrade an existing ArcSDE geodatabase to a 9.2 or later release, this value is not changed in the DBTUNE table. To make BLOB the default data type for binary attribute columns, you need to manually alter the DEFAULTS ATTRIBUTE_BINARY parameter to BLOB. After you make this change, new feature classes created with the DEFAULTS keyword will use BLOB for binary columns. To migrate the attribute columns in existing data from LONG RAW to BLOB, see Migrating Oracle data from one storage type to another in the "Geodatabase data storage and schema" section of the help. If you are using feature class representations, you must create the feature class with a configuration keyword that has the ATTRIBUTE_BINARY parameter set to BLOB. If you have your DEFAULTS ATTRIBUTE_BINARY value set to LONGRAW, you will need to create another configuration keyword users can specify when they create feature classes that will contain representation classes. For example, you could add the following configuration keyword REPRESENTATIONS as follows: ##REPRESENTATIONS ATTRIBUTE_BINARY BLOB UI_TEXT "Configuration keyword used to create feature classes containing representation classes" END

For more information on creating custom keywords, see DBTUNE configuration keywords . If a feature class is created with a configuration keyword that contains an ATTRIBUTE_BINARY parameter set to LONGRAW and multiple representations are created, an error message will be returned:

77

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Unable to create the representation. Underlying DBMS error.

This happens because each time a new representation class is added, two new fields are added to the business table of the feature class—one LONGRAW and one BLOB. Tables in Oracle cannot contain more than one LONGRAW field, so when the second LONGRAW field is added, it fails. ◦ UNICODE_STRING parameter The UNICODE_STRING parameter specifies whether or not text columns will be stored as VARCHAR2 (nonUnicode) or NVARCHAR2 (Unicode) data types. For a discussion of Unicode data, see An overview of Unicode in the "Defining the properties of a geodatabase" section of the help. ◦ Comments You can add a COMMENT parameter in the dbtune.sde file if you like by adding a line beginning with a single pound sign (#). You might do this if you create your own custom keywords and want to add comments on how or when the keyword should be used. For example, you could add a comment to a user's log file keyword: #COMMENT "This keyword is used by ArcSDE to create log file tables for all users logged in as editor"

See DBTUNE configuration keywords for information on adding custom keywords.

Configuration parameters specific to geodatabases in Oracle Spatial Oracle Spatial feature classes are ArcSDE feature classes with Oracle's SDO_GEOMETRY data type to store feature geometry in a column in the business table. Many of the storage parameters used for ArcSDE compressed binary feature classes apply to Oracle Spatial feature classes. Also, some storage parameters exist solely to establish how Oracle Spatial feature classes are stored, indexed, and accessed. For a description of Oracle Spatial, consult the Oracle Spatial User's Guide and Reference . ◦ Creating new business tables ArcSDE uses the B_STORAGE, B_INDEX_ROWID, and B_INDEX_USER storage parameters to store the business table and the nonspatial indexes on the business table. ◦ Creating Oracle Spatial metadata for new feature classes The database view USER_SDO_GEOM_METADATA is part of Oracle Spatial, not ArcSDE. It contains metadata about SDO_GEOMETRY columns in existing tables owned by the user. Each user has its own USER_SDO_GEOM_METADATA view. To be indexed and queried, the owner of the table must record metadata for each SDO_GEOMETRY column in USER_SDO_GEOM_METADATA. The ArcSDE clients that create a feature class will choose the metadata for the feature class. Often, these clients accept a configuration keyword corresponding to a parameter group in the DBTUNE table. The storage parameters that control the metadata for new Oracle Spatial feature classes are the following: SDO_DIMNAME_ SDO_LB_ SDO_UB_ SDO_TOLERANCE_ SDO_SRID

78

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

NOTE: If a coordinate reference system is provided during the creation of a feature class, the SDO_SRID parameter is ignored and not written to the USER_SDO_GEOM_METADATA view. Oracle Spatial permits feature geometries of two, three, or four dimensions in the combinations x/y, x/y/ z, x/y/z (measure), or x/y/z/m. Through these storage parameters, ArcSDE allows you to specify metadata for each dimension. The in some parameter names should be replaced by one of the digits 1, 2, 3, or 4, corresponding to the dimension number. If you do not supply these storage parameters, the ArcSDE client application that creates the feature class will determine the name, upper and lower bound (extent), and tolerance of each dimension. ◦ Creating a spatial index The DBTUNE parameter SDO_INDEX_SHAPE determines how Oracle Spatial creates the spatial index. ArcSDE appends the contents of this parameter (the configuration string) to the CREATE INDEX statement before submitting the statement to Oracle. The configuration string is inserted into the SQL statement after the PARAMETERS keyword. For example: CREATE INDEX MY_SP_INDEX ON MY_SP_TABLE(SHAPE) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS ( );

The configuration string is a quoted string containing a list of parameter = value elements. There are many parameters that you can specify in the configuration string. To understand the Oracle Spatial index parameters and how they interact, read the applicable sections of the Oracle Spatial User's Guide and Reference . Notice the differences between the physical storage parameters in the spatial index configuration string and in a business table configuration string (as specified in B_STORAGE). One difference is due to the way Oracle expects these parameters to appear in SQL statements. The Oracle statements are formatted differently, so the configuration strings are formatted differently. Also, not every physical storage parameter used for creating tables is available for creating spatial indexes. B_STORAGE

"TABLESPACE ORSPBIZ PCTFREE 10 INITRANS 4 STORAGE(INITIAL 512000)"

SDO_INDEX_SHAPE

"tablespace=ORSPIDX initial=512000"

◦ Verifying polygon rotation Both ArcSDE and Oracle Spatial expect that exterior polygon boundaries are stored in counterclockwise rotation and that inner boundaries are stored clockwise. If the rotation polygon boundary is not stored with this rotation, the polygon will fail the ArcSDE topographic validation test and will not be sent to the ArcSDE client. ◦ Sample DBTUNE parameter groups for Oracle Spatial feature classes This section presents DBTUNE parameter groups that apply to several common scenarios. These samples emphasize the storage parameters for Oracle Spatial feature classes. When designing your own parameter groups, you may want to add parameters to support other needs, such as geometric networks or log files. You could also satisfy these requirements via parameters in the DEFAULTS parameter group. If you are not using Oracle Spatial by default, you can create a simple parameter group to create Oracle Spatial feature classes with mostly default settings. The tables and indexes will be created in the user's default tablespace using default physical storage parameters, unless specified otherwise in the DEFAULTS parameter group. The spatial index will be a two dimensional R-tree.

79

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

##SDO_GEOMETRY GEOMETRY_STORAGE "SDO_GEOMETRY" SDO_INDEX_SHAPE "sdo_indx_dims=2" UI_TEXT "Oracle Spatial: default settings" END

With Oracle Spatial, if data is often loaded using a specific spatial reference identifier (SRID), such as the geodetic SRID 8307 (latitude/longitude WGS 84), you can create an expanded version of the previous parameter group. You don't have to specify the upper and lower bounds and tolerance, but you can if you want all your feature classes to have the same metadata for the X and Y dimensions. This is useful if you want to use the feature classes in the same feature dataset. Also, this case specifies that any polygon boundaries with reversed rotation will be reordered before sending them to ArcSDE clients. NOTE: For geodetic data, the extents are specified in decimal degrees and the tolerances are specified in meters. ##SDO_GEOMETRY_8307 GEOMETRY_STORAGE "SDO_GEOMETRY" SDO_INDEX_SHAPE "sdo_indx_dims=2" SDO_SRID 8307 SDO_DIMNAME_1 "Lon" SDO_LB_1 -180.000000 SDO_UB_1 180.000000 SDO_TOLERANCE_1 0.001 SDO_DIMNAME_2 "Lat" SDO_LB_2 -90.000000 SDO_UB_2 90.000000 SDO_TOLERANCE_2 0.001 UI_TEXT "Oracle Spatial: WGS84" END

The following example can be used to load a feature class with an R-tree spatial index into the tablespace ORSPBIZ. The R-tree spatial index will be created in the tablespace ORSPIDX. The ArcSDE client that is loading the data will decide the values for the metadata. ##SDO_GEOMETRY_ORSPBIZ GEOMETRY_STORAGE "SDO_GEOMETRY" B_STORAGE "TABLESPACE ORSPBIZ" SDO_INDEX_SHAPE "tablespace=ORSPIDX sdo_indx_dims=2" UI_TEXT "Tablespace ORSPBIZ / ORSPIDX" END

The following example can be used to load a feature class with a quadtree spatial index having a fixedsize tiling level (tessellation level) of 6. The spatial index will be created in the tablespace ORSPIDX. Commit interval is important for quadtree indexes. It indicates the number of business table records that will be processed before committing the index data. Without it, all the records of the business table are processed before committing the index data. This will cause problems when indexing tables with many records. NOTE: The parameter sdo_commit_interval is so important that ArcSDE automatically includes it in SQL indexing statements for Oracle Spatial tables even if you do not specify it as part of the SDO_INDEX_SHAPE parameter. It is set to 1,000.

80

Administering ArcSDE® for Oracle®

##SDO_GEOMETRY_QT_6 GEOMETRY_STORAGE SDO_INDEX_SHAPE END

Configuring an ArcSDE geodatabase

"SDO_GEOMETRY" "tablespace=ORSPIDX sdo_level=6 sdo_commit_interval=1000"

Section 14 About Oracle Spatial DBTUNE storage parameters Note: This topic was updated for 9.3.1. NOTE: Geodatabases in an Oracle Spatial database management system (DBMS) created with an ArcGIS Server Enterprise license only Because storage parameters for Oracle Spatial are different than other Oracle databases used with ArcSDE, descriptions and examples of how the storage parameters are used with Oracle Spatial are given below.

Creating new business tables ArcSDE uses the B_STORAGE, B_INDEX_ROWID, and B_INDEX_USER storage parameters to store the business table and the nonspatial indexes on the business table. Creating Oracle Spatial metadata for new feature classes The database view USER_SDO_GEOM_METADATA is part of Oracle Spatial, not ArcSDE. It contains metadata about SDO_GEOMETRY columns in existing tables owned by the user. Each user has its own USER_SDO_GEOM_METADATA view. To be indexed and queried, the owner of the table must record metadata for each SDO_GEOMETRY column in USER_SDO_GEOM_METADATA. The ArcSDE clients that create a feature class will choose the metadata for the feature class. Often, these clients accept a configuration keyword corresponding to a parameter group in the DBTUNE table. The storage parameters that control the metadata for new Oracle Spatial feature classes are as follows: SDO_DIMNAME_ SDO_LB_ SDO_UB_ SDO_TOLERANCE_ SDO_SRID

NOTE: If a coordinate reference system is provided during the creation of a feature class, the SDO_SRID parameter is ignored and not written to the USER_SDO_GEOM_METADATA view. Oracle Spatial permits feature geometries of two, three, or four dimensions in the combinations x/y, x/y/z, x/y/m (measure), or x/y/z/m. Through these storage parameters, ArcSDE allows you to specify metadata for each dimension. The in some parameter names should be replaced by one of the digits 1, 2, 3, or 4, corresponding to the dimension number. If you do not supply these storage parameters, the ArcSDE client application that creates the feature class will determine the name, upper and lower bound (extent), and tolerance of each dimension.

Creating a spatial index The DBTUNE parameter SDO_INDEX_SHAPE determines how Oracle Spatial creates the spatial index. ArcSDE appends the contents of this parameter (the configuration string) to the CREATE INDEX statement before submitting the statement to Oracle. The configuration string is inserted into the SQL statement after the PARAMETERS keyword. For example:

81

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

CREATE INDEX MY_SP_INDEX ON MY_SP_TABLE(SHAPE) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS ( );

The configuration string is a quoted string containing a list of parameter = value elements. There are many parameters that you can specify in the configuration string. To understand the Oracle Spatial index parameters and how they interact, read the applicable sections of the Oracle Spatial User's Guide and Reference . Notice the differences between the physical storage parameters in the spatial index configuration string and in a business table configuration string (as specified in B_STORAGE). One difference is due to the way Oracle expects these parameters to appear in SQL statements. The Oracle statements are formatted differently, so the configuration strings are formatted differently. Also, not every physical storage parameter used for creating tables is available for creating spatial indexes. B_STORAGE SDO_INDEX_SHAPE

"TABLESPACE ORSPBIZ PCTFREE 10 INITRANS 4 STORAGE(INITIAL 512000)" "tablespace=ORSPIDX initial=512000"

Sample DBTUNE parameter groups for Oracle Spatial feature classes This section presents DBTUNE parameter groups that apply to several common scenarios. (Remember, parameters are grouped by configuration keywords.) These samples emphasize the storage parameters for Oracle Spatial feature classes. Oracle and ESRI recommend using R-tree spatial indexes with SDO_GEOMETRY storage. In some of the next set of examples, you will see the parameter sdo_indx_dims=2, which specifies how many dimensions should be indexed with an R-tree spatial index. With Oracle 9.2, the default value is 2, meaning the first two dimensions (x and y). For previous versions of Oracle, the default value was the number of dimensions recorded in USER_SDO_GEOM_METADATA. There were various problems creating R-tree spatial indexes on dimensions other than x and y. For example, Oracle does not support R-tree indexes on the measure dimension. If you are creating R-tree spatial indexes and are using a version of Oracle prior to 9.2, it is recommended that you always include this parameter. If you are not using Oracle Spatial by default, you can create a simple parameter group to create Oracle Spatial feature classes with mostly default settings. The tables and indexes will be created in the user's default tablespace using default physical storage parameters, unless specified otherwise in the DEFAULTS parameter group. The spatial index will be a two-dimensional R-tree. ##SDO_GEOMETRY GEOMETRY_STORAGE "SDO_GEOMETRY" SDO_INDEX_SHAPE "sdo_indx_dims=2" UI_TEXT "Oracle Spatial: default settings" END

With Oracle Spatial, if data is often loaded using a specific spatial reference identifier (SRID), such as the geodetic SRID 8307 (latitude/longitude WGS 84), you can create an expanded version of the previous parameter group. You don't have to specify the upper and lower bounds and tolerance, but you can if you want all your feature classes to have the same metadata for the X and Y dimensions. This is useful if you want to use the feature classes in the same feature dataset. Also, this case specifies that any polygon boundaries with reversed rotation will be reordered before sending them to ArcSDE clients. NOTE: With Oracle9 i geodetic data, the extents are specified in decimal degrees and the tolerances are specified in meters. ##SDO_GEOMETRY_8307

82

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

GEOMETRY_STORAGE "SDO_GEOMETRY" SDO_INDEX_SHAPE "sdo_indx_dims=2" SDO_SRID 8307 SDO_DIMNAME_1 "Lon" SDO_LB_1 -180.000000 SDO_UB_1 180.000000 SDO_TOLERANCE_1 0.05 SDO_DIMNAME_2 "Lat" SDO_LB_2 -90.000000 SDO_UB_2 90.000000 SDO_TOLERANCE_2 0.05 UI_TEXT "Oracle Spatial: WGS84" END

The following example can be used to load a feature class with an R-tree spatial index into a tablespace called ORSPBIZ. The R-tree spatial index will be created in the tablespace ORSPIDX. The ArcSDE client that is loading the data will decide the values for the metadata. ##SDO_GEOMETRY_ORSPBIZ GEOMETRY_STORAGE "SDO_GEOMETRY" B_STORAGE "TABLESPACE ORSPBIZ" SDO_INDEX_SHAPE "tablespace=ORSPIDX sdo_indx_dims=2" UI_TEXT "Tablespace ORSPBIZ / ORSPIDX" END

The following example can be used to load a feature class with a quadtree spatial index having a fixed-size tiling level (tessellation level) of 6. The spatial index will be created in the tablespace ORSPIDX. Commit interval is important for quadtree indexes but is ignored for R-tree spatial indexes. It indicates the number of business table records that will be processed before committing the index data. Without it, all the records of the business table are processed before committing the index data. This will cause problems when indexing tables with many records. NOTE: The parameter sdo_commit_interval is so important that ArcSDE automatically includes it in SQL indexing statements for Oracle Spatial tables, even if you do not specify it as part of the SDO_INDEX_SHAPE parameter. It is set to 1,000. ##SDO_GEOMETRY_QT_6 GEOMETRY_STORAGE SDO_INDEX_SHAPE END

"SDO_GEOMETRY" "tablespace=ORSPIDX sdo_level=6 sdo_commit_interval=1000"

When designing your own parameter groups, you may need to add parameters to support other geodatabase constructs such as geometric networks or terrains. You could also satisfy these requirements by setting parameters in the DEFAULTS parameter group. For example, if the GEOMETRY_STORAGE parameter of the DEFAULTS keyword is set to SDO_GEOMETRY, then when you create topologies, networks, or terrains, the default composite keywords for these will be used. Since the default composite keywords don't specify GEOMETRY_STORAGE, the DEFAULTS GEOMETRY_STORAGE will be used; in this case, that would be SDO_GEOMETRY. If instead your DEFAULTS GEOMETRY_STORAGE keyword is set to something other than SDO_GEOMETRY, but you want to create, for example, a terrain that uses SDO_GEOMETRY storage, you need to create a new set of terrain keywords designed to store terrains with SDO_GEOMETRY storage. The following is an example of this as it would look in the dbtune.sde file:

83

Administering ArcSDE® for Oracle®

##TERRAIN_SDO UI_TERRAIN_TEXT GEOMETRY_STORAGE

Configuring an ArcSDE geodatabase

"The terrain default configuration" "SDO_GEOMETRY"

B_STORAGE

"PCTFREE 0 INITRANS 4 TABLESPACE ter_tblspc"

B_INDEX_ROWID

"PCTFREE 0 INITRANS 4 TABLESPACE ter_tblspc NOLOGGING"

B_INDEX_SHAPE

"PCTFREE 0 INITRANS 4 TABLESPACE ter_tblspc NOLOGGING"

B_INDEX_USER

"PCTFREE 0 INITRANS 4 TABLESPACE ter_tblspc NOLOGGING"

END ##TERRAIN_SDO::EMBEDDED GEOMETRY_STORAGE "SDO_GEOMETRY" B_STORAGE

"PCTFREE 0 INITRANS 4 TABLESPACE ter_tblspc"

B_INDEX_ROWID

"PCTFREE 0 INITRANS 4 TABLESPACE ter_tblspc NOLOGGING"

B_INDEX_SHAPE

"PCTFREE 0 INITRANS 4 TABLESPACE ter_tblspc NOLOGGING"

B_INDEX_USER

"PCTFREE 0 INITRANS 4 TABLESPACE ter_tblspc NOLOGGING"

END

Section 15 Composite configuration keywords Note: This topic was updated for 9.3.1. The composite keyword is a unique type of keyword used when you want to store tables from the same network, terrain, or topology class in separate spaces. You would do this, for instance, if one table is much more active than the others or if one table in the class is much larger than the others. Composite configuration keywords are subdivided into elements: the parent element, which does not have a suffix, and the composite keyword elements, which are demarcated by the addition of the :: suffix to the parent element’s configuration keyword. You can create composite keywords of your own, but the ones present by default are the NETWORK_DEFAULTS, TOPOLOGY_DEFAULTS, and TERRAIN_DEFAULTS composite keywords. For the NETWORK class, NETWORK_DEFAULTS is the parent class. The other elements of the NETWORK class composite keyword are NETWORK_DEFAULTS::DESC and NETWORK_DEFAULTS::NETWORK. When you use NETWORK_DEFAULTS for your network class, parameters and values are read from all three configuration keywords. If you want to create your own set of network configuration keywords, you would create, for example: NETWORK_HWY NETWORK_HWY::DESC NETWORK_HWY::NETWORK

As with all custom keywords, you would specify the storage values you want to use for special, nondefault network classes. In this example, you would specify NETWORK_HWY to create a network class, and ArcSDE will use the NETWORK_HWY, NETWORK_HWY::DESC, and NETWORK_HWY::NETWORK keywords. If you do not choose a network class composite configuration keyword from the ArcCatalog interface, the ArcGIS network is created with the storage parameters within the NETWORK_DEFAULTS composite configuration keyword. See What is a geometric network? in the "Network analysis" section of the help to learn more about geometric networks.

84

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

The TOPOLOGY composite keyword controls the storage of topology tables. Your ArcSDE instance must have a valid topology keyword in the DBTUNE table for topology to be built. The TOPOLOGY composite keyword consists of the parent element, TOPOLOGY_DEFAULTS, and TOPOLOGY_DEFAULTS::DIRTYAREAS, which indicates where the DIRTYAREAS topology table will be stored. The DIRTYAREAS table can grow quite large and is very active in versioned geodatabases. Therefore, if your geodatabase uses topology and a lot of versioned editing takes place on the data, you will want to alter the parameter values of TOPOLOGY_DEFAULTS::DIRTYAREAS to store the DIRTYAREAS table components in a separate storage location; by default, they have the same storage settings as the topology table. Be aware that datasets that participate in the same topology should use the same geometry storage type; if they do not, you may experience some topology errors due to slight variations in the way the data is stored. These variations are extremely small in most cases but could cause a violation of one or more of your topology rules. See the topic Topology basics in the "Working with geodatabase datasets" section of the help for an introduction to the topic of topology. The TERRAIN composite keyword controls the storage of the following tables created for terrain datasets: ◦ DTM__COMPOSITETILES ◦ DTM__INSIDETILES ◦ DTM__MRFC ◦ DTM__DIRTYAREA ◦ DTM__DISCONNECT_ ◦ DTM__PROPS The ExtensionDatasetID# is the value in the ID field of the GDB_EXTENSIONDATASETS table for the particular terrain dataset. The OBJECTCLASSID# is the value in the ID field of the GDB_OBJECTCLASSES table for the dataset. The terrain keywords are TERRAIN_DEFAULTS, which controls the default storage of the first four tables listed above, and TERRAIN_DEFAULTS::EMBEDDED, which controls the storage of the DTM__DISCONNECT_ tables. DTM__DISCONNECT_ store embedded feature classes. For this reason, they could be much larger than the other terrain tables; therefore, you may want to alter the storage parameters of the TERRAIN_DEFAULTS::EMBEDDED keyword to store these tables in a different place or in a different sized extent, depending on the DBMS you use to store your geodatabase. NOTE: Terrains can only be created if you have the 3D Analyst extension installed and active.

Composite keywords and geometry storage The default composite configuration keywords do not contain a GEOMETRY_STORAGE parameter. As mentioned in the topic The DEFAULTS keyword , any necessary parameters that are missing from a specified keyword are read from the DEFAULTS keyword. This saves you from having to retype all the parameters and parameter values for every custom keyword you create. However, this also means that if you are using an Oracle, SQL Server, or PostgreSQL database and want to use a geometry storage type other than that defined with the DEFAULTS keyword for your terrains, networks, or topologies, you need to create your own custom composite keywords for these that include the GEOMETRY_STORAGE parameter.

85

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

NOTE: In SQL Server databases, two additional sets of network, topology, and terrain composite keywords have already been added for you: one for the geometry storage type and one for the geography storage type. For example, if you are using ArcSDE for PostgreSQL and you leave your DEFAULTS GEOMETRY_STORAGE set to ST_GEOMETRY but you want to occasionally store your topology tables using the PostGIS geometry storage type, you would create a set of topology composite keywords for the PG_GEOMETRY type. You would do this if you create some of your feature classes with the PG_GEOMETRY keyword and want to create a topology for these. Custom keywords for the topology might look something like the following: ##TOPOLOGY_PG_GEOMETRY UI_TOPOLOGY_TEXT "Topology setting for PG_GEOMETRY" GEOMETRY_STORAGE "PG_GEOMETRY" A_STORAGE "TABLESPACE pgtblspace" B_STORAGE "TABLESPACE pgtblspace" D_STORAGE "TABLESPACE pgtblspace" END ##TOPOLOGY_PG_GEOMETRY::DIRTYAREAS GEOMETRY_STORAGE "PG_GEOMETRY" A_STORAGE "TABLESPACE pgtblspace" B_STORAGE "TABLESPACE pgtblspace" D_STORAGE "TABLESPACE pgtblspace" END

In this example, the UI_TOPOLOGY_TEXT parameter is included to allow users to choose this keyword when creating topologies. The GEOMETRY_STORAGE parameter is set to PG_GEOMETRY so the dirtyarea and shape fields in the topology system tables will use PG_GEOMETRY for their data storage type. These custom keywords do not include the index parameters; that means the settings for those parameters will be read from the DEFAULTS keyword. NOTE: Be aware, your configuration keyword name cannot exceed 32 characters total.

Section 16 Making configuration keywords available in ArcGIS About user interface parameters Note: This topic was updated for 9.3.1. NOTE: Applies to geodatabases created with an ArcGIS Server Enterprise license only ArcGIS users can specify configuration keywords when they create datasets. To make configuration keywords accessible to ArcGIS Desktop users, you must have a user interface (UI) storage parameter in the configuration keyword's parameter group. Any configuration keywords that do not have a UI storage parameter will not be available to the ArcGIS users. The UI storage parameters are UI_TEXT —General user interface storage parameter; to be used with any keyword, other than network or topology keywords, you want to make available to users UI_NETWORK_TEXT —User interface storage parameter for a parent network keyword UI_TOPOLOGY_TEXT —User interface storage parameter for a parent topology keyword UI_TERRAIN_TEXT —User interface storage parameter for a parent terrain keyword

86

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

These parameters are present in most of the keyword parameter lists of the default dbtune.sde file. However, if you create your own keywords that you want to be available to ArcGIS users, you should add the appropriate UI storage parameter to the keyword's parameter list. NOTE: A UI storage parameter is not needed and should not be added to the DATA_DICTIONARY configuration keyword parameter list. The DATA_DICTIONARY configuration keyword is used to specify storage of the ArcSDE geodatabase system tables and cannot be used for datasets. Some rules about adding user interface storage parameters ◦ If there are no UI storage parameters in a configuration keyword parameter group, the configuration keyword will not be recognized by ArcGIS or ArcObjects. ◦ You shouldn't have more than one UI parameter per configuration keyword. For example, you shouldn't have both UI_TEXT and UI_NETWORK_TEXT in the same configuration keyword parameter group. ◦ If multiple UI storage parameters are present, ArcGIS will only recognize one of them. If UI_TEXT and UI_NETWORK_TEXT, UI_TOPOLOGY_TEXT, or UI_TERRAIN_TEXT are in the same group, UI_TEXT will be ignored and the other parameter will be recognized. For example: ##SDO_GEOMETRY GEOMETRY_STORAGE "SDO_GEOMETRY" ATTRIBUTE_BINARY "BLOB" RASTER_STORAGE "SDO_GEORASTER" SDO_COMMIT_INTERVAL 1000 UI_TEXT "User Interface text description for SDO_GEOMETRY" UI_NETWORK_TEXT

"User Interface network text description for SDO_GEOMETRY keyword"

END

In this case, UI_NETWORK_TEXT will be used, mistakenly indicating this is a parent network keyword. If more than one of the following is present in the same group: UI_NETWORK_TEXT, UI_TOPOLOGY_TEXT, and UI_TERRAIN_TEXT, the first UI parameter encountered for that keyword in the DBTUNE table will be used and the subsequent UI parameter ignored. For example: ##NETWORK_DEFAULTS ATTRIBUTE_BINARY UI_TOPOLOGY_TEXT UI_NETWORK_TEXT B_STORAGE #

"BLOB" "User Interface topology default configuration" "User Interface network default configuration" "PCTFREE 0 INITRANS 4" TABLESPACE

Here, UI_TOPOLOGY_TEXT will be read first, mistakenly indicating this is a parent topology keyword.

How to add a UI parameter to the DBTUNE table To add a UI configuration parameter to the DBTUNE table 1. Export the DBTUNE table to the dbtune.sde file using the sdedbtune –o export command. 2. Open the dbtune.sde file in a text editor.

87

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

3. Locate or create the configuration keyword that you want to make available in the ArcGIS user interface. 4. If the keyword is used to build tables, feature classes, and indexes, add the UI_TEXT storage parameter to the parameter list. If the keyword is a parent network keyword, add the UI_NETWORK_TEXT storage parameter. If the keyword is a parent topology keyword, add the UI_TOPOLOGY_TEXT storage parameter. 5. Overwrite the DBTUNE table with the new information by importing the altered dbtune.sde file using the sdedbtune –o import command. Tip • See the Administration Command Reference installed with the ArcSDE component of ArcGIS Server Enterprise for details on how to use the sdedbtune command. • You won't be able to programmatically access a configuration keyword using ArcObjects if there is no UI parameter specified. • See Composite configuration keywords for details about parent keywords.

Section 17 The DATA DICTIONARY keyword Note: This topic was updated for 9.3.1. NOTE: Present in all ArcSDE geodatabases but can only be altered in geodatabases created under an ArcGIS Server Enterprise license The DATA_DICTIONARY configuration keyword in the DBTUNE table contains the parameters that define the storage of ArcSDE geodatabase system tables. That means these parameters are read when the geodatabase is created so if you want to modify the storage of these tables, you must alter the dbtune.sde file prior to performing the postinstallation setup, then specify this file when the geodatabase is created. This is especially important on DB2 and Oracle databases because if a specific tablespace is not specified under the DATA_DICTIONARY keyword for certain system tables, these tables will automatically be created in the temporary tablespace on DB2 or the default tablespace of the user (in this case, the ArcSDE administrator's tablespace). Four of the ArcSDE system tables—VERSION, STATES, STATE_LINEAGES, and MVTABLES_MODIFIED—participate in the ArcSDE versioning model and record events resulting from changes made to multiversioned tables. If your site plans to make extensive use of a multiversioned database, these four system tables and their associated indexes will be quite active. In this case, modifying the DATA_DICTIONARY parameters associated with these objects to separate them into their own tablespace allows you to position their data files with data files that experience low I/O activity and thus minimize disk I/O contention. Below is a description of these tables, common to all DBMS implementations, which have the potential to be quite active. An additional table that has the potential to be highly active if you use metadata searches is also described. Knowing what the tables do will help you determine how to store them and their associated indexes. Table

Description

STATES

Stores change numbers (state IDs) during versioned editing, similar to Oracle SCNs. Contains one row per state ID. Active in a versioned editing environment. May contain thousands to tens of thousands of rows.

88

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Table

Description

STATE_LINEAGES

Identifies ordered sequences of state IDs describing chronology of versioned editing. Highly active during versioned editing. May contain millions of rows.

VERSIONS

Stores named references to logical groups of edits (versions). Not active. May contain hundreds to thousands of rows.

MV_TABLES_MODIFIED Identifies which tables are edited at each state ID. Active during versioned editing. May contain tens of thousands to hundreds of thousands of rows. SDE_XML_INDEX_TAGS Defines properties of XPath indexes for metadata searches. Active during content searches by tag and when rebuilding full-text indexes. May contain thousands to tens of thousands of rows, possibly more for large metadata portals.

Individual DBMS types may contain additional parameters for other tables or indexes. See the following topics to find DATA_DICTIONARY information specific to your DBMS. DB2 DATA_DICTIONARY keyword Informix DATA_DICTIONARY keyword Oracle DATA_DICTIONARY keyword PostgreSQL DATA_DICTIONARY keyword SQL Server DATA_DICTIONARY keyword

Section 18 Oracle DATA DICTIONARY keyword Note: This topic was updated for 9.3.1. Most geodatabases in Oracle will not require more than one tablespace for the ArcSDE data dictionary tables. However, if you anticipate the need to manage space for the following segments independently of the rest of the ArcSDE system tables, create one or more tablespaces for those segments when you create your Oracle database. If you do create additional data dictionary tablespaces, place them on a fast storage volume such as RAID 10. If you want to store business tables and indexes, states tables and indexes, and/or XML tables and indexes in different tablespaces, uncomment the appropriate TABLESPACE line or lines in the dbtune.sde file and type your tablespace names in the line prior to creating your geodatabase. ##DATA_DICTIONARY ATTRIBUTE_BINARY "BLOB" B_STORAGE "PCTFREE 0 INITRANS 4 #TABLESPACE STORAGE (INITIAL 40K)" B_INDEX_ROWID "PCTFREE 0 INITRANS 4 #TABLESPACE STORAGE (INITIAL 40K) NOLOGGING" B_INDEX_USER "PCTFREE 0 INITRANS 4 #TABLESPACE STORAGE (INITIAL 40K) NOLOGGING" STATES_TABLE "INITRANS 4 # TABLESPACE STORAGE (INITIAL 1M)" STATES_INDEX "INITRANS 5 #TABLESPACE STORAGE (INITIAL 7M)" STATE_LINEAGES_INDEX "PCTFREE 0 INITRANS 4 #TABLESPACE STORAGE (INITIAL 128K) NOLOGGING" MVTABLES_MODIFIED_TABLE "INITRANS 4 #TABLESPACE STORAGE (INITIAL 2M)" MVTABLES_MODIFIED_INDEX "INITRANS 4 #TABLESPACE STORAGE (INITIAL 1M)" END

Section 19 The DEFAULTS keyword Note: This topic was updated for 9.3.1. NOTE: Present in all ArcSDE geodatabases but can only be altered in geodatabases created under an ArcGIS Server Enterprise license NOTE: Also present in file geodatabases; however, this topic covers ArcSDE geodatabases. Please see Configuration keywords for file geodatabases in the "Defining the properties of a geodatabase" section of the help for information on the DEFAULTS keyword for file geodatabases. The DBTUNE table has a fully populated DEFAULTS configuration keyword upon geodatabase creation. You can think of the parameters in the DEFAULTS configuration keyword of the DBTUNE table as the master, or fall back, storage parameters for user data; if you don't supply a configuration keyword or you supply an incomplete keyword (one that is missing parameters) when data is created or imported, the missing parameters are read from the DEFAULTS keyword. Therefore, when you alter the DEFAULTS keyword parameter group, you should populate it with values that represent the most common storage configuration of your data. Doing so relieves you of the need to define all the parameters for each of the keywords you define. For example, if you create a configuration keyword to create tables in a storage space segregated from the rest of the data, you only need to add the parameters that specify the tables' storage location. The rest of the parameters, such as the geometry storage type, can be picked up from the DEFAULTS keyword parameter group. Populating the DEFAULTS keyword with the most commonly used values for your particular site also makes it easier for the users who create data; if the DEFAULTS keyword contains the settings they will need for 95 percent of the data, they will only have to worry about selecting a different keyword for the remaining 5 percent. The DEFAULTS configuration keyword can be selected whenever you create a table, index, feature class, or raster dataset. If you don't supply a keyword when you create or load data, the DEFAULTS keyword parameter group is used automatically. The configuration parameters present by default in the DEFAULTS parameter group vary by DBMS. Below are the DEFAULTS parameter groups for each database management system type with the ArcGIS 9.3 release. They 90

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

are represented as how they would appear in the dbtune file, not how they look in the DBTUNE table. (For instance, there would be no double pound sign in front of the configuration keyword in the DBTUNE table.) Consult the following topics to see the DEFAULTS keyword parameter lists for each DBMS. DB2 DEFAULTS Informix DEFAULTS Oracle DEFAULTS PostgreSQL DEFAULTS SQL Server DEFAULTS

Section 20 Oracle DEFAULTS keyword Note: This topic was updated for 9.3.1. As the name indicates, the settings under the DEFAULTS configuration keyword are used by default when you create tables, feature classes, raster datasets, and indexes. If you do not specify a different keyword when data is created in the geodatabase, or if you specify a keyword that is missing some necessary parameters, values from the DEFAULTS keyword are used. You need to supply the information shown in brackets () and uncomment the associated TABLESPACE lines by removing the # sign. The parameters grouped under the DEFAULTS keyword should be set to values that apply to most of the data in your geodatabase. If you do not uncomment the tablespace lines and provide values, the data will be stored in the default tablespace of the user creating the data. ##DEFAULTS

GEOMETRY_STORAGE "ST_GEOMETRY" ATTRIBUTE_BINARY "BLOB" RASTER_STORAGE "BLOB" AUX_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" AUX_STORAGE "PCTFREE 0 INITRANS 4 # TABLESPACE " A_INDEX_RASTER "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" A_INDEX_ROWID "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" A_INDEX_SHAPE "PCTFREE 0 INITRANS 4 #TABLESPACE NOLOGGING" A_INDEX_STATEID "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" A_INDEX_USER "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" A_INDEX_XML "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" A_STORAGE "PCTFREE 0 INITRANS 4 # TABLESPACE " BLK_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 # TABLESPACE

91

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

NOLOGGING" BLK_STORAGE "PCTFREE 0 INITRANS 4 # TABLESPACE " BND_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" BND_INDEX_ID "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" BND_STORAGE "PCTFREE 0 INITRANS 4 # TABLESPACE " B_INDEX_RASTER "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" B_INDEX_ROWID "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" B_INDEX_TO_DATE "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" B_INDEX_USER "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" B_INDEX_XML "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" B_STORAGE "PCTFREE 0 INITRANS 4 # TABLESPACE " D_INDEX_DELETED_AT "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" D_INDEX_STATE_ROWID "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" D_STORAGE "PCTFREE 0 INITRANS 4 # TABLESPACE " RAS_INDEX_ID "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" RAS_STORAGE "PCTFREE 0 INITRANS 4 # TABLESPACE " S_INDEX_ALL "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" S_STORAGE "PCTFREE 0 INITRANS 4 # TABLESPACE " ST_GEOM_LOB_STORAGE "STORE AS ( ENABLE STORAGE IN ROW CHUNK 8K RETENTION CACHE)" UI_TEXT "" ST_INDEX_LOCAL_PARTITION "FALSE" XML_DOC_INDEX "PCTFREE 0 INITRANS 4 NOLOGGING # TABLESPACE " XML_DOC_LOB_STORAGE "NOCACHE NOLOGGING CHUNK 4K PCTVERSION 5 DISABLE STORAGE IN ROW # TABLESPACE " XML_DOC_MODE "COMPRESSED" XML_DOC_STORAGE "PCTFREE 0 INITRANS 4 # TABLESPACE " XML_DOC_TEXT_TYPE "LONGRAW" XML_DOC_VAL_LOB_STORAGE "NOCACHE NOLOGGING CHUNK 4K PCTVERSION 5 DISABLE STORAGE IN ROW # TABLESPACE " XML_IDX_INDEX_DOUBLE "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" XML_IDX_INDEX_ID "PCTFREE 0 INITRANS 4 # TABLESPACE

92

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

NOLOGGING" XML_IDX_INDEX_PK "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" XML_IDX_INDEX_TAG "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" XML_IDX_INDEX_TEXT "" XML_IDX_STORAGE "PCTFREE 0 INITRANS 4" XML_IDX_TEXT_TAG_STORAGE "" XML_IDX_TEXT_UPDATE_MEMORY "" XML_IDX_TEXT_UPDATE_METHOD "NONE" UNICODE_STRING "TRUE" END

Section 21 Log file keywords Note: This topic was updated for 9.3.1. NOTE: Applies to geodatabases created with an ArcGIS Server Enterprise license only Log file configuration keywords in the DBTUNE table are used to control the storage of ArcSDE log file tables. You can create log file keywords for particular users so that whenever the user creates a selection set that leads to the creation of ArcSDE log file tables, the settings for that user's log file keyword are used. You create user-specific log file keywords in the format LOGFILE_. For example, if you want to create a log file configuration keyword for user Moe, use the keyword LOGFILE_Moe. If the connecting user name is not Moe and it does not have its own user-specific log file keyword, the LOGFILE_DEFAULTS keyword is used. Creating a log file configuration keyword for each user allows you to store the different users' log files on separate devices. Most ArcSDE geodatabases function well using the LOGFILE_DEFAULTS storage parameters supplied with the installed dbtune.sde file. However, for applications that make heavy use of log files, such as ArcGIS Desktop, it may help performance to spread the log files across the file system. NOTE: If you create user-specific log file keywords, there is no need to include a UI_TEXT parameter. The user does not specify his or her log file keyword when the data is created; rather, the system searches for the keyword that matches the connected user name when log file tables need to be created. Parameters of log file keywords For the creation of shared log file tables, the LD_STORAGE and LF_STORAGE parameters control the storage of the SDE_LOGFILE_DATA and SDE_LOGFILES tables. The LF_INDEXES parameter defines the storage of the indexes of the SDE_LOGFILES table, while the LD_INDEX_DATA_ID and LD_INDEX_ROWID parameters define the storage of the SDE_LOGFILE_DATA table. If you have configured the server to use session-based or stand-alone log files in addition to shared log files, ArcSDE uses a different set of storage parameters when it creates the session-based and stand-alone log file tables. The SESSION_STORAGE parameter defines the storage of the session-based and stand-alone log file tables. The SESSION_INDEX parameter defines the storage of the session-based and stand-alone log file table indexes.

93

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Consult the following topics to see the default parameters for the LOGFILE_DEFAULTS keyword for each database management system. LOGFILE DEFAULTS for DB2 LOGFILE DEFAULTS for Informix LOGFILE DEFAULTS for Oracle LOGFILE DEFAULTS for PostgreSQL LOGFILE DEFAULTS for SQL Server

Section 22 LOGFILE DEFAULTS for Oracle Note: This topic was updated for 9.3.1. The following are the default log file parameters as they would appear in the dbtune files available with ArcSDE for Oracle. To provide storage information for the parameters that are commented out, uncomment them by removing the pound sign (#) and provide a tablespace name. You can also change the other storage parameters. Uncomment and set these parameters in the dbtune.sde file prior to creating the geodatabase. If you do not alter the values prior to geodatabase creation, you can use the sdeconfig command to set them after the geodatabase is set up. Consult the ArcSDE Administration Command Reference included with the ArcSDE component of ArcGIS Server Enterprise for details on the sdeconfig command. ##LOGFILE_DEFAULTS LF_STORAGE "PCTFREE 0 INITRANS 4" # TABLESPACE LF_INDEXES "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" LD_STORAGE "PCTFREE 0 INITRANS 4" # TABLESPACE LD_INDEX_ROWID "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" LD_INDEX_DATA_ID "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" SESSION_STORAGE "PCTFREE 0 INITRANS 4" # TABLESPACE SESSION_INDEX "PCTFREE 0 INITRANS 4 # TABLESPACE NOLOGGING" SESSION_TEMP_TABLE 0 UI_TEXT "User Interface text description for LOGFILE_DEFAULTS" END

Section 23 Log file configuration options Note: This topic was updated for 9.3.1. NOTE: Log file tables are used in all ArcSDE geodatabases but are only configurable in geodatabases created under an ArcGIS Server Enterprise license. ArcSDE geodatabases use log file tables to maintain lists of selected records. Records are written to log file tables for later use by the application whenever a selection of a specific size is made, a reconciliation or post on a versioned database is performed, or a disconnected editing checkout is done in a client application. The log file tables store the OBJECTIDs of the selected features so they can be redisplayed. This allows for faster analysis and processing of information.

94

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

In ArcGIS, by default, log file tables are used if the selection set contains 100 or more records. This selection threshold of 100 features is set in the registry. It can be changed; however, ESRI does not recommend you do so. There is no proven performance reason for changing it, and doing so could even cause performance problems. In ArcIMS, if you are using server feature count mode, all selections of any size use the log file tables. For details on feature count modes in ArcIMS, please consult the ArcIMS help provided with that software. The available ArcSDE log file options are as follows: ◦ Shared log files ◦ Session-based log files ◦ Stand-alone log files ◦ Pools of session-based or stand-alone log files owned by the ArcSDE administrator Each is described in its own section in this topic. In most cases, the default ArcSDE log file configuration for your database management system (DBMS) should be sufficient and is the recommended setting. For Oracle, DB2, Informix, and PostgreSQL, the default is shared ArcSDE log files; for SQL Server, it is session-based log files created in the temporary database (tempdb). Log file options are set using specific parameters in the SERVER_CONFIG and DBTUNE tables (sde_server_config and sde_dbtune in SQL Server and PostgreSQL databases). Parameters in these tables are altered using the sdeconfig and sdedbtune commands, respectively. Syntax for these parameters can be found in the ArcSDE Administration Command Reference provided with the ArcSDE component of ArcGIS Server Enterprise.

Shared log files Shared log files are shared by all sessions that connect as the same user. If you have multiple users connecting with the same user account, all those sessions will be inserting records into and deleting records from the same log file data table. When you want to use shared log files Use shared log files if you have a large number of concurrent sessions, each session connects using an individual DBMS user account (which is the recommended way for making connections to the geodatabase), and you are not using SQL Server to store your geodatabase. When you might not want to use shared log files You may not want to use shared log files if you have numerous connections made with the same login such as if you use an ArcIMS service that generates multiple connections with the same login. This can lead to contention and wait times for the SDE_LOGFILE_DATA table. In those cases, you might want to use session-based log files. If you store your geodatabase in SQL Server, you would be better off using session-based log files created in tempdb, the default setting for ArcSDE for SQL Server. Tables created for shared log files The log file tables used for this option are SDE_LOGFILES and SDE_LOGFILE_DATA. They are created in the schema of the connecting user the first time the user makes a selection that exceeds the selection threshold. For ArcGIS Desktop, this threshold is 100 records. SDE_LOGFILES stores information about each selection set (log file) that is created. The logfile_name and logfile_id columns in this table uniquely identify the name of the log file, and the logfile_id column links the log file record to the SDE_LOGFILE_DATA table. The SDE_LOGFILE_DATA table contains the logfile_data_id and the feature identifier for the selected records.

95

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

All records are deleted as soon as the selection set is cleared to prevent the SDE_LOGFILE_DATA table from growing too large. The SDE_LOGFILES table is truncated when the user's session ends. Both SDE_LOGFILE_DATA and SDE_LOGFILES remain in the user's schema. Settings to use shared log files In the SERVER_CONFIG table (sde_server_config in PostgreSQL and SQL Server), the following settings are needed to create shared log file tables: MAXSTANDALONELOGS = 0 ALLOWSESSIONLOGFILE = FALSE LOGFILEPOOLSIZE = 0 Settings to control storage of shared log file tables and indexes There are several parameters under the LOGFILE_DEFAULTS keyword of the DBTUNE table that control how or where log file tables are stored in the database. You do not have to set these to use shared log files, but you can set them if you want to alter how the SDE_LOGFILES and SDE_LOGFILE_DATA tables and indexes are stored in the database. Which parameters are present and what they control depend on the DBMS being used. For DB2, Informix, and Oracle, the following parameters control storage for shared log file tables and indexes: LD_INDEX_DATA_ID LD_INDEX_ROW_ID LD_STORAGE LF_INDEXES LF_STORAGE See DB2 DBTUNE configuration parameters , Informix DBTUNE configuration parameters , or Oracle DBTUNE configuration parameters for explanations of these parameters. For PostgreSQL, the following parameters are used: LD_INDEX_ALL LD_STORAGE LF_INDEX_ID LF_INDEX_NAME LF_STORAGE See PostgreSQL DBTUNE configuration parameters for explanations of these parameters. For SQL Server, these parameters are used: LD_INDEX_ALL LD_STORAGE LF_CLUSTER_ID LF_CLUSTER_NAME LF_INDEX_ID LF_INDEX_NAME LF_STORAGE See SQL Server DBTUNE configuration parameters for explanations of these parameters. Required user permissions to use shared log files

96

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Since the log file tables are owned by the user, users must be granted privileges that allow them to create the required data objects such as tables. This is required even if the user has read-only access to ArcSDE or ArcSDE is set to be read-only. If these privileges are not granted, users will receive an error message the first time they create a selection set larger than the threshold size for that particular client application. However, once the SDE_LOGFILES and SDE_LOGFILE_DATA tables are created for a user, the ArcSDE administrator can revoke the privileges. For example: Ian is a city planner who would only select data from the geodatabase to perform analyses related to his work. Therefore, he would be considered a read-only user. However, for Ian to create the SDE_LOGFILES and SDE_LOGFILE_DATA tables in the city's ArcSDE geodatabase for SQL Server, he needs to have CREATE TABLE privileges. Rather than grant Ian CREATE TABLE privileges indefinitely, the ArcSDE administrator decides to log in to the geodatabase as Ian, make a selection that exceeds the selection threshold, then revoke Ian's CREATE TABLE privilege. The following are the required permissions in each DBMS to use shared log file tables: DB2

Informix

Oracle

CONNECT

RESOURCE CREATE SESSION

CREATETAB

CREATE TABLE

IMPLICIT_SCHEMA

CREATE TRIGGER

PostgreSQL*

SQL Server

CONNECT

CONNECT

USAGE and CREATE on the user's own schema

CREATE TABLE

CREATE SEQUENCE CREATE PROCEDURE

Most DBMSs grant CONNECT (CREATE SESSION in Oracle) privileges to all users by default; therefore, you only need to explicitly grant this permission if you have revoked it from PUBLIC. *For most PostgreSQL users, you will create a corresponding schema and grant the user AUTHORIZATION on the schema. However, for users to be truly read-only, you cannot grant AUTHORIZATION to them on their schemas. Therefore, you will need to temporarily grant each read-only user USAGE and CREATE permissions on the schema, connect as each user, and perform a selection that will create the log file tables in the user's schema. Then you can revoke the read-only user's CREATE permission from the schema. The USAGE privilege must remain so the user can utilize the log file tables in the future.

Session-based log files Session-based log file data tables are dedicated to a single session and may contain multiple selection sets (log files). Each session that logs in will require a set of tables for selections. When you want to use session-based log files You definitely want to use this if your geodatabase is stored in SQL Server. In SQL Server, it is possible to create session-based log files in the tempdb database, which means there are no tables for you to manage in the geodatabase, there is minimal transaction logging, and you don't have to give users CREATE TABLE permissions in the database. Since this is the default setting for geodatabases in SQL Server, you don't need to change the settings to use this log file option. For the other supported DBMSs, you might use session-based log files if you have numerous concurrent connections being made to the geodatabase with the same login. When you might not want to use session-based log files If you have read-only users who connect to the database, you cannot use session-based log files. The only exception to this is in SQL Server databases in which the session-based log file table is created in tempdb.

97

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

As mentioned in the following section, the session table is dropped from the user's schema when the session ends. That means it has to be re-created when needed; therefore, users need to have permissions to create tables to be able to use session-based log file tables. When using the default ArcSDE for SQL Server setting, users do not require CREATE TABLE permission in the database for the session table to be created in tempdb. Tables created for session-based log files In Oracle, DB2, Informix, and PostgreSQL databases, three tables are created: SDE_LOGFILES, SDE_LOGFILE_DATA, and SDE_SESSION. SDE_LOGFILE_DATA is not actually used in this case, but it is created automatically. The SDE_LOGFILES table stores information about the selection set plus a session tag that is appended to the name of the SDE_SESSION table. The SDE_SESSION table stores the feature identifier for the selected set and the log file ID. The SDE_LOGFILES and SDE_LOGFILE_DATA tables remain in the geodatabase. The SDE_LOGFILES table is truncated when the connecting application disconnects. The SDE_SESSION table is truncated when the connecting application deletes the log files, and the table is dropped when the session disconnects. In SQL Server, one table is created in tempdb in the format ##SDE_session. This table is truncated when the connecting application deletes its log files, and the table is dropped when the session disconnects. Be aware that you cannot see temporary objects in Enterprise Manager or the Object Explorer in Management Studio. Settings to use session-based log files (nonpooled) In the SERVER_CONFIG table (sde_server_config in PostgreSQL and SQL Server), the following settings are needed to create session-based log file tables that are not owned by the ArcSDE administrator: ALLOWSESSIONLOGFILE = TRUE MAXSTANDALONELOGS = 0 LOGFILEPOOLSIZE = 0 Settings to control storage of session-based log file tables and indexes There are several parameters under the LOGFILE_DEFAULTS keyword of the DBTUNE table that control how or where log file tables are stored in the database. You do not have to set these to use session-based log files, but you can set them if you want to alter how the SDE_LOGFILES, SDE_LOGFILE_DATA, and SDE_SESSION tables and indexes are stored in the database. Which parameters are present and what they control depend on the DBMS being used. For DB2, Informix, and Oracle, the following parameters control storage for session-based log file tables and indexes: LD_INDEX_DATA_ID LD_INDEX_ROW_ID LD_STORAGE LF_INDEXES LF_STORAGE SESSION_INDEX SESSION_STORAGE See DB2 DBTUNE configuration parameters , Informix DBTUNE configuration parameters , or Oracle DBTUNE configuration parameters for explanations of these parameters. For PostgreSQL, the following parameters are used:

98

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

LD_INDEX_ALL LD_STORAGE LF_INDEX_ID LF_INDEX_NAME LF_STORAGE SESSION_INDEX SESSION_STORAGE See PostgreSQL DBTUNE configuration parameters for explanations of these parameters. For SQL Server, these parameters are used: LD_INDEX_ALL LD_STORAGE LF_CLUSTER_ID LF_CLUSTER_NAME LF_INDEX_ID LF_INDEX_NAME LF_STORAGE SESSION_TEMP_TABLE The SESSION_TEMP_TABLE parameter must be set to 1 (TRUE) to allow the session-based log file table to be created in tempdb. If you change the SESSION_TEMP_TABLE parameter to 0 (FALSE), the SDE_LOGFILES, SDE_LOGFILE_DATA, and SDE_SESSION tables will be created in the connecting user's schema. This has implications for the privileges required for the user. See SQL Server DBTUNE configuration parameters for explanations of these parameters. Required user permissions to use session-based log files Session-based log files are owned by the user who started the connecting session (unless you are using SQL Server with the default log file configuration that creates a table in tempdb). This means users need to have privileges that allow them to create the necessary database objects. DB2

Informix

CONNECT

RESOURCE CREATE SESSION

Oracle

CREATETAB

CREATE TABLE

IMPLICIT_SCHEMA

CREATE TRIGGER

PostgreSQL* CONNECT USAGE and CREATE on the user's own schema

CREATE SEQUENCE CREATE PROCEDURE

*For most PostgreSQL users, you will create a corresponding schema and grant the user AUTHORIZATION on the schema, which automatically confers USAGE and CREATE permissions on the schema. If you use the recommended SQL Server settings, users only require the ability to connect to the database. However, if you change the SDE_dbtune SESSION_TEMP_TABLE parameter to 0, connecting users require CREATE TABLE permission in the database in addition to CONNECT privileges. Most DBMSs grant CONNECT (CREATE SESSION in Oracle) privileges to all users by default; therefore, you only need to explicitly grant this permission if you have revoked it from PUBLIC.

Stand-alone log files 99

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Stand-alone log files are created by a session for each selection set the application needs to store. Stand-alone log files generate the largest number of tables of all the log file options. Keep in mind that you need to configure enough space to store all these log file tables. The DBTUNE parameters SESSION_STORAGE and SESSION_INDEX allocate space for the tables and indexes of stand-alone log files in the majority of DBMSs. When you want to use stand-alone log files If you aren't concerned with granting CREATE permissions to all users, you can use stand-alone log file tables. One advantage to stand-alone log file tables is that when a selection set is cleared, the SDE_LOGDATA table that held that selection will be truncated rather than deleted. Truncating can be performed more rapidly than a delete operation because no internal SQL statement has to be issued. However, there aren't many instances for which this gain in performance would outweigh the cost of creating and storing individual log file tables for each layer. When you might not want to use stand-alone log files If you have read-only users who connect to the database, you can't use stand-alone log files. As mentioned in the next section, the SDE_LOGDATA tables are dropped from the user's schema when the connection is terminated. They have to be re-created each time a layer's selection threshold is passed, so you cannot remove CREATE permissions from users if they are going to connect to the geodatabase. Tables created for stand-alone log files For each selection set above the selection threshold made by a session, a new SDE_LOGDATA table is created for each layer. This eliminates contention for the SDE_LOGDATA table. However, since a new table is created for each selection set and dropped when the session disconnects, a large number of CREATE TABLE and DROP TABLE SQL statements are generated. The SDE_LOGFILES and SDE_LOGFILE_DATA tables are created per connection in the user's schema. The SDE_LOGFILES table stores the selection set properties, but the SDE_LOGFILE_DATA table isn't used. When the selection set is no longer needed for the layers, the SDE_LOGDATA tables are truncated. The SDE_LOGDATA tables are dropped when the session disconnects. The SDE_LOGFILES and SDE_LOGFILE_DATA tables remain in the user's schema even after the user disconnects; however, the SDE_LOGFILES table is truncated. Settings required to use stand-alone log files (nonpooled) The parameter in the SERVER_CONFIG (sde_server_config in PostgreSQL and SQL Server) table that specifies the number of stand-alone log files that can be created is MAXSTANDALONELOGS. The default setting for MAXSTANDALONELOGS is 0, so if you want to use stand-alone log files, you must set the number of MAXSTANDALONELOGS to the number of stand-alone log files you want each user to be able to create. The following settings are needed to create stand-alone log file tables that are not owned by the ArcSDE administrator: MAXSTANDALONELOGS = LOGFILEPOOLSIZE = 0 Stand-alone log files are used until the session's quota—defined by the MAXSTANDALONELOGS server configuration parameter—is exhausted. When the user runs out of stand-alone log files—in other words, if the application needs to simultaneously create more selection sets (log files) than MAXSTANDALONELOGS allows—ArcSDE will attempt to create session-based log files but only if ALLOWSESSIONLOGFILE is set to TRUE. If it can't create a session-based log file, it tries to create a shared log file. If a shared log file can't be created and the stand-alone log files are used up, ArcSDE returns an error. See the section ArcSDE log file flowcharts for examples of the order in which log file types are used. Settings to control storage of stand-alone log file tables and indexes

100

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

There are several parameters under the LOGFILE_DEFAULTS keyword of the DBTUNE (sde_dbtune in PostgreSQL and SQL Server) table that control how or where log file tables are stored in the database. You do not have to set these to use stand-alone log files, but you can set them if you want to alter how the SDE_LOGFILES, SDE_LOGFILE_DATA, and SDE_LOGDATA tables and indexes are stored in the database. Which parameters are present and what they control depend on the DBMS being used. For DB2, Informix, and Oracle, the following parameters control storage for stand-alone log file tables and indexes: LD_INDEX_DATA_ID LD_INDEX_ROW_ID LD_STORAGE LF_INDEXES LF_STORAGE SESSION_INDEX SESSION_STORAGE See DB2 DBTUNE configuration parameters , Informix DBTUNE configuration parameters , or Oracle DBTUNE configuration parameters for explanations of these parameters. For PostgreSQL, the following parameters are used: LD_INDEX_ALL LD_STORAGE LF_INDEX_ID LF_INDEX_NAME LF_STORAGE SESSION_INDEX SESSION_STORAGE See PostgreSQL DBTUNE configuration parameters for explanations of these parameters. For SQL Server, these parameters are used: LD_INDEX_ALL LD_STORAGE LF_CLUSTER_ID LF_CLUSTER_NAME LF_INDEX_ID LF_INDEX_NAME LF_STORAGE SESSION_TEMP_TABLE The SESSION_TEMP_TABLE parameter must be set to 1 (TRUE) to allow the stand-alone log file tables to be created in tempdb. If you change the SESSION_TEMP_TABLE parameter to 0 (FALSE), the SDE_LOGFILES, SDE_LOGFILE_DATA, and SDE_SESSION tables will be created in the connecting user's schema. This has implications for the privileges required for the user. See SQL Server DBTUNE configuration parameters for explanations of these parameters.

101

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Required user permissions to use stand-alone log files DBMS user accounts using stand-alone log file tables have to have CREATE privileges for the necessary database objects. Unlike with shared log files, you can't revoke a user's privileges after the log file tables are created, because a new user-owned table per layer is created each time a session creates a large enough selection. DB2

Informix

Oracle

CONNECT

RESOURCE CREATE SESSION

CREATETAB

CREATE TABLE

IMPLICIT_SCHEMA

CREATE TRIGGER

PostgreSQL*

SQL Server**

CONNECT

CONNECT

At least USAGE and CREATE on the user's own schema

CREATE SEQUENCE CREATE PROCEDURE

*For most PostgreSQL users, you will create a corresponding schema and grant the user AUTHORIZATION on the schema, which automatically confers USAGE and CREATE permissions on the schema. **If you leave SESSION_TEMP_TABLE set to 1, SQL Server users only require CONNECT privileges to the database. However, if you change the SDE_dbtune SESSION_TEMP_TABLE parameter to 0, connecting users require CREATE TABLE permission in the database in addition to CONNECT privileges. Most DBMSs grant CONNECT (CREATE SESSION in Oracle) privileges to all users by default; therefore, you only need to explicitly grant this permission if you have revoked it from PUBLIC.

Pools of log files owned by the ArcSDE administrator The ArcSDE administrator can create a pool of log files that can be checked out and used by other users. These can be either session-based or stand-alone log files. Shared log files cannot be checked out from an ArcSDE log file pool. Using a pool of ArcSDE log files avoids having to grant users CREATE privileges in the database. When you want to use pools of ArcSDE administrator-owned log files You would use a pool of log files if you cannot give users the ability to create log file tables in their own schemas. Users still need to have permissions to create a session or connect to the database, though. It is a more efficient use of pool resources to use session-based log files in the pool because session-based log files will write multiple selection sets to a single table, whereas stand-alone log files use one table for each eligible selection set. When you might not want to use pools of ArcSDE administrator-owned log files Overall, using pools of log files requires slightly more maintenance because you must estimate the number of necessary log file tables, and you may find yourself adjusting the size of the pool or the number of pools used. Keep in mind that a large log file pool or a large number of log file pools can have a negative impact on performance. Tables created for pools of ArcSDE administrator-owned log files The value set for the LOGFILEPOOLSIZE parameter in the SERVER_CONFIG table determines the number of SDE_LOGPOOL_ tables created in the ArcSDE administrative user's schema. For example, if you set LOGFILEPOOLSIZE to 5, the following tables are created in the schema of the ArcSDE administrator: SDE_LOGPOOL_1 SDE_LOGPOOL_2 SDE_LOGPOOL_3 SDE_LOGPOOL_4 102

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

SDE_LOGPOOL_5 An additional table in the ArcSDE administrator's schema, SDE_LOGFILE_POOL, records the SDE_ID for the ArcSDE session and a table ID. The in the name of the SDE_LOGPOOL table corresponds to the value in the table_ID column of the SDE_LOGFILE_POOL table. If you use a pool of session-based log files, each session that creates a selection exceeding the selection threshold adds one record to the SDE_LOGFILE_POOL table and the session is allocated to one of the SDE_LOGPOOL_ tables. If additional log files are created by the same session—for example, a second selection set of 300 records is created in one ArcMap session—the new log files (selection set) are added to the same SDE_LOGPOOL table. When log files are cleared, the SDE_LOGPOOL table that is checked out to the session is truncated. For example, if the second selection set in the ArcMap session is cleared, the 300 records are removed from the SDE_LOGPOOL table, but the records for the first selection set remain. When the first selection set is cleared, these records are removed from the SDE_LOGPOOL table. If you use a pool of stand-alone log files, each log file (selection set of the required size) creates a new record in the SDE_LOGFILE_POOL table and uses one of the SDE_LOGPOOL tables. For example, if in a single ArcMap session, you selected (1) from a feature class that stored information about businesses, all the businesses licensed to serve food and (2) from a feature class that stored storm drain information, all catch basins located within a kilometer of a business that served food, there would be two records added to the SDE_LOGFILE_POOL table: one for the selection set of businesses and one for the selection set of catch basins. Each selection set would be assigned its own SDE_LOGPOOL table. As a log file (selection set) is cleared, the corresponding SDE_LOGPOOL table is truncated. Settings required to use ArcSDE administrator-owned pools of log files The settings in the SERVER_CONFIG table that specifically affect pools of log files are LOGFILEPOOLSIZE and HOLDLOGPOOLTABLES. As mentioned in the previous section, to create a pool of log files, set the configuration parameter LOGFILEPOOLSIZE to the number of log files (in other words, the number of SDE_LOGPOOL tables) that you determine need to be created. This number should reflect the number of sessions that will connect to your server in addition to the stand-alone log files, if allowed. To calculate the total number of log files you should set for the log file pool, use the following formulas: ◦ If session log files are allowed but not stand-alone log files LOGFILEPOOLSIZE = total sessions expected For example, if MAXSTANDALONELOGS is set to 0, ALLOWSESSIONLOGFILE is set to TRUE, and you expect no more than 30 connections to the geodatabase at any one time, set LOGFILEPOOLSIZE to 30. ◦ If stand-alone log files are allowed but not session log files LOGFILEPOOLSIZE = MAXSTANDALONELOGS * total sessions expected For instance, if MAXSTANDALONELOGS is set to 5, ALLOWSESSIONLOGFILE is set to FALSE, and you estimate no more than 10 connections will be made to the geodatabase at any one time, set LOGFILEPOOLSIZE to 50. LOGFILEPOOLSIZE = 5 * 10 ◦ If both stand-alone log files and session log files are allowed LOGFILEPOOLSIZE = (MAXSTANDALONELOGS + 1) * total sessions expected

103

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

For instance, if MAXSTANDALONELOGS is set to 8, ALLOWSESSIONLOGFILE is set to true, and you estimate there will be no more than 20 connections to the database at any one time, you would set LOGFILEPOOLSIZE to 180. LOGFILEPOOLSIZE = (8 + 1) * 20 If the pool is exhausted and another log file table is needed, ArcSDE will attempt to create it in the user's schema. If the log file table cannot be created in the user's schema, an error is returned. The SDE_LOGPOOL_ tables are created or dropped whenever the LOGFILEPOOLSIZE parameter is changed. In the previous example, when LOGFILEPOOLSIZE is set to 180, 180 SDE_LOGPOOL_ tables are created. If you change the LOGFILEPOOLSIZE parameter to 100, 80 of those tables will be dropped. The other log file pool parameter, HOLDLOGPOOLTABLES, determines when an SDE_LOGPOOL table gets returned to the pool and can be used by other users. If HOLDLOGPOOLTABLES is set to TRUE (the default value), records remain in the SDE_LOGFILE_POOL table and SDE_LOGPOOL tables stay locked until the connecting session is terminated. If HOLDLOGPOOLTABLES is set to FALSE, the log file tables are released and the SDE_LOGFILE_POOL table is truncated whenever the selection set is no longer needed. This behavior is the same for pools of stand-alone and session-based log files. Settings to control storage of ArcSDE administrator-owned pools of log file tables and indexes There are only a few parameters under the LOGFILE_DEFAULTS keyword of the DBTUNE (sde_dbtune in PostgreSQL and SQL Server) table that control how the SDE_LOGPOOL tables and their indexes are stored. ArcSDE for PostgreSQL and SQL Server use the LD_STORAGE and LD_INDEX_ALL parameters in the sde_dbtune table to set storage for the SDE_LOGPOOL tables and their indexes. These two parameters also control the storage of the SDE_LOGFILE_DATA table and index. See PostgreSQL DBTUNE configuration parameters or SQL Server DBTUNE configuration parameters for explanations of these parameters. In ArcSDE geodatabases for Oracle, Informix, and DB2, the LD_STORAGE, LD_INDEX_ROWID, and LD_INDEX_DATA_ID DBTUNE parameters are used to set storage for the SDE_LOGPOOL tables and their indexes. These three parameters also control the storage of the SDE_LOGFILE_DATA table and indexes. See Oracle DBTUNE configuration parameters , Informix DBTUNE configuration parameters , or DB2 DBTUNE configuration parameters for explanations of these parameters. You do not have to set these to use pools of log file tables, but you can set them if you want to alter how the SDE_LOGPOOL tables and indexes are stored in the database. Required user permissions to use ArcSDE administrator-owned pools of log files To utilize the log file tables in the pool, users only require the ability to connect to the database and use the objects in the ArcSDE administrator's schema. DB2

Informix

Oracle

PostgreSQL*

CONNECT CONNECT CREATE SESSION CONNECT

SQL Server CONNECT

USAGE on the sde schema

*If your PostgreSQL database is used exclusively for your geodatabase, you will usually grant USAGE permission on the sde schema to PUBLIC to avoid having to grant it to every individual role or group. USAGE on the sde schema is necessary for users to access the geodatabase.

ArcSDE log file flowchart The following diagram demonstrates the order in which ArcSDE will try to use log file tables.

104

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Flow chart showing ArcSDE use of log file tables It is recommended you stick with the default log file settings for your DBMS, but if you change your log file configuration parameters from the default values, be aware there are situations in which you might end up using more than one type of log file at a time. For example, if you set the following parameters: MAXSTANDALONELOGS=20 ALLOWSESSIONLOGFILE=true LOGFILEPOOLSIZE=0 and all 20 log files are in use, when the request for another log file comes in, a session-based log file will be used. If you have the following settings in a SQL Server database, that session-based log file table will be created in tempdb: MAXSTANDALONELOGS=20 ALLOWSESSIONLOGFILE=true LOGFILEPOOLSIZE=0 SESSION_TEMP_TABLE=1

105

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Similarly, if you have these settings and 15 log files are needed simultaneously, all 10 of the log file tables in the pool will be used plus 5 shared log files will be created. MAXSTANDALONELOGS=0 ALLOWSESSIONLOGFILE=true LOGFILEPOOLSIZE=10 If you have the same settings in a SQL Server database plus have SESSION_TEMP_TABLE set to 1, the 10 log file tables in the pool will be used first, then the next 5 session-based log file tables will be created in tempdb.

Section 24 About data types Note: This topic was updated for 9.3.1. When you create a table or add a column to a table in the database, columns are created as a specific data type. Data types are classifications that identify possible values for and operations that can be done on the data as well as the way the data in that column is stored in the database. When you import data of one type into a column of another data type, you need to understand what the equivalent data types are between ArcSDE and your database management system (DBMS) because it can impact data content. Also, when creating new datasets in ArcGIS, it is helpful to know the equivalent data types between ArcGIS and your DBMS. For example, if you add a floating point (float) column to an existing feature class, that equates to a numeric data type column in a SQL Server database. NOTE: Moving data from one database to another can cause data types to remap. Each DBMS product can use different data types. The matrix below compares the data types used by each DBMS for each ArcSDE data type. For example, for the ArcSDE date type, DB2 uses a timestamp data type, Informix and SQL Server use a datetime data type, Oracle uses a date data type, and PostgreSQL uses a timestamp without time zone data type. ArcSDE type

DB2

Informix

Oracle

SQL Server

PostgreSQL

SE_STRING_TYPE

CHAR, VARCHAR

CHAR, VARCHAR

VARCHAR2(size)

CHAR, VARCHAR

VARCHAR (character varying)

SE_NSTRING_TYPE

na

na

NVARCHAR2(size) NCHAR, NVARCHAR

na

SE_NCLOB_TYPE

na

na

NCLOB

NTEXT

TEXT

SE_INT16_TYPE (SE_SMALLINT_TYPE)

SMALLINT

SMALLINT

NUMBER(n):

SMALLINT

SMALLINT

SE_INT32_TYPE (SE_INTEGER_TYPE)

INTEGER

INT

INTEGER

n can be in the range of 1 to 5. INTEGER

NUMBER(n): n can be in the range of 5 to 10; however, if created with the sdetable -o create operation o, int32 results in NUMBER(38).

106

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

ArcSDE type

DB2

Informix

Oracle

SE_INT64_TYPE

BIGINT

INT8

NUMBER(n):

SE_FLOAT32_TYPE (SE_FLOAT_TYPE)

FLOAT

DECIMAL (precision < 7, scale > 0)

NUMBER(n,m):

SE_FLOAT64_TYPE (SE_DOUBLE_TYPE)

DOUBLE

FLOAT

NUMBER(n,m)

SE_DATE_TYPE

TIMESTAMP

DATETIME

DATE

DATETIME

SE_UUID_TYPE*

NCHAR, (UUID NCHAR LEN)

NCHAR(38)

UNIQUEIDENTIFIER VARCHAR(38)

SE_BLOB_TYPE

BLOB

LONG RAW

IMAGE

BYTEA

INT

ST_GEOMETRY or GEOMETRY

NOTE: The server configuration parameter INT64TYPES must be TRUE to create columns with this data type.

BLOB

SQL Server

BIGINT, NUMERIC n can be in the range (precision < 19, scale = 0) of 10 to 38.

PostgreSQL BIGINT

NUMERIC (precision REAL n can be in the range < 7, scale > 0) of 1 to 7, m is 127 or less. NUMERIC (precision NUMERIC (n,m) n can be in the range > = 7, scale > 0) of 7 to 38, m is 127 or less. TIMESTAMP WITHOUT ZONE

BLOB SE_SHAPE_TYPE

ST_GEOMETRY ST_GEOMETRY NUMBER(38) SDO_GEOMETRY ST_GEOMETRY Oracle data type depends on the geometry storage chosen for the layer: compressed binary or well-known binary = NUMBER(38); Oracle Spatial = SDO_GEOMETRY; Spatial Type = ST_GEOMETRY.

PostgreSQL data type depends on the geometry chosen for the layer: Spatial Type = st_geometry, PostGIS = geometry

*The unique identifier field will be created as NCHAR in Oracle and SQL Server if the configuration keyword with which you specified the table's creation had the parameter UNICODE_STRING set to TRUE. Go to the following topics to see the ArcGIS to DBMS type mapping for a particular DBMS: DB2 data types Informix data types Oracle data types PostgreSQL data types SQL Server data types

107

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Section 25 Oracle data types Note: This topic was updated for 9.3.1. When you create a feature class or table in ArcGIS, there are 11 different data types available for each column. These types are mapped to Oracle types in the following table: ArcGIS data type

Oracle data type

Notes

OBJECTID

NUMBER(38)

NOT NULL

SHORT INTEGER

NUMBER(4)

LONG INTEGER

NUMBER(38)

FLOAT

NUMBER(38,8)

DOUBLE

NUMBER(38,8)

TEXT

NVARCHAR2 or VARCHAR2

DATE

DATE

BLOB

BLOB

GUID

CHAR(38)

GEOMETRY ST_GEOMETRY*

This field will be NVARCHAR2 in the database only if your geodatabase is using Unicode storage; otherwise, VARCHAR2 is used.

Oracle data type depends on the geometry storage specified for the layer.

NUMBER(38) SDO_GEOMETRY RASTER

BLOB

Oracle data type depends on the raster storage specified in the DBTUNE table.

LONG RAW SDO_GEORASTER

* ST_Geometry is a superclass. The actual data subtype created (such as ST_Multilinestring or ST_Point) depends on what type of feature class you create, whether polygon, line, point, multipoint, or multipatch.

Section 26 About geometry storage types Note: This topic was updated for 9.3.1. Physical storage of geometry for features is managed using standard data types. The geometry storage types available for you to use depend on what database management system (DBMS) you have. Some have spatial data types while others provide standard binary or binary large object (BLOB) storage types. A summary of the available storage types by DBMS are listed in the table below. DBMS

Geometry Storage

DB2

Spatial Extender ST_Geometry * —Geometry Object

◦ Utilizes extended spatial type for managing vector data

Spatial DataBlade —Geometry Object

◦ Utilizes extended spatial type for managing vector data

Informix

Column Type Notes

ST_Geometry *

◦ Based on the ISO SQL MM specification for spatial; built in concert with ESRI ◦ Based on the ISO SQL MM specification for spatial; built in concert with ESRI

108

Administering ArcSDE® for Oracle®

DBMS

Geometry Storage

Oracle

Spatial Type for ST_Geometry * Oracle —Geometry type

Configuring an ArcSDE geodatabase

Column Type Notes ◦ Utilizes extended spatial type for managing vector data ◦ Based on the ISO SQL MM specification for spatial ◦ Default geometry storage for ArcSDE for Oracle

Well-Known Binary (OGCWKB)

BLOB

ArcSDE Compressed Binary

LONG RAW or Provides high performance, scalability, and reliability BLOB

Oracle Spatial —Geometry Type

SDO_Geometry Oracle Spatial users can optionally use the SDO_Geometry column type. You can make this decision on a table by table basis, so you can choose the best option for each individual dataset.

PostgreSQL Spatial type for PostgreSQL

ST_Geometry *

OGC simple features type

◦ Utilizes extended spatial type for managing vector data ◦ Based on the ISO SQL MM specification for spatial ◦ Default geometry storage for ArcSDE for PostgreSQL

SQL Server**

PostGIS

Geometry

ArcSDE Compressed Binary

Image

PostGIS users can choose to use the PostGIS geometry column type. This type follows the OpenGIS Simple Features Specification for SQL. ◦ The binary type fully manages complex binary streams required for complex line and polygon features found in typical and advanced GIS applications. ◦ The default geometry storage for ArcSDE geodatabases for SQL Server.

Well-Known Binary (OGCWKB)

Image

OGC simple features type

Microsoft SQL Geometry Server Geometry type

◦ One of the Microsoft SQL Server spatial storage types

Microsoft SQL Geography Server Geography type

◦ One of the Microsoft SQL Server spatial storage types

◦ Provides a spatial type for managing vector data that is defined by coordinates on an arbitrary plane and for which the curvature of the Earth does not need to be taken into account ◦ Provides a spatial type for spatial data that is defined by latitude and longitude coordinates and for which the curvature of the Earth does need to be taken into account

* ST_Geometry is a superclass comprising several instantiable subclasses. **Geodatabases created on database servers (SQL Server Express instances) use the ArcSDE compressed binary storage type; you cannot specify another geometry storage type. For DBMSs that allow multiple types of storage options, you could use any combination of available storage methods. For example, you may choose to store a point layer as Oracle Spatial geometry type and a polygon layer as ST_Geometry type. That is where the geometry configuration parameters of the DBTUNE table come in. For geodatabases stored in Oracle, SQL Server, or PostgreSQL, there are configuration values you can set to specify which geometry storage to use. To set the default geometry storage type—the one that you would use for most of your data—you would alter the value of the GEOMETRY_STORAGE parameter under the DEFAULTS configuration keyword in the DBTUNE table. You can also create separate geometry storage keywords that specify different geometry storage types. You can then use these keywords when creating or importing data to the geodatabase, thereby storing that data using a storage type other than the one specified in DEFAULTS. Spatial types

109

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

A spatial type embeds support for GIS feature geometry into the DBMS kernel. Some DBMSs that support spatial types comply with the OpenGIS SQL specification for user-defined types (UDTs) and the ISO SQL Multimedia Spatial Standard. These standards define columns capable of storing spatial data such as the location of a landmark, a street, or a parcel of land. Use of these spatial types integrates geometry and nonspatial attributes, providing a single point of access inside the DBMS through a SQL API. Informix and IBM DB2 support spatial types. The Spatial Type for Oracle and PostgreSQL, which use an ST_Geometry type, are also spatial types, as is Oracle Spatial and the PostGIS geometry type. For spatial types, geometry is stored in the business table. NOTE: ESRI recommends you do not use SQL commands to alter the geometry storage type of a dataset after it has been created.

Section 27 Configuring Oracle Net Services to use ST_Geometry SQL functions Note: This topic was updated for 9.3.1. The SQL functions of the spatial type for Oracle (ST_Geometry) use shared libraries that are accessed via Oracle's external procedure agent, or extproc. The spatial type for Oracle requires these libraries during SQL to spatial type functions. They are not used when accessing ST_Geometry columns through ArcSDE. The Oracle listener must be configured to call functions in these libraries through Oracle's external procedure framework. While it is not strictly required unless you are planning to use the SQL functions, it is recommended that you perform this configuration. Oracle listeners are highly configurable. For example, there may be multiple listeners associated to your database, and each listener can manage multiple types of service requests. This is a complex topic, the many variations of which are not covered in this document. It is important that you refer to the Oracle Database Net Services Administrator's Guide for details about configuring your listeners.

How ST_Geometry function calls work Functions are implemented in PL/SQL, which in turn calls functions written in the C programming language stored in external shared library files. The functions are called from PL/SQL using an alias name that maps the name of the library—in the case of the spatial type for Oracle, ST_SHAPELIB—to the name of the library file. (See the documentation for the Oracle CREATE LIBRARY command for details.) The first time a spatial type function is called that needs something from ST_SHAPELIB, the database requests the listener to spawn an extproc process for the SQL session. The extproc is given the location of ST_SHAPELIB, the name of the function to be called, and its parameters. The extproc loads ST_SHAPELIB and calls the function. If the external function calls functions in other external libraries, such as the Geometry library (sg) or the Projection Engine library (pe), those libraries are also loaded by the extproc. When the external function completes, the extproc returns the results and remains active, waiting for additional function calls during this session. The extproc process terminates when the SQL session disconnects. To make this work, the following configuration is needed: ◦ The database needs to know the location of the file containing ST_SHAPELIB so it can pass this information to the listener process and on to the extproc. In most cases, this is done for you by the ArcSDE installation process. ◦ The database must know of the service that handles requests to the extproc. This is configured in the file tnsnames.ora. ◦ The extproc must be allowed to load the file containing ST_SHAPELIB. This is done by defining the environment variable EXTPROC_DLLS in the file listener.ora.

110

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

◦ The location of the Geometry and Projection Engine libraries must be added to the list of locations from which shared libraries can be loaded. On UNIX systems, this means the location must be defined in LD_LIBRARY_PATH (or SHLIB_PATH or LIBPATH, depending on your operating system). The environment variable must be defined for the extproc in the file listener.ora. ◦ The extproc (usually running as the user that owns ORACLE_HOME) must have read permissions on the location of the library files and execute permissions on the files. ◦ After its configuration is changed, the listener must be restarted.

Configuring the listener Telling the extproc where to find the shared libraries is the most important aspect of configuring the listener. You need to modify the listener configuration to specify the location of the shared libraries and restart the Oracle listener process so the configuration changes will take effect. Two standard Oracle Listener configuration files are involved: tnsnames.ora and listener.ora. These files usually reside in ORACLE_HOME/net/admin. This document presents the configuration settings that are needed. There are several ways to manage the settings. You can edit the text files with a text editor, use the Oracle Net Manager, or use the Oracle Net Configuration Assistant. Oracle provides documentation about how to configure the listener. Please refer to the Oracle Database Net Services Administrator's Guide for details. Before making any changes, make backup copies of the files tnsnames.ora and listener.ora.

Configuring tnsnames.ora The file tnsnames.ora contains a directory of known database services. This file can define services on the local database or on remote servers. One entry is specifically for use by the local database server to use interprocess communications (IPC) to send function calls to the extproc. This entry is labeled EXTPROC_CONNECTION_DATA. Here is an example as it appears in the file tnsnames.ora. (Please note that this will probably not be the only entry in the file.) EXTPROC_CONNECTION_DATA = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(Key = EXTPROC1)) ) (CONNECT_DATA = (SID = PLSExtProc) (PRESENTATION = RO) ) )

◦ EXTPROC_CONNECTION_DATA This entry must always have the label EXTPROC_CONNECTION_DATA. ◦ Key and SID The two items in this entry that could be changed are the name of the key (EXTPROC1) and the SID (PLSExtProc). These items are used to link this entry to corresponding information in the file listener.ora. The key can be any short name but must be the same in both the listener.ora and tnsnames.ora files. These values are case sensitive. They are used only by the listener process and not by users or applications.

Configuring listener.ora The file listener.ora describes some (not necessarily all) of the services for which the listener listens for requests. This example uses the same listener for the extproc as for connection requests for the database. Other configurations are possible. 111

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

NOTE: This is a sample only and may be different for every database instance. SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = C:\oracle\product\10.2.0\db_1) (PROGRAM = extproc) (ENVS="EXTPROC_DLLS=C:\ArcSDE\sdeexe93\bin\st_shapelib.dll") ) (SID_DESC = (SID_NAME = sde93) (ORACLE_HOME = C:\oracle\product\10.2.0\db_1) (GLOBAL_NAME = sde93) ) ) LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1)) (ADDRESS = (PROTOCOL = TCP)(HOST = svr1.dmn1.com)(PORT = 1521)) ) )

◦ SID_LIST_LISTENER This label begins a list of SIDs to be handled by the listener named LISTENER (the default listener name). ◦ SID_LIST and SID_DESC The example above defines two services, which are listed as two SID_DESC entries under the heading SID_LIST. The first in the list (PLSExtProc) handles extproc requests, and the second (sde93) handles client sessions. ◦ SID_NAME = PLSExtProc This corresponds to the SID specified for the extproc in the file tnsnames.ora. ◦ ORACLE_HOME This defines the location of the Oracle home for this service. The extproc program files load from a folder beneath this location. ◦ PROGRAM This specifies the file name of the extproc executable file. This case-sensitive name might be extproc or extproc.exe depending on the operating system type. The file is located in ORACLE_HOME/bin. ◦ ENVS This is a list of environment variables that the extproc uses when it runs. The list is colon delimited. This list must include a definition of the environment variable EXTPROC_DLLS (see below) and any other environment variable the extproc needs when it runs, often including LD_LIBRARY_PATH on UNIX and Linux systems. LD_LIBRARY_PATH often includes the location of the Geometry and Projection Engine libraries. ◦ EXTPROC_DLLS This environment variable defines a list of libraries that the extproc can load and call functions from directly. The path to the file containing ST_SHAPELIB must be specified here. The Geometry and

112

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Projection Engine libraries are not included in this list because the extproc does not call functions in them directly. The list is colon delimited. All paths must be absolute. There is no environment variable substitution. The optional keywords ANY and ONLY can be used to loosen or restrict the way the extproc uses library files. In many cases, neither keyword is needed. ◦ KEY = EXTPROC1 The name in the example, EXTPROC1, links this listener with the corresponding service entry in the file tnsnames.ora. It distinguishes this listener from other IPC listeners that might be present on the same database server. The key can be any short name but must be the same in the files listener.ora and tnsnames.ora. The key is case sensitive.

Section 28 Locators in the geodatabase Note: This topic was updated for 9.3.1. A locator is an object that you can use to convert textual descriptions of locations into geographic features. The most common locator is an address locator, which you can use to geocode addresses. See An overview of geocoding in the "Geocoding and address management" section of the help for an introduction to geocoding. ArcSDE stores locator definitions in the Locators system table. Three main types of locators can be stored in an ArcSDE geodatabase: ◦ Locator styles—Used as templates on which to base new locators ◦ Locators—Defines the inputs, outputs, logic, and one or more reference datasets that are used to find locations Locators are usually created by adding properties to a locator style that specify which reference datasets and which columns in those reference datasets to use to find locations. Using ArcCatalog to create a locator based on a locator style is the easiest way to create a new locator, but you can also use ArcToolbox geocoding tools. See Creating an address locator in the "Geocoding and address management" section of the help to learn how to create a new locator. ◦ Attached locators—Copies of properties of the locators that were used to create a geocoded feature class When you create a geocoded feature class by geocoding a table of addresses using an address locator, ArcSDE stores a copy of the locator properties that were used to create the geocoded feature class. ArcSDE uses this attached locator when you rematch addresses in the geocoded feature class. Each locator style, locator, and attached locator has a number of properties that define the locator. ArcSDE stores each property of a locator as a record in the Metadata system table. NOTE: To use an ArcSDE address locator—a geocoding service—a user must have SELECT privileges on the reference datasets and geocoding index tables used by the address locator. Only the owner of the ArcSDE dataset can grant privileges to the dataset. For a description of the locator schema, see the topic appropriate for the DBMS you are using. Locators in a geodatabase stored in DB2 Locators in a geodatabase in Informix Locators in a geodatabase stored in Oracle Locators in a geodatabase in PostgreSQL Locators in a geodatabase in SQL Server 113

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Geocoding rules Address locators use a set of geocoding rules that define how addresses are parsed, standardized, and matched to the reference data used by the address locator. ArcSDE stores geocoding rules in the GCDRULES table. Each row in the GCDRULES table corresponds to a single file in a set of geocoding rules. Beginning with ArcSDE 9.2, ArcSDE allows you to store a copy of geocoding rules inside the locator, thus making it independent of any modification made to the GCDRULES table.

Section 29 Language support in the geodatabase Note: This topic was updated for 9.3.1. Beginning with ArcGIS 9.2, character data types in ArcSDE geodatabases are enabled for Unicode, which allows you to more easily work with multiple languages. See An overview of Unicode in the "Defining the properties of a geodatabase" section of the help for a definition of Unicode. By default with ArcGIS 9.2 and later releases, character data is created with Unicode encoding in SQL Server and Oracle databases unless you set the DBTUNE parameter UNICODE_STRING to false under the DEFAULTS configuration keyword . In Oracle databases, if you want to disable Unicode character encoding, you need to add the UNICODE_STRING parameter to the DBTUNE table. Use the sdedbtune –o insert command to add the UNICODE_STRING parameter to the DEFAULTS keyword. To disable Unicode character encoding in SQL Server databases, use the sdedbtune –o alter command to change the value of the UNICODE_STRING parameter to FALSE. For details on and syntax for the sdedbtune parameter, consult the ArcSDE Administration Command Reference provided with the ArcSDE component of ArcGIS Server Enterprise. The UNICODE_STRING parameter is not used with DB2, Informix, or PostgreSQL databases. To enable Unicode character encoding in a new DB2, Informix, or PostgreSQL database, specify a code set of UTF-8 when the database is created. To enable Unicode character encoding in an existing DB2 or Informix database, you must alter the database collation using SQL. Consult your DB2 or Informix documentation for information on setting or changing the collation of a database. The encoding for a PostgreSQL database cannot be changed after it is created. For more database-specific language information, see the following topics: ◦ Language support for DB2 ◦ Language support for Informix ◦ Language support for Oracle ◦ Language support for PostgreSQL ◦ Language support for SQL Server

Section 30 Language support for Oracle Note: This topic was updated for 9.3.1. If you create a database using the database configuration assistant (DBCA), Oracle sets the default character set according to the operating system locale settings. You can change the character set during the database creation based on your needs. The character set is selected when the database is created with the CREATE DATABASE statement and cannot be changed afterward. To change a character set, the database must be re-created and the

114

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

data reloaded. Consult the Oracle National Language Support Guide for your Oracle release to determine the character set that is right for your data. If you have upgraded your database and client applications to ArcGIS 9.2 or greater, you do not have to set the NLS_LANG variable on the client. However, if you are using a server and/or client prior to ArcSDE 9.2, to properly convert and preserve the characters, you must set the Oracle NLS_LANG variable in the client application's system environment. Consult the ArcSDE 9.1 Configuration and Tuning Guide for Oracle .pdf file installed with ArcSDE for information on setting this variable. Tip ◦ For a complete list of character encoding standards supported by your Oracle database and their naming conventions, please refer to the Oracle National Language Support Guide .

Section 31 XML columns in the geodatabase Note: This topic was updated for 9.3.1. ArcSDE handles XML data nearly the same way it handles spatial GIS data. A business table can have one or more columns of type XML. These columns can store XML documents that contain structured information such as descriptions or classifications of spatial features. XML documents are also useful for storing longer text descriptions than are typically stored in a column, and text indexes built on those descriptions let you search for features using their content. For example, ArcIMS Metadata Services use XML columns to create a searchable collection of documents that describe GIS resources. An XML column will always have a full-text index that lets you search for a word anywhere in a document. The column may optionally have an XPath index that lets you search for a word or a number in a specific XML element or attribute. Functionality for full-text indexing must be installed and configured in the database before an XML column can be created. See Configuring a database to support XML columns to get started. Information about an XML column is maintained in an ArcSDE system table named xml_columns. Information about an XML column's XPath index is maintained in the ArcSDE system tables xml_indexes and xml_index_tags. For each XML column, ArcSDE creates additional tables, which are used to store and index XML documents. ◦ The XML document table (sde_xml_doc) stores the XML document and maintains a full-text index on the document's content. ◦ The XML index table (sde_xml_idx) is created for XML columns that have an XPath index. This table stores the text or number content for each XPath that is indexed and maintains a full-text index on the content from some XPaths. The ID number in the table names of the XML index table and XML document table is the internal registration number for the XML column.

115

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

To see further details on the tables used to track XML columns in the database, see the following topics: XML columns in a geodatabase stored in DB2 XML columns in a geodatabase in Informix XML columns in a geodatabase stored in Oracle XML columns in a geodatabase stored in PostgreSQL XML columns in a geodatabase in SQL Server For information on configuration parameters that control the storage of these tables, see DBTUNE configuration parameter name-configuration string pairs . ArcSDE for Oracle includes two scripts to help you configure your database to store XML data. See Tuning an Oracle instance for XML data storage for details.

How XML documents are indexed ArcSDE XML columns always have a full document index. The XML document table stores the original XML document and also a copy of the document's content with the XML markup removed. A database text index is created on the document's content without XML markup. This index lets a search quickly find all documents that contain a given word or phrase, such as "population," anywhere in the text. ArcSDE XML columns may optionally have an XPath index as well. XPath is a language used to identify specific parts of an XML document. An XML column's XPath index is created from an index definition that uses XPath notation to identify the elements and attributes in the column's XML documents that can be searched. Each XML column can use a different index definition to build its XPath index. An XML column's XPath index can be created and managed using ArcObjects; if you are using an Enterprise geodatabase, it can also be created and managed using the sdexml administrative command. For example, suppose documents in the XML column describe a feature's source and the documents include an accuracy element that stores a number indicating the accuracy of the source in meters. Building an XPath index that includes the accuracy element would let you find all the features whose source accuracy is greater than a given value. The XPath index should only include elements and attributes in the XML documents that are available to be searched by a client application. Keeping the XPath index small will improve the XML column's performance. By default, an XML column will not have an XPath index. If you don't need to search individual XML elements or attributes, there is no need to create an XPath index. If you do create an index definition, you must specify not only which XML elements and attributes, or XPaths, will be indexed but also how their values will be indexed. Each XPath is assigned a data type that is appropriate 116

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

to the type of content it contains. Each XPath can be indexed as a number, as a short character string, or using a database text index. These are discussed in more detail below. The XPath index is really a collection of numeric, character, and text indexes. When an XML document is stored, it is checked to see if it contains any of the elements or attributes in the column's XPath index definition. If so, the content of those XPaths is extracted from the document and added to a text, character, or numeric index depending on the data type of the XPath in the index definition.

About database text indexes One of the advantages to storing information in XML documents is being able to use database text indexing and searching functionality to search those documents. Text indexes can provide better search results for large amounts of text and shorter text that has a large amount of variation between documents. Text indexes use linguistic analysis when matching the search phrase to the document's content and typically use relevance ranking to order the results based on the quality and frequency of those matches. When the database builds a text index, it evaluates the original text and includes words in the index based on the indexing rules and database settings that are in place. Typically, words that have meaning, such as "river," "pollution," and "population," will be included in the text index, but words such as "and," "the," and "in" won't be included. Words may be indexed so searching with the word "fishing" would also match the words "fish," "fished," and "fisher"; this is known as stemming. Stemming is just one example of the advanced text indexing and searching methods that databases typically provide. Each database may use different rules or algorithms to index the same text and may therefore produce different results with the same data. Also, each database may use different text indexing methods by default; for example, stemming may be performed by default in one database while in another database it must be enabled. Review the text indexing documentation for your database and set the database and the DBTUNE configuration parameters properly to achieve the desired results for your XML column. Different rules are used to index text written in different languages. For example, the words that are left out of the text index will be different in English and French such as "et," "le," and "dans." Also, what defines a word is different in some languages; Western languages typically define a word as all the text between two spaces, but different rules may be used in German, Asian, and other languages where the text between two spaces may be a phrase. Different databases may support different languages for text indexing, and all text indexing methods may not be available in all languages. All documents in an XML column must contain text in the same language. The database text indexing components and the DBTUNE configuration parameters must be properly configured for that language in those XML documents to be indexed and searched correctly. The language used for text indexing may have to be configured separately from other language settings in the database. Different databases approach text index updates in different ways. When a new XML document is stored in an XML column, the full text of the document and the content of any XPaths handled with a database text index will have their values extracted from the document and stored in the appropriate places. However, by default the database may not immediately process and analyze the text and then update the text indexes. This is generally a good thing. If many documents containing a lot of text are added to or updated in an XML column, the resources required to index the new text may decrease the performance of other database applications.

XPath index definition data types In the XPath index, document content may be included in a text, character, or numeric index; this corresponds to the data types STRING, VARCHAR, and DOUBLE in the XPath index definition. If an XPath's data type is STRING, content in that element or attribute is indexed using a text index. XPaths with the data type VARCHAR will have their content placed in a regular character column and indexed as they would be in a typical database table. XPaths with the data type DOUBLE will have their values placed in a numeric column and indexed. An XPath index data type is not provided for dates.

117

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

When new documents are published, you can find them right away with searches evaluated using XPaths indexed as VARCHAR or DOUBLE. You will not be able to find new documents with searches against XPaths indexed as STRING (or the full document text index) until the database's text indexes have been updated to include information from the new documents. Choosing STRING or VARCHAR for an XPath If the domain of an XPath will always be a short string or a word or phrase from a list, consider indexing the element as VARCHAR. When an XPath contains a text code or a one-word entry, you are often looking for an exact match between the search string and the entire content of the XPath; an application that searches an XPath like this will often provide a list of values to choose from. This type of information is better handled with the VARCHAR data type; the exact match will be faster and the content of an XPath will consume less space in the database than if the same content was indexed as STRING. However, all values stored in an XPath indexed as VARCHAR must be no more than 254–256 characters long depending on the database. Attempts to store an XML document will fail if the document includes an XPath that is indexed as VARCHAR and the content of the XPath is too long. Text indexing is better suited for searching XPaths containing text that can be freely entered by a person, even if the text isn't very long. The linguistic analysis performed with a text index may produce better results searching that type of content than traditional searches against a character column. An XML column's full document text index lets you find a word anywhere in the document. Sometimes a search needs to be more focused than that. For example, if the XML column contains information describing different GIS resources and you want to be able to find all work your organization produced for a project, you might include an element describing the purpose of the resource in the XPath index, and searches by project would look for references to the project name only in that element. This may make searches by project more accurate if the words used in project names may be used in different contexts. Elements describing concepts like the purpose of a resource are typically best handled by database text indexes. Both VARCHAR and STRING XPaths can be searched using wildcard characters, but the wildcard character supported by the database may be different for these two data types in the same database. Also, the way in which wildcard characters can be used and the performance of the search may be different for each data type. Check your database documentation to determine what characters can be used as wildcards and how they can be used. For XPaths indexed as STRING, you may not need to use wildcard characters if stemming is performed during text indexing; if stemming is not performed and wildcard characters are used often in searches, consider adding this capability to your XML column's text indexes to improve search performance. Indexing numbers If an XPath contains numbers, indexing them as DOUBLE lets you evaluate their contents numerically. For example, if an element contained the scale denominator of the source data for a feature, such as 24,000, you would be able to find all features whose source data was at a scale greater or less than a given value. If an XPath's data type is DOUBLE in the XML column's index definition but a document contains text in that XPath instead, the document will be stored successfully, but the value in that XPath won't be included in the XPath index and a conflict will be recorded in the geodatabase. An error noting this conflict will appear in an ArcSDE service log file if verbose logging is enabled for the geodatabase. For the element containing the scale denominator of the source data, the value "24000" will index successfully but the values "1:24000" and "1/24000" will not. The presence of the colon (:) and slash (/) characters means the values can't be manipulated as numbers. Similarly, for elements containing the percent cloud cover in an image or the cost of a resource that are indexed as DOUBLE, the values "10%" or "$50" would not be indexed and conflicts would be recorded. In contrast, if a value will be indexed as text and a document contains a number in that metadata element, the number will be handled as text; a conflict won't be recorded.

The XPath index definition file 118

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

An XPath index is defined using a text file that contains a general description of the index definition and a list of XPaths. A default index definition file is not provided; the contents of an XML column's XPath index depend entirely on the nature of the XML documents it contains and their intended use. The anatomy of an index definition file The following example is an excerpt from an XPath index definition used with a collection of documents that describe GIS resources. The individual components of the index definition file are described below. DESCRIPTION: ISO 19115 metadata collection index ##TAG LOCATION PATH: /metadata/dataIdInfo/idPurp DESCRIPTION: Purpose of the resource DATA TYPE: STRING EXCLUSION: FALSE END ##TAG LOCATION PATH: /metadata/distInfo/ditributor/distorFormat/formatName DESCRIPTION: Format of the resource DATA TYPE: VARCHAR EXCLUSION: FALSE END ##TAG LOCATION PATH: /metadata/dataIdInfo/tpCat/TopicCatCd/@value DESCRIPTION: Topic category code DATA TYPE: DOUBLE EXCLUSION: TRUE END

In this example, an XML element containing information about the purpose of the resource is added to the database text index; longer text authored by a person is better indexed in this manner. An XML element containing the format of the data, map, service, or other resource is added to the character string index; short, brief text is better indexed in this manner, particularly if the values originate from a fixed domain and you want to search the XML column for an exact match. Also, an XML attribute containing a numeric code identifying the theme of the resource, such as agriculture, oceans, or transportation, is ready to be indexed as a number but is currently excluded from the XPath index. ◦ XPath index description— The purpose of the XPath index. If present, the description must be provided on the first line in the file following the text "DESCRIPTION:". Descriptions must be no longer than 64 characters in length; longer text will be truncated to 64 characters. ◦ Set of tags— A list of XPaths, or tags, whose contents can be searched. Each tag must be defined by a set of properties that are preceded by a line with the text "##TAG" and are followed by a line with the text "END". No other text can be present on either of these lines; they signify the beginning and ending of the list of properties that define a tag. Each tag can have the following properties. Only one property can be defined on each line. Tag properties can be defined in any order. ▪ Tag location— An XPath that identifies the absolute location of an XML element or attribute in an XML document; other parts of an XML document cannot be indexed. When an XML document is stored, if an element or attribute in the document has an XPath that exactly matches the XPath of a tag in the XML column's index definition, its content will be indexed. This property is mandatory and must be provided on a line beginning with the text "LOCATION PATH:".

119

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

The XPath must begin with a forward slash (/) followed by the document's root element, and it must not use XML namespaces. If an XPath includes an asterisk (*) to identify a set of nodes or square brackets ([]) to include subqueries that conditionally select tags, attempts to create an XPath index on an XML column will fail. XPaths must be 254–256 characters in length or less, depending on the database being used. If an index definition has an XPath longer than is supported by your database, attempts to create an XPath index for an XML column will fail. ▪ Tag description— A brief overview of the information contained by the tag. Descriptions are optional. They may help someone edit the index definition later. Descriptions must be no longer than 64 characters in length; longer text will be truncated to 64 characters. If provided, this information must be on a line beginning with the text "DESCRIPTION:". ▪ Tag data type— A value indicating how to index the tag's content. Valid values are STRING, VARCHAR, or DOUBLE; these indexing options are discussed in detail in the sections above. A data type is optional. If provided, this information must be on a line beginning with the text "DATA TYPE:". If not provided, the tag's content will be indexed as STRING and included in the text index. ▪ Tag exclusion— A value indicating if the tag's content should be included in or excluded from the XPath index. Valid values are FALSE or TRUE. When FALSE, the tag is included in the XPath index and its content is indexed. When TRUE, the tag's definition is stored in the geodatabase but is excluded from the XPath index, and its content will not be indexed. While prototyping or modifying a client application, it can be helpful to keep a tag in the index definition even though it isn't currently being used. An exclusion value is optional. If provided, this information must be on a line beginning with the text "EXCLUSION:". If not provided, the tag will be included in the XPath index.

Modifying the XPath index You can change an XML column's index definition at any time. To do so, modify the index definition file by adding, removing, excluding, or modifying tags as appropriate. For example, if you want to change a client application to add new search criteria, you must add the corresponding XPaths to the index definition file. Next, you must alter the XML column's index definition using the updated file. The index definition recorded in the sde_xml_index_tags table is modified, leaving existing tags alone or modifying them and adding or removing tags as appropriate. Then, the indexed values in the XML index table must be updated. If tags are added or if existing tags have their data type changed, all documents in the XML column will be opened and examined and values in those tags will be indexed properly. Values associated with tags that have been removed will be removed from the XML index table. If any existing tags remain the same, their indexed values will remain untouched. Afterwards, the text index associated with the XPath index must be updated to reflect any changes. The full document text index will remain unchanged.

Indexing, searching, and performance Many properties of an XML column affect how indexing and searching function and perform in different ways. The performance of your client applications and the database itself can be affected by how you elect to configure and maintain the XML column's content. After reviewing the information below, you should work with your database administrator and integrate database maintenance tasks that are specific to your XML column with other routine database maintenance operations in a way that best suits your organization. Storing XML documents

120

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

XML columns will be stored compressed in the database by default; this is the recommended storage option. However, you might choose to store XML documents uncompressed to make them available to other database applications; this can be accomplished by changing the DBTUNE configuration parameters used at the time an XML column is created. However, when stored uncompressed, XML documents consume more storage space and returning the documents found by searches will be slower because of the larger volume of data that must be handled. When new documents are stored in an XML column, the original copy of the document is stored. A copy of the document is created and all XML markup is removed, then the remaining content from the document is stored for inclusion in the full document index. The original document is checked to see if it contains any XPaths included in the XPath index definition, if one exists. If so, the values of those XPaths are extracted and indexed. Storing a large number of XML documents at once can impact the performance of your application and the database. If you know a large number of documents will be added or updated at once, consider planning for that operation to occur when there is less demand on the database such as in the early morning or the evening. Indexing and searching XML documents After a document is stored, it can be searched immediately using XPaths indexed as VARCHAR and DOUBLE. For the full document index and XPaths indexed as STRING, the database may not immediately process and analyze the new text and then update its text indexes; documents can't be searched with criteria based on these indexes until their information has been included in them. There are two aspects to consider in determining when you will be able to find new documents using the text indexes: when updates to the text indexes will begin and how long they will take. When the text indexes are updated depends on the database and how it is configured for text indexing. Different databases have different options that determine when text indexes are updated. Some databases automatically update the text indexes by default; others require updates to be started manually, though typically you can create a scheduled job to start the updates at a given time or after a given interval. It is important to note that if the database updates the indexes automatically, the indexes may not be updated immediately; the database typically chooses an appropriate time to index the text based on the amount of resources that are available. If your database doesn't automatically update the text indexes, you may be able to use DBTUNE configuration parameters to override the default settings and define a time or interval when the text indexes will be updated for your XML column; otherwise you will have to use the database's tools to create and schedule a text indexing job. Follow the recommendations provided in the database documentation regarding the best method or time interval for updating text indexes in your database. If no clear recommendations are made, schedule text index updates to occur nightly. The text indexing process can consume a lot of database resources; running this operation during the day could slow down many applications depending on the database. The length of time required to update the text indexes depends on the amount of database resources available, the amount of text in each XML document, the number of XPaths indexed as STRING and how much text they contain, the total number of new or modified documents in the XML column, and how text indexing is configured for that XML column. Indexing the text during off-peak hours will complete more quickly if more database resources are available when other applications are not being used. By default, text indexes will typically be configured for incremental updates. This means the database tracks changes that have been made to the XML column's documents. Only documents that are new or have changed since the last update to the text indexes will be processed the next time the text indexes are updated. It is not recommended to change this behavior; changing this would require processing all documents every time the text indexes are updated, which would take a significantly longer time. If you perform a type of linguistic analysis and index the results in advance, searches using that type of linguistic analysis will be faster. For example, adding indexes to support wildcard searches will make those searches faster. Adding more indexes for more types of linguistic analysis may produce faster and better search results,

121

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

but the trade-off is that indexing will take more time because more processing must be done in advance. Keep this in mind when determining the text indexing configuration you want to use for your XML column. While it may be desirable to update the text indexes more than once a day, this is not generally advisable. If you choose to update the text indexes more than once a day, carefully consider the length of time required to update the text indexes when determining the time interval between updates. You should not start one update before the previous one has finished or try to start one update immediately after the previous one has completed. There is no way to know what resources will be available, how much text must be updated, or what other operations will be affected at a given time. If you choose to update text indexes frequently while you are prototyping a client application, be sure to change the settings for your XML column to be appropriate for a production database before deploying your application. DBTUNE configuration parameters are only applied at the time an XML column is created. Changes to an XML column's settings, such as when its text indexes will be updated, must be handled directly in the database. The safest and most reliable method is to schedule text index updates nightly at an appropriate time in relation to other scheduled database maintenance operations. Optimizing the database text indexes The more often text indexes are updated, the faster they become fragmented. The more fragmented the text indexes are, the more the performance of searches on those indexes will degrade. Even if an XML column is updated nightly, the indexes will become fragmented over time. When the number of documents in an XML column has increased by approximately 25 percent, the text indexes should be optimized to reduce fragmentation and restore their optimal search performance. Depending on how your XML column is used and how often its contents change, you may want to automate optimizing its text indexes by scheduling a task in the database for this operation. For example, you might optimize the indexes monthly if that time interval is appropriate for your data. If a database doesn't support optimizing text indexes as a specific type of task, you can get similar results by completely rebuilding the text index, that is, reprocessing all documents in the XML column; this may be referred to as full population. You should optimize text indexes during off-peak hours. Consult the database documentation to learn more about text indexing options and updating, optimizing, and rebuilding full text indexes.

How to create and manage XML columns XML columns can be created and managed using ArcObjects. If you are using an Enterprise geodatabase, they can also be created and managed using the sdexml administrative command. These methods do not share the same options for managing XML columns. Custom code written using ArcObjects can store XML documents in an XML column, create and modify an XPath index for an XML column, search the documents in an XML column using the XPath index, and update the database text indexes to include the information in new XML documents. The sdexml administrative command lets you view individual documents in an XML column, create and modify an XPath index for an XML column, and provide statistics about the published documents and indexed XPaths. For Oracle databases only, an XML column's database text indexes can also be optimized; you can continue searching an XML column while the indexes are being optimized. See the ArcSDE administrative command reference for details about using the sdexml command. NOTE: The sdexml administrative command is only available if you are using an Enterprise geodatabase. For XML columns created to support an ArcIMS Metadata Service, ArcIMS provides additional utilities to create and modify an XPath index, update and optimize the database text indexes, and report conflicts where documents contain text in an XPath indexed as DOUBLE. See the ArcIMS help system for more information.

122

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Section 32 Configuring a database to support XML columns Note: This topic was updated for 9.3.1. One reason to set up full-text indexing in your database is to use ArcSDE XML columns such as with an ArcIMS Metadata Service. The database indexes and searches XML documents using its text indexing capabilities. Beginning with 9.3, ArcSDE XML columns are supported in DB2 (except on z/OS), Informix, Oracle, PostgreSQL, and SQL Server. Each database requires text indexing functionality to be installed and configured to create an XML column. In addition to enabling full text indexing, there are other DBTUNE configuration settings that need to be considered that will affect the language, storage, searching, and maintenance of an ArcSDE XML column. Definitions for these parameters can be found in the configuration parameter topics for each DBMS. Once an XML column has been created, many of its configuration settings can't be changed. Use the links below to learn about configuring a database to support text indexing and text searches. If the XML column will store documents written in a language other than the default for your DBMS, both the database text indexing components and the DBTUNE settings must be properly configured for your language. The following information can be found in the DBMS-specific "Configuring database to support XML" topics. DB2

Installing and configuring Net Search Engine

Informix

Installing text search DataBlade modules Configuring the database to search the contents of an XML column

Oracle

Installing and configuring the text component for Oracle Configuring the database to search the contents of an XML column

PostgreSQL Configuring the database to search the contents of an XML column SQL Server Installing and configuring the full-text search engine in SQL Server 2000 Installing and configuring the full-text search engine in SQL Server 2005 Installing and configuring the full-text search engine in SQL Server 2005 Express licensed for ArcGIS Server Enterprise Installing and configuring the full-text search engine in SQL Server 2005 Express licensed for ArcGIS Server Workgroup Configuring the database to search the contents of an XML column Managing database text indexes

Section 33 Configuring an Oracle database to support XML columns About configuring an Oracle database to support XML columns Note: This topic was updated for 9.3.1. ArcSDE XML columns require that Oracle Text for Oracle 10 g and Oracle9 i be installed and that user accounts granted privileges to use the Oracle Text components. Once this is accomplished, the database and ArcSDE must be properly configured and maintained to optimize search results and performance. In particular, the database and ArcSDE must be properly configured to support searching XML columns written in languages other than English. XML documents are stored in the database as an Oracle Large Object (LOB). The LOB storage and caching parameters, the tablespace's block size, and the buffer cache configuration all affect the speed at which LOB data is retrieved, which in turn, affects performance when searching. It is also important to manage the text indexes

123

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

properly to maintain good performance. ArcSDE for Oracle includes two scripts to help you configure your database to store XML data. See Tuning an Oracle instance for XML data storage for details. These steps are described in the following sections.

How to configure an Oracle database to support XML columns Install and configure the text component for Oracle 1. Follow the instructions in the Oracle documentation to install the appropriate text component for your version of the database. Oracle Text is installed by default with a typical installation of Oracle 10 g and Oracle9 i . However, if you upgraded an earlier version of the database for which the text component was not installed, Oracle Text may not be installed as part of the upgrade. If this is the case, it must be installed as an additional component after the upgrade is completed. 2. Follow the instructions in the Oracle documentation to verify the text component has been installed and is working properly. 3. Log in to SQL*Plus as the ctxsys user to grant privileges to the user who will own the XML column by issuing the command: sql>grant execute on ctx_ddl to ;

is the user who will own the column. For ArcIMS metadata services, is the user specified in the service's ArcXML configuration file. 4. If you plan to query a table using the contents of an XML column, check the default lexer that will be used for linguistic analysis with text indexes using SQL*Plus—this is particularly important when the column will contain XML documents with text written in a language other than English. If custom settings are not provided in the ArcSDE DBTUNE table, the default Oracle Text parameters will determine how text indexes are created for ArcSDE XML columns. The default objects used for text indexes are owned by the ctxsys user and are created for the database installation, not for individual databases. Their properties are set based on the language settings used when Oracle is installed; see the sections about system-defined preferences and system parameters in the Oracle Text Reference for your version of the database to learn how these properties are set. Check the default text settings to determine if custom preferences are required for your XML column. 1. Query the CTX_PARAMETERS view to determine what the default settings currently are for your Oracle installation. The parameters that affect ArcSDE XML columns are DEFAULT_LEXER, DEFAULT_STOPLIST, DEFAULT_STORAGE, DEFAULT_WORDLIST, and DEFAULT_INDEX_MEMORY. select * from ctx_parameters;

By default these parameters are typically set to the system-defined preferences with the same name that are owned by the ctxsys user or an appropriate value. For example, the DEFAULT_LEXER is typically set to use the preference CTXSYS.DEFAULT_LEXER. However, someone in your organization may have previously configured Oracle to use a custom preference by default instead. 2. Query the CTX_PREFERENCES view to learn about the available preferences. This is how you can learn which lexer is being used by the CTXSYS.DEFAULT_LEXER preference, for example. Any custom preferences created by other users will also be described. 124

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

select * from ctx_preferences;

For many Western European languages and for languages where a language-specific lexer is not provided, the CTXSYS.DEFAULT_LEXER preference will typically use the BASIC_LEXER lexer, the CTXSYS.DEFAULT_WORDLIST preference will often use the BASIC_WORDLIST wordlist, and so on. 3. To successfully index and search some Western European languages, specific wordlist settings are required. If your language is French you will want to make sure the stemmer and fuzzy_match attributes for the BASIC_WORDLIST preference are set to French, for example. Query the CTX_PREFERENCE_VALUES view to ensure the system-defined preferences are correctly set for the language of your XML documents. select * from ctx_preference_values;

4. Compare the results from the above queries to the allowed settings for lexers, wordlists, and other text objects documented in the Oracle Text Reference for your version of the database. If the current default settings are not correct for the language of your XML documents and existing custom text preferences are not available, you must create custom text preferences to correctly index and search your XML documents and reference those preferences using the ArcSDE DBTUNE XML_IDX_INDEX_TEXT parameter before creating your XML column.

Configure the database and DBTUNE parameters for an XML column Setting text indexing parameters After checking the current text settings in Oracle and consulting the Oracle Text Reference, you may want to customize the settings that will be used to index your XML documents. This requires creating the appropriate preferences in Oracle and then referencing those parameters with the ArcSDE DBTUNE parameter XML_IDX_INDEX_TEXT. Then, use the DBTUNE keyword containing the custom XML_IDX_INDEX_TEXT parameter when creating an XML column. For an ArcIMS Metadata Service you can reference a DBTUNE parameter in its ArcXML configuration file. ◦ Using a custom lexer Depending on the language of your XML documents and the settings at the time Oracle was installed, the DEFAULT_LEXER parameter may not be configured to use the best lexer for your situation. A lexer preference must be set correctly for your language to successfully index XML documents. For example, if the language you are working in is Thai, Oracle does not provide a Thai lexer and the DEFAULT_LEXER preference may be set to use the BASIC_LEXER lexer as a result. The BASIC_LEXER indexes and searches text using whitespace only, which may not offer the best results with a language such as Thai. If your XML documents are encoded as UTF-8, you may get better results using the WORLD_LEXER in this case if you are using Oracle 10 g or a newer version. All XML documents published to an ArcSDE XML column by ArcIMS Metadata Services are encoded as UTF-8. It may be helpful to review the system-provided text objects before creating custom preferences, for example, to be sure that the lexer you want to use is available with your Oracle installation. select * from ctx_objects;

If the WORLD_LEXER is available, you can create a custom text preference referencing this lexer as follows: 125

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

exec ctx_ddl.create_preference('WORLDLEXER', 'WORLD_LEXER');

To use this preference when creating an XML column, reference it in the XML_IDX_INDEX_TEXT DBTUNE parameter. Always preface the preference name with the user who created the preference. For example, if the geodatabase administrator logged in as the user "sde" when they created the preference, reference the preference in the XML_IDX_INDEX_TEXT parameter as follows. Anyone can use a text preference created by another user. LEXER sde.WORLDLEXER

If you can use the BASIC_LEXER to index your XML documents you may be interested in creating a custom lexer to merge text that includes non-alphanumeric characters into one word, for example. This can be accomplished using the printjoins attribute of the BASIC_LEXER, and would be useful to standardize indexing and searching of place names that use punctuation such as Coeur d'Alene. Creating a custom lexer using the BASIC_LEXER's skipjoin attribute with the apostrophe character would index Couer d'Alene as Couer dAlene. Also, any incorrect spellings of this place using extra apostrophes such as C'ouer d'Alene would also be indexed as Couer dAlene which could produce better search results. For example, you would create a text preference like this as follows: begin ctx_ddl.create_preference('BASIC_LEX_SKIP', 'BASIC_LEXER'); ctx_ddl.set_attribute('BASIC_LEX_SKIP', 'skipjoins', ''''); end; /

Use care when changing how punctuation is indexed. The same preference will be used when indexing all text in your XML documents. Values in one XML element may use punctuation differently than in others. A custom lexer preference may also be required in cases where the DEFAULT_LEXER is correctly set to use the BASIC_LEXER, but the attributes of the BASIC_LEXER are not correct for your language. The BASIC_LEXER attributes for index stems, composite word indexing, alternate spelling, and new German spelling must be set appropriately for your language to correctly index XML documents. This is particularly important for Western European languages. After checking the appropriate values for these attributes for your language in the Oracle Text Reference, create a custom lexer preference following the example above and then reference it in the XML_IDX_INDEX_TEXT DBTUNE parameter. ◦ Using a custom wordlist or stoplist Depending on the language of your XML documents and the settings at the time Oracle was installed, the DEFAULT_WORDLIST and DEFAULT_STOPLIST preferences may not have the correct configuration for your language. The wordlist preference must be set correctly for your language to successfully search XML documents. This is particularly important for Western European languages, where the BASIC_WORDLIST preference must have the correct language set for stemming and fuzzy matching. The stoplist preference controls which words in the XML documents will not be indexed and, therefore, not available for searching. Stoplists are available for several languages. You can also customize the stoplists if this is appropriate for your situation.

126

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

After checking the appropriate values for these settings for your language in the Oracle Text Reference, create a custom preference and then add it to the XML_IDX_INDEX_TEXT DBTUNE parameter's value.

Setting storage parameters for XML columns Many different DBTUNE parameters can be used to define the location in which objects associated with an XML column should be stored. An XML column will always have an XML document table, which stores the XML documents. A text index is always created on all content in these documents to support finding all documents containing a given word. Storage parameters for this table can be defined as follows. ◦ Storage parameters for the XML document table are defined with the XML_DOC_STORAGE parameter. ◦ Storage parameters for indexes on the XML document table's columns are provided with the XML_DOC_INDEX parameter. ◦ XML documents are stored in this table as large objects. Storage parameters for these large objects are defined with the XML_DOC_LOB_STORAGE and XML_DOC_VAL_LOB_STORAGE parameters, which are discussed in more detail in the section 'Configuring LOB storage'. An XML column may optionally have an XML index table, which stores the information in individual XML elements that can be searched. A text index is always created for this table to support searching descriptive text. Storage parameters for this table can be defined as follows. ◦ Storage parameters for the XML index table are defined with the XML_IDX_STORAGE parameter. ◦ Storage parameters for indexes on the XML index table's columns are provided with the XML_IDX_INDEX_PK, XML_IDX_INDEX_ID, XML_IDX_INDEX_TAG, XML_IDX_INDEX_DOUBLE, and XML_IDX_INDEX_STRING parameters. ◦ Information from the XML documents that is indexed as text is stored as large objects. Storage parameters for these are defined with the XML_IDX_TEXT_TAG_STORAGE parameter, which are discussed in more detail in the section 'Configuring LOB storage'. Typical storage parameters can be defined for all of the above tables and indexes with the exception of the specialized storage parameters for the large objects. However, storage parameters for an XML column's text indexes must be defined differently. With the default DBTUNE parameters, four tables are created to manage each text index. An Oracle text preference must be created to define storage parameters for these tables, then the storage preference must be referenced in the XML_IDX_INDEX_TEXT parameter. Both text indexes must use the same storage preference. The following example creates a text preference named "XML_STORAGE" that places any tables created for an XML column's text indexes into a tablespace named "TXTIDX". BEGIN CTX_DDL.CREATE_PREFERENCE('XML_STORAGE', 'BASIC_STORAGE'); CTX_DDL.SET_ATTRIBUTE('XML_STORAGE', 'I_TABLE_CLAUSE', 'TABLESPACE TXTIDX STORAGE (INITIAL 1K)'); CTX_DDL.SET_ATTRIBUTE('XML_STORAGE', 'K_TABLE_CLAUSE', 'TABLESPACE TXTIDX STORAGE (INITIAL 1K)'); CTX_DDL.SET_ATTRIBUTE('XML_STORAGE', 'R_TABLE_CLAUSE', 'TABLESPACE TXTIDX STORAGE (INITIAL 1K) LOB (DATA) STORE AS (CACHE)'); CTX_DDL.SET_ATTRIBUTE('XML_STORAGE', 'N_TABLE_CLAUSE',

127

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

'TABLESPACE TXTIDX STORAGE (INITIAL 1K)'); CTX_DDL.SET_ATTRIBUTE('XML_STORAGE', 'I_INDEX_CLAUSE', 'TABLESPACE TXTIDX STORAGE (INITIAL 1K) COMPRESS 2'); CTX_DDL.SET_ATTRIBUTE('XML_STORAGE', 'P_TABLE_CLAUSE', 'TABLESPACE TXTIDX STORAGE (INITIAL 1K)'); END; /

To use this storage preference when creating an XML column, add it to the XML_IDX_INDEX_TEXT parameter. For example, if the geodatabase administrator logged in as the user "sde" when they created the storage preference, reference it in the XML_IDX_INDEX_TEXT parameter as follows. LEXER sde.WORLDLEXER STORAGE sde.XML_STORAGE

Consult the Oracle Text Reference for more information about creating a custom storage preference. Be sure to always include the storage clauses recommended by Oracle for text indexes.

Configuring LOB storage XML documents are stored as large objects (LOBs) in the XML document table in the xml_doc and xml_doc_val columns, and in the XML index table in the text_tag column. It is important to configure these columns accurately to achieve the best possible search performance. Using in-line or out-of-line storage LOBs are stored inline if the LOB data is stored in the same block as the rest of the data in the row. However, inline storage is only possible if the LOB data is less than 4KB in size. With out-of-line storage, the data is stored in the LOB segment and only the LOB locator is stored with the rest of the data in the row. By default, Oracle stores LOB data inline. You can specify whether LOB data associated with an XML column is stored inline or out of line using the ArcSDE DBTUNE parameters XML_DOC_LOB_STORAGE and XML_DOC_VAL_LOB_STORAGE for the XML document table and XML_IDX_TEXT_TAG_STORAGE for the XML index table. When LOB data is stored out of line for an XML column, by default, ArcSDE places that data in the same tablespace as the XML document table. The LOB data may be moved to a different tablespace than the one containing the XML document table by using the XML DBTUNE parameters XML_DOC_STORAGE, XML_DOC_VAL_STORAGE, and XML_IDX_TEXT_TAG_STORAGE. A typical XML document that contains metadata describing a GIS resource will be greater than 4KB in size. Tests show XML columns associated with ArcIMS Metadata Services perform best when the LOB data is stored out of line in a separate tablespace from the XML document table. Specify out-of-line storage for the XML column by setting these parameters to "DISABLE STORAGE IN ROW". After configuring another tablespace to store the LOB data, add that tablespace's name to the parameter values. An ArcIMS Metadata Service may contain gazetteer data instead of typical metadata XML documents; this place name information is very small, typically less than 100 bytes in size. XML columns containing small documents will perform best when the LOB data is stored inline. The default DBTUNE keyword IMS_GAZETTEER specifies in-line storage for LOB data by setting the XML_DOC_STORAGE and XML_DOC_VAL_STORAGE parameters to "ENABLE STORAGE IN ROW". When defining storage for XPath indexes, you should store the data out of line. This is because these indexes can be of varying sizes and, therefore, some might be stored inline and others out of line. Having to search both inline and out of line can slow down the indexes. Only store the data inline if you are certain all data is of the same size and small.

128

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

The XML_IDX_TEXT_TAG_STORAGE parameter does not have a default value in the DEFAULTS keyword and is not included in the IMS_GAZETTEER keyword. Specify the following storage information for the XML_IDX_TEXT_TAG_STORAGE parameter in the DBTUNE table so XPath index storage is out of line: NOCACHE NOLOGGING CHUNK 4K PCTVERSION 5 DISABLE STORAGE IN ROW

When appropriate, use a similar value with "ENABLE STORAGE IN ROW" to store the data inline. For more information about inline and out of line storage, see Oracle's LOB performance guidelines. ◦ LOB caching and logging LOB data may be read and written using the buffer cache. When the LOB data isn't accessed using the buffer cache, it is read and written by directly accessing the data each time. Caching can improve search performance for XML columns for which LOB data is stored out of line, particularly for frequently accessed LOBs. By default, Oracle will not cache LOB data that is stored out of line. If logging is specified, changes to out-of-line LOB data will be added to the redo logs. Logging is enabled when LOB data is cached. This may decrease performance for publishing XML documents. With ArcSDE XML columns, LOB data will initially be stored as NOCACHE NOLOGGING. However, XML columns that store LOB data out of line should be set to CACHE LOGGING to optimize search performance. For XML columns associated with an ArcIMS metadata service, both LOB columns in the XML document table will be set to CACHE LOGGING when the aimsmetaindx command is run. The caching and logging properties won't affect LOB data that is stored inline such as with XML columns that contain gazetteer data. For more information about caching and logging, see Oracle's LOB performance guidelines. ◦ Tablespace block size and buffer cache configuration When out-of-line LOB data is not present in the buffer cache, the block size can affect the amount of time required to read data from disk. You can improve search performance against an XML column if you know the data's distribution, and you set the tablespace and buffer cache to use the correct block size. For example, if most of the LOB data is less than 8 KB in size and the tablespace block size is 16 KB, more time will be spent reading data from the disk than necessary. In this situation, you would improve performance if you used Oracle's multi-block-size configuration, storing the out-of-line LOB data in a tablespace that was set to use 8 KB blocks. Setting the tablespace block size must happen in combination with allocating memory for the buffer cache. The size of the buffer cache depends on the block size of the tablespace used to store the out-ofline LOB data. If the tablespace uses an 8 KB block size, memory must be allocated for an 8 KB buffer cache. You must be sure enough system memory has been allocated to support the cache. Oracle uses a tablespace block size of 16 KB by default. Initially, you should use a tablespace with the default block size and buffer cache settings to store out-of-line LOB data. Then, once XML documents have been published to the XML column, you can analyze the distribution of that data using the xml_lob_block_distribution script that is available in the SDEHOME\tools\oracle directory. ESRI tests show that typical metadata XML documents published to an XML column will be less than 8 KB in size. To optimize search performance for this type of XML column, you can take advantage of Oracle's multi-block-size configuration to store the out-of-line LOB data in a tablespace with an 8 KB block size, while other tablespaces can continue storing data in 16 KB blocks. First, the Oracle instance must be configured to allow a block size of 8 KB, then you can create a new tablespace that uses the 8 KB block size and 8 KB buffer cache to store the out-of-line LOB data. Modify the ArcSDE DBTUNE 129

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

XML_DOC_STORAGE, XML_DOC_VAL_STORAGE, and XML_IDX_TEXT_TAG_STORAGE parameters to use the new tablespace and create a new XML column using those parameters. Finally, republish your XML documents to the new XML column. Ideally, all out-of-line LOB data blocks would be stored in the buffer cache to optimize search performance. You can use the xml_lob_cache_size script in the SDEHOME\tools\oracle directory to estimate the cache size required to store all the LOB blocks. Before running this script, change the block_size variable at the beginning of the script to the actual block size for the tablespace storing the LOB data. Depending on available physical memory, you could adjust the buffer cache to ensure that as many LOB data blocks will be stored in the buffer cache as possible. See the Oracle documentation for more information about the tablespace db_block_size parameter and the buffer cache.

Updating an XML column's text indexes By default, when XML documents are stored in an XML column the text indexes associated with the column will not be automatically updated to include text from the new documents. Until the text indexes have been updated, any XML documents that have not been indexed can't be found by a search. ArcSDE does not provide any utilities that can be used to manually trigger updates to an XML column's text indexes. For XML columns associated with an ArcIMS Metadata Service, ArcIMS provides configuration options and a command-line utility can be used to update the text indexes.

Set the optimizer parameters for Oracle9i For Oracle9 i , a few optimizer parameters should be set in the database for searches to perform well. Setting these parameters will not adversely affect other client software that accesses your ArcSDE database. You do not need to set these parameters for newer versions of Oracle. For Oracle9 i , the following parameter must be added to your Oracle server's init.ora file: OPTIMIZER_MODE=CHOOSE

Only the optimizer mode must be set; the other parameters used with Oracle8 i aren't required. NOTE: Beginning with ArcSDE 9.2, Oracle 8 i is not supported. However, if you are using ArcSDE 9.1 or lower with Oracle 8 i , the following parameters must be added to your Oracle server's init.ora file: OPTIMIZER_INDEX_CACHING = 90 OPTIMIZER_INDEX_COST_ADJ = 10 OPTIMIZER_MODE=CHOOSE

Refer to the Oracle8 i documentation for a complete discussion of these parameters. In general, setting these parameters as specified directs the Oracle8 i optimizer to favor index scans and nested loop execution plans over a full table scan or a sort merge.

Section 34 Using multiple geodatabases within a DBMS Note: This topic was updated for 9.3.1. Each database management system (DBMS) has different rules for using multiple geodatabases. In general, though, it is possible to create separate databases, store a geodatabase in each one, and connect to each one using separate ArcSDE services no matter what DBMS you are using. 130

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Beginning with ArcGIS 9.2, you can also create multiple geodatabases inside one Oracle database. This model for storing multiple geodatabases in one Oracle database is in Using multiple geodatabases in Oracle as is information on creating more than one geodatabase in different Oracle databases. This is followed by topics containing specific information for storing multiple geodatabases using other DBMS types and models. The following table lists sections of each of the DBMS-specific topics. Use it to help you find the information you need. Oracle

Creating multiple geodatabases in multiple Oracle databases A description of using multiple geodatabases in one Oracle database Creating multiple geodatabases in one Oracle database Managing multiple geodatabases in one Oracle database Listing the geodatabases in an Oracle database Creating stored procedures in the geodatabases stored in Oracle users' schemas Connecting to geodatabases in Oracle users' schemas Loading data into geodatabases in Oracle users' schemas Creating backups of geodatabases in Oracle users' schemas Deleting a geodatabase from a user's schema

SQL Server Creating multiple geodatabases in a SQL Server instance using the single spatial database model A description of the SQL Server multiple spatial database model Migrating from the SQL Server multiple spatial database model to the single spatial database model DB2

Creating multiple geodatabases in a DB2 instance

Informix

Creating multiple geodatabases in Informix

PostgreSQL Creating multiple geodatabases in a PostgreSQL database cluster

Section 35 Using multiple geodatabases in Oracle Note: This topic was updated for 9.3.1. There are two possible ways to store multiple geodatabases when using an Oracle database management system (DBMS): you can install separate instances of Oracle and, in each instance, create a geodatabase, or you can create a master geodatabase in an Oracle instance and also create dependent geodatabases in other users' schemas in that same instance. The first option requires you to install multiple instances of Oracle. If you use an ArcSDE service to connect to the geodatabase, you need one service for each geodatabase. Each geodatabase is maintained and upgraded independently. Each can also be uninstalled and deleted independently. The second option uses one installation of Oracle, one installation of the ArcSDE component of ArcGIS Server Enterprise, and one ArcSDE service to connect. It requires that you have multiple users in the database, each of whom has been granted ArcSDE administrative privileges to install, administer, and upgrade the geodatabase stored in his/her schema. Each geodatabase is maintained and upgraded independently. You can delete individual geodatabases in a user's schema after removing all registered data, but you cannot delete the master geodatabase without deleting all the geodatabases stored in users' schemas. Information about each option is given in the following sections. Multiple geodatabases in separate Oracle databases Multiple geodatabases in one Oracle database A description of using multiple geodatabases in one Oracle database Creating multiple geodatabases in one Oracle database Managing multiple geodatabases in one Oracle database

131

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

Listing the geodatabases in an Oracle database Creating stored procedures in the geodatabases stored in users' schemas Connecting to geodatabases in users' schemas Loading data into geodatabases in users' schemas Creating backups of geodatabases in users' schemas Deleting a geodatabase from a user's schema

Multiple geodatabases in separate Oracle databases You can create multiple geodatabases in separate Oracle databases by setting up and installing each Oracle database as you would when setting up just one.

If you make a separate direct connection to each geodatabase, you do not have any additional configuration steps to make beyond the usual direct connection configuration. (See Setting up clients for a direct connection .) Then, when you make a connection to the database using database authentication, you need to specify the net service name appended to the end of the database password to indicate to which database you want to connect. For example, for a net service name of benedict2, you would type the password as follows: mypassword@benedict2

If you make a direct connection to a remote Oracle database and use operating system (OS) authentication, you need to append the LOCAL variable and value to the direct connect syntax in the Service field in ArcCatalog or the server (–s) option at the command line. For instance, to use OS authentication for the net service benedict2, you would type the connection string followed by a forward slash, then LOCAL=benedict2, as shown below: sde:oracl10g:/;LOCAL=benedict2

132

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

If you make a direct connection to a local Oracle database and use OS authentication, you append the ORACLE_SID variable and value to the direct connect syntax instead. sde:oracle10g:/;ORACLE_SID=benedict2

If you use an ArcSDE service, each connection needs its own unique ArcSDE service name and port number. Therefore, you must add a new entry to the services file for the new service and port number. You must also create a copy of the dbinit.sde file for each additional geodatabase you create. The following are the steps to create multiple ArcSDE service instances. For Windows 1. Make a copy of your dbinit.sde file, giving it a new name. This name must include the name of the new ArcSDE service. For example, if the new service will be sdeora2, name the dbinit file dbinit_sdeora2.sde. 2. Update the new dbinit file with the proper DBMS connection variables (i.e., ORACLE_SID). 3. If you want to set up your second geodatabase with different parameters than your first geodatabase, also copy your dbtune.sde and giomgr.def files and give the copies different names. 4. If necessary, update the new giomgr.defs file to specify operating parameters of the new instance. 5. If necessary, update the new dbtune.sde file to specify parameters for creating data in the new geodatabase. 6. Run the ArcSDE for Oracle Post Installation wizard to create the geodatabase. Be sure to: ◦ Specify the net service name of the second Oracle database on the User information dialog box. ◦ Specify the .dbf file and path for the second database in the SDE user and tablespace information dialog box. ◦ Specify your customized dbinit.sde and giomgr.def files on the first ArcSDE configuration files dialog box. ◦ Choose the custom dbtune file option on the second ArcSDE configuration files dialog box and specify your customized file. ◦ Specify the net service name for the second Oracle database on the User information dialog box. ◦ Specify the service name, port number, password, and Oracle SID for the second Oracle database on the ArcSDE service information dialog box. NOTE: If you do not run the Post Installation wizard but, instead, use sdesetup and sdeservice to create the geodatabase and service, you must manually update the services.sde and Windows services file with the new instance name, port number, and network protocol. The Windows services file is found at \WINNT\system32\drivers\etc\ or \WINDOWS\system32\drivers\etc\, depending on your operating system. For UNIX/Linux 1. Make a copy of your dbinit.sde file, giving it a new name. This name must include the name of the new ArcSDE service. For example, if the new service will be sdeora2, name the dbinit file dbinit_sdeora2.sde.

133

Administering ArcSDE® for Oracle®

Configuring an ArcSDE geodatabase

2. Update the new dbinit file with the proper DBMS connection variables (i.e., ORACLE_SID). 3. If you want to set up your second geodatabase with different parameters than your first geodatabase, make backup copies of your existing dbtune.sde and giomgr.def files, giving them adifferent name. 4. Update the services.sde file with the new instance name, port number, and network protocol. 5. Add the service name, port number, and network protocol to the /etc/services file. Make sure the port number selected is not already in use. 6. If necessary, update the new giomgr.defs file to specify operating parameters of the new instance. 7. If necessary, update the new dbtune.sde file to specify parameters for creating data in the new instance's database. 8. Run the sdesetup command to create the geodatabase in the second Oracle database and authenticate the software.

sdesetup -o install -d -s -l -p Local Security Policy. Under Security Settings, choose Local Policies, then User Rights Assignment.

169

Administering ArcSDE® for Oracle®

Connecting to an ArcSDE geodatabase

How to start an ArcSDE service Register an ArcSDE service on UNIX 1. Edit the $SDEHOME/etc/services.sde file. # # ESRI ArcSDE service name and port number # esri_sde 5151/tcp

2. Add the same service name and port number to the operating system/etc/services file. nfsd 2049/udp # NFS server daemon (clts) nfsd 2049/tcp # NFS server daemon (cots) lockd 4045/udp # NFS lock daemon/manager lockd 4045/tcp esri_sde 5151/tcp # ArcSDE service

Tip • Some UNIX systems cause applications to search the Network Information Service (NIS) file rather than the local services file. If you want to have the operating system search the local services file instead, you must force it to do so. For information on how to do this, see Forcing a search of the local services file on UNIX systems .

Start a local ArcSDE service on UNIX The sdemon command manages ArcSDE services configured on UNIX systems. 1. Type the command "sdemon" with the "–o start" operation to start the ArcSDE service. sdemon –o start

2. You will be prompted to type a password. Type the password of the ArcSDE administrative user. The password will not be displayed on the screen for system security. Please enter the ArcSDE DBA password:

Tip You must be logged in as either the owner of the ArcSDE service's home directory, $SDEHOME, or as the root user to start an ArcSDE service. • For details on the use of sdemon and other administration commands, consult the Administration Command Reference that is provided with ArcGIS Server Enterprise. You can also download a PDF version of the file from the Geodatabase Resource Center .

Start a remote ArcSDE service on UNIX NOTE: Not supported on Linux platforms

170

Administering ArcSDE® for Oracle®

Connecting to an ArcSDE geodatabase

Before an ArcSDE service on a UNIX system can be started from a remote UNIX or Windows machine, you must complete four configuration steps. Examples shown in the steps below are for an Oracle database and Solaris platform. 1. The dbinit.sde file must contain the database connection and the library path to the ArcSDE and DBMS dynamic libraries. Create the $SDEHOME/etc/ dbinit.sde file. set ORACLE_HOME=/bula/oracle set ORACLE_SID=ora set LD_LIBRARY_PATH=/usr/lib:/bula/oracle/lib:/bula/oraexe/sdeexe92/lib unset TWO_TASK

If you are running AIX, substitute LIBPATH for LD_LIBRARY_PATH. If you are running HP-UX, substitute SHLIB_PATH for LD_LIBRARY_PATH. 2. You must add additional one-line entries to the /etc/services and the /etc/inetd.conf files on both the local and remote servers, then reinitialize the inetd daemon. As the root user, duplicate the service name in the /etc/services file as a User Datagram Protocol (UDP) entry that uses the same port number. # \etc\services esri_sde 5151/tcp esri_sde 5151/udp

3. As the root user, update the /etc/inetd.conf file. Add this line to the bottom of the file. dgram udp wait /bin/sderemote iomgr_inetd

4. As the root user, identify the relevant process using the UNIX command ps -u piped through grep. Reinitialize the inetd daemon by sending it a signal hang-up (SIGHUP). As the ArcSDE administrator, make sure the ArcSDE service is not started. $ ps –u root | grep inetd root 112 1 0 Jun 28 ? 0:08 /usr/sbin/inetd –s $ kill –HUP 112 $ sdemon –o status ArcSDE Instance esri_sde Status on bula at Tue Jun 28 07:38:59 2005 ____________________________________ ArcSDE instance esri_sde is not available on bula.

After you have completed the four configuration steps, you can test the remote startup procedure from either a UNIX or a Windows computer using the sdemon command with the –s and –i options. From either a UNIX or Windows computer, type the sdemon command with the start operation to remotely start an ArcSDE service. Include the server (–s) and service (–i) options. $ sdemon –o start –p password –s bula –i esri_sde ArcSDE Instance esri_sde started Fri Oct 26 07:42:02 2007

171

Administering ArcSDE® for Oracle®

Connecting to an ArcSDE geodatabase

Start a local ArcSDE service on Windows You can start or restart an ArcSDE service on Windows from the Services menu. 1. Open the Administrative Tools menu from the Control Panel. 2. Open the Services menu. 3. Highlight the ArcSDE service. The name of the service always begins with ArcSde Service, and the service name itself is enclosed in parentheses—for example: ArcSde Service(arcsde). 4. Right-click the ArcSDE service and choose Start from the context menu, click the Start Service button on the toolbar, or click the Action menu and choose Start. Tip • If the service fails to start, make a note of the Windows error number and see Troubleshooting the ArcSDE service .

Start a remote ArcSDE service on Windows You can start a remote Windows ArcSDE service from another Windows machine. 1. Be sure the ArcSDE administrator belongs to the Windows administrator or power user group on the remote machine and has access via the system's environment variables to the sdemon command. 2. To determine that the remote ArcSDE service host is accessible over the network, use the ping command from an MS-DOS prompt. At the MS-DOS command prompt, type the command "ping" followed by the name or TCP/IP address of the remote computer. ping muybridge Pinging muybridge.esri.com [198.3.6.69] with 32 bytes of data: Reply from 198.3.6.69: bytes=32 time CHECKPOINT command if at all possible. It is important that you read the backup and recovery documentation available for Oracle. The documentation is as follows: Backup and Recovery Guide Oracle 10g online documentation list Oracle 11g online documentation list Tip ◦ If you have user-schema geodatabases, be sure to backup the master geodatabase as well as the userschema geodatabase. There are some tables in the SDE user's schema that are utilized by user-schema geodatabases.

Section 4 Recovery models for Oracle Note: This topic was updated for 9.3.1. Oracle manages changes to its contents and structure in such a manner as to guarantee recovery of the database to the last committed transaction after any single point of failure. To the last committed transaction means that once control is returned to the user after executing a COMMIT statement, Oracle guarantees the committed data has been written to disk in some form and is recoverable. Single point of failure means that any single file or process can fail without losing the contents of any committed transaction. If a data file is lost or corrupted, the contents of the redo logs guarantee that the data is recoverable. If a control file breaks, the other control files ensure that the information remains safe. A process may be killed, but committed data is never lost. To recover a database after any failure, Oracle takes these steps: 1. Reads the init.ora file to determine the names and locations of the control files 2. Reads the control files to verify their consistency with each other and to determine the physical file structure of the database 3. Opens each data file mentioned in the control file to determine whether that data file is current and reflects the latest committed change or is in need of recovery 4. Opens each redo log file in sequence and applies the information found there to each data file, as necessary, to bring each data file to the state where it contains all its committed transactions If the database has lost a control file, the database is recovered by replacing the lost control file with a copy of a current control file. If the database has lost one or more data files, the database is recovered by first replacing the lost data file or data files with backup copies, then using the redo logs (online or archived) to make the restored copies current. If the backup copies are restored to different locations from the original files they are intended to replace, you must use the ALTER DATABASE > RENAME FILE command to tell the Oracle instance where the restored files are to be found.

205

Administering ArcSDE® for Oracle®

Maintaining a geodatabase

If the database has lost the current online redo log, the database instance halts when it attempts to commit more transactions. No data will have been lost, but the latest transaction will not be committed and may need to be reentered when the database comes back up. However, the current online redo log must be replaced, and a backup of the database should immediately be performed. If the database has lost any archived redo logs, the database instance continues to function, because it has no knowledge of the loss. However, the ability to recover the database in the event of a second media failure or file loss may be compromised. A fresh backup should be taken if the archived redo logs are lost.

Section 5 About compressing a geodatabase Note: This topic was updated for 9.3.1. To understand compression, you must first understand how versioning works. If you are unfamiliar with this concept, see Understanding versioning in the "Data management workflows, transactions, and versioning" section of the help. As edits are made to a versioned ArcSDE geodatabase, the number of states (a version's lineage) and rows in the delta tables (the adds and deletes tables) grows significantly. This can slow database performance. A version's lineage grows whenever edits are saved. Each save made in an edit session creates a state in the lineage that is not trimmed until the database is compressed. To avoid performance degradation, you will need to periodically compress your versioned geodatabase. The compress command removes the states that are no longer referenced by a version and can move rows in the delta tables to the base table. A compress operation can only be performed by the ArcSDE administrator and operates against all states in the geodatabase, regardless of the version owner. After running a compress on a geodatabase, you should update the database statistics. See the section "Update statistics using Analyze in ArcCatalog" in the topic Updating statistics on a geodatabase licensed under ArcGIS Server Enterprise . This topic covers the following information: ◦ What happens during a compress operation ◦ Achieving a full compress ◦ Frequency of compress operations ◦ After compressing a geodatabase ◦ Notes about compressing a geodatabase in DB2 ◦ Notes about compressing a geodatabase in Informix ◦ Notes about compressing a geodatabase in Oracle ◦ Notes about compressing a geodatabase in SQL Server What happens during a compress operation The compress operation first scans into memory the instance's state tree configuration. Using this information, compress deletes all states that do not participate within a version's lineage. Deleting a state deletes all the rows from the delta tables that are associated with the state being deleted. The next step the compress operation performs is to collapse any candidate lineage of states into one state. A candidate lineage is a collection of states that can be compressed into one state without affecting the logical representation for any table in a given version. The final step, when applicable, is to move rows from the delta tables into the base tables. For each step of the operation, database transactions are started and stopped for each table being compressed. The transaction verifies each table is consistent during each step of the process. 206

Administering ArcSDE® for Oracle®

Maintaining a geodatabase

The compress operation can be stopped or killed while it is executing because the operation is designed to be transactionally consistent. Therefore, if the operation encounters an error, fails, or abruptly stops, the versioned tables being compressed are still logically correct with respect to any version's representation. You probably would never need to stop a compress while it is executing on an ArcSDE geodatabase for SQL Server Express but might do so on an ArcSDE geodatabase on one of the other supported DBMSs. One reason you might do this is if you run the compress while users are connected to the geodatabase, then discover the compress is consuming a large amount of system resources, you might want to stop the compress operation and run it again when fewer or no users are connected. Achieving a full compress Performance improvement will be greatest if the compress operation leaves no rows in the delta tables and the state tree is trimmed back to zero. To achieve this ◦ Reconcile and post all outstanding changes in child versions to the DEFAULT version. ◦ Delete the versions themselves. ◦ Make sure no user is connected.* ◦ Perform the compress. See the topics Compressing an ArcSDE geodatabase licensed under ArcGIS Server Enterprise and Compressing a geodatabase on an ArcSDE database server to learn how to perform a compress operation. It may not always be possible to reconcile, post, delete versions, and disconnect all users before a compress operation. For instance, if you are tracking history using versions or need to maintain design versions for a project, the historic and design versions remain pinned to a state within the state tree; therefore, these states will not be removed during a compress of the geodatabase. You can successfully compress without doing all these steps, and you will still see some performance improvements. *ArcIMS does not acquire locks on states and, therefore, would not influence the compress. ArcGIS clients, including ArcIMS map services, do acquire locks and, therefore, will influence the compress operation. You can see the results of each compress operation in the COMPRESS_LOG table in the geodatabase (SDE_compress_log in SQL Server and PostgreSQL databases). You can also check the VERSIONS table (SDE_versions in SQL Server and PostgreSQL databases) to see if the state ID for the DEFAULT version has returned to zero. If it has and there are no other outstanding versions, a full compression has been achieved. Frequency of compress operations The frequency with which you need to perform a compress operation is based on the amount of editing that takes place in your geodatabase. If you have a high volume of edits, you should probably compress the geodatabase once a day. For average or low edit volumes, you should compress at least once a week. NOTE: It is important not to wait too long between compress operations; the greater the amount of editing activity that takes place, the longer it will take to compress the geodatabase. If you don't compress the geodatabase at least once a week, the compress could take several hours to complete when you do finally run it. After compressing a geodatabase You should update the statistics on your geodatabase after you have run a compress operation. For information on updating statistics, see About updating geodatabase statistics .

Notes about compressing a geodatabase in Oracle It is possible for compress transactions to be quite large. Therefore, for Oracle databases configured with automatic undo space management, make sure the ArcSDE administrator's UNDO_POOL is not set too low and that enough undo table space exists to complete the compress operation. 207

Administering ArcSDE® for Oracle®

Maintaining a geodatabase

If you are manually controlling the undo space using rollback statements, you should create a separate rollback table space that is large enough to hold the transactions of the compress operation and assign one rollback segment to it. The size of the table space and rollback segment required depends on the number of states that will be deleted during the compress, but as a rule of thumb, you should start with a rollback segment of at least 300 MB. However, a much larger rollback segment may be required if data edits occur often or you compress infrequently. You will need to set the name of the rollback segment in the COMPRESS_ROLLBACK_SEGMENT storage parameter of the DEFAULTS DBTUNE configuration keyword. NOTE: This storage parameter doesn't exist under the DEFAULTS configuration keyword until you add it. If this parameter is not set, the next available online rollback segment will be used. If the rollback segment is not large enough, the compress operation will fail since the transaction will be forced to roll back. Oracle recommends that you use automatic undo management. Starting with Oracle9 i , automatic undo management is done by allocating space in the form of an undo table space instead of allocating rollback segments of different sizes. Tip ◦ If you are adding the COMPRESS_ROLLBACK_SEGMENT parameter to the DEFAULTS configuration keyword for the first time, you will need to use the sdedbtune export and import operations. If the parameter already exists under the DEFAULTS configuration keyword, you can use the sdedbtune alter operation to change its value. See the Administration Command Reference installed with ArcSDE for details on how to use the sdedbtune command.

Section 6 Compressing an ArcSDE geodatabase licensed under ArcGIS Server Enterprise About compressing the geodatabase Note: This topic was updated for 9.3.1. NOTE: Applies to geodatabases created with an ArcGIS Server Enterprise license only As a geodatabase is edited over time, delta tables increase in size and the number of states increases. The larger the tables and the more states, the more data ArcGIS must process every time you display or query a version. Therefore, the greatest impact on performance is not the number of versions but the amount of change contained in the adds (A) and deletes (D) tables for each version. As a result, versions can have different query response times. To maintain database performance, the ArcSDE administrator must periodically run the ArcCatalog Compress command to remove unused data. Only the ArcSDE administrator can run a compress operation. Compressing performs two key tasks: ◦ Removes unreferenced states and their associated delta table rows ◦ Moves entries in the delta tables common to all versions into the base tables, reducing the amount of data the database management system (DBMS) will need to search through for each version query, thereby improving query performance and system response time When a large volume of uncompressed changes have accumulated, compressing the database can take hours. To avoid this, compress on a regular basis. It is a good idea to compress at the end of every day or after a period of high database activity such as data loading.

208

Administering ArcSDE® for Oracle®

Maintaining a geodatabase

During a compress, users can stay connected to the geodatabase. If any user is editing a version, the branch for that state is locked and will not take part in the compression. It's best, therefore, to have all users disconnect before starting to ensure the entire state tree can compress. It is not necessary to disconnect sessions that are read-only such as an ArcIMS session. If you ever find yourself waiting for compress to complete because you need the computer for something else, you can end the compress at any time. This will not leave the database in an inconsistent state. You can continue compressing at a later time. It is important to update statistics for every versioned feature class and table in the geodatabase both before and after compressing. After edits and a database compress have taken place, database statistics are no longer accurate. This hurts query performance. To learn how to update statistics, see Updating statistics on a geodatabase licensed under ArcGIS Server Enterprise . For more information on delta tables, states, and the compress operation, read the white paper entitled Versioning . Go to http://support.esri.com and click the White Papers link on the Knowledge Base tab. Tip ◦ Compressing geodatabases stored in user's schemas in Oracle You compress a geodatabase stored in a user's schema in the same manner as the SDE master geodatabase. However, the compress operation must be performed by the schema owner, not the SDE user. If the SDE user tries to compress a geodatabase stored in another user's schema, the compress will fail with an insufficient permissions error.

How to compress the geodatabase Adding the Compress command to ArcCatalog 1. In ArcCatalog, click View, click Toolbars, and click Customize. 2. Check the Context Menus check box in the list of toolbars. This will open the Context Menus dialog box. 3. Expand the Context Menus list. 4. Click the arrow next to the Remote Database Context Menu. You may have to scroll down to see this. 5. Click the Commands tab in the Customize dialog box. 6. In the Categories window, click Geodatabase tools. 7. Click and drag the Compress Database command from the Commands list and drop it on the context menu. The command appears in the context menu. 8. Click Close on the Customize dialog box.

Compressing the database in ArcCatalog 1. In ArcCatalog, create a new database connection as the ArcSDE administrative user. (This would be the schema owner for a geodatabase stored in a user's schema in an ArcSDE geodatabase for Oracle.) 2. Add the Compress command to ArcCatalog (see "Adding the Compress command to ArcCatalog" above). 3. Right-click the new database connection and click Compress Database.

Section 7 About updating geodatabase statistics

209

Administering ArcSDE® for Oracle®

Maintaining a geodatabase

Note: This topic was updated for 9.3.1. Database management systems (DBMSs) determine the most efficient way to execute the queries sent to them based on database statistics. Therefore, for optimal performance of datasets created within ArcSDE geodatabases, you need to keep the statistics current by frequently updating the database statistics. When a feature class is registered as versioned, the adds and deletes tables are created to hold the business table's added and deleted records. The version registration process automatically updates the statistics for all the required tables at the time it is registered. After that, as changes are made to the feature class, the distribution of information in the tables and indexes changes, causing the database statistics to become outdated. You can update the statistics of feature classes from within ArcCatalog, no matter what supported database you use to store your data. This is the preferred method for updating statistics. For instructions on updating database statistics, see either Updating statistics on a geodatabase licensed under ArcGIS Server Enterprise or Updating statistics on geodatabases on ArcSDE database servers . For ArcSDE geodatabases licensed under ArcGIS Server Enterprise, you can also use the update_dbms_stats operation of the sdetable administration command to update the statistics for the tables and indexes of a feature class. The update_dbms_stats operation updates the statistics for all the tables of a feature class that require statistics. To have the update_dbms_stats operation update the statistics for all the required tables, do not specify the –K (schema object) option. sdetable –o update_dbms_stats –t railroad –m compute –u bruno –p pj

When you update statistics using ArcGIS, the statistics of a table's indexes are automatically computed, so there is no need to separately generate statistics for the indexes. However, if you need to separately update index statistics—for example, if you updated a table's statistics using a DBMS tool—you can use the sdetable update_dbms_stats operation with the –n option and the index name. The example below illustrates how the statistics for the stormdrain_idx index of the stormdrain business table can be updated. sdetable –o update_dbms_stats –t stormdrain –K B –n stormdrain_idx –u me –p dontlook

For details on the use of the sdetable command, consult the ArcSDE Administration Command Reference provided with the ArcSDE component. Database statistics should be updated in the following instances: ◦ After you perform major operations, such as creating new datasets, adding or removing topology rules, or loading large amounts of new data into existing objects. ◦ On a regular basis to maintain statistics made stale by edits to existing data; for actively edited geodatabases, updating statistics once a week should maintain acceptable performance. NOTE: Updating database statistics is an input/output (I/O)-intensive operation. You should plan to update statistics when database traffic is at its lightest. As stated above, it is recommended that you update your database statistics through ArcCatalog or by using the sdetable –o update_dbms_stats command. However, most DBMSs provide tools you can use for statistics on ArcSDE geodatabases licensed through ArcGIS Server Enterprise. Be cautious using these tools, though; in most cases, you will need to update the statistics of each individual table that makes up, for instance, a feature class because the DBMS is not aware of the connection between these tables. These tools, and certain DBMS settings related to updating statistics, are described in the following sections. The following topics discuss updating statistics for different DBMSs: 210

Administering ArcSDE® for Oracle®

Maintaining a geodatabase

Updating geodatabase statistics in DB2 databases Updating geodatabase statistics in Informix databases Updating geodatabase statistics in Oracle databases Updating geodatabase statistics in PostgreSQL databases Updating geodatabase statistics in SQL Server databases

Section 8 Updating statistics on a geodatabase licensed under ArcGIS Server Enterprise About updating geodatabase statistics Note: This topic was updated for 9.3.1. NOTE: Applies to geodatabases created with an ArcGIS Server Enterprise license only You should update database statistics before and after a compress operation; after you add or remove topology rules; and after you have finished importing, loading, or copying data into an ArcSDE geodatabase. To do this, you can use the analyze command in ArcCatalog to help maximize query performance. The analyze command updates the statistics of business tables, feature tables, and delta tables along with the statistics on those tables’ indexes. When you update the statistics for a feature dataset, statistics for all the feature classes in that feature dataset are updated. If the feature dataset contains a geometric network, the network tables are also updated. You could also update statistics using the sdetable ArcSDE administration command. Using this command, you can update statistics for specific tables, indexes, or all indexes. Optionally, you can use the statistic tools provided with your DBMS to update statistics. Consult your DBMS documentation for information on how to use those tools. NOTE: If your ArcSDE geodatabase is stored in a DB2 for z/OS database, you must use the DBMS tools rather than ArcCatalog or sdetable.

How to Update statistics using Analyze in ArcCatalog 1. Connect to the geodatabase under Database Connections in the Catalog tree that contains the dataset on which you want to update statistics. 2. Right-click the dataset in the Catalog tree. This can be a feature dataset, feature class, or table. 3. Click Analyze. 4. Check those tables you want analyzed. 5. Click OK.

Update statistics using the sdetable ArcSDE administration command At the command prompt, issue the sdetable command with the update_dbms_stats operation. The syntax for this command is sdetable –o update_dbms_stats –t [–K ] [–n {ALL|}] [–i ] [–s ] [–D ] –u [–p ] [–N] [–q]

211

Administering ArcSDE® for Oracle®

Maintaining a geodatabase

Where a word or phrase is enclosed in angle brackets , you need to supply the values specific to your database. Any option enclosed in square brackets [] is optional depending on the circumstances. For example, if you do not specify a server name, ArcSDE will assume it is to be run on the current server. If you don't supply a database password in the command, you will be prompted to input it before the command proceeds. Tip • For details on the use of sdetable and other administration commands, consult the Administration Command Reference that is provided with ArcGIS Server Enterprise. You can also download a PDF version of the file from the Geodatabase Resource Center .

Section 9 Updating geodatabase statistics in Oracle databases Note: This topic was updated for 9.3.1. The following settings can impact how Oracle database statistics are updated: ◦ The ArcSDE technology has been developed as an online transaction processing (OLTP) system. As such, Oracle initialization parameters geared toward optimizing data warehousing queries adversely affect the performance of ArcSDE queries and should not be used. The STAR_TRANSFORMATION_ENABLED parameter should be set to FALSE. You should create the Oracle database using an OLTP template and not a data warehousing template. You should not enable parallel execution on the ArcSDE schema. ◦ If you do not have enough temporary tablespace to compute statistics on larger tables, increase the size of your temporary tablespace.

212

Administering ArcSDE® for Oracle®

Tuning an ArcSDE geodatabase

Chapter 7 Tuning an ArcSDE geodatabase Section 1 An overview of tuning an ArcSDE geodatabase Note: This topic was updated for 9.3.1. Tuning is the process of sharing available resources among users by configuring the components of a database to minimize contention and maximize efficiency. The more people you have accessing your databases, the more tuning you will likely do. If you are using ArcSDE geodatabases for SQL Server Express (an ArcSDE database server), there is very little tuning you would do. If you make a lot of changes to the data, you might perform a database shrink to see some performance improvement. But mostly, you would perform only regular maintenance, such as backups , compress operations, and rebuilding indexes , not tuning on these types of geodatabases. Since ArcSDE geodatabases created under the ArcGIS Server Enterprise license are highly customizable and usually accessed by a large number of users, there are many things you can do to tune performance. Some of the tuning tasks you can perform to improve geodatabase performance levels are listed here. Each task contains links to pages that will either elaborate on the concept or describe how to perform the task using ArcGIS. Tuning task

Description

Where to get more information on this task

Separate frequently used files to minimize disk input/ output (I/O) contention.

If a large number of connections are accessing the same files in the same location on disk, database performance will be slow because the connections are competing with one another for the same resources. To reduce this competition, you can store database files in different locations on disk. The files and locations will vary by database management system (DBMS) used.

See Recommendations to minimize disk I/O contention for details on methods to reduce competition for resources.

Set initialization parameters and create and size storage spaces to tune memory.

Components of the DBMS, such as temporary spaces and buffers, See Recommendations for tuning memory for need to be created and sized properly to allow enough memory information on memory use by the DBMS. for ArcGIS/ArcSDE processes. For information on initialization parameters in In addition, certain parameters set in the DBMS and ArcSDE the database you can set to improve control how resources are allocated to connections. You can alter performance, see DBMS initialization the values of these parameters to better use memory resources. parameter recommendations .

Switch to load-only mode when loading large amounts of data.

When you switch a feature class to load-only mode, the indexes are dropped. This can decrease the time it takes to load large amounts of data into a feature class because there is no index maintenance taking place.

To learn how parameter settings in the DBTUNE table affect the storage of database objects, see The dbtune file and DBTUNE system table and its associated topics DBTUNE configuration keywords and DBTUNE configuration parameter name-configuration string pairs .

For information on ArcSDE initialization parameters, see ArcSDE initialization parameters . For details on how to load large amounts of data efficiently, see Workflow strategies for loading data in the "Adding datasets and other geodatabase elements" section of the help. To learn how to switch to load-only mode using the sdelayer command or how to bulk load data using shp2sde, cov2sde, or sdeimport, consult the ArcSDE Administration Command Reference provided with the ArcSDE component of ArcGIS Server Enterprise.

213

Administering ArcSDE® for Oracle®

Tuning task

Description

Tune the ArcSDE uses a multilevel spatial index for data stored in the spatial index ArcSDE compressed binary and Open Geospatial Consortium grid size. well-known binary (OGCWKB) geometry storage types. Tuning the spatial index grid size may improve performance of spatial queries.

Tuning an ArcSDE geodatabase

Where to get more information on this task To learn about spatial indexes and how to tune them, see Tuning spatial indexes .

Create views You might find that users repeatedly perform the same queries. To learn about spatial and multiversioned for common You could create views for these common queries to decrease the views, see Using database views . queries. amount of time it takes to get information from the database. NOTE: Views can also be used to control access to data. For instance, if you want a user to only see certain data from a table and not the entire table, you can create a view that contains only the desired data elements, then grant the user permission to access only the view, not the table. Shrink a geodatabase in SQL Server Express.

Data files within your SQL Server Express databases may break into increasingly scattered fragments as data is edited, which can cause slight performance degradation. You can occasionally shrink the geodatabase to improve performance.

See Shrinking geodatabases for details on the shrink operation and how to perform it.

Section 2 Recommendations to minimize disk I/O contention Note: This topic was updated for 9.3.1. NOTE: Applies to geodatabases created with an ArcGIS Server Enterprise license only In general, minimizing disk input/output (I/O) contention is achieved through proper planning and administration of your database system. To plan your system, you must estimate the size of all the database components and determine their relative rates of access, then position the components given the amount of disk space available and the size and number of disk drives you have. Tip ◦ Diagramming the disk drives and labeling them with the components help keep track of the location of each component. Have the diagram handy when you create your database. The following topics contain recommendations to help you reduce disk I/O contention on your database management system: ◦ Recommendations for DB2 databases ◦ Recommendations for Informix databases ◦ Recommendations for Oracle databases ◦ Recommendations for SQL Server databases

Section 3 Minimize disk I/O contention in Oracle Note: This topic was updated for 9.3.1.

214

Administering ArcSDE® for Oracle®

Tuning an ArcSDE geodatabase

Of all the configurable components of a geodatabase, storage is perhaps the most frequently and extensively customized. Likewise, each database administrator (DBA) has a preferred method for organizing both the logical and physical storage structures of the Oracle database, based on research and techniques that have proven successful in the past. You have broad flexibility to design a storage model for your geodatabase that fits the specific needs of your data, applications, and existing management policies. ArcSDE has few strict storage requirements. You may choose to deploy an entry level computer with a single data disk and one tablespace for GIS data, or a high end server with dozens of disk arrays and hundreds of Oracle files, each successfully supporting their intended environments. Fortunately, you can adapt both ArcSDE and Oracle to take advantage of whatever resources are available to run your geodatabase. To minimize disk I/O contention for Oracle databases, you can position frequently accessed files on separate disks, when possible, and group on the same disks frequently accessed files with infrequently accessed files. To do this 1. Estimate the size of all the database components and determine their relative rates of access. 2. Position the components given the amount of disk space available and the size and number of disk drives. Diagramming the disk drives and labeling them with the components help keep track of the location of each component. Have the diagram handy when you create your database. Some recommendations on how to avoid resource contention on an ArcSDE geodatabase stored in Oracle are listed below. For an explanation of the Oracle components discussed here, such as tablespaces and segments, consult your Oracle documentation. ◦ Keep your database design as simple as possible. This does not mean that your design must be inherently simple, only that complexity in the design should stem from complexity in the data you are modeling, rather than arbitrary decisions. Start with a single tablespace for your geodatabase, then justify and document each additional tablespace you create. Documenting the purpose of each tablespace will not only prove useful for anyone working on the system in the future (yourself included) but will force you to consider more carefully the benefit of each additional tablespace you need to manage. ◦ Separate system segments from user segments. Keeping user segments, such as feature classes, separate from system segments, such as the ArcSDE and Oracle data dictionaries, simplifies quota management and avoids fragmentation that can lead to decreased performance. Furthermore, it is logically easier to monitor activity at the tablespace level when these segments are stored independently. ◦ Separate data for different projects. Using dedicated tablespaces for different projects, departments, or other logical entities can facilitate monitoring and management. Restore operations affecting one project's tablespace will not take another project offline. You can assign unlimited quotas on a set of tablespaces to users in one department without the risk of them exhausting space for another department. Linking I/O activity and file growth to teams or individuals is easier when those entities use their own tablespaces. ◦ Separate large segments from small segments You can enforce extent sizes at the tablespace level rather than only at the segment level. Using a uniform extent size for all segments in a tablespace eliminates free space fragmentation and encourages high performance. However, this requires grouping segments by extent size to balance the number of extents per segment, leading to wasted space from excessive extent sizes.

215

Administering ArcSDE® for Oracle®

Tuning an ArcSDE geodatabase

Extent sizes of 128 KB for small tables, 1 MB for large feature classes, and 128 MB for large rasters are reasonable, though you can customize these values based on your own environment and research. ◦ Separate read-only data from writable data. If a tablespace contains entirely read-only data, you can put the tablespace explicitly in read only mode, explicitly. This reduces the volume of data that you need to back up regularly. Read-only data files are also excellent candidates for storage on redundant array of independent disks (RAID) 5 arrays because they will benefit from striping during read access and will not decrease array performance with excessive write activity. ◦ Use multiple disks or arrays to store files. Important Oracle files, such as control files, online redo logs, and archived redo logs, should be multiplexed, or mirrored, by the Oracle software to provide maximum protection. NOTE: Control files record critical information such as a list of files that participate in the database. Online and archived redo log files track changes to the database for recovery purposes. It is difficult or impossible to fully recover a database without current copies of these files. Even on database servers with a single-volume storage array, a stand-alone internal disk is usually available for storing the operating system, page file, and ArcSDE and Oracle executables. Use this disk for storing multiplexed control and redo log files. ◦ If using RAID storage, use RAID types appropriately. A redundant array of inexpensive disks (RAID) is a class of storage management services. There are several generic RAID strategies. These strategies are denoted by a number, or RAID level. They are as follows: RAID 0, or striping, stores small pieces of the same file system across multiple physical disks in units called stripes. The advantage of striping is improved performance. By spreading a file system's contents across multiple devices, the RAID controller can read from and write to multiple disks at the same time. The disadvantage to RAID 0 is that when any one disk in the RAID 0 array goes offline, the entire array is unavailable. RAID 1, or mirroring, stores a duplicate copy of everything written to one disk on a second disk. The advantage of mirroring is data protection. A database can lose one disk with no data loss and no degradation of service during the crash event. For this reason, RAID 1 is used with many geodatabases, especially those with high availability requirements. The disadvantage to mirroring is cost. Because data is stored twice, twice as many disks are necessary to store the same information, compared to standalone or striped disks. A small write penalty is also involved due to the need to write duplicate data. RAID 10, also called RAID 1+0 , combines the advantages of both RAID levels 1 and 0. RAID 10 arrays stripe data across sets of mirrored disks. This provides the performance advantage of RAID 0 and the data protection advantage of RAID 1. RAID 10, and vendor-specific implementations based on the RAID 10 strategy, offers the best I/O performance for busy geodatabases. RAID 10 is expensive because it requires additional hardware to store the mirrored data. You may consider using RAID 10 selectively to protect and provide high performance for your busiest files, choosing other RAID or stand alone configurations for read only, archived, or less frequently modified data. If you can afford to use RAID 10 for all of your database storage, do so. Otherwise, consider mixing various RAID and stand alone disk configurations to achieve the best reliability and performance for the hardware at your disposal.

216

Administering ArcSDE® for Oracle®

Tuning an ArcSDE geodatabase

Whenever possible, store write intensive files on RAID 1 or RAID 10 devices. Such files include redo logs and data files for undo tablespaces. If necessary, use stand alone disks with Oracle multiplexing and a comprehensive backup strategy. RAID 5, also called striping with rotating parity, requires the equivalent of only one additional disk in the entire array for storing redundant information. To accomplish this, RAID 5 stripes data across multiple disks, then stores one additional chunk of parity information for the whole stripe. If one disk in the array goes offline, the RAID processor can reconstruct the missing data from the remaining disks and the parity information. The advantages of RAID 5 are improved read performance through the use of striping, and low cost redundancy by using parity information rather than full mirroring. Because geodatabases tend to be read intensive, RAID 5 is well suited for geodatabase applications, especially when moderately high availability is required. However, because RAID 5 does not store fully redundant information, it is more susceptible to data loss than RAID 10. Although such occurrences are rare, if two disks in a RAID 5 array go offline simultaneously, the array does not have enough remaining information to reconstruct the missing data, so the whole volume must go offline. Performance can also suffer in two cases. First, when data is written to the array, parity information must also be computed and stored. Second, when a drive is offline, read and write performance decrease dramatically while the RAID processor reconstructs data for the missing disk on-the-fly. For a highly active geodatabase, the available throughput during these events may be insufficient to provide an acceptable level of service. ◦ Utilize Oracle automated storage management. Oracle 10 g introduced the automated storage management (ASM) feature. ASM is essentially a RAID system that is optimized for and dedicated to servicing Oracle databases. ASM uses an Oracle instance to broker data I/O requests to a group of raw partitions that it manages as a disk group. Disk groups can provide striping, mirroring, and a special mirroring called high redundancy that stores three copies of data, instead of the normal two. ◦ Use a small PCTFREE value for read-only data Oracle allows you to reserve a certain amount of free space in each data block when inserting new data into a table. Once the free space limit for a block is reached, Oracle will not insert additional data into that block. This free space can be used only by updates to existing rows stored in that block. By reserving space for update operations only, you can prevent rows from exceeding the available space in their original block and having to migrate to a new block. Migration is an expensive operation for the row, both at update time and when accessed in subsequent operations such as queries. Many geodatabases experience very little update activity, either because the tables are static—as is largely the case with rasters—or because they are edited in a multiversioned workflow, in which case pairs of delete and insert operations substitute for actual updates. Therefore, to maximize the amount of space in each block used for storing geodatabase data, ArcSDE is preconfigured to reserve no free space by setting the PCTFREE 0 clause in the DBTUNE storage strings. If you want to reserve free space for SQL updates by custom applications, alter the PCTFREE values in the default DBTUNE configuration. To learn more about DBTUNE configuration, see The dbtune file and the DBTUNE table , DBTUNE configuration keywords , DBTUNE configuration parameter name-configuration string pairs , and The DEFAULTS keyword . ◦ Properly configure LOB storage Large Object (LOB) data types are used by Oracle to store large, unstructured datasets. ArcSDE uses this data type for large datasets that are processed by specialized ArcSDE algorithms.

217

Administering ArcSDE® for Oracle®

Tuning an ArcSDE geodatabase

LOB data may be stored in-line, meaning that LOB and non-LOB data from the same row in a table are stored in the same Oracle data block. Alternatively, LOB data may be stored out-of-line meaning the LOB data is stored separately from the rest of the row data in a special area set aside for it by the database. Oracle stores LOB data in-line or out-of-line depending upon the size of the LOB and the storage parameters associated with creation of the table holding the LOB data. If the total size of a LOB plus the storage locator is less than 4,000 bytes and the ENABLE STORAGE IN ROW clause is specified, the LOB datum is stored in the same block as the rest of the row fields. If possible to achieve, this configuration will result in less I/O to read a single LOB datum. If the total size of a LOB datum plus the storage locator exceeds 4,000 bytes or the DISABLE STORAGE IN ROW clause is specified, Oracle stores the LOB datum out-of-line. This configuration will result in two I/Os to fetch a single LOB datum—the first to fetch row data plus the LOB locator and a second to fetch LOB itself. To create a new row with a LOB datum, Oracle effectively performs an insert of the new row storing the row data and the LOB locator followed by an update of the same row to add the actual LOB data. If several rows having LOB data are inserted in a single SQL statement, all inserts are performed before any update. This has important consequences on the storage parameters chosen for a table holding LOB data. If, for example, you insert nine rows with LOB data and Oracle inserts them into a single block, then performs the update, it may happen that none of the LOB data fits into the original block and that all must chain or migrate to another block. Setting a high value for PCTFREE will reduce this undesirable effect. To calculate an appropriate value for PCTFREE, first estimate the average size of the LOB data and the average size of the non-LOB data. If datasize is the amount of space available in a block datasize = blocksize - blockheadersize

then num_rows = TRUNC (datasize / (aveLOB + aveNonLOB) )

will be the maximum number of rows expected to fit completely into a block. Set PCTFREE to a value that will limit the amount of non-LOB data to be inserted, leaving space for LOB data, as follows: PCTFREE = 1 - (num_rows * aveNonLOB / datasize )

The F_STORAGE configuration string within the DBTUNE table controls the allocation of space for feature tables. By default, PCTFREE is set to 30 in the F_STORAGE configuration strings. A larger value of PCTFREE is necessary to reduce the problem of row chaining that may occur when data is stored as a binary large object (BLOB) data type.

Section 4 Recommendations for tuning memory Note: This topic was updated for 9.3.1. NOTE: Applies to geodatabases created with an ArcGIS Server Enterprise license only Each process running on a computer requires a certain amount of memory to temporarily store its machine code and data. Database management systems (DBMS) also employ shared memory to store data used by many client

218

Administering ArcSDE® for Oracle®

Tuning an ArcSDE geodatabase

applications. Memory tuning involves the allocation of the memory resource to the various components of the database management system. The following topics offer summary recommendations on how you can improve your system's use of memory when working with ArcSDE: ◦ Recommendations for DB2 ◦ Recommendations for Informix ◦ Recommendations for Oracle ◦ Recommendations for PostgreSQL ◦ Recommendations for SQL Server For additional information on how your particular DBMS uses memory, consult your DBMS documentation.

Section 5 Tuning memory in Oracle Note: This topic was updated for 9.3.1. Below are a few general rules regarding configuration of the Oracle system global area (SGA) as well as memory structures affecting the size of an Oracle user's private global area (PGA). SGA is a block of shared memory that Oracle allocates and shares with all sessions. For more information about SGA, refer to the Oracle Concepts Guide for your Oracle release. ◦ SGA must not swap. You should not create an SGA that is larger than two-thirds the size of your server's physical random access memory (RAM). Your virtual memory must be able to accommodate both SGA and the requirements of all active processes on the server. ◦ Avoid excessive paging. Using your operating system tools (vmstat on Unix systems and the Task Manager on Windows), check for excessive paging. A high degree of paging can result from an SGA that is too large. ◦ Configure enough virtual memory. As a rule, Oracle recommends that your swap space be at least three to four times the size of your physical RAM. The required size of the swap file on Unix or the page file on Windows depends on the number of active ArcSDE sessions. For every ArcSDE service (application server) session, a gsrvr process and a corresponding Oracle process are started. To determine the memory usage of these processes, use the ps –elf command on Unix systems or the Processes tab of the Windows Task Manager. You must deduct the size of the Oracle SGA from the Oracle user processes. The total size of the ArcSDE gsrvr, the ArcSDE giomgr, Oracle user, Oracle background, operating system, and any other processes running on the server must be able to fit into virtual memory. For ArcSDE client applications that connect directly to an Oracle instance, the gsrvr process does not exist. Also, if the ArcSDE service is not used because all client applications connect directly to the Oracle instance, the giomgr process will not be started either. For this reason, direct connections have a smaller memory imprint on the server since the gsrvr process is absent. Parameters that affect memory include LOG_BUFFER SHARED_POOL_SIZE

219

Administering ArcSDE® for Oracle®

Tuning an ArcSDE geodatabase

DB_CACHE_SIZE PGA_AGGREGATE_TARGET SGA_TARGET WORKAREA_SIZE_POLICY For an explanation of and suggested settings for these parameters, see Oracle initialization parameters . ◦ Use explicit quotas on tablespaces to avoid using up all available storage space. Users with privileges to create Oracle objects, such as the SDE user, the owner of a geodatabase stored in a user schema, and data owners, can access storage space through one of two methods: by possessing the UNLIMITED TABLESPACE system privilege or by receiving an explicit quota on a tablespace. The UNLIMITED TABLESPACE privilege allows a user to allocate an unlimited amount of space in any or all tablespaces in the database, including the Oracle managed SYSTEM and SYSAUX tablespaces. This invites the possibility for an end user, intentionally or accidentally, to exhaust all available storage space and even to crash the Oracle instance. For this reason, it is best if only database administrator (DBA) users possess this powerful system privilege. For users who are not DBAs, you should assign a quota on one or more tablespaces to enable them to create Oracle objects in a controlled manner. For example, you may grant the GIS_ADMIN data owner user a quota on the GIS_DATA and GIS_INDEX tablespaces but not on the SYSTEM and SYSAUX tablespaces. This allows you to control where the data owner can create its tables and indexes and, optionally, how much space those objects can consume. Usually, the DBA will assign either an unlimited quota or no quota on each tablespace to project instance administrator and data owner users. In this way, the DBA controls where the data is physically stored-such as on a mirrored disk array for increased data protection-and can segregate data into logical containers separate from system data and data for other projects and applications. The unlimited quota allows the data owner to allocate as much space as necessary within the tablespaces to which it has access. This is generally appropriate because users with access to the data owner account typically have additional training or experience and often know more about the storage requirements of their own GIS data than does the DBA. In environments where data editors or data viewers are permitted to create their own geodatabase objects, such as output from geoprocessing operations, you may choose to assign a limited quota on the tablespaces to which those users have write access. For instance, on the GIS_DATA tablespace, data viewers may have a 100 MB quota, data editors have a 500 MB quota, and data owners have an unlimited quota. You should customize quota assignments to meet the specific needs of your data and business processes.

Section 6 Tuning spatial indexes About the spatial index Note: This topic was updated for 9.3.1. NOTE: This topic deals with spatial grid indexes. Spatial grid indexes are used with tables using binary geometry in Oracle and SQL Server and tables using ST_Geometry in Oracle. IBM DB2 Spatial Extender also uses a multilevel grid spatial index, but since the spatial index in DB2 is generated by the Spatial Extender, you should use the Index Advisor tool provided by IBM to help tune this index. You can read more about this tool at IBM's Information Center .

220

Administering ArcSDE® for Oracle®

Tuning an ArcSDE geodatabase

The multilevel spatial index is used to decrease the time it takes to locate features that match a spatial query. It defines imaginary x/y grids for a feature class. There may be one, two, or three of these grid levels defined per feature class. The size of each grid in an ArcSDE feature class must be at least three times the previous grid size. Most feature classes need only one grid level, but more levels may be needed if the average sizes of the feature envelopes (the bounding boxes of each feature) vary widely. For more information on spatial indexes, see An overview of spatial indexes in the geodatabase in the "Defining the properties of a geodatabase" section of the help. Each feature in the feature class is indexed using only one of the grid levels; small features are indexed in the first level and larger features in the second or third grid levels, if these levels are present. ArcSDE places an entry (a row) in the spatial index table for every instance in which a single feature intersects a single cell in the one grid level used for that feature. When spatial data is displayed or previewed in ArcGIS, ArcSDE performs filtering to return only those features that fall within the envelope of the display extent. ◦ ArcSDE identifies which grid cells and levels intersect the minimum bounding rectangle of the display extent. ◦ ArcSDE returns all the features within those grid cells that intersect the minimum bounding rectangle. This is the results set. When you perform a query that includes a relational operator, such as finding the intersection of geometries, comparisons are done to reduce the result set to the features that satisfy the relational operator in the query. ArcGIS 9.2 and later releases Beginning with ArcGIS 9.2, the spatial index is calculated for you when you first load data into a dataset and provide a coordinate system in ArcGIS Desktop. You should not need to tune such spatial grid indexes. However, you can recalculate the spatial index if you want. This is done in ArcCatalog. 1. In ArcCatalog, right-click the feature class and click Properties. 2. Click the Indexes tab. 3. The bottom section of this tab contains the spatial index information. You can click Recalculate to rebuild the spatial index. NOTE: If the Recalculate button is not active, you are likely using a geometry storage type that does not use a spatial grid index or you are not the owner of the dataset or an administrator in the database. ArcGIS 9.1 and earlier releases If you are using an older release of ArcGIS and ArcSDE (9.1 or lower) and are using spatial grid indexes, you likely defined the spatial index yourself or used the default grid size settings. The default grid size settings are designed to ensure that the data can be loaded. In most circumstances, the default grid sizes will be appropriate for fast spatial queries. However, depending on the characteristics of your data, they may not be the optimal size. Tuning the grid sizes might result in better spatial query performance. When you tune the spatial index, you must balance selectivity against reducing the number of entries in the spatial index. The greater the number of entries in the spatial index, the fewer features there will be in the result sets, which the secondary spatial filter must examine and possibly eliminate to meet the requirements of the spatial query. However, the more spatial index entries there are, the larger the spatial index will be, which will slow down queries on the spatial index table. When performance tuning, the only way to tell if you have made a positive change is to monitor the results of each change. ArcSDE provides statistics about the spatial index which, along with performance testing, can ease 221

Administering ArcSDE® for Oracle®

Tuning an ArcSDE geodatabase

the tuning process. The administration command sdelayer –o si_stats is the primary tool for reporting spatial index grid statistics used to tune the spatial index. If you feel you need to tune your spatial index, you can follow the steps below. NOTE: Building a new spatial index for an ArcSDE feature class is a server-intensive operation; you should not do it for very large feature classes when a large number of users are logged in to the server.

How to tune a spatial index NOTE: Applies to geodatabases created with an ArcGIS Server Enterprise license only The general steps to follow when tuning a spatial index are as follows: 1. Establish a repeatable test to measure spatial query performance. This may be a manual test or you might create an automated test that performs and times a defined set of spatial queries. 2. Use sdelayer –o si_stats to gather beginning spatial index statistics. Be sure to record the original size of the grid levels in case you decide to revert to them. You might decide to do this if you find the changes you made to the grid size cause spatial query performance to decline. The syntax for sdelayer –o si_stats is as follows: sdelayer –o si_stats –l [–i ] [–s ] [–D ] –u –p [–q]

NOTE: If you are not the owner of the table/feature class, you must qualify the table name with the owner name, for example, owner.table. The following is an example of what gets returned by sdelayer –o si_stats: Layer Administration Utility Layer 5 Spatial Index Statistics: Level 1, Grid Size 4.940464025 Grid Records: 966 Feature Records: 23 Grids/Feature Ratio: 42 Avg. Features per Grid: 16.37 Max. Features per Grid: 96 % of Features Wholly Inside 1 Grid: 59.71 Spatial Index Record Count By Group Grids: 4

>10 23 100%

>25

>50

0 0%

0 0%

>100 0 0%

>250 0 0%

>500 0 0%

0 0%

0 0%

The statistic Grids/Feature Ratio shows the ratio of the number of entries in the spatial index table versus the number of features in the feature class. Fewer entries in the spatial index table equate to faster queries. Optimally, the Grids/Feature Ratio should be less than 2. If it exceeds 4, consider modifying the spatial index settings. As you can see in the example above, with a Grids/Feature Ratio of 42, this spatial index needs modifying.

222

Administering ArcSDE® for Oracle®

Tuning an ArcSDE geodatabase

At the end of the output is a histogram showing how many spatial index records (entries) exist for each feature. The majority of the features should have fewer than four records. Even in a well-tuned spatial index, if there are a few features that are significantly larger than the others, these features will have more spatial index entries. If many features have more than four spatial index entries, consider modifying the spatial index. 3. Change the spatial index grid settings. You can use ArcCatalog or the sdelayer command to do this. For more information, see the topic Setting spatial indexes in the "Defining the properties of a geodatabase" section of the help. To use sdelayer, do the following: ◦ Use sdelayer –o load_only_io to drop the spatial index. Switching the feature class to load-only mode drops the spatial index. sdelayer –o load_only_io –l [–i ] [–s ] [–D ] [–u ] [–p ] [–q]

◦ Use sdelayer –o alter –g n,n,n to specify new grid sizes. Specify 0 for the second or third grid size if not used. sdelayer –o alter –l –g {[,[,]]} [–S ] [–i ] [–s ] [–D ] –u [–p ] [–N] [–q]

◦ Use sdelayer –o normal_io to rebuild the spatial index and make the layer accessible again. sdelayer –o normal_io –l [–i ] [–s ] [–D ] [–u ] [–p ] [–q]

4. Run your query performance test again, and check the spatial index statistics to see if the changes had the desired effect. If not, you could try again or you might choose to undo the changes, especially if they have a negative effect on performance. You would do this by repeating step 3 using the grid index sizes you recorded in step 2. 5. Repeat steps 3 and 4 until you run out of reasonable changes to make or you find that remaining changes have a negligible effect on performance. Tip • A good starting place is to set the grid size to three times the length of the edge of an averagesized feature. • Where possible, use only one spatial index grid level. Because it needs to search each level used in each feature class, ArcSDE usually performs best when a single spatial index grid level is used. However, feature classes with highly variable feature envelope sizes may benefit from multilevel spatial indexes. You may choose to experiment with a multilevel spatial index to see if it will improve the spatial index statistics and the query performance. • Where possible, specify a grid size where a high percentage of features fall wholly within one grid cell. If the percentage falls below 80 percent, consider modifying the spatial index settings.

223

Administering ArcSDE® for Oracle®

Tuning an ArcSDE geodatabase

• For details on the use of sdelayer and other administration commands, consult the Administration Command Reference that is provided with the software. You can also download a PDF version of the file from the ESRI Resource Center.

Section 7 Using database views Note: This topic was updated for 9.3.1. NOTE: Applies to geodatabases created with an ArcGIS Server Enterprise license only Essentially, views are stored queries that select data from specified tables. The difference between a view and a regular query executed by a user or client application is that views are stored in the database, and the underlying tables can be indexed to improve performance. Since views are stored in the database, view functionality varies from one database management system (DBMS) product to another. These differences are described in the DBMS-specific topics listed here: ◦ Views in DB2 ◦ Views in Informix ◦ Views in Oracle ◦ Views in PostgreSQL ◦ Views in SQL Server With ArcSDE, it is possible to define views against a single table, between two feature classes, or between a feature class and a table, or you can create more complex views containing subqueries or spanning databases. ArcSDE views are created with the sdetable –o create_view command. A spatial ArcSDE view includes the spatial column of a feature class. This view appears as a feature class to ArcSDE clients. NOTE: When you create a view on a versioned dataset, you will only see the business table and not the edits in the delta tables. Views can be created using the sdetable administration command. The syntax of sdetable –o create_view is sdetable –o create_view –T –t –c alter table EMPLOYEES add (address varchar2(30)); Table altered. SQL> desc EMPLOYEES;

Name

Null?

Type

OBJECTID

NOT NULL

NUMBER(38)

NAME

VARCHAR2(32)

DEPARTMENT

NOT NULL

NUMBER

HIRE_DATE

NOT NULL

DATE

ADDRESS

VARCHAR2(30)

SQL> select view_name, text_length, text from all_views 2 where owner = 'GDB' and view_name = 'VIEW_DEPT_200';

VIEW_NAME

TEXT_LENGTH

TEXT

VIEW_DEPT_200

110

SELECT "OBJECTID","NAME","DEPARTMENT","HIRE_DATE" FROM GDB.EMPLOYEES WHERE department = 200

The view is unchanged by this alteration of its base table. The base table of a view need not be registered with ArcSDE unless it provides a geometry (vector), raster, or XML column managed by ArcSDE. In those cases, the base table is already registered with ArcSDE but the view itself must be registered separately. Registered row ID columns are unique, nonnull integer columns used by ArcSDE to uniquely identify rows in a table or view. Although you can create a view without registering a row ID column, such a view has limited functionality. A registered row ID column is required for queries and other operations that use ArcSDE log files. ArcGIS also uses the registered row ID column for selections, queries, and other operations. If you use a table or view with ArcGIS that has no registered row ID column, ArcGIS may create a temporary row ID column for use with the table or view. This operation can slow down the process of connecting to a table or view. 230

Administering ArcSDE® for Oracle®

Tuning an ArcSDE geodatabase

You should register row ID columns for your views as user-maintained row ID columns. Generally, ArcSDE does not support editing through views. Therefore, there is no need for ArcSDE to create an Oracle sequence to generate new row IDs for the view, which is what ArcSDE does for row ID columns maintained by ArcSDE.

Creating a view with a join You can create views with joins by including a comma-delimited list of table names as a quoted string after the -t option. The following view returns the employee ID, employee name, and employee salary by joining two tables, EMPLOYEES (owned by the connected user) and SALARY (from the schema PAYROLL): sdetable –o create_view –T view_dept_100_salaries –t "employees,payroll.salaries" –c 'employees.objectid,employees.name,payroll.salaries.salary' –w "department = 100 and employees.objectid = payroll.salaries.employeeid" –u gdb –p gdb

If the tables are not owned by the connected user, the name must be in owner.table format. When using multiple tables, you must qualify the names of each column listed after –c with the name of the table using the format table.column or owner.table.column. To use tables that are in a geodatabase in a user's schema, specify the user-owned geodatabase with the –D option.

Section 9 Tuning an Oracle instance for XML data storage Note: This topic was updated for 9.3.1. NOTE: Applies to geodatabases created with an ArcGIS Server Enterprise license only The ArcSDE component for Oracle includes two scripts in the SDEHOME > Tools > oracle directory that help you configure your Oracle instance for optimum performance when storing XML data. The scripts are xml_lob_block_distribution.sql and xml_lob_cache_size.sql. xml_lob_block_distribution This script reports the distribution of XML data in a table. You input the name of the table with the XML column and the script returns the distribution of the XML data in the following blocks: ◦ Data less than 8 KB ◦ Data between 8 KB and 16 KB ◦ Data greater than 16 KB Using this information, you can determine the size of the majority of your XML data. If most of your XML data is less than 8 KB but you are using a 16 KB block size, you could have a wasted space in the database, and each query response would require twice as much memory, half of which isn't being used. If you used an 8 KB block size instead, you would be able to pack twice as much data into each response and twice as much data into the cache and potentially have fewer reads from the database for a query that returned the same number of records. However, if the majority of your XML data is larger than 16 KB and you're using an 8 KB block size, you might have twice as many blocks holding your data than if you were using a 16 KB block size. That means that every response needs to do twice as many reads from disk for the same number of records in the business table, which would slow down query performance. xml_lob_cache_size

231

Administering ArcSDE® for Oracle®

Tuning an ArcSDE geodatabase

The xml_lob_cache_size script helps to estimate the cache requirements for XML data in a specified block size. As with the xml_lob_block_distribution script, you input the name of the table with the XML column. Plus, you can specify a block size. If no block size is specified, the current db_block_size is used for the estimate. The information returned from this script tells you how large the LOB cache should be to optimize search performance. NOTE: You cannot change the block size of an existing Oracle database. If these scripts indicate you need a different block size to optimize your XML queries, you will need to create a backup of your existing database, create a new database with the correct block size, and move your data to the new database.

232

Administering ArcSDE® for Oracle®

Creating and moving geodatabases

Appendix A Creating and moving geodatabases Section I Creating a new geodatabase About creating a new geodatabase In many situations, you will want to create a new empty geodatabase (GDB), then add new datasets to the geodatabase by defining their schema and properties and subsequently adding contents to each new dataset. The first step—creating a new geodatabase—is described here.

Creating new geodatabases Creating a personal geodatabase Creating a new personal geodatabase involves creating an .mdb file on disk. This is a simple, straightforward process that is performed by using ArcCatalog or geoprocessing tools. How to create a new personal geodatabase using ArcCatalog 1. Right-click the file folder in the ArcCatalog tree where you want to create the new personal geodatabase. 2. Point to New. 3. Click Personal Geodatabase. ArcCatalog creates a new personal geodatabase in the location you selected and sets its name to edit mode. 4. Type a new name for this personal geodatabase and press Enter.

How to create a new personal geodatabase using geoprocessing Use the tool Create Personal GDB in ArcToolbox to specify the path name to the file folder location and the name of the new geodatabase you want to create. The Create Personal GDB tool is located in ArcToolbox within the Data Management toolbox in the Workspace toolset (Data Management > Workspace).

Creating a file geodatabase Creating a new file geodatabase involves creating a special file folder on disk using ArcGIS. This is a simple, straightforward process that is performed by using ArcCatalog or geoprocessing tools. How to create a new file geodatabase using ArcCatalog 1. Right-click the file folder in the ArcCatalog tree where you want to create the new file geodatabase. 2. Point to New. 3. Click File Geodatabase. ArcCatalog creates a new file geodatabase in the location you selected. 4. Rename the new file geodatabase by right-clicking on the new file geodatabase name and choosing Rename.

233

Administering ArcSDE® for Oracle®

Creating and moving geodatabases

How to create a new file geodatabase using geoprocessing Use the tool Create File GDB in ArcToolbox to specify the path name to the file folder location and name of the new geodatabase you want to create. The Create File GDB tool is located in the Data Management toolbox in the Workspace toolset (Data Management > Workspace).

Creating an ArcSDE geodatabase Two different procedures are used to create an ArcSDE geodatabase. One is used for creating geodatabases on ArcSDE database servers (instances of SQL Server Express). The other is used to create ArcSDE geodatabases licensed through ArcGIS Server Enterprise. You create new geodatabases on database servers in ArcCatalog. Creating these geodatabases creates new databases on a SQL Server Express database instance. You must have ArcSDE database server administrator permissions to create new geodatabases. The geodatabases that get created on database servers store the ArcSDE geodatabase system tables in the dbo schema . They only use Windows-authenticated users and can only be connected to using a direct connection . ArcSDE geodatabases licensed through ArcGIS Server Enterprise are stored using separate database management system (DBMS) products. Therefore, before you can create the ArcSDE geodatabase system tables and your data tables, you must set up your DBMS. How you set up your DBMS is specific to the DBMS product you are using; therefore, consult your DBMS documentation for information on setting up your DBMS. For tips on setting up your DBMS to work well with ArcSDE, see Recommendations to minimize disk I/O contention and Recommendations for tuning memory .

How to create a geodatabase on an ArcSDE database server First, you will need to have installed SQL Server Express (a database server) and enabled it to store geodatabases. To learn how to do this, see the installation guide provided with the ArcGIS Desktop (ArcEditor or ArcInfo), ArcGIS Engine, or ArcGIS Server Workgroup installation media. Next, you will add the database server to your Catalog tree as follows: 1. In the ArcCatalog tree, expand the Database Servers folder. 2. Double-click Add Database Server. 3. In the Add Database Server dialog box, specify the location and name of the ArcSDE database server (the location and name of the SQL Server Express instance) you want to add to ArcCatalog. A default instance is created with the same name as the server on which it is installed and an instance name of SQLEXPRESS. (Example: TIVO2\SQLEXPRESS, where TIVO2 is the server name and SQLEXPRESS is the instance.) Click OK. The server icon will appear under Database Servers in the Catalog tree.

New database server icon in Catalog tree 234

Administering ArcSDE® for Oracle®

Creating and moving geodatabases

Tip ◦ If you add the database server and the icon appears in the ArcCatalog tree with a blank white square on it, the database server has been added, but its status is unknown.

Database server status unknown Try double-clicking it to connect. If you are unable to connect, contact the administrator of that database server to find out if the SQL Server instance is running and what type of permission you have on that database server. Once you have added an ArcSDE database server, you can create a geodatabase: 1. In the ArcCatalog tree, right-click the ArcSDE database server on which you want to create a new geodatabase. 2. Click New Geodatabase. 3. Type a name for the new geodatabase in the Geodatabase name text box. The name must begin with a letter, cannot contain spaces or special characters (such as #, @, or *), and has a maximum length of 31 characters when combined with your server name. 4. If you want to change the database file location, specify the new location in the Geodatabase file text box by clicking the ellipsis button (...) and browsing to the location. 5. Type the size of the new geodatabase in the Initial Size text box and choose MB or GB from the Units drop-down menu, or use the default size of 100 MB. (Regardless of the initial size, the geodatabase will grow as it needs to, up to 4 GB.) The initial size of the geodatabase cannot be smaller than that of the model database in the SQL Server Express instance. The model database is the system template for all new databases. The size of the model database determines the minimum size of any database created in that SQL Server Express instance. If you attempt to create a geodatabase smaller than this minimum size, database creation will fail and the following error message will be returned: Error creating this geodatabase CREATE DATABASE failed. Primary file must be at least to accommodate a copy of the model database.

6. Click OK. A progress bar will display while the database file and geodatabase schema are created. When complete, the new geodatabase will appear on the Contents tab and in the ArcCatalog tree. NOTE: You cannot create a new geodatabase on a database server (nor delete an existing geodatabase) if you are connecting with an ArcView license. Tips ◦ It can take some execution time to create a new geodatabase, especially if the initial file size is large.

235

Administering ArcSDE® for Oracle®

Creating and moving geodatabases

◦ Do not create the geodatabase at the root level (i.e., directly on the C drive of the computer). Beginning with ArcGIS 9.3, a full text index is created with geodatabases in SQL Server Express in the same location as the database. These indexes are not supposed to reside at the root level. Therefore, the geodatabase should not be created at the root level.

How to create an ArcSDE geodatabase licensed through ArcGIS Server Enterprise First, you must set up a supported DBMS. Supported types are Oracle, SQL Server, DB2, Informix, and PostgreSQL. You will need to follow the directions provided with your DBMS software on how to create a DBMS. In the Administering ArcSDE geodatabases section of this help, some tips are provided on the amount of memory and storage size you will need to use your DBMS with ArcSDE as well as some recommended DBMS initialization parameter settings you can make in your database to best work with ArcSDE. After your DBMS software is installed and you have a database, you can install ArcSDE and perform the postinstallation steps necessary to create an ArcSDE Enterprise geodatabase. If you are installing ArcSDE on a Windows computer, you should use the Post Installation wizard to create your ArcSDE geodatabase. The Post Installation wizard creates the ArcSDE geodatabase system tables and the ArcSDE administrator account, assigns the proper permissions to the ArcSDE administrator account, authorizes the ArcSDE software, and creates and starts the ArcSDE application server. If you are installing ArcSDE on a UNIX box, you will perform these same postinstallation tasks, but you will execute them at the command prompt of a UNIX shell. For a summary of the specific tasks to be performed before and after installing the ArcSDE software, see the "ArcSDE Enterprise" subsection of the topic About new installations of the ArcSDE component .

Section II About exporting and importing ArcSDE geodatabases Note: This topic was updated for 9.3.1. There are times when you may want to move or copy your database from one server to another. For example, you might want to move your development database to a production server. To do this, use one of the following: ◦ XML documents XML workspace documents use uncompressed files to convey datasets. This could be a problem if you are trying to transport large amounts of data, such as raster datasets; it could be difficult to find enough transfer media for all the uncompressed files. Be sure your transfer media can handle the data you are exporting. To learn how to export datasets to an XML workspace document, see Exporting feature datasets, classes, and tables to an export file . To learn how to import datasets from an XML workspace document, see Importing feature datasets, classes, and tables from an XML workspace document . Both these topics are in the "Adding datasets and other geodatabase elements" section of the help. ◦ ArcSDE export files ArcSDE export files transfer datasets in compressed format, but they are not geodatabase aware. That means there are extra steps you must take to make the transferred datasets usable by ArcGIS Desktop. See Moving a geodatabase using ArcSDE export files for information on using ArcSDE export files to transfer data. ◦ The methods available for your database management system These are described in the following sections. Use these links to navigate to these sections.

236

Administering ArcSDE® for Oracle®

Creating and moving geodatabases

Moving DB2 databases Moving Informix databases Moving Oracle databases Moving PostgreSQL databases Moving SQL Server databases

Moving Oracle databases You can use Oracle's export and import utilities to transport ArcSDE data. Be sure all necessary objects are exported along with the data tables. Remember, ArcSDE feature classes and rasters exist as a number of tables and related database objects. Leaving any related object behind renders the data inoperable in the target database. Therefore, it is recommended that the export include the data owner's entire schema. The entire ArcSDE administrator's schema also needs to be included in the export/import operation, because ArcSDE data objects rely on the metadata repository in the ArcSDE administrator's schema to manage the data and provide structure to it. Transportable table spaces One way to keep tables together is to use Oracle transportable table spaces. This is especially efficient when moving large databases. In the Oracle releases prior to 10 g , the operating system architectures of the source and destination servers had to match. In other words, both servers had to be big endian or both had to be little endian. The operating systems for both servers also had to be either 32 bit or 64 bit. For Oracle 10 g servers transferring to an Oracle 10 g server, you do not have to be concerned with matching system architecture, because the Oracle 10 g recovery manager (RMAN) utility can be used to convert the data files. Things to consider when transporting table spaces are as follows: ◦ Each table space must be self-contained—tables and their indexes must be in the same table space before that table space can be transported. In other words, all the table's dependencies must share its table space. ◦ The size of the transfer media must accommodate the data files to be transported. ◦ You cannot import the table space if the destination database already has a table space with the same name. ◦ You cannot import the table spaces if a table or index stored in the table space already exists on the destination server. Tables and indexes must be uniquely named within their schema. ◦ Exports must be performed by a user with EXP_FULL_DATABASE privileges.

Section III Moving a geodatabase using ArcSDE export files About moving a geodatabase using ArcSDE export files Note: This topic was updated for 9.3.1. NOTE: Applies to geodatabases created with an ArcGIS Server Enterprise license only You can use the administration command sdeexport to create an ArcSDE export file of an ArcSDE geodatabase licensed through ArcGIS Server Enterprise and the sdeimport command to move the ArcSDE export file to another server.

237

Administering ArcSDE® for Oracle®

Creating and moving geodatabases

ArcSDE export files transfer data in compressed format, thus saving space on the transfer media, but they are not geodatabase aware. Therefore, extra work is required to make them usable from ArcGIS Desktop.

How to move a geodatabase using ArcSDE export files 1. At the command prompt, export the datasets to transfer media using the sdeexport command. 2. To import, copy the export files from the transfer media to a local disk drive on the target server. 3. Import the files from the local disk drive to the target geodatabase using the sdeimport command. NOTE: The sdeimport command is not geodatabase aware and therefore is not capable of updating the geodatabase metadata to indicate that the spatial column is part of the dataset. When importing a raster dataset, drop the footprint spatial column from the raster dataset's business table. If a raster catalog is imported, the spatial column is retained. Following the import, the raster catalog must be registered with the geodatabase within ArcCatalog. To do so, right-click the raster catalog and click Register with the geodatabase. 4. After data is imported to the database, update your database statistics. See Updating statistics on a geodatabase licensed under ArcGIS Server Enterprise for instructions on how to do this. Tip • For details on the use of sdeimport and other administration commands, consult the Administration Command Reference that is provided with the software. You can also download a PDF version of the file from the ESRI support site or Resource Center.

238

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

Appendix B Data storage in the geodatabase Section I ArcSDE Compressed Binary storage Note: This topic was updated for 9.3.1. The ArcSDE Compressed Binary storage type is the primary storage type for ArcSDE geodatabases stored in SQL Server and was the default storage type for ArcSDE geodatabases stored in Oracle prior to ArcGIS 9.3. It uses a binary storage mechanism for storing feature geometry. Beginning with ArcGIS 9.3, the default feature storage type for Oracle was changed from Long Raw to ST_Geometry. The ArcSDE Compressed Binary storage type can be used to store geometry in ArcSDE geodatabases in Oracle or SQL Server databases. Compressing the geometry offers efficient storage and retrieval of spatial data by reducing the space required to store data by as much as 40 percent. The client application, after verifying the geometry, compresses and sends it to the server, where it is stored in Compressed Binary format in a feature table, or F table. Compressing the geometry on the client unloads the task from the ArcSDE server and reduces the transmission time to send the geometry. A compressed binary feature class is made up of three tables: the business table, feature table, and spatial index table. The business table contains attributes and a spatial column. The spatial column is a key to the feature and spatial index tables. The relationship between the business table and feature table is managed through the spatial column and the feature ID (FID) column. This key, which is maintained by ArcSDE, is unique. For further description of feature classes stored in the ArcSDE Compressed Binary format, see Feature classes in a geodatabase in SQL Server and Feature classes in a geodatabase in Oracle . In SQL Server databases, ArcSDE Compressed Binary is the default geometry storage, and it is stored as an image data type. The DBTUNE table parameter GEOMETRY_STORAGE defines the geometry storage format of a feature class. In geodatabases in SQL Server, the GEOMETRY_STORAGE value for the default is SDEBINARY. Under the DEFAULTS keyword in the dbtune.sde file, the GEOMETRY_STORAGE is set to SDEBINARY. ##DEFAULTS GEOMETRY_STORAGE

"SDEBINARY"

END

You can change the default GEOMETRY_STORAGE in a geodatabase in SQL Server to use the Open Geospatial Consortium, Inc. (OGC), Well-Known Binary storage data type by changing the value of the GEOMETRY_STORAGE parameter of the DEFAULTS keyword to OGCWKB. For a description of this data type, see The OGC Well-Known Binary representation for geometry .

239

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

If you have changed your DEFAULTS GEOMETRY_STORAGE to OGCWKB but want to create some of your feature classes with ArcSDE Compressed Binary, you could create a configuration keyword to specify when you create specific feature classes. For example, in the dbtune.sde file, such a configuration keyword might appear as follows: ##SDEBINARY GEOMETRY_STORAGE UI_TEXT COMMENT END

"SDEBINARY" "" "Used to create feature classes with SDEBINARY geometry storage"

For information on creating DBTUNE keywords, see DBTUNE configuration keywords . For geodatabases stored in Oracle, ArcSDE Compressed Binary geometry can be stored as either a binary large object (BLOB) or LONG RAW data type. ArcSDE geodatabases in Oracle use ST_Geometry storage by default, so if you want to store most of your geometry in ArcSDE Compressed Binary format, you need to alter the DEFAULTS GEOMETRY_STORAGE parameter to either SDEBINARY, which is the ArcSDE Compressed Binary geometry stored as a LONG RAW data type, or to SDELOB, which is the ArcSDE Compressed geometry stored as a BLOB. For information on tuning storage of BLOBs in a geodatabase stored in Oracle, see the Oracle section of Minimize disk I/O contention in Oracle . NOTE: Oracle has deprecated the LONG RAW storage type. For this reason, it is recommended that you not use SDEBINARY storage for new feature classes. If you want to have a mix of geometry types in your ArcSDE geodatabase for Oracle, you can leave the DEFAULTS GEOMETRY_STORAGE parameter set to ST_GEOMETRY, then specify other configuration keywords to be used when you create particular feature classes. Available keywords are SDELOB, SDO_GEOMETRY, SDEBINARY, and WKB_GEOMETRY.

Section II The OGC Well-Known Binary representation for geometry Note: This topic was updated for 9.3.1. The well-known binary representation for OGC geometry (WKBgeometry) provides a portable representation of a geometry value as a contiguous stream of bytes. It permits geometry values to be exchanged between an ODBC client and a database in binary form. It is not compressed. This geometry storage type can be used with ArcSDE geodatabases stored in Oracle or SQL Server to store twodimensional geometry. Feature classes stored in the OGC Well-Known Binary type are also made up of three tables—the business table, the feature table, and the spatial index table—just like feature classes stored in ArcSDE Compressed Binary. The business table contains attributes and a spatial column. The spatial column is a key to the feature and spatial index tables. The relationship between the business table and the feature table is managed through the spatial column and the FID column. This key, which is maintained by ArcSDE, is unique. If you want to store most of your feature class data in OGC Well-Known Binary format, change the value of the GEOMETRY_STORAGE parameter under the DEFAULTS configuration keyword of the DBTUNE table to OGCWKB. If, instead, you want to store only some of your feature classes in the OGC Well-Known Binary format, you can specify the WKB_GEOMETRY configuration keyword when you create those feature classes.

What is the OGC Well-Known Binary representation?

240

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

This is part of the Open Geospatial Consortium's Simple Features specification that implements a simple storage model for point, line, and polygon features using x,y coordinates. It is a focused specification that has been adopted and extended by most adopters including ESRI as part of the geodatabase support using ArcGIS and ArcSDE software. The well-known binary representation for geometry is obtained by serializing a geometry instance as a sequence of numeric types drawn from the set {Unsigned Integer, Double} and serializing each numeric type as a sequence of bytes using one of two well-defined, standard binary representations for numeric types, NDR or XDR. NOTE: XDR stands for eXtended Data Representation. XDR is an IETF standard of the presentation layer in the OSI model. XDR allows data to be transported in an independent manner so data can be transferred between computer systems. NDR stands for Network Data Representation . It is an implementation of the presentation layer in the OSI model. The specific binary encoding used for a geometry byte stream is described by a one-byte tag that precedes the serialized bytes. The only difference between the two encodings of geometry is byte order. The XDR encoding is big endian, while the NDR encoding is little endian. That means the XDR encoding representation of an unsigned integer—a 32-bit (4 byte) data type that encodes a nonnegative integer in the range [0, 4294967295]—is big endian, as is the XDR encoding representation of a double—a 64-bit (8 byte) doubleprecision data type that encodes a double-precision number using the IEEE 754 double-precision format. Conversely, the NDR representation of an unsigned integer is little endian (least significant byte first), and the NDR representation of a double is little endian (sign bit is last byte). Conversion between the NDR and XDR data types for unsigned integers and doubles is a simple operation involving the reversal of bytes within each unsigned integer or double in the byte stream.

Description of WKB geometry byte streams The basic building block of the well-known binary representation for geometry is the byte stream for a point that consists of two doubles. The byte streams for other geometries are built using the byte streams for geometries that have already been defined. The following is a definition of the byte stream: Basic Type definitions byte : 1 byte uint32 : 32 bit unsigned integer (4 bytes) double : double precision number (8 bytes) Building Blocks : Point, LinearRing Point { double x; double y; }; LinearRing uint32 Point }

{ numPoints; points[numPoints];

enum wkbGeometryType { wkbPoint = 1, wkbLineString = 2, wkbPolygon = 3, wkbMultiPoint = 4, wkbMultiLineString = 5, wkbMultiPolygon = 6, wkbGeometryCollection = 7 }; enum wkbByteOrder { wkbXDR = 0,

Big Endian

241

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

wkbNDR = 1

Little Endian

}; WKBPoint { byte uint32 Point } WKBLineString { byte uint32 uint32 Point } WKBPolygon byte uint32 uint32 LinearRing } WKBMultiPoint byte uint32 uint32 WKBPoint }

byteOrder; wkbType; point;

1

byteOrder; wkbType; numPoints; points[numPoints];

2

WKBMultiLineString byte uint32 uint32 WKBLineString } wkbMultiPolygon { byte uint32 uint32 WKBPolygon }

{ byteOrder; wkbType; numRings; rings[numRings];

3

{ byteOrder; wkbType; num_wkbPoints; WKBPoints[num_wkbPoints];

4

{ byteOrder; wkbType; num_wkbLineStrings; WKBLineStrings[num_wkbLineStrings];

WKBGeometry { union { WKBPoint WKBLineString WKBPolygon WKBGeometryCollection WKBMultiPoint WKBMultiLineString WKBMultiPolygon } }; WKBGeometryCollection { byte uint32 uint32 WKBGeometry }

byteOrder; wkbType; num_wkbPolygons; wkbPolygons[num_wkbPolygons];

5

6

point; linestring; polygon; collection; mpoint; mlinestring; mpolygon;

byte_order; wkbType; num_wkbGeometries; wkbGeometries[num_wkbGeometries]

7

Assertions for well-known binary representation for geometry The well-known binary representation for geometry is designed to represent instances of the geometry types described in the geometry object model and in the OpenGIS Abstract Specification. These assertions imply the following for rings, polygons, and multipolygons: ◦ Linear rings—Rings are simple and closed, which means that linear rings may not self-intersect.

242

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

◦ Polygons—No two linear rings in the boundary of a polygon may cross each other. The linear rings in the boundary of a polygon may intersect, at most, at a single point but only as a tangent. ◦ Multipolygons—The interiors of two polygons that are elements of a multipolygon may not intersect. The boundaries of any two polygons that are elements of a multipolygon may touch at only a finite number of points.

Section III The OGC Well-Known Text representation of spatial reference systems Note: This topic was updated for 9.3.1. The well-known text representation of spatial reference systems provides a standard textual representation for spatial reference system information. The definitions of the well-known text representation are modeled after the POSC/EPSG coordinate system data model. A spatial reference system, also referred to as a coordinate system, is a geographic (latitude-longitude), a projected (x,y), or a geocentric (x,y,z) coordinate system. The coordinate system is composed of several objects. Each object has a keyword in uppercase (for example, DATUM or UNIT) followed by the defining, comma-delimited parameters of the object in brackets. Some objects are nested; the objects themselves are composed of objects. Implementations are free to substitute standard brackets ( ) for square brackets [ ] and should be prepared to read both forms of brackets. The Extended Backus-Naur Form (EBNF) definition for the string representation of a coordinate system is as follows, using square brackets (see note above): = | | = PROJCS["", , , {,}* ] = PROJECTION[""] = PARAMETER["", ] =

A dataset's coordinate system is identified by the PROJCS keyword if the data is in projected coordinates, by GEOGCS if in geographic coordinates, or by GEOCCS if in geocentric coordinates. The PROJCS keyword is followed by all the pieces that define the projected coordinate system. The first piece of any object is always the name. Several objects follow the projected coordinate system name: the geographic coordinate system, the map projection, one or more parameters, and the linear unit of measure. All projected coordinate systems are based on a geographic coordinate system, so the pieces specific to a projected coordinate system are described first. For example, UTM zone 10N on the NAD83 datum is defined as PROJCS["NAD_1983_UTM_Zone_10N", , PROJECTION["Transverse_Mercator"], PARAMETER["False_Easting",500000.0], PARAMETER["False_Northing",0.0], PARAMETER["Central_Meridian",-123.0], PARAMETER["Scale_Factor",0.9996], PARAMETER["Latitude_of_Origin",0.0], UNIT["Meter",1.0]]

The name and several objects define the geographic coordinate system object in turn: the datum, the prime meridian, and the angular unit of measure.

243

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

= GEOGCS["", , , ] = DATUM["", ] = SPHEROID["", , ] = = = PRIMEM["", ] =

The geographic coordinate system string for UTM zone 10N on NAD83 is GEOGCS["GCS_North_American_1983", DATUM["D_North_American_1983", SPHEROID["GRS_1980",6378137,298.257222101]], PRIMEM["Greenwich",0], UNIT["Degree",0.0174532925199433]]

The UNIT object can represent angular or linear units of measure. = = = UNIT["", ] =

Conversion factor specifies the number of meters (for a linear unit) or number of radians (for an angular unit) per unit and must be greater than zero. Therefore, the full string representation of UTM zone 10N is PROJCS["NAD_1983_UTM_Zone_10N", GEOGCS["GCS_North_American_1983", DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137,298.257222101]], PRIMEM["Greenwich",0],UNIT["Degree",0.0174532925199433]], PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000.0], PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-123.0], PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_of_Origin",0.0], UNIT["Meter",1.0]]

A geocentric coordinate system is quite similar to a geographic coordinate system. It is represented by = GEOCCS["", , , ]

Section IV The ST_Geometry storage type Note: This topic was updated for 9.3.1. ArcSDE geodatabase storage for Oracle, DB2, Informix, and PostgreSQL uses a SQL data type built by ESRI—ST_Geometry—which provides full geodatabase support as well as SQL access to feature class geometry. This enables you to write SQL applications using your database management system (DBMS), which can access and use feature operations and queries. Each DBMS is supported as follows: DBMS

Description

Oracle

The ST_Geometry data type is a high-performance storage type provided as part of ArcSDE for Oracle that includes ISO- and OGC-compliant SQL access to geodatabase features. Beginning with the ArcGIS 9.3 release, it is the default feature geometry storage format in new installations of ArcSDE geodatabases for Oracle.

244

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

DBMS

Description

IBM DB2

The DB2 Spatial Extender, provided by IBM as part of the DB2 product, is the only option used to store feature geometry in geodatabases in DB2. It was codeveloped by ESRI and IBM, is a high-performance storage type that provides ISO- and OGC-compliant SQL access to geodatabase features, and uses the ST_Geometry data type.

IBM Informix

The Informix Spatial DataBlade, provided by IBM as part of the Informix product, is the only option used to store feature geometry in geodatabases in Informix. It was codeveloped by ESRI and IBM, is a high-performance storage type that provides ISO- and OGC-compliant SQL access to geodatabase features, and uses the ST_Geometry data type.

PostgreSQL The ST_Geometry data type is the default for storing feature geometry in an ArcSDE geodatabase for PostgreSQL. As with the other DBMS implementations, the PostgreSQL implementation provides ISO- and OGC-compliant SQL access to geodatabase features.

This topic describes how geometry has been implemented within ST_Geometry—as a User-defined Data Type (UDT). UDTs are data structures and functions that are defined based on the operations that can be performed on the data, not in terms of how you implement them. The IBM DB2 Spatial Extender and IBM Informix Spatial DataBlade use the ST_Geometry data type, and the ST_Geometry data type is supported in ArcSDE geodatabases for Oracle and PostgreSQL. As a data type, ST_Geometry allows you to define columns that store spatial data. The ST_Geometry data type itself is an abstract, noninstantiated superclass, the subclasses (or subtypes) of which may be instantiated. An instantiated data type is one that can be defined as a table column and have values of its type inserted into it. A column can be defined as type ST_Geometry, but ST_Geometry values cannot be inserted into it since they cannot be instantiated. Therefore, only the subtype values can be inserted into this column. The ST_Geometry data type can accept and store any of its subtypes, while its subtypes (subclass data types) can only accept their own values. The following chart demonstrates the hierarchy of the ST_Geometry data type and its subclasses (or subtypes). ST_Curve, ST_Surface, ST_MultiCurve, and ST_MultiSurface are defined to be noninstantiated types. No constructors are defined for these types.

245

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

The ST_Geometry superclass and its subclasses

Subclasses The ST_Geometry data type is not instantiable but instead must store its instantiable subclasses. The subclasses are divided into two categories: the base geometry subclasses and the homogeneous collection subclasses. The base geometries include ST_Point, ST_LineString, and ST_Polygon, while the homogeneous collections include ST_MultiPoint, ST_MultiLineString, and ST_MultiPolygon. As the names imply, the homogeneous collections are collections of base geometries. In addition to sharing base geometry properties, homogeneous collections have some of their own properties. To discover the subtype of an ST_Geometry, use the ST_GeometryType function. The ST_GeometryType function takes an ST_Geometry and returns the instantiated subtype in the form of a character string. To find out how many base geometry elements are contained in a homogeneous collection, use the ST_NumGeometries function, which takes a homogeneous collection and returns the number of base geometry elements it contains. The ST_GeometryN function takes a homogeneous collection and an index and returns the nth base geometry. Each subtype stores the type of geometry implied by its name; for instance, ST_MultiPoint stores multipoints. Each subtype has particular functions that can return information about the subtype. A summary of the subtypes, their descriptions, and example functions that can be used to get information about the subtypes are listed in the table below.

246

Administering ArcSDE® for Oracle®

Subtype ST_Point

Description

Data storage in the geodatabase

Functions used with the subtype

◦ A zero-dimensional geometry that occupies a single location in coordinate space.

◦ ST_X—Returns a point's x-coordinate value as a double-precision number

◦ Has a single x,y coordinate value, is always simple, and has a NULL boundary.

◦ ST_Y—Returns a point's y-coordinate value as a double-precision number

◦ Used to define features such as oil wells, landmarks, and elevations.

◦ ST_Z—Returns a point's z-coordinate value as a double-precision number ◦ ST_M—Returns a point's m-coordinate value as a double-precision number

ST_LineString

◦ A one-dimensional object stored as a sequence of points defining a linear interpolated path.

◦ ST_StartPoint—Returns the first point of a linestring

◦ ST_LineStrings have length.

◦ ST_EndPoint—Returns the last point of a linestring

◦ The ST_LineString is simple if it does not intersect its interior. ◦ The endpoints (the boundary) of a closed ST_LineString occupy the same point in space. ◦ An ST_LineString is a ring if it is both closed and simple. ◦ The endpoints normally form the boundary of an ST_LineString unless the ST_LineString is closed, in which case the boundary is NULL. ◦ The interior of an ST_LineString is the connected path that lies between the endpoints, unless it is closed, in which case the interior is continuous.

◦ ST_PointN—Takes a linestring and an index to an nth point and returns that point ◦ ST_Length—Returns a linestring's length as a double-precision number ◦ ST_NumPoints—Returns the number of points in a linestring's sequence as an integer ◦ ST_IsRing—Returns 1 (TRUE) if a linestring is a ring or 0 (FALSE) if it is not ◦ ST_IsClosed—Returns 1 (TRUE) if a linestring is closed or 0 (FALSE) if it is not

◦ ST_LineStrings are often used to define linear features such as roads, rivers, and power lines. ST_Polygon

◦ A two-dimensional surface stored as a sequence of points defining its exterior bounding ring and zero or more interior rings. ◦ ST_Polygon has area and is always simple. ◦ The exterior and any interior rings define the boundary of an ST_Polygon, and the space enclosed between the rings defines the ST_Polygon's interior. ◦ The rings of an ST_Polygon can intersect at a tangent point but never cross. ◦ Defines parcels of land, water bodies, and other features having spatial extent.

ST_MultiPoint

◦ ST_Area—Returns a polygon's area as a double-precision number ◦ ST_ExteriorRing—Returns a polygon's exterior ring as a linestring ◦ ST_NumInteriorRing—Returns the number of interior rings a polygon contains ◦ ST_InteriorRingN—Takes a polygon and an index and returns the nth interior ring as a linestring ◦ ST_Centroid—Returns a point that is the center of the polygon's envelope ◦ ST_PointOnSurface—Returns a point that is guaranteed to be on the surface of the polygon

◦ A collection of ST_Points. ◦ Has a dimension of 0. ◦ An ST_MultiPoint is simple if none of its elements occupy the same coordinate space. ◦ The boundary of an ST_MultiPoint is NULL. ◦ Defines such things as aerial broadcast patterns and incidents of a disease outbreak.

247

Administering ArcSDE® for Oracle®

Subtype ST_MultiLineString

Description ◦ A collection of ST_LineStrings. ◦ ST_MultiLineStrings have length. ◦ ST_MultiLineStrings are simple if they only intersect at the endpoints of the ST_LineString elements. ◦ ST_MultiLineStrings are nonsimple if the interiors of the ST_LineString elements intersect.

Data storage in the geodatabase

Functions used with the subtype ◦ ST_Length—Returns the cumulative length of all the ST_LineString elements of a multilinestring as a double-precision number ◦ ST_IsClosed—Returns 1 (TRUE) if the multilinestring is closed and 0 (FALSE) if it is not

◦ The boundary of an ST_MultiLineString is the nonintersected endpoints of the ST_LineString elements. ◦ The ST_MultiLineString is closed if all its ST_LineString elements are closed. ◦ The boundary of an ST_MultiLineString is NULL if all the endpoints of all the elements are intersected. ◦ Used to define entities such as streams or road networks. ST_MultiPolygon

◦ A collection of polygons. ◦ ST_MultiPolygons have area. ◦ The boundary of an ST_MultiPolygon is the cumulative length of its elements' exterior and interior rings. ◦ The interior of an ST_MultiPolygon is defined as the cumulative interiors of its element ST_Polygons.

◦ ST_Area—Returns the cumulative ST_Area of a multipolygon's polygon elements as a double-precision number ◦ ST_Centroid—Returns a point that is the center of a multipolygon's envelope ◦ ST_PointOnSurface—Returns a point that is guaranteed to be normal to the surface of one of the multipolygon's polygon elements

◦ The boundary of an ST_MultiPolygon's elements can only intersect at a tangent point. ◦ Defines features such as a forest stratum or a noncontiguous parcel of land such as a Pacific island chain.

Note that each subtype inherits the properties of the ST_Geometry superclass but also has properties of its own. Functions that operate on the ST_Geometry data type accept any of the subclass data types (subtypes). However, some functions have been defined at the subtype level and only accept certain subtypes. For example, the ST_GeometryN function only takes ST_MultiLinestring, ST_MultiPoint, or ST_MultiPolygon subtype values as input.

Using ST_Geometry with ArcGIS ArcGIS is designed to work with the ST_Geometry spatial type through ArcSDE. ST_Geometry is the spatial storage type when using ArcSDE for DB2 or ArcSDE for Informix. ArcSDE for PostgreSQL uses the ST_Geometry spatial type by default but also supports the PostGIS spatial type for geometry storage. ArcSDE for Oracle also uses ST_Geometry by default and additionally supports a number of different geometry storage types such as SDELOB, SDO_Geometry, and SDEBINARY. These different schemas can all be used together in the same database. While there can only be one default geometry schema, individual feature classes can be created using different geometry schemas. ESRI recommends creating feature classes in spatial type format using ArcGIS versus using SQL. This recommendation is based on the following: ◦ Data that you create or add to your ArcSDE geodatabase using ArcGIS Desktop software is automatically registered with ArcSDE and the geodatabase. All required components are created for you by the software. It can be used immediately by ArcGIS. It can also be used immediately via SQL and other applications.

248

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

(An additional registration step is required to enable the feature class for versioning.) ◦ By default, the spatial index is generated for you. An additional step is not required to create the spatial index. ◦ Complete tools are available to you for determining and specifying the spatial reference for your data. Many spatial references have already been defined and are available for use. If none of these spatial references represent the projection that is desired, you are able to modify the current projections or create your own. If you want to use the same spatial reference of an existing dataset, you can import that exact spatial reference as well. If you do not create feature classes in spatial type format using ArcGIS, you must do the following: ◦ Register the spatial column with ArcSDE. In geodatabases using the spatial type in DB2, Informix, and Oracle, you can set the SERVER_CONFIG parameter DISABLEAUTOREG to false, thereby enabling the automatic registration of the spatial column by the ArcSDE service. In geodatabases in PostgreSQL that use the spatial type, use the ST_register_spatial_column function to register the ST_Geometry column. ◦ Create a spatial index on the table. See Creating spatial indexes on tables with an ST_Geometry column for instructions. ◦ Register the table as a feature class with ArcSDE using the sdelayer –o register command. See the ArcSDE administration command reference for syntax and usage. ◦ Register the feature class with the geodatabase. The last two steps are explained in the last section of the topic Enhancing ArcGIS functionality using spatial types .

Creating a new feature class with ArcGIS There are four primary ways to create a new feature class in your geodatabase: ◦ Use ArcCatalog. ◦ Use the geoprocessing tool Create Feature Class. ◦ Save the contents of a map layer in ArcMap. ◦ Convert an external data source into a geodatabase feature class (e.g., convert a shapefile or a computeraided design [CAD] file). To convert an external data source to a geodatabase feature class, use the import tools in either ArcCatalog or ArcToolbox. There are two ways you can import data: use the context-sensitive menu in ArcCatalog or use the To Geodatabase toolset in ArcToolbox. When you import data that is in a format not used by the geodatabase, ArcGIS automatically converts it into data types used by the geodatabase. For instructions on how to create a new feature class using ArcGIS, see Creating feature classes . When you create new feature classes in a geodatabase in DB2 or Informix, it automatically uses ST_Geometry storage. If you keep the default DBTUNE settings in a geodatabase in Oracle or PostgreSQL, newly created feature classes will also use ST_Geometry storage. At this stage, you now have a feature class stored in ST_Geometry format. In addition to being ready for use by ArcGIS, the feature class is also available for use via spatial-type SQL operators and functions.

Section V ST_Geometry storage in Oracle

249

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

Note: This topic was updated for 9.3.1. ArcSDE for Oracle offers a geometry storage type that provides International Organization for Standardization (ISO)- and Open Geospatial Consortium, Inc. (OGC)-compliant structured query language (SQL) access to the geodatabase. This storage extends the capabilities of the Oracle database by providing storage for objects (points, lines, and polygons) that represent geographic features. It was designed to make efficient use of Oracle database resources; to be compatible with Oracle database features such as replication and partitioning; and to provide rapid access to spatial data. It allows you to integrate spatial data with other types of business data, so your multiuser database gains the advantage of adding a geographic component to your analyses and data products. Keeping your spatial data together with other business objects also simplifies multiuser access, management, and security of your data because you will have to manage fewer data storage resources. Beginning with ArcGIS 9.3, new ArcSDE geodatabases for Oracle use the ST_Geometry spatial type for geometry storage by default. It implements the SQL 3 specification of user-defined data types (UDTs), allowing you to create columns capable of storing spatial data such as the location of a landmark, a street, or a parcel of land. For an explanation of the ST_Geometry spatial type, refer to the How ST_Geometry stores spatial data section of this topic. Using the ST_Geometry spatial type in an ArcSDE geodatabase for Oracle, you can access your spatial data through SQL functions that implement the ISO SQL/MM Spatial Standard and to the Simple Feature Specification of the OGC. You can use SQL commands to store, retrieve, and manipulate spatial features as you would any other type of data. You can use a long list of standards-based functions with SQL commands and stored procedures to retrieve and analyze spatial data. Having SQL access to the data makes it possible for you to use other applications to access data that was created in an ArcSDE geodatabase for Oracle. To use SQL to access a geodatabase in Oracle that uses the spatial type, you must configure the Oracle Listener. See Configuring Oracle Net Services to use ST_Geometry SQL functions for details. Beginning with ArcGIS 9.3, new ArcSDE geodatabases for Oracle require that all ST functions and operators be qualified with the SDE schema name. For example, if executing a query that uses the ST_Union operator, the operator must be typed as "sde.ST_Union". Geodatabases upgraded from ArcSDE 9.2 or earlier do not require this. This topic describes ◦ The architecture of the spatial type as it is used in an ArcSDE geodatabase for Oracle ◦ How to store feature classes using ST_Geometry storage ◦ Registering existing spatial tables with ArcSDE ◦ Convert between other data types and the spatial type for Oracle ◦ Where to find related documentation For information on how to work with tables that use ST_Geometry storage using SQL, see ◦ Creating a table with an ST_Geometry column ◦ Inserting features to a table with an ST_Geometry column ◦ Creating spatial indexes on tables with an ST_Geometry column ◦ Querying tables with an ST_Geometry column ◦ Updating and deleting values in an ST_Geometry spatial column ◦ Using spatial views on tables with an ST_Geometry column

250

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

NOTE: To access spatial features with SQL, the ST_Geometry libraries have to be installed on the same server as the Oracle DBMS. If you plan to run your Oracle DBMS on a server separate from ArcSDE, be sure the operating system of your Oracle server is supported for ArcSDE as well.

How ST_Geometry stores spatial data The following is the Oracle description of ST_Geometry: Name

Type

ENTITY NUMBER(38) NUMPTS NUMBER(38) MINX

FLOAT(64)

MINY

FLOAT(64)

MAXX

FLOAT(64)

MAXY

FLOAT(64)

MINZ

FLOAT(64)

MAXZ

FLOAT(64)

MINM

FLOAT(64)

MAXM

FLOAT(64)

AREA

FLOAT(64)

LEN

FLOAT(64)

SRID

NUMBER(38)

POINTS

BLOB

The attributes of the spatial type represent the following information: ◦ Entity—The type of geometric feature stored in the spatial column (linestring, multilinestring, multipoint, multipolygon, point, or polygon), the value of which is a bit mask derived from the st_geom_util stored procedure ◦ Numpts—The number of points defining the geometry; for multipart geometries, includes the separators between each part, one point for each separator ◦ Minx, miny, maxx, maxy—The spatial envelope of the geometry ◦ Area—The area of the geometry ◦ Len—The perimeter length of the geometry ◦ SRID—Contains the identifier for the geometry that links it to its associated spatial reference (coordinate system) record in the ST_Spatial_References table ◦ Points—Contains the byte stream of the point coordinates that define the geometry Like other object types, the ST_Geometry data type contains a constructor method and functions. A constructor method is a function that returns a new instance (object) of the data type and sets up the values of its attributes. The name of the constructor is the same as the type (ST_Geometry). When you instantiate an object of the ST_Geometry type, you invoke the constructor method. For example: create table hazardous_sites (name location

varchar2(128), st_geometry);

251

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

The following are ST_Geometry accessor functions take a single ST_Geometry as input and return the requested property value as a number. ◦ The ST_Area member function returns the area of a geometry. ◦ ST_Len returns the length of a geometry. ◦ ST_Entity returns a number containing a bit mask that describes the entity type. ◦ ST_NumPoints returns the number of points (vertices) that define a geometry. ◦ ST_MinM, ST_MinX, ST_MinY, ST_MinZ returns the minimum desired coordinate of a geometry. ◦ ST_MaxM, ST_MaxX, ST_MaxY, ST_MaxZ return the maximum desired coordinate of a geometry. ◦ ST_SRID returns the spatial reference identifier for a geometry. ◦ Get_release is a static member function used internally for spatial type administration (i.e., upgrades and patches). For example, the following query returns the name and area of the individual states in the United States. SELECT name, st_area(geometry) FROM us_states ORDER BY name;

ST_LineString, ST_MultiLineString, ST_MultiPoint, ST_MultiPolygon, ST_Point, and ST_Polygon are all subtypes (or subclasses) of ST_Geometry. ST_Geometry and its subtypes share common attributes and functions. The constructor definition for ST_LineString, ST_MultiLineString, ST_MultiPoint, ST_MultiPolygon, ST_Point, and ST_Polygon is the same. The name of the constructor is the same as the type it contructs. Since ST_Point is a finite object (a single point value), it can also be created using one of the following methods. This method utilizes coordinate points and an SRID. METHOD FINAL CONSTRUCTOR FUNCTION ST_POINT RETURNS SELF AS RESULT Argument Name Type In/Out Default? PT_X PT_Y SRID

NUMBER NUMBER NUMBER

IN IN IN

SQL> insert into sample_pt values (ST_Point (10, 20, 1) );

This method allows a user to specify coordinate points and an elevation value for each point. METHOD FINAL CONSTRUCTOR FUNCTION ST_POINT RETURNS SELF AS RESULT Argument Name PT_X PT_Y PT_Z SRID

Type NUMBER NUMBER NUMBER NUMBER

In/Out Default? IN IN IN IN

SQL> insert into sample_pt values (ST_Point (10, 20, 5, 1) );

This last method for ST_Point additionally allows a measure value to be specified as part of the point object created.

252

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

METHOD FINAL CONSTRUCTOR FUNCTION ST_POINT RETURNS SELF AS RESULT Argument Name PT_X PT_Y PT_Z MEASURE SRID

Type

In/Out Default?

NUMBER NUMBER NUMBER NUMBER NUMBER

IN IN IN IN IN

SQL> insert into sample_pt values (ST_Point (10, 20, 5, 401, 1) );

SP_GRID_INFO SP_Grid_Info is used as the data type for the field GRID in the table ST_Geometry_Index. It contains the gridlevel information for spatial indexes. SQL> desc sp_grid_info Name GRID1 GRID2 GRID3

Null?

Type NUMBER NUMBER NUMBER

Schema user To install ArcSDE and use the ST_Geometry type and domain index in the Oracle DBMS, the SDE user must be granted the proper system privileges to instantiate types, operators, and stored procedures. The following system privileges are required: CREATE TYPE UNLIMITED TABLESPACE CREATE LIBRARY CREATE OPERATOR CREATE INDEXTYPE CREATE PUBLIC SYNONYM DROP PUBLIC SYNONYM NOTE: The CONNECT and RESOURCE roles include these privileges.

Metadata schema The spatial type for Oracle types and metadata tables are owned by the SDE schema. The schema definition is the base table description for metadata tables used to define and describe the type column/table, spatial index, and spatial references information. The term type refers to the ST_Geometry spatial type. Spatial index refers to the ST_Spatial_Index domain index. All type and domain index type definitions, packages, and metadata tables are created in the SDE schema. Views will also be prefixed ST_ including the OpenGIS views on GEOMETRY_COLUMNS and SPATIAL_REFERENCES. Because the definitions for ST_Geometry are owned by the SDE user, you should never delete the SDE user from the database if you still have tables in the database that contain ST_Geometry columns. Doing so will cause those tables to be inaccessible. As mentioned in Oracle's Application Developers Guide, when a user is dropped from the database, one of the drop statements executed is DROP TYPE with the FORCE option. This statement removes all types owned by 253

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

that user, so that user can be removed from the database. DROP TYPE FORCE causes types to be dropped even if they have dependent types or tables associated with them. Once that happens, the associated tables are marked invalid, rendering the data in the tables inaccessible. For a description of each table, see the tables listed in System tables of a geodatabase stored in Oracle . The tables are as follows: ST_COORDINATE_SYSTEMS ST_GEOMETRY_COLUMNS ST_GEOMETRY_INDEX ST_SPATIAL_REFERENCES

Creating feature classes in Oracle with ST_Geometry storage Beginning with ArcGIS 9.3, when you first install the ArcSDE component, the ST_Geometry schema is the default storage type. The default settings for ArcSDE storage are defined in the DBTUNE table by the GEOMETRY_STORAGE parameters. If you want to store most of your feature class data in the ST_Geometry format, leave the GEOMETRY_STORAGE parameter of the DEFAULTS keyword set to ST_GEOMETRY. If you initially created your geodatabase prior to ArcGIS 9.3, you must alter your DBTUNE table's settings to create feature classes with ST_GEOMETRY columns by default by setting the GEOMETRY_STORAGE parameter under the DEFAULTS keyword to ST_GEOMETRY. You should also alter the ST_GEOM_LOB_STORAGE parameter under the DEFAULTS keyword list. When added to the DEFAULTS keyword, however, the LOB segment name should not be included in this parameter's definition. If it is included, unless you alter the value for the name, feature class creation will fail when a second feature class is created, because each LOB segment name must be unique for a given schema. The following ST_GEOM_LOB_STORAGE parameter example contains no object names, thereby avoiding name collisions within the same schema: ST_GEOM_LOB_STORAGE " STORE AS ( ENABLE STORAGE IN ROW CHUNK 8K RETENTION CACHE")

NOTE: Use the sdedbtune administration command to alter DBTUNE settings. For details on using the sdedbtune command, consult the ArcSDE Administration Command Reference. ArcSDE for Oracle supports a number of different geometry storage schemas—these different schemas can all be used together in the same database. While there can be only one default geometry schema, individual tables can be created using different geometry schemas. If you want to store just some of your feature classes with spatial type storage, you can specify the keyword ST_GEOMETRY when you create the feature class. If you do this, that particular feature class will be created with an ST_Geometry column. In the dbtune file, the ST_GEOMETRY keyword appears as follows: ##ST_GEOMETRY GEOMETRY_STORAGE "ST_GEOMETRY" ATTRIBUTE_BINARY "BLOB" RASTER_STORAGE "BLOB" ST_GEOM_LOB_STORAGE " STORE AS ( # TABLESPACE ENABLE STORAGE IN ROW CHUNK 8K RETENTION CACHE # INDEX (TABLESPACE )" UI_TEXT

"User Interface text description for ST_GEOMETRY"

254

Administering ArcSDE® for Oracle®

COMMENT

Data storage in the geodatabase

"Any general comment for ST_GEOMETRY keyword"

END

Examples of valid values for the ST_GEOM_LOB_STORAGE parameter include the following: ##ST_GEOMETRY GEOMETRY_STORAGE "ST_GEOMETRY" ATTRIBUTE_BINARY "BLOB" RASTER_STORAGE "BLOB" ST_GEOM_LOB_STORAGE " STORE AS (TABLESPACE TERRA_NDX ENABLE STORAGE IN ROW CHUNK 8K RETENTION CACHE INDEX (TABLESPACE LOBIDX)" UI_TEXT

"User Interface text description for ST_GEOMETRY"

COMMENT

"Any general comment for ST_GEOMETRY keyword"

END

##ST_GEOMETRY GEOMETRY_STORAGE "ST_GEOMETRY" ATTRIBUTE_BINARY "BLOB" RASTER_STORAGE "BLOB" ST_GEOM_LOB_STORAGE " STORE AS (ENABLE STORAGE IN ROW CHUNK 8K RETENTION CACHE)" UI_TEXT

"User Interface text description for ST_GEOMETRY"

COMMENT

"Any general comment for ST_GEOMETRY keyword"

END

NOTE: As mentioned earlier in this section, if you define the LOB and LOB index table space names, you must alter these values prior to each feature class creation. If you do not, subsequent feature class creations will fail because each segment name must be unique. For more examples and further information on creating and maintaining Oracle LOB segments, search the ESRI support site for "LOB segment." Several knowledge base articles exist on the subject. Top of page

Using existing ST_Geometry tables ArcSDE can successfully use tables containing ST_Geometry columns created using SQL (sometimes referred to as third-party tables) as long as the tables meet certain prerequisites: ◦ It must be owned by the user registering the table. ◦ It must have a single ST_Geometry column. ◦ It must have no other columns of a user-defined type. ◦ It must have a single type of geometry (points, lines, or polygons). The geometries can be multipart. ◦ Geometry should be valid; otherwise, accessing these geometries may have unexpected results.

Performing registration of third-party tables containing ST_Geometry columns The ArcSDE administration command sdelayer –o register registers a spatial table as a feature class. To register tables containing an ST_Geometry column, the prerequisites described in the previous section must be met. The tables you register may be empty or they may already contain data. Registering tables that already contain data

255

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

When you register a table that already contains data, the data has a spatial reference system assigned to it. That means when you register the table with ArcSDE, you do not have to specify the spatial reference ID (SRID) with the –R option. ArcSDE checks the defined SRID of the first record in the table and uses that. Be aware, though, that the SRID must exist in the ST_SPATIAL_REFERENCES table for it to be accepted. If the spatial reference system you need is not already in the ST_SPATIAL_REFERENCES table, the recommended way to get it there is to open ArcCatalog, connect to the geodatabase, and create a new feature class that uses the spatial reference system you want and ST_Geometry storage. When you do this, the ST_SPATIAL_REFERENCES table is populated with the SRID you need and ArcCatalog calculates the x,y, z-, and m- offsets and units and the layer extent for you. It is also possible to use SQL to insert the spatial reference, but when you do so, you must be sure to calculate the correct x,y, z-, and m- offsets and units yourself. In the following example, a table, TOWERS, containing records of point geometries (–e p) in a spatial column, SHAPE, is registered. Since the spatial reference is already known, it does not have to be specified when registering the table with sdelayer. Using the –C option, a unique, not-NULL column, FID, is added to the table to be used as a row ID column. sdelayer –o register –l towers,shape –e p –C fid,SDE –u brooke –p pwd19

For tables that contain a large number of records, registration may take less time if you register the row ID column as user maintained. sdelayer –o register –l towers,shape –e p –C fid,USER –u brooke –p pwd19

However, if you register the feature identifier column as user maintained and subsequently register the feature class with the geodatabase, ArcGIS will add an additional feature identifier column, object_ID. ArcGIS will maintain the values of this column. If the table contains a large number of records, adding this additional object_ID column may take some time. Registering spatial tables that do not contain data If the table does not contain data and does not have an assigned SRID, you have to specify an SRID when the table is registered. This is done with the –R option. The SRID specified at this time must already be present in the SPATIAL_REFERENCES table in the geodatabase and corresponds to the SRID defined by ArcSDE. As mentioned in the previous section, to populate the SPATIAL_REFERENCES table with the spatial reference system you want to use, open ArcCatalog, connect to the geodatabase, and create a new feature class that uses the spatial reference system you want and ST_Geometry storage. Then query the SPATIAL_REFERENCES system to discover the SRID that was assigned to the spatial reference system you specified for the feature class. Use this SRID when registering the spatial table. In the following example, an empty table, DRAINAGE, is registered with ArcSDE. The table already contains an integer, unique, not-NULL column, ID, that will be used for the row ID column. The SRID is specified with the –R option. sdelayer –o register –l drainage,line –e l+ –C id,SDE –R 6 –u hortence –p topsecret If the table does not contain data and does not have an assigned SRID, and you do not specify one when the table is registered with ArcSDE, it will be assigned the default SRID value of 0. This SRID exists for sample and documentation purposes only and is not recommended for use with production data. The specifications for this SRID are as follows: FalseX

-400

FalseY

-400

XYUnits

1000000000

FalseZ

-100000

256

Administering ArcSDE® for Oracle®

ZUnits

10000

FalseM

-100000

MUnits

10000

Data storage in the geodatabase

XYCluster_Tol 0.000000008983153 ZCluster_Tol

.001

MCluster_Tol

.001

Projection

GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]], PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]

Auth_srid

4326

Auth_name

EPSG

For further information on using the sdelayer command, consult the ArcSDE Administration Command Reference provided with the ArcSDE component of ArcGIS Server Enterprise. The sdelayer command only adds the table to the ArcSDE system tables. To be able to use ArcGIS Desktop geodatabase functionality such as topology, versioning, and networks, you must also register the table with the geodatabase. See Registering tables to be used by ArcGIS Desktop for more information on registering tables with the geodatabase.

Converting geometry to the spatial type for Oracle The following is a description of spatial data formats and how you can convert between them and the spatial type for Oracle.

OGC well-known text representation The spatial type has several functions that generate geometries from text descriptions. The functions include ◦ ST_GeomFromText—Creates an ST_Geometry from a text representation of any geometry type ◦ ST_PointFromText—Creates an ST_Point from a point text representation ◦ ST_LineFromText—Creates an ST_LineString from a linestring text representation ◦ ST_PolyFromText—Creates an ST_Polygon from a polygon text representation ◦ ST_MPointFromText—Creates an ST_MultiPoint from a multipoint representation ◦ ST_MLineFromText—Creates an ST_MultiLineString from a multilinestring representation ◦ ST_MPolyFromText—Creates an ST_MultiPolygon from a multipolygon representation The text representation is an ASCII text-formatted string that allows geometry to be exchanged in ASCII text form. You can use these functions in a third- or fourth-generation language (3GL or 4GL) program because they don't require the definition of any special program structures. The ST_AsText function converts an existing geometry into a text representation. Using the well-known text representation in a C program The well-known text representation of geometry can be incorporated into a C program. The structure for such an implementation is defined below. The notation {}* indicates zero or more repetitions of the tokens within the braces. The braces do not appear in the output token list. := | | | | |

257

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

| := POINT := LINESTRING := POLYGON := MULTIPOINT := MULTILINESTRING := MULTIPOLYGON := EMPTY | | Z | M | ZM := := double precision literal := double precision literal := := double precision literal := double precision literal := double precision literal := := double precision literal := double precision literal := double precision literal := := double := double := double := double

precision precision precision precision

literal literal literal literal

:= EMPTY | ( {, | Z ( {, | M ( {, | ZM ( {,

}* ) }* ) }* ) }* )

:= EMPTY | ( {,< LineString Text > }*) := EMPTY | ( {, }*

)

:= EMPTY | ( {,< LineString Text>}* := EMPTY | ( < Polygon Text > {, < Polygon Text > }*

) )

Using well-known text representation in a SQL editor Since the well-known text representation is text, it can conveniently be typed into a SQL script or directly into a SQL editor. The text is converted to and from a geometry by a function. Functions that convert text to geometry have the following syntax: function ('',)

258

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

For example: ST_PointFromText('point zm(10.01 20.04 3.2 9.5)', 1)

The spatial reference identifier, SRID—the primary key to the SPATIAL_REFERENCES table—identifies the possible spatial reference systems within an Oracle instance. An SRID is assigned to a spatial column when it is created. Before a geometry can be inserted into a spatial column, its SRID must match the SRID of the spatial column. The '' is made up of three basic components enclosed in single quotes: ' [coordinate type] [coordinate list]'

The geometry type is defined as one of the following: point, linestring, polygon, multipoint, multilinestring, or multipolygon. The coordinate type specifies whether or not the geometry has z-coordinates and/or measures. Leave this argument blank if the geometry has neither; otherwise, set the coordinate type to Z for geometries containing zcoordinates, M for geometries with measures, and ZM for geometries that have both. The coordinate list defines the double-precision vertices of the geometry. Coordinate lists are comma-delimited and enclosed by parentheses. Geometries having multiple components require sets of parentheses to enclose each component part. If the geometry is empty, the EMPTY keyword replaces the coordinates. The following examples provide a complete list of all possible permutations of the text description portion of the text representation: Geometry type

Text description

Comment

ST_Point

'point empty'

empty point

ST_Point

'point z empty'

empty point with z-coordinate

ST_Point

'point m empty'

empty point with measure

ST_Point

'point zm empty'

empty point with z-coordinate and measure

ST_Point

'point ( 10.05 10.28 )'

point

ST_Point

'point z( 10.05 10.28 2.51 )'

point with z-coordinate

ST_Point

'point m( 10.05 10.28 4.72 )'

point with measure

ST_Point

'point zm(10.05 10.28 2.51 4.72 )'

point with z-coordinate and measure

ST_LineString

'linestring empty'

empty linestring

ST_LineString

'linestring z empty'

empty linestring with zcoordinates

ST_LineString

'linestring m empty'

empty linestring with measures

ST_LineString

'linestring zm empty'

empty linestring with zcoordinates and measures

ST_LineString

'linestring (10.05 10.28 , 20.95 20.89 )'

linestring

ST_LineString

'linestring z(10.05 10.28 3.09, 20.95 31.98 4.72, 21.98 29.80 3.51 )'

linestring with z-coordinates

ST_LineString

'linestring m(10.05 10.28 5.84, 20.95 31.98 9.01, 21.98 29.80 12.84 )'

linestring with measures

ST_LineString

'linestring zm(10.05 10.28 3.09 5.84, 20.95 31.98 4.72 9.01, 21.98 29.80 3.51 12.84)'

linestring with z-coordinates and measures

ST_Polygon

'polygon empty'

empty polygon

ST_Polygon

'polygon z empty'

empty polygon with zcoordinates

259

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

Geometry type

Text description

Comment

ST_Polygon

'polygon m empty'

empty polygon with measures

ST_Polygon

'polygon zm empty'

empty polygon with zcoordinates and measures

ST_Polygon

'polygon ((10 10, 10 20, 20 20, 20 15, 10 10))'

polygon

ST_Polygon

'polygon z((10 10 3, 10 20 3, 20 20 3, 20 15 4, 10 10 3))'

polygon with z-coordinates

ST_Polygon

'polygon m((10 10 8, 10 20 9, 20 20 9, 20 15 9, 10 10 8 ))'

polygon with measures

ST_Polygon

'polygon zm((10 10 3 8, 10 20 3 9, 20 20 3 9, 20 15 4 9, 10 10 3 8 ))'

polygon with z-coordinates and measures

ST_MultiPoint

'multipoint empty'

empty multipoint

ST_MultiPoint

'multipoint z empty'

empty multipoint with zcoordinates

ST_MultiPoint

'multipoint m empty'

empty multipoint with measures

ST_MultiPoint

'multipoint zm empty'

empty multipoint with zcoordinates and measures

ST_MultiPoint

'multipoint (10 10, 20 20)'

multipoint with two points

ST_MultiPoint

'multipoint z(10 10 2, 20 20 3)'

multipoint with z-coordinates

ST_MultiPoint

'multipoint m(10 10 4, 20 20 5)'

multipoint with measures

ST_MultiPoint

'multipoint zm(10 10 2 4, 20 20 3 5)'

multipoint with z-coordinates and measures

ST_MultiLineString 'multilinestring empty'

empty multilinestring

ST_MultiLineString 'multilinestring z empty'

empty multilinestring with zcoordinates

ST_MultiLineString 'multilinestring m empty'

empty multilinestring with measures

ST_MultiLineString 'multilinestring zm empty'

empty multilinestring with zcoordinates and measures

ST_MultiLineString 'multilinestring ((10.05 10.28 , 20.95 20.89 ),( 20.95 20.89, 31.92 21.45))'

multilinestring

ST_MultiLineString 'multilinestring z((10.05 10.28 3.4, 20.95 20.89 4.5),( 20.95 20.89 4.5, 31.92 21.45 3.6))'

multilinestring with zcoordinates

ST_MultiLineString 'multilinestring m((10.05 10.28 8.4, 20.95 20.89 9.5), (20.95 20.89 9.5, 31.92 21.45 8.6))'

multilinestring with measures

ST_MultiLineString 'multilinestring zm((10.05 10.28 3.4 8.4, 20.95 20.89 4.5 9.5), (20.95 20.89 multilinestring with z4.5 9.5, 31.92 21.45 3.6 8.6))' coordinates and measures ST_MultiPolygon

'multipolygon empty'

empty multipolygon

ST_MultiPolygon

'multipolygon z empty'

empty multipolygon with zcoordinates

ST_MultiPolygon

'multipolygon m empty'

empty multipolygon with measures

ST_MultiPolygon

'multipolygon zm empty'

empty

ST_MultiPolygon

'multipolygon (((10 10, 10 20, 20 20, 20 15 , 10 10), (50 40, 50 50, 60 50, 60 40, 50 40)))'

multipolygon

ST_MultiPolygon

'multipolygon z(((10 10 7, 10 20 8, 20 20 7, 20 15 5, 10 10 7), (50 40 6, 50 multipolygon with z50 6, 60 50 5, 60 40 6, 50 40 6)))' coordinates

ST_MultiPolygon

'multipolygon m(((10 10 2, 10 20 3, 20 20 4, 20 15 5, 10 10 2), (50 40 7, 50 multipolygon with measures 50 3, 60 50 4, 60 40 5, 50 40 7)))'

ST_MultiPolygon

'multipolygon zm(((10 10 7 2, 10 20 8 3, 20 20 7 4, 20 15 5 5, 10 10 7 2), (50 40 6 7, 50 50 6 3, 60 50 5 4, 60 40 6 5, 50 40 6 7)))'

multipolygon with zcoordinates and measures

OGC well-known binary representation

260

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

The well-known binary representation for OGC geometry (WKBGeometry) provides a portable representation of a geometry value as a contiguous stream of bytes. It permits geometry values to be exchanged between an ODBC client and a SQL database in binary form. The well-known binary representation for geometry is obtained by serializing a geometry instance as a sequence of numeric types drawn from the set {Unsigned Integer, Double}, then serializing each numeric type as a sequence of bytes using one of two well-defined standard binary representations for numeric types—NDR and XDR. The specific binary encoding used for a geometry byte stream is described by a one-byte tag that precedes the serialized bytes. The only difference between the two encodings of geometry is byte order. The XDR encoding is big endian, while the NDR encoding is little endian. The spatial type for Oracle has several functions that generate geometries from well known binary representations. The functions include ◦ ST_GeomFromWKB—Creates an ST_Geometry from a WKB representation of any geometry type ◦ ST_PointFromWKB—Creates an ST_Point from a point WKB representation ◦ ST_LineFromWKB—Creates an ST_LineString from a linestring WKB representation ◦ ST_PolyFromWKB—Creates an ST_Polygon from a polygon WKB representation ◦ ST_MPointFromWKB—Creates an ST_MultiPoint from a multipoint WKB representation ◦ ST_MLineFromWKB—Creates an ST_MultiLineString from a multilinestring WKB representation ◦ ST_MPolyFromWKB—Creates an ST_MultiPolygon from a multipolygon WKB representation The well-known binary representation is a contiguous stream of bytes. It permits geometry to be exchanged between an ODBC client and a SQL database in binary form. Because these geometry functions require the definition of C structures to map the binary representation, they are intended for use within a 3GL program and aren't suited to a 4GL environment. The ST_AsBinary function converts an existing geometry value into well-known binary representation. For more information on the well-known binary representation, see The OGC Well-Known Binary representation for geometry .

Related documentation You may want to read further about Open Geospatial Consortium, Inc. (OGC), standards and Oracle database functionality. This section offers some suggestions on where you can find this information.

Where to find OGC documentation The OGC is a nonprofit organization working to formalize open interface specifications for geoprocessing products and services. Its Web site— www.opengeospatial.org —will provide you with information on adopted and proposed specifications, discussion papers on technology issues, and white papers on open standards in general. OGC also maintains another site for its OGCNetwork— www.ogcnetwork.org . OGCNetwork is an online forum that brings together OGC members and the public to engage in discussion, testing, and demonstration of open geospatial specification-based capabilities. Additional OGC documentation sources include the following: ◦ Simple features specification The OpenGIS Simple Features Specification for SQL can be found at www.opengeospatial.org/docs/ 99-049.pdf . The purpose of this specification is to define a standard SQL schema that supports storage, retrieval, query, and update of simple geospatial feature collections via the ODBC API. A simple feature is defined by the OpenGIS Abstract specification to have both spatial and nonspatial attributes. Spatial attributes are geometry valued, and simple features are based on 2D geometry with linear interpolation between vertices. 261

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

◦ Conformance testing The spatial type for Oracle will be tested with the Conformance Test Guidelines for OpenGIS Simple Features Specification for SQL before final release. Information on conformance testing can be found at www.opengeospatial.org/resource/testing?highlight=testing . ◦ OGC conformance test scripts The test suite software is provided by OGC in two ways for each test—as a set of SQL scripts and as embedded C programming language source code. OGC recognizes that this test suite software will probably have to be adapted to work with software products seeking conformance. Organizations whose products are being tested may select either form of test suite for adaptation and testing. The Spatial Type for Oracle has been tested using the OpenGIS Simple Features Specification for SQL Compliance Testing suite located at www.opengeospatial.org/resources/?page=testing&view=sfsql .

Where to find Oracle documentation For Oracle documentation, you can visit Oracle's Web site at www.oracle.com/index.html for general information about Oracle products and services. To obtain documentation for Oracle 10 g database software, try the Oracle Database Documentation Library, found at www.oracle.com/pls/db102/portal.portal_db?selected=1 (requires a login). ◦ Working with Oracle data types and extensions For information about working with Oracle data types and extensions, the following Oracle books are available online at the above link under the Books section tab. ▪ Application Developers Guide—Fundamentals ▪ Application Developer's Guide—Large Objects ▪ Application Developer's Guide—Object-Relational Features ▪ Data Cartridge Developer's Guide ▪ Oracle Call Interface Programmer's Guide Also, the white paper LOB Performance Guidelines is available at http://www.oracle.com/technology/ products/database/application_development/pdf/lob_performance_guidelines.pdf . ◦ Errors/Troubleshooting Oracle error and troubleshooting codes and information can also be found at http://otn.oracle.com/pls/ db10g/portal.portal_demo3?selected=1 . Specifically, error codes can be found at http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10744/toc.htm . You can also find assistance from other Oracle database users on the Oracle OTN forums at http://forums.oracle.com/forums .

Section VI BLOB data storage in Oracle geodatabases Note: This topic was updated for 9.3.1. BLOB is a database management system (DBMS) industry acronym for binary large object. BLOB columns were implemented several years ago by Oracle Corporation to replace LONG RAW technology for storing binary data.

262

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

The architecture of the BLOB data type is divided into three basic components: the BLOB column, the LOB segment, and the LOB index. The BLOB column stores the LOB locator (36 bytes) and binary data in row if it is less than 3,965 bytes and in-row storage has not been disabled for the column. NOTE: Tests by ESRI have shown that allowing storage in row provides the best performance, so you are advised not to disable in-row storage. If the binary data exceeds 3,964 bytes, the in-row storage space of the BLOB column is not allocated, and the LOB locator references the binary data stored in the LOB segment. Therefore, a value stored in a BLOB column with in-row storage enabled is always at least 36 bytes (the space allocated to the LOB locator) and may be as large as 4,000 bytes (the combined space allocated to the LOB locator and the maximum space that can be allocated to binary data stored in row). The LOB segment is divided into chunks. Chunks must be a multiple of the Oracle data block size. For example, if the data block size is 8K, the LOB segment can be created with a minimum chunk size of 8K. If the length of the data stored within the LOB segment is 5,000 bytes, it is stored in the LOB segment since it exceeds 3,964 bytes and the chunk size is 8K or 8,192 bytes. In this case, 3,192 bytes of the LOB segment chunk remains unused. Transferring data from LONG RAW to BLOB can result in more space being required—perhaps as much as a 30 percent increase due to the unused space in the LOB segment. This is unavoidable if your data exceeds the 3,964-byte in-row storage threshold of the BLOB column. The 8K chunk size experiences the best I/O performance while wasting the least amount of space. The 16K chunk size wastes more space than an 8K chunk size. Therefore, to avoid the loss of space, you are advised to either re-create the database that currently has a 16K data block size with an 8K data block size or, if that is not possible, create LOB segments in table spaces that have been created with an 8K block size. To do this, you need to allocate an 8K buffer cache in the Oracle System Global Area (SGA). Chunk sizes of 4K and 2K have been found to waste less space, but the increase in I/O cost does not warrant using them. The LOB index is only used if the number of chunks addressed by the LOB locator exceeds 12; otherwise, the first 12 chunks are addressed by the LOB locator. The following three figures illustrate the three possible storage cases of binary data stored in a BLOB column. In the first case, 3,000 bytes of binary data are stored in row, since 3,000 bytes is less than the 3,965-byte in-row storage threshold. If in-row storage is not disabled for the BLOB column, the LOB segment and the LOB index are not used. Typically, this results in a faster fetch of the BLOB data due to the reduced number of I/O operations since Oracle does not need to access the LOB segment or the LOB index.

BLOB data smaller than 3,965 bytes in size stored in-row 263

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

The next figure illustrates the second case, in which the binary data is larger than 3,964 bytes (in this case, the data is 81,920 bytes) and cannot fit in row. Therefore, the LOB locator references the binary data that is stored in the LOB segment. Since the binary data does not occupy more than 12 chunks in the LOB segment, the LOB locator stores its addresses. In this case, the LOB index is not used.

BLOB data greater than 3,964 bytes in size stored out-of-row. A LOB locator in the table points to the LOB segment where the data is stored. In the final illustration, the binary data is so large (106,496 bytes) that the LOB index is required. In this case, the binary data exceeds the in-row storage plus requires more than 12 chunks within the LOB segment to store it. For data this large, the LOB locator references the LOB index to obtain the location of the chunks within the LOB segment. This case is extremely rare for vector data and can be avoided for raster data.

264

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

BLOB data stored out-of-row, requiring a LOB index

Setting the DBTUNE parameters to store BLOB columns The storage parameters of the DBTUNE table control how ArcGIS creates tables and indexes in Oracle. Some of the storage parameters also determine which data type is used when a table is created. For details on the DBTUNE table, see The dbtune file and the DBTUNE table . For general information on DBTUNE storage parameters, see DBTUNE configuration parameter name-configuration string pairs . The ArcSDE DBTUNE storage parameters, GEOMETRY_STORAGE, RASTER_STORAGE, and ATTRIBUTE_BINARY, determine which Oracle data type is used to store ArcSDE data. Note that beginning with ArcSDE 9.2, the RASTER_BINARY_TYPE storage parameter was replaced with the RASTER_STORAGE parameter. If you currently have ArcSDE 9.1 installed, substitute all references to RASTER_STORAGE with RASTER_BINARY_TYPE. The RASTER_BINARY_TYPE parameter accepts only two values: LONGRAW and BLOB. The GEOMETRY_STORAGE parameter controls the storage of vector data that is stored in a feature class. The RASTER_STORAGE parameter controls the storage of raster data that is stored in a raster dataset, raster catalog, or raster attribute. Finally, the ATTRIBUTE_BINARY parameter controls the storage of all other binary data that is not vector or raster. To create BLOB columns, the parameters must be set as follows within a given DBTUNE keyword: GEOMETRY_STORAGE SDELOB RASTER_STORAGE BLOB

265

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

ATTRIBUTE_BINARY BLOB

ESRI recommends the following LOB storage parameters for vector and raster data: ◦ Always enable in-row storage because most geographic information system (GIS) data fits within the 3,964-byte in-row threshold. Performance is best when data is stored in row. ◦ Enable cache since ArcSDE data is frequently read. ◦ Since ArcSDE does not perform updates on BLOB data but instead performs only inserts and deletes, set the PCT_VERSION to 0 as there is no need to maintain older versions of the data within the LOB segment. ◦ You should not use a chunk size less than 8K. Chunk sizes of 2K and 4K increase the amount of I/O because the Oracle server process must fetch more chunks. You will probably find that an 8K chunk size wastes less space than 16K. If you use a chunk size of 2K or 4K, you will find that it wastes less space, but tests have found that the display time for most raster and vector data increases dramatically over storing in an 8K chunk size. Since the chunk size must always be a multiple of the data block size, the best data block size to use for storing GIS data in BLOBs is 8K. The following is an example of how the raster DBTUNE storage parameters have been modified to accommodate a raster blocks table stored as a BLOB data type. RASTER_STORAGE "BLOB" BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE RASTER LOB (BLOCK_DATA) STORE AS (TABLESPACE RASTER_LOB_SEGMENT CACHE PCTVERSION 0)" AUX_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE RASTER LOB (OBJECT) STORE AS (TABLESPACE RASTER CACHE PCTVERSION 0)"

If the raster block pixel data is less than 3,965 bytes, it is stored within the BLOCK_DATA column in the RASTER table space. However, if it exceeds this threshold, it is stored in the LOB segment in the RASTER_LOB_SEGMENT table space. The LOB index is only used if the number of chunks exceeds 12. This is unlikely to happen for ArcSDE data. Consider a LOB segment with a chunk size of 8K. Before the LOB index is used, the ArcSDE binary data needs to exceed 96K. The following is an example of how the vector DBTUNE storage parameters have been modified to accommodate the feature table stored in a BLOB data type: GEOMETRY_STORAGE "SDELOB" F_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE VECTOR LOB (POINTS) STORE AS (TABLESPACE VECTOR_LOB_SEGMENT CACHE PCTVERSION 0)"

If the feature's binary data is less than 3,965 bytes, it is stored within the POINTS column in the VECTOR tablespace. However, if it exceeds this threshold, it is stored in the LOB segment in the VECTOR_LOB_SEGMENT tablespace. ATTRIBUTE_BINARY "BLOB"

266

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

B_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE BIZZTABS LOB (DOCUMENT) STORE AS (TABLESPACE BIZZ_LOB_SEGMENT CACHE PCTVERSION 0)" A_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE BIZZTABS LOB (DOCUMENT) STORE AS (TABLESPACE BIZZ_LOB_SEGMENT CACHE PCTVERSION 0)"

In this example, if the business table's binary data is less than 3,965 bytes, it is stored within the business table's BLOB column in the BIZZTABS table space. However, if it exceeds this threshold, it is stored in the LOB segment in the BIZZ_LOB_SEGMENT table space. The BLOB column in this example is DOCUMENT. If the above B_STORAGE DBTUNE parameter is used to create a table that does not have a DOCUMENT column, the following error is returned by Oracle: ORA-00904: "DOCUMENT": invalid identifier

Therefore, it is not wise to add B_STORAGE or A_STORAGE parameters referencing a specific BLOB column to the DEFAULTS keyword, since the business table must contain these columns. Instead, create separate DBTUNE keywords and add these storage parameters to the keywords. The keyword that contains the storage parameter is referenced during the creation of the table. It should also be noted that storage parameters of the DEFAULTS keyword are used if they are not included with a specific keyword. Due to this fact, it is not necessary to add a particular storage parameter within a keyword if its configuration string is identical to the storage parameter under the DEFAULTS keyword. For instance, if all the storage parameters except B_STORAGE and A_STORAGE of a new keyword, ROADS, have the same configuration string as those of the DEFAULTS keyword, you only need to create the B_STORAGE and A_STORAGE parameters under the ROADS keyword. All other storage parameters are read from the DEFAULTS keyword since they are not found in the ROADS keyword. For information on DBTUNE keywords and the DEFAULTS keyword, see DBTUNE configuration keywords and The DEFAULTS keyword , respectively.

Section VII The Oracle Spatial geometry and raster types Note: This topic was updated for 9.3.1. ArcSDE supports Oracle Spatial's Object Relational Model as a method to store spatial data. Oracle Spatial extends the Oracle database with the addition of spatial data management functions, spatial metadata schema, indexing methods, and implementation rules. Oracle Spatial provides a spatial geometry type—MDSYS.SDO_GEOMETRY—and a spatial raster type—MDSYS.SDO_GEORASTER. See Using the Oracle Spatial geometry type for more information on using the geometry type with ArcSDE geodatabases and Using the Oracle Spatial raster type for more information on using the Oracle Spatial GeoRaster type with ArcSDE geodatabases. For additional information on Oracle Spatial and the storage types it provides, please see the Oracle Spatial User's Guide and Reference for your Oracle release.

Section VIII Using the Oracle Spatial geometry type Note: This topic was updated for 9.3.1.

267

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

ArcSDE supports Oracle Spatial's Object Relational Model as an optional method to store spatial data. Specifically, Oracle Spatial or Locator geometry can be used to store and manage the feature and raster contents of datasets within ArcSDE geodatabases. Oracle Spatial is an extension to the Oracle DBMS that adds a spatial type and spatial query functions to Oracle. It is offered by Oracle using two primary options. ◦ Oracle Spatial is an optional feature of the Oracle Database Enterprise Edition. In addition to providing the SDO_Geometry type, Oracle Spatial provides a number of additional geospatial capabilities. ◦ Oracle Locator provides a subset of Oracle Spatial capabilities. It is included as a standard feature of Oracle Database Standard and Enterprise Editions. Among other capabilities, it provides the Oracle Spatial geometry type (referred to as SDO_Geometry) and a SQL API to this content. Oracle Spatial shares duplicate functionality with much GIS technology including ArcGIS. The primary way in which most ArcGIS users apply Oracle Spatial is as an optional mechanism for geodatabase storage and access in an Oracle DBMS. Essentially, one of the choices that ArcGIS users can make each time they create a new feature class or raster dataset in a geodatabase in Oracle is how to store feature or raster geometry—they can use either the geodatabase or the Oracle Spatial data storage options. See An overview of feature geometry and raster data storage for a list of feature and raster storage options when using an Oracle DBMS. For additional information on Oracle Spatial, refer to the Oracle Spatial User's Guide and Reference for your Oracle release. You can use the following links to navigate this topic: ◦ An overview of Oracle Spatial data storage ◦ How to make SDO_GEOMETRY your default geometry storage ◦ What happens when you create feature classes with SDO_GEOMETRY geometry storage ◦ How to use existing Oracle Spatial tables ◦ Interoperability considerations

An overview of Oracle Spatial data storage Oracle Spatial extends the Oracle database with the addition of spatial data management functions. Oracle Spatial provides a spatial geometry type (MDSYS.SDO_GEOMETRY), spatial metadata schema, indexing methods, functions, and implementation rules, which are described below. NOTE: Oracle Locator is a subset of Oracle Spatial. Oracle Locator includes the SDO_GEOMETRY data type along with some of the functionality provided with Oracle Spatial. Oracle Locator may be used with ArcSDE. Please refer to Oracle's documentation for an explanation of the difference between Oracle Spatial and Oracle Locator. Throughout this topic, "Oracle Locator" can be used in place of references to "Oracle Spatial." ◦ SDO_GEOMETRY The Oracle Spatial geometry type SDO_GEOMETRY is implemented using Oracle's extensible objectrelational type system. The SDO_GEOMETRY type stores information about a geometry including its geometry type, spatial reference ID, interpolation type (straight versus curved), and coordinate values. The SDO_GEOMETRY type supports single and multipart point, line, and area geometry. Geometries may be defined as having linear interpolation between coordinates as defined by the OpenGIS Simple

268

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

Feature Specification. Geometries may also be constructed from circular curves or a combination of both interpolation methods. Application programs are responsible for properly inserting, updating, and fetching the contents of the SDO_GEOMETRY type using Oracle's object-relational SQL interface. Applications are also responsible for ensuring that the content of each geometry adheres to the rules defined in the Oracle Spatial documentation. Oracle provides geometry validation routines that can be executed after inserting geometries. NOTE: Oracle's geometry validation routines do not implement precisely the same set of rules as the ArcSDE geometry validation. However, ArcSDE is designed to write SDO_GEOMETRY that satisfies Oracle's validation rules. ◦ Metadata schema Information about every SDO_GEOMETRY column should be recorded in the Oracle Spatial metadata schema, although Oracle Spatial does not do this automatically. (The Oracle Spatial metadata schema is exposed for each schema as the view USER_SDO_GEOM_METADATA.) The software that creates SDO_GEOMETRY columns must insert the metadata for those columns. ArcSDE does this for any SDO_GEOMETRY feature classes it creates. The metadata contains the spatial column name, the name of the table it resides in and its owner, the Oracle SRID, the number of dimensions, the range of each dimension, and its coordinate tolerance. ◦ Spatial indexes Spatial indexes provide fast access to features based on the location of their geometry. For SDO_GEOMETRY, R-tree spatial indexes are generally the most efficient and easiest to create, and Oracle recommends their use in most situations. Oracle Spatial provides the Spatial Index Advisor utility to assist in determining the best type of spatial index for a given table. In addition, consult your Oracle Spatial User's Guide and Reference for detailed information on supported spatial index types, how to create them, and the trade-offs of different spatial index methods. ◦ Spatial functions Oracle Spatial extends SQL with spatial search functions for primary and secondary filtering. Including the SDO_FILTER function in a SQL query will perform a primary spatial search utilizing the spatial index. Spatial predicates, such as SDO_RELATE and SDO_CONTAINS, return secondary relationships between pairs of SDO_GEOMETRY objects. Oracle Spatial has spatial transformation functions that change the form of an SDO_GEOMETRY value. For example, the SDO_BUFFER function computes the coordinates of a new SDO_GEOMETRY object as a buffer polygon at a given distance surrounding the original geometry. Other spatial transformation functions include SDO_DIFFERENCE and SDO_INTERSECTION. ◦ Coordinate reference and SRID Oracle Spatial provides access to a number of predefined coordinate reference systems using Spatial Reference Identifier (SRID) values. The SRID value, stored in the SDO_GEOMETRY object, specifies the coordinate reference for the geometry stored in that object. If it is not NULL, the SRID in the SDO_GEOMETRY object is a foreign key into a table containing details about each SRID. This table is called MDSYS.CS_SRS. The SDO_TRANSFORM function uses the spatial reference ID to establish coordinate reference transformations. ArcSDE may also use this information to create ArcSDE spatial references.

How does ArcSDE use Oracle Spatial?

269

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

ArcSDE supports Oracle Spatial or Oracle Locator for storing and managing geometry in an Oracle database. To use it, you must have SDO_GEOMETRY specified for the GEOMETRY_STORAGE parameter of one of your configuration keywords. If you want to use Oracle Spatial geometry storage most of the time, specify SDO_GEOMETRY for the GEOMETRY_STORAGE parameter in your DEFAULTS configuration keyword. If you want to use it for only some datasets, utilize the SDO_GEOMETRY keyword when creating each individual dataset.

Making Oracle Spatial your default geometry schema When you first install the 9.3 ArcSDE component, ST_Geometry is the default geometry storage type. The default settings for ArcSDE storage are defined in the DBTUNE table by the GEOMETRY_STORAGE parameters. Changing the default ArcSDE geometry storage to use Oracle Spatial is easy. For the DEFAULTS keyword, change the GEOMETRY_STORAGE parameter from ST_GEOMETRY to SDO_GEOMETRY. After the default GEOMETRY_STORAGE setting has been changed to SDO_GEOMETRY, ArcSDE creates feature classes with SDO_GEOMETRY columns by default. NOTE: Use the sdedbtune administration command to alter DBTUNE settings. For details on using the sdedbtune command, consult the ArcSDE Administration Command Reference installed with ArcSDE. ArcSDE for Oracle supports a number of different geometry storage schemas—these different schemas can all be used together in the same database. While there can only be one default geometry schema, individual tables can be created using different geometry schemas. If you want to store just some of your feature classes with the Spatial Type for Oracle storage, you can specify the keyword SDO_GEOMETRY when you create the feature class. If you do this, that particular feature class will be created with an SDO_GEOMETRY column. In the dbtune file, the SDO_GEOMETRY keyword appears as follows: ##SDO_GEOMETRY GEOMETRY_STORAGE "SDO_GEOMETRY" ATTRIBUTE_BINARY "BLOB" RASTER_STORAGE "SDO_GEORASTER" SDO_COMMIT_INTERVAL 1000 UI_TEXT "User Interface text description for SDO_GEOMETRY" COMMENT

"Any general comment for SDO_GEOMETRY keyword"

END

Top of page

What happens when you create feature classes with SDO_GEOMETRY geometry storage When you create a feature class with SDO_GEOMETRY storage, the following happens: ◦ An SDO_GEOMETRY column is added to the business table of the feature class. ArcSDE creates a feature class by adding a geometry column to the specified business table. When the GEOMETRY_STORAGE parameter is set to SDO_GEOMETRY, ArcSDE adds an SDO_GEOMETRY column to the business table. In this example, a business table named Countries has name and population properties-after adding a geometry column, it also has an SDO_GEOMETRY column named Borders. If needed, a unique feature identifier column (called OBJECTID in the following example) is added and populated.

270

Administering ArcSDE® for Oracle®

Name

Data type

NAME

VARCHAR2(32)*

Data storage in the geodatabase

Null?

POPULATION NUMBER(11) BORDERS

MDSYS.SDO_GEOMETRY

OBJECTID

NUMBER(38)

NOT NULL

*NVARCHAR2(32) if using Unicode strings A geometry column can be added to the business table using ArcCatalog, the sdelayer administration utility, or the ArcSDE C and Java APIs. ◦ A spatial index is created on the SDO_GEOMETRY column. When an SDO_GEOMETRY column is added to a business table, a spatial index on that geometry column is usually created. By default, ArcSDE creates an R-tree index on an SDO_GEOMETRY column. (ArcSDE will also support creating Oracle Spatial Fixed and Hybrid indexes, but these are no longer generally recommended by Oracle.) Alternatively, ArcSDE can create feature classes with no spatial index; however, spatial queries cannot be supported until a spatial index is created. Oracle's SDO_FILTER, used by ArcSDE, requires the presence of a spatial index. You can create a spatial index several ways—in ArcCatalog; with the sdelayer administration utility; using the Oracle Spatial Index Advisor; using SQL; or programmatically using the ArcSDE C and Java APIs. ArcSDE automatically drops and re-creates Oracle Spatial indexes created by ArcSDE whenever the feature class is switched between LOAD_ONLY_IO and NORMAL_IO mode. Spatial indexes defined by the Oracle Spatial Index Advisor application or created using SQL are not dropped when ArcSDE switches the feature class to LOAD_ONLY_IO mode. ◦ A record is added to the Oracle Spatial metadata view. When ArcSDE adds an SDO_GEOMETRY column to a business table, it also adds the required Oracle Spatial metadata record to the USER_SDO_GEOM_METADATA view. This metadata includes the table name, SDO_GEOMETRY column name, spatial reference ID, and coordinate dimension information. If a third-party application or SQL is used to create the table, the spatial column, and its metadata, and the table is then registered with ArcSDE, ArcSDE will not delete the metadata when unregistering the table with ArcSDE. However, ArcSDE will always delete the metadata when deleting the table, such as it does with the sdetable -o delete command. ◦ A coordinate dimension is specified. You can create ArcSDE geometry as 2D (x/y), 2D with measures, 3D (x/y/z), or 3D with measures. When creating new feature classes or adding an SDO_GEOMETRY column to an existing table, ArcSDE places the Oracle Spatial dimension information in the DIMINFO column of the metadata view. ▪ The x-coordinate is the first dimension. ▪ The y-coordinate is the second dimension. ▪ The z-coordinate is the third dimension if the feature class is defined as having elevations. ▪ The m-coordinate is the last dimension (third or fourth, depending on the presence or absence of a z-coordinate) if the feature class is defined as having measures. ◦ The SRID of each SDO_GEOMETRY value is set based on the coordinate reference.

271

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

Oracle Spatial provides predefined coordinate references in the MDSYS.CS_SRS table. When using ArcSDE to create a new feature class, to set a specific SRID for the SDO_GEOMETRY column, identify the appropriate Oracle Spatial coordinate reference description, then set the feature class's SDO_SRID DBTUNE storage parameter to that value. For example: #MY_SDO_KEYWORD GEOMETRY_STORAGE SDO_GEOMETRY SDO_SRID 8307 . . . (other parameters) . . . END

If the SDO_SRID storage parameter is not set, ArcSDE sets the SRID of each SDO_GEOMETRY value to NULL, as well as the SRID in the corresponding metadata record. ArcSDE does not require the Oracle Spatial SRID. ArcSDE maintains the coordinate reference information for each feature class in its own SPATIAL_REFERENCES table independently from Oracle Spatial. Consult your Oracle Spatial User's Guide and Reference for information on supported coordinate references. ◦ The SDO_GEOMETRY column is populated. When storing geometry in the database, ArcSDE populates the SDO_GEOMETRY value from an ArcSDE API object called SE_SHAPE. The SE_SHAPE object can contain simple and complex geometry that may include elevations, measures, CAD data, annotation, and surface patches. The SDO_GEOMETRY data type supports a subset of these geometric properties. Because there is not a one-to-one mapping of the components in the SDO_GEOMETRY and the SE_SHAPE object, ArcSDE follows a set of rules when storing ArcSDE data in Oracle Spatial tables. ▪ Create four-digit SDO_GTYPE based on the geometry's entity type. ▪ Set the SDO_SRID to NULL if no Oracle Spatial coordinate reference is provided in a DBTUNE parameter. ▪ Write coordinate values in the appropriate coordinate reference system. ▪ Write coordinates in the order x, y, z, and m, defining elevation and measure ordinates only if present in the source SE_SHAPE object. ▪ If elevations and/or measure ordinates are present in the source SE_SHAPE object, store all coordinates with an elevation and/or measure ordinate. ▪ Set elevations and measure ordinates to NaN ("Not a Number") if specific coordinates in the geometry contain undefined elevation or measure values. ▪ Allow measures on any geometry type, not just linestrings. The first and last coordinates need not contain measure values. ▪ Do not restrict measure values to ascending or descending order. ▪ Write circular curves to the SDO_GEOMETRY type when the feature class is registered with the CAD entity mask (c); otherwise, convert the curves to densified straight-edged linestrings. ▪ Convert noncircular arcs (cubic spline, Bezier) to straight-edged linestrings. When the feature class is registered with the CAD entity mask (c), also store the curved representation in SE_ANNO_CAD_DATA. ▪ Validate all features before writing them to the database. The validation rules are described in the ArcSDE Developer Help.

272

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

▪ Use SDO_POINT to store single part x/y or x/y/z point in the SDO_GEOMETRY object. For other types of point feature classes, store the point vertices in the SDO_ORDINATE_ARRAY. NOTE: ArcSDE does not support heterogeneous geometry collection in the SDO_GEOMETRY object, and ArcSDE does not encode SDO_ETYPE 0 elements in the SDO_GEOMETRY object. SDO_ETYPE 0 elements are application specific. See "Interoperability considerations" below for more information. ◦ An additional column is added to the business table if storing CAD and annotation properties. The SDO_GEOMETRY type cannot store all types of geometric elements that ArcSDE storage must support. When storage for these elements is required (as determined from the geometry type flags specified when the feature class is created), ArcSDE adds a column called SE_ANNO_CAD_DATA to the business table. Using the Counties feature class example from above, the business table would now contain the following: Name

Data type

NAME

VARCHAR2(32)*

POPULATION

NUMBER(11)

BORDERS

MDSYS.SDO_GEOMETRY

Null?

SE_ANNO_CAD_DATA BLOB OBJECTID

NUMBER(38)

NOT NULL

*NVARCHAR2(32) if using Unicode strings Whenever ArcSDE detects the data source has CAD data, ArcSDE writes a simple geometric representation of the CAD data into the SDO_GEOMETRY value and writes the unmodified CAD data into the SE_ANNO_CAD_DATA value. If the data source does not have CAD data, ArcSDE sets the SE_ANNO_CAD_DATA value to NULL. The SE_ANNO_CAD_DATA property contains data from numerous ArcGIS components: ▪ AutoCAD or MicroStation data from ArcSDE CAD Client ▪ Parametric objects such as cubic splines and Bezier curves from ArcMap ▪ Surface patches from ArcMap Spatial Analyst ▪ Annotation from ArcInfo Workstation (before ArcGIS 8) ◦ Spatial queries on the feature class are performed using Oracle Spatial filter functions. ArcSDE uses the Oracle Spatial SDO_FILTER function to perform the primary spatial query. ArcSDE performs secondary filtering of the SDO_GEOMETRY based on the spatial relationship requested by the application. Applications may also include Oracle Spatial primary and secondary filter functions in the SQL WHERE clause supplied to ArcSDE. Using spatial filters in the WHERE clause, applications can distribute the spatial query to the database server, the ArcSDE application server, and the application itself.

Using existing Oracle Spatial tables ArcSDE can successfully use tables containing SDO_GEOMETRY columns created externally by other applications or using SQL (sometimes referred to as third-party tables) as long as the tables meet certain prerequisites:

273

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

◦ It must be owned by the user registering the table. ◦ It must have a single SDO_GEOMETRY column. ◦ It must have no other columns of a user-defined type. ◦ It must have a valid entry in the view USER_SDO_GEOM_METADATA. ◦ It must have a single type of geometry (points, lines, or polygons). Geometry can be multipart. ◦ It must have an integer, unique, not-NULL column suitable as a registered row ID column. ◦ It should have a spatial index. ◦ It should pass Oracle's geometry validation tests; otherwise, accessing these geometries may have unexpected results. ◦ All the spatial records must have non-null valid number values in the SDO_ORDINATES array.

Performing manual registration of third-party tables containing SDO_GEOMETRY columns The ArcSDE administration command sdelayer –o register manually registers a table as a feature class. Manually registering tables as feature classes gives you more control over how a table is registered. Here is an example of registering a table called TBL containing point geometries (–e p) in a spatial column called SHAPE. The table has an integer column called PID that will be used as a user-maintained unique feature identifier column (–C pid,USER). sdelayer –o register –l tbl,shape –e p –C pid,USER –u –p

To manually register these tables, the prerequisites described above must be met.

Using autoregistration for third-party tables containing SDO_GEOMETRY columns Autoregistration is a feature of ArcSDE that can find and register unregistered Oracle Spatial tables, allowing ArcSDE to access these tables as feature classes. Autoregistration is controlled by the ArcSDE initialization parameter DISABLEAUTOREG, which is set to TRUE by default. This means the default state for Autoregistration is "off." To turn on autoregistration, use the following administration command: sdeconfig –o alter –v DISABLEAUTOREG=FALSE –u sde –p

ArcSDE provides a list of registered feature classes to client applications at certain times, such as when a user connects to the server using ArcCatalog or when running the command sdelayer –o describe. In the process of providing this list, ArcSDE autoregistration searches the Oracle Spatial metadata view, ALL_SDO_GEOM_METADATA, for tables containing SDO_GEOMETRY columns on which the user has SELECT privileges and that are not already registered as feature classes. When a table is discovered that matches these criteria, ArcSDE automatically registers it, making the table available to ArcSDE client applications. To register the table, ArcSDE must know the geometry type. Autoregistration looks at the first row in a newly discovered table to establish the ArcSDE geometry type. Autoregistration will not register empty tables, but empty tables can be registered manually with sdelayer –o register. If you know the table contains rows with differing geometry types, the sdelayer command can be used to alter the geometry type definition after autoregistration completes. ArcSDE with Oracle Spatial requires a column to identify each row. See "Unique feature identifier column (OBJECTID)." Autoregistration searches for a column in the table to use as a unique feature identifier column. To qualify, the column must be defined as NUMBER(38) UNIQUE NOT NULL. If such a column is found, ArcSDE records it in the ArcSDE table registry as the unique feature identifier column

274

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

for the table. If a suitable unique feature identifier column is not found, the table is registered, but operations requiring a unique feature identifier are unavailable. For SDO_GEOMETRY columns that have an Oracle Spatial SRID, ArcSDE stores the information in the ArcSDE SPATIAL_REFERENCES table. ArcSDE sets its spatial reference AUTH_NAME field to ORACLE and the AUTH_SRID field to the SRID value. ArcSDE tests the coordinate reference description and, if it is valid, sets the SRTEXT field to the Oracle Spatial coordinate reference description.

Interoperability considerations A common misconception is that applications can interoperate simply because they support the same underlying geometry type. However, the geometry type is only one aspect of the geodatabase as well as other GIS database schemas. Gaining a common understanding of rules, constraints, schema, and implementation is also required. Some things you should consider when using Oracle Spatial with ArcSDE and ArcSDE clients are the following: ArcSDE and ArcGIS do not support multiple geometry columns in a table. Tables with multiple SDO_GEOMETRY columns should be accessed through views that contain only one SDO_GEOMETRY column. To use data in an Oracle Spatial table that contains multiple spatial columns, create a spatial view using SQL. This view should only contain one spatial column. Next, register the spatial view with ArcSDE using sdelayer –o register. To learn how to create and register a view containing only one SDO_GEOMETRY column, see the Knowledge Base article Create an Oracle view of an Oracle Spatial layer (containing multiple geometry columns) and register it with ArcSDE . ArcSDE and ArcGIS only support a single geometry type in an SDO_GEOMETRY column. If a single SDO_GEOMETRY column in a table contains multiple geometry types (for example, some records are points and some are polygons), the table cannot be registered with ArcSDE or the geodatabase; the feature class must be registered as containing one geometry type. Oracle Spatial does not necessarily enforce geometry type constraints on an SDO_GEOMETRY column. Without this enforcement, one application may want to enforce a single geometry type constraint, but another application could insert different geometry types. Beginning with Oracle9 i , you have the option to constrain the geometry type on insert into a table with a spatial index creation parameter. For earlier Oracle versions, another option to enforce geometry type constraints is to create an insert-update trigger that checks the SDO_GEOMETRY GTYPE property to enforce geometry types. Oracle Spatial does not automatically enforce geometry validation on the insert or update of an SDO_GEOMETRY value. ArcSDE validates geometry when inserting or updating geometries. However, Oracle Spatial itself does not automatically enforce geometry validation on the insert or update of an SDO_GEOMETRY value if you insert or update geometries using methods other than ArcSDE clients, such as SQL. Problems would occur if illegal or poorly formed geometry values were passed to ArcSDE client applications. To reduce the occurrences of these potential problems, you should validate any geometries created or changed by any method other than an ArcSDE client application. NOTE: Starting with ArcSDE 9.1, ArcSDE no longer validates SDO_GEOMETRY features as they are fetched from the database. This change was done to improve fetch performance. There are two tools available for validating geometry. Oracle's VALIDATE_GEOMETRY_WITH_CONTEXT will check geometries using Oracle's shape validation rules, and sdelayer –o feature_info will check them using ArcSDE's rules. The feature_info operation optionally includes as part of its output information on whether or

275

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

not a shape's geometry is valid for ArcSDE. For details on the use of this operation, please refer to the Administration Command Reference documentation included with your ArcSDE installation. ArcSDE geometry validation is not the same as Oracle Spatial geometry validation. While it is important that geometries pass Oracle Spatial validation, successfully validating geometries with Oracle's validation routines does not guarantee that the geometries will be validated by ArcSDE. You can create an insert-update trigger to fire the SDO_VALIDATE function to enforce validation of SDO_GEOMETRY types. The ArcSDE C API can be used to write an application that retrieves features even if they fail ArcSDE shape validation. However, it is then up to the client application to determine the suitability of the geometry, or how to fix it. ArcSDE does not support heterogeneous geometry collections in an SDO_GEOMETRY object. Most applications reading SDO_GEOMETRY objects would not know how to interpret SDO_ETYPE 0 data created by other applications. Oracle Spatial allows applications to insert application-specific data into an SDO_GEOMETRY object. Applications do this by embedding their data using an SDO_ETYPE value of 0. This allows applications great flexibility to store many types of unconventional geometry and other data. However, the meaning of the application-specific data is known only to the application that generated that special SDO_GEOMETRY object. Such application-specific data cannot be reliably supported in an interoperable environment. Applications reading SDO_GEOMETRY objects probably would not know how to interpret SDO_ETYPE 0 data created by other applications. Applications updating SDO_GEOMETRY objects would not know how to edit or preserve the SDO_ETYPE 0 data. When reading SDO_GEOMETRY objects containing SDO_ETYPE 0 elements, ArcSDE will ignore the SDO_ETYPE 0 data and will pass only the simple feature geometry elements it supports to the application. When updating SDO_GEOMETRY objects containing SDO_ETYPE 0 elements, ArcSDE will not preserve the SDO_ETYPE 0 data. Therefore, applications that need to ensure that SDO_ETYPE 0 data is preserved should make sure that users do not have UPDATE access to the table. ArcSDE requires that all SDO_GEOMETRY values in a column be in the same coordinate reference system. If the coordinate reference is undefined, the SRID value should be NULL as defined in the Oracle Spatial User's Guide and Reference. Prior to Oracle9 i, Oracle Spatial does not automatically enforce spatial reference ID validation on the insertion or update of an SDO_GEOMETRY value. To enforce validation of SDO_GEOMETRY types on these older Oracle instances, you can create an insert-update trigger to fire the SDO_VALIDATE function. Starting with Oracle9i, Oracle Spatial requires that the SRID in each geometry match each other and the SRID in the spatial metadata, even if it is NULL. Oracle Spatial and ArcSDE both assume that the first and second dimensions of the SDO_GEOMETRY are x and y, respectively. If an SDO_GEOMETRY object has three dimensions, ArcSDE assumes the third dimension is a measure if the dimension name (in the spatial metadata) starts with an M; otherwise, the third dimension is assumed to be elevation. You can control how ArcSDE interprets the third dimension by setting the feature class's entity flag to have either elevations or measures. Oracle9 i Release 2 extended the SDO_GTYPE member of the SDO_GEOMETRY type to allow encoding of whichever dimension contains a measure ordinate. The second digit of the four-digit SDO_GTYPE may be 0, 3, or 4. If it is 3 or 4, this indicates which dimension contains the measure ordinate. ArcSDE 9.0 and above recognizes this encoding. Otherwise, if the SDO_GEOMETRY object has four dimensions, the measure is expected to be the last ordinate.

276

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

In this example, sdelayer sets the entity type of a feature class to store linestrings and elevations: sdelayer –o add –e l3

In this example, sdelayer sets the entity type of a feature class to store linestrings and measures: sdelayer –o add –e lM

Oracle Spatial (but not Oracle Locator) provides functions for linear reference system (LRS) calculations using measure values. Oracle Spatial LRS functions require that all measure values in a geometry be monotonically ascending or descending without NaN values. Oracle Spatial LRS also restricts measure values to linestrings. ArcSDE allows measures and LRS calculations on all geometric types, with support for arbitrarily ordered measure values and NaN values. If you intend to use Oracle Spatial LRS functions, be sure to design your application and database to operate within the Oracle Spatial LRS constraints. ArcSDE needs a unique feature identifier in the spatial table to perform spatial queries, log file queries, single-row operations, and multiversioned database operations. With ArcSDE compressed binary schema, the geometry column can serve this purpose because it is a foreign key into the feature table and is defined as a non-NULL, unique integer value. SDO_GEOMETRY does not include a unique identifying value, so when ArcSDE adds the SDO_GEOMETRY column to an existing table, it may also add a unique identifying column. Such a column is referred to as the registered row ID column. This column is often called OBJECTID, but it can have another name. Or, an existing column can be used for the registered row ID column so long as it is indexed and is an integer, UNIQUE, and NOT NULL. Registered row ID columns maintained by ArcSDE must be NUMBER(38) UNIQUE NOT NULL. A registered row ID column can be added using the sdetable administration command or the ArcCatalog application. Many applications, such as ArcGIS, require a registered row ID column in each table or feature class. Each application has its own requirements and limitations. Multiversioned views are available for SQL access to the multiversioned database. ArcGIS uses a multiversioned database implemented through ArcSDE for editing operations. The multiversioned database provides long transaction support for multiple simultaneous design alternatives. Multiversioned views are available for SQL access to the multiversioned database, including Oracle Spatial tables registered as versioned. See Using database views for more information. Modification of Oracle Spatial feature classes participating in networks or topologies should be restricted to ArcGIS applications. ArcGIS can create and maintain networks and integrated topological feature classes from simple feature classes that use the SDO_GEOMETRY type. ArcGIS manages the relationships and maintains the topological integrity of the data—modifications to the underlying features through ArcGIS are reflected in these integrated networks. Modification of Oracle Spatial feature classes participating in these networks or topologies should be restricted to ArcGIS applications. Other applications can freely read the data, but any modifications they make are not reflected in the networks or topologies. Modification of Oracle Spatial feature classes participating in relationships and constraints should be restricted to ArcGIS applications. ArcGIS enforces relationships and constraints across many different data sources. Feature classes containing an SDO_GEOMETRY type may be included in relationships and may have constraints defined on them.

277

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

Modification of Oracle Spatial feature classes participating in relationships and constraints should be restricted to ArcGIS applications. Other applications can freely read the data, but their edits are not properly handled. Tip ◦ You can find further information and help with Oracle Spatial issues on the ESRI Online Support Center .

Section IX Using the Oracle Spatial raster type Note: This topic was updated for 9.3.1. The Oracle Spatial raster data type SDO_GEORASTER is implemented using Oracle's extensible objectrelational type system. It was introduced with the release of Oracle 10 g . The SDO_GEORASTER type stores information about a raster including its pixel type, spatial reference ID, and pixel values. The SDO_GEORASTER type supports all ESRI pixel types: 1 bit through 64 bit, signed, unsigned, and floating point. ArcSDE supports Oracle Spatial's SDO_ GEORASTER data type as an option to store raster data. NOTE: Application programs are responsible for properly inserting, updating, and fetching the contents of the SDO_GEORASTER type using Oracle's object-relational structured query language (SQL) interface. Applications are also responsible for ensuring that the content of each raster adheres to the rules defined in the Oracle documentation. Upon creating a table containing an Oracle SDO_GEORASTER column, ArcSDE populates the required Oracle metadata schema. It is the responsibility of applications such as ArcSDE to perform this task, since it is not performed automatically by Oracle. Should you register a table containing an Oracle SDO_GEORASTER column that was created by a third-party product, it is the responsibility of that product to properly populate the Oracle metadata schema for the SDO_GEORASTER column.

Storing rasters as SDO_GEORASTER The settings for ArcSDE geodatabase storage are defined in the DBTUNE table; the RASTER_STORAGE parameter controls the storage of raster data. To create a table in an ArcSDE geodatabase that contains an SDO_GEORASTER column and, therefore, stores raster as SDO_GEORASTER, you must use a configuration keyword that contains a RASTER_STORAGE parameter set to SDO_GEORASTER when you create the raster dataset or catalog. When you first install the ArcSDE 9.3 component, the default setting for RASTER_STORAGE in the DBTUNE table is BLOB and the default GEOMETRY_STORAGE is ST_GEOMETRY. Below is a partial list of the DEFAULTS keyword parameters: ##DEFAULTS GEOMETRY_STORAGE ATTRIBUTE_BINARY RASTER_STORAGE

"ST_GEOMETRY" "BLOB" "BLOB"

If you plan to store the majority of your raster data in SDO_GEORASTER format, you need to alter the RASTER_STORAGE parameter of the DEFAULTS keyword. In addition, you cannot use a GEOMETRY_STORAGE type of ST_GEOMETRY or SDO_GEOMETRY if you are using SDO_GEORASTER for your raster storage; therefore, you must change your GEOMETRY_STORAGE to either SDELOB or SDEBINARY and set RASTER_STORAGE to SDO_GEORASTER in your DEFAULTS configuration keyword to make SDO_GEORASTER the default storage for your raster data.

278

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

NOTE: It is recommended you not use SDEBINARY geometry storage, which stores the data as LONG RAW, for new data because Oracle will be deprecating support for LONG RAW at its 11 g release. In the following example, the DEFAULTS keyword is altered to create vector data using SDELOB storage and raster data using SDO_GEORASTER storage. ##DEFAULTS GEOMETRY_STORAGE ATTRIBUTE_BINARY RASTER_STORAGE

"SDELOB" "BLOB" "SDO_GEORASTER"

Following the change, ArcSDE creates raster catalogs and raster datasets with SDO_GEORASTER columns by default. Although there can only be one default raster schema (one setting for RASTER_STORAGE under the DEFAULTS configuration keyword), you can use the existing SDO_GEOMETRY configuration keyword to specify SDO_GEORASTER for RASTER_STORAGE when you create a raster catalog or dataset. Do this if you only need to store a minority of your raster data in SDO_GEORASTER format. Before the SDO_GEORASTER keyword can be used, you need to edit the table space information for the RDT_STORAGE and RDT_INDEX_COMPOSITE parameters. By default, the table space information is not included with the SDO_GEORASTER keyword. In the dbtune.sde file, the SDO_GEORASTER keyword appears as follows: ##SDO_GEORASTER GEOMETRY_STORAGE RASTER_STORAGE ATTRIBUTE_BINARY RDT_STORAGE # RDT_INDEX_COMPOSITE # UI_TEXT COMMENT END

"SDELOB" "SDO_GEORASTER" "BLOB" "PCTFREE 0 INITRANS 4" TABLESPACE "PCTFREE 0 INITRANS 4 TABLESPACE STORAGE ( INITIAL 409600) NOLOGGING" "User Interface text description for SDO_GEORASTER" "Any general comment for SDO_GEORASTER keyword"

To change the information in the DBTUNE table for this keyword, use the sdedbtune administration command. You can find details on how to use this command in the ArcSDE Administration Command Reference, installed in the SDEHOME directory. Or you can create a new configuration keyword to use to store raster datasets as SDO_GEORASTER; for example: ##GEORASTER RASTER_STORAGE SDO_COMMIT_INTERVAL UI_TEXT

"SDO_GEORASTER" 1000 "Use to create raster catalogs and datasets with GEORASTER storage"

END

Notice that the preceding examples do not have a complete set of storage parameters associated with them. That is because any parameters not specified in a keyword are picked up from the DEFAULTS keyword. That means there is no need to include parameters that have the same values as those specified under the DEFAULTS keyword. In the examples above, parameters such as BND_STORAGE and AUX_STORAGE aren't included;

279

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

they are read from the DEFAULTS keyword. For the new configuration keyword example (GEORASTER), this means the GEOMETRY_STORAGE parameter is also being read from DEFAULTS. If you do not include the GEOMETRY_STORAGE parameter in your custom SDO_GEORASTER configuration keyword, be sure the GEOMETRY_STORAGE under DEFAULTS is not set to SDO_GEOMETRY or ST_GEOMETRY. For more information on geometry storage keywords, see Oracle DBTUNE configuration parameters . For general information on the DBTUNE table or configuration keywords, see The dbtune file and the DBTUNE table or DBTUNE configuration keywords , respectively.

Adding a third-party table You can use the ArcSDE administration command sderaster –o add to register a table containing an SDO_GEORASTER column that was created by a third-party application. For example: sderaster –o add –l landforms,raster –u gis –p gis

For a table to be added to ArcSDE, it must meet the following criteria: ◦ It must be owned by the user adding the table. ◦ It must have a single SDO_GEORASTER column. ◦ It must have a valid GeoRaster Data Manipulation Language (DML) trigger created with the sdo_geor_utl.createDMLTrigger stored procedures. ◦ It must have a valid SDO_GEORASTER data table. ◦ It cannot contain any SDO_GEOMETRY or ST_GEOMETRY columns.

Known limits of using SDO_GEORASTER with an ArcSDE geodatabase The following is a list of limits to keep in mind when storing raster data in your ArcSDE geodatabase as SDO_GEORASTER. ◦ Oracle does not support piecewise updates for SDO_GEORASTER. Therefore, it is not possible to mosaic image files to an existing raster dataset that is stored as an SDO_GEORASTER. ◦ Pyramids cannot be constructed during the insertion of data. After inserting image data into an SDO_GEORASTER, a separate update step is required to construct the pyramid. For this reason, you should always uncheck the Build pyramid check box on the dialog box of any of the ArcGIS geoprocessing tools that create raster datasets or raster catalogs. ◦ The image data cannot be currently stored in a compressed format in SDO_GEORASTER if you are using Oracle 10 g Release 1 (R1). Oracle added image compression to the SDO_GEORASTER type in Oracle 10 g Release 2 (R2). If you are using Oracle 10 g R1, you should always set the compression type to NONE on the dialog box of any ArcGIS geoprocessing tools when you use them to create raster datasets or raster catalogs. ◦ Oracle implements SDO_GEORASTER as a band-integrated architecture. Therefore, it is not possible to add and delete individual bands of a raster dataset. ◦ ArcSDE and ArcGIS do not support multiple raster columns in a table. Tables with multiple SDO_GEORASTER columns should be accessed through views that contain only one SDO_GEORASTER column. Use the sdetable create_view operation to create these views of the table. See the ArcSDE Administration Command Reference for details on using the sdetable command.

Section X Migrating Oracle data from one storage type to another

280

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

About migrating Oracle data types Note: This topic was updated for 9.3.1. Beginning with Oracle 11 g, LONG RAW data types are no longer supported. It is possible your current ArcSDE geodatabase in Oracle contains LONG RAW fields. You might have attribute columns, geometry columns, or columns in the raster side tables that use LONG RAW storage. The storage for these columns is controlled by the DBTUNE parameters ATTRIBUTE_BINARY, GEOMETRY_STORAGE, and RASTER_STORAGE respectively. The defaults for these parameters under the DBTUNE DEFAULTS configuration keyword have changed. The following table shows the default setting under the DEFAULTS keyword in the DBTUNE table in ArcSDE 9.3, 9.2, and prior geodatabases. Parameter

Default at ArcGIS 9.3 Default at ArcGIS 9.2

Default prior to ArcGIS 9.2

ATTRIBUTE_BINARY

BLOB

LONG RAW

BLOB

GEOMETRY_STORAGE ST_GEOMETRY

LONG RAW (SDEBINARY) LONG RAW (SDEBINARY)

RASTER_STORAGE

LONG RAW

BLOB

LONG RAW

Data created in new 9.3 geodatabases using the default parameter settings for ArcGIS 9.3 do not use the LONG RAW storage type. However, any existing data created with any or all of these parameters set to LONG RAW or any new data in upgraded geodatabases that have these parameters set to LONG RAW will still contain LONG RAW columns. To change the data types for these columns, you must alter your DBTUNE settings and migrate the data. Beginning with ArcGIS 9.3, you can use the Migrate Storage geoprocessing tool, ArcSDE administration commands, ArcObjects, or the ArcSDE API to migrate existing LONG RAW columns to another data type. Additionally, you can migrate other geometry storage data types to ST_GEOMETRY storage. Possible migration paths include the following: Parameter

Migrate from/to

ATTRIBUTE_BINARY

LONG RAW to BLOB

GEOMETRY_STORAGE LONG RAW (SDEBINARY) to BLOB (SDELOB) LONG RAW to ST_GEOMETRY BLOB to ST_GEOMETRY SDO_GEOMETRY to ST_GEOMETRY RASTER_STORAGE

LONG RAW to BLOB

If the table was registered as versioned, migrating it to a different geometry storage type also updates the shape column in the Adds table. If the feature class has archiving enabled, the archive table's shape column is also updated. The following conditions must be met before you convert your data: ◦ You must make a backup of the data before you migrate it. ◦ If you are converting the spatial column type, the data must be stored in high precision. If your data is currently stored with low (basic) precision, you must first migrate it to high precision before you migrate the storage type. This can be done with either the Upgrade Spatial Reference geoprocessing tool or the sdelayer command with the alter operation. See Migrating to high precision for information on migrating a dataset's precision. ◦ If you are converting the spatial column, the table must contain an object ID column. Registering the table with the geodatabase will automatically add this column, or you can use the sdetable command with the alter_reg operation to add it. ◦ You must be the owner of the table that contains the column being migrated. 281

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

◦ The configuration keyword you specify when migrating the data type has to contain the correct value for the GEOMETRY_STORAGE, ATTRIBUTE_BINARY, or RASTER_STORAGE parameter. For example, if you want to migrate a LONG RAW geometry column to ST_GEOMETRY, but you specify a keyword that has the GEOMETRY_STORAGE parameter set to SDO_GEOMETRY, the migration will fail. ◦ When data is migrated from one data type to another, a new segment is created in the database to which the data is copied. Once the migration is complete, the metadata gets repointed to the new segment and the old one is deleted. That means during the migration, there are two copies of the data; therefore, make sure you have enough room in the database for two copies of the data. This is mostly an issue when migrating raster data from LONG RAW to BLOB. Since both attribute and raster storage will be migrated to a BLOB data type and BLOB is an option for the conversion of geometries, it is recommended that you read the topic BLOB data storage in Oracle geodatabases before proceeding with the migration instructions. The following sections describe how to migrate the attribute, geometry, or raster storage of a table in an ArcSDE geodatabase in Oracle.

How to migrate data types Using the Migrate Storage geoprocessing tool 1. Open the Migrate Storage tool. This can be found in the Data Management Tools toolbox in the Database set of tools. 2. Browse to the location of the dataset you want to migrate. You can add multiple datasets. 3. Choose a configuration keyword from the drop-down list. The configuration keyword must contain parameters set to one of the supported storage options. For example, if you are migrating the geometry of a LONG RAW feature class, the keyword you choose must have the GEOMETRY_STORAGE parameter set to SDELOB or ST_GEOMETRY. If you choose a keyword that contains a parameter set to an unsupported migration path, such as a GEOMETRY_STORAGE parameter set to SDO_GEOMETRY, the migration will fail. 4. Click OK. 5. Disconnect from the geodatabase and reconnect. This will refresh the shape column names, which may have changed when the storage type changed. Tip • Remember, you must be the owner of the data to be able to migrate its geometry, raster, or attribute storage. • Be sure you have a backup copy of any data you intend to migrate. That way, if migration fails for any reason, you still have your original data. • For information on using geoprocessing scripts for the migration, see Migrate Storage (Data Management) .

Using ArcSDE administration commands Migrating geometry columns You can change the geometry storage used in a feature class in a geodatabase in Oracle by using the migrate operation with the sdelayer command. The migrate operation changes the geometry storage of the feature class to the geometry storage type in the DBTUNE configuration keyword you specify with the –k option. 282

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

The syntax for the sdelayer command with the migrate operation is as follows: sdelayer –o migrate –l –k [–i ] [–s ] –u [–p ] [–N]

Where –l specifies the name of the business table of the feature class and the shape column. –k designates the DBTUNE configuration keyword for the geometry storage type to which you are migrating the feature class. The keyword must contain a GEOMETRY_STORAGE parameter set to either SDELOB or ST_GEOMETRY. –i indicates the ArcSDE service or direct connection information. –s defines the name of the server on which the database resides. –u specifies the database user name of the feature class owner. –p specifies the password of the user. –N suppresses the prompt to confirm the operation. You will receive an error message when you execute this command if any of the following is true: ◦ The user specified with –u is not the feature class owner. ◦ The existing storage type of the feature class and the specified DBTUNE keyword are identical. (In other words, the feature class is already using the geometry storage type you specified with the keyword.) ◦ You try to use the migrate operation in an ArcSDE 9.2 or earlier geodatabase. Migrating attribute and other LONG RAW columns You can migrate LONG RAW attribute columns to BLOB using the sdetable command with the migrate operation. This operation changes the storage of the attribute column from LONG RAW to BLOB by specifying a DBTUNE configuration keyword that has the ATTRIBUTE_BINARY parameter set to BLOB. You can also use sdetable to migrate all the LONG RAW columns in a table at once. For example, if you have a feature class that is using LONG RAW raster storage and contains a binary attribute column of LONG RAW, when you use sdetable, both columns are converted based on the parameters set in the configuration keyword you specify with the –k option. As long as the specified configuration keyword contains both an ATTRIBUTE_BINARY parameter set to BLOB and a RASTER_STORAGE parameter set to BLOB, both column data types will be converted. The syntax for sdetable –o migrate is as follows: sdetable –o migrate –t –k [–i ] [–s ] –u [–p ] [–N] [–q]

Where –t specifies the name of the table containing the column (or columns) to be migrated. –k designates the DBTUNE configuration keyword for the storage type to which you are migrating. –i indicates the ArcSDE service or direct connection information. –s defines the name of the server on which the database resides. –u specifies the database user name of the table owner. –p specifies the password of the user. 283

Administering ArcSDE® for Oracle®

Data storage in the geodatabase

–N suppresses the prompt to confirm the operation. As with the other commands, the migration will fail if you are not the owner of the table, you try to migrate a table in a pre-9.3 geodatabase, or there are no valid parameters included with the specified configuration keyword. Tip • Be sure you have a backup of copy of any data you intend to migrate. That way, if migration fails for any reason, you still have your original data.

284

Administering ArcSDE® for Oracle®

Connecting to a geodatabase from ArcGIS Desktop

Appendix C Connecting to a geodatabase from ArcGIS Desktop Section I Creating spatial database connections About creating spatial database connections Note: This topic was updated for 9.3.1. With ArcCatalog, you can explore and manage geographic data stored in a relational database management system (RDBMS) through ArcSDE. Similarly, SDE for Coverages lets you access coverage, ArcInfo Librarian, and ArcStorm databases the same way you access data from an RDBMS. To access these databases, you must add a spatial database connection to the Catalog tree. When you create a spatial database connection, a file is created on the client computer* that contains the connection information you provide through the Spatial Database Connection dialog box. Some of the information you provide through the spatial database connection dialog box is mandatory; other information is optional, depending on the requirements at your site. For instance, you can choose to save or not save any version and database user name and password information as part of the connection file.

Spatial Database Connection dialog box

285

Administering ArcSDE® for Oracle®

Connecting to a geodatabase from ArcGIS Desktop

*If you use the data from this connection as the source for a service, such as a geoprocessing or geocoding service, you may need to place the connection file in a shared location on your network. See the topics Preparing resources to publish as services (in the ArcGIS Server help) and Accessing ArcSDE data in tools for more information about sharing a connection file. Database information You specify information pertinent to the database connection in the first three fields on the Spatial Database Connection Properties dialog box. ◦ In the Server field, type the name of the server on which the database you're connecting to resides. If you are making a direct connection, this information is not required but it is recommended you provide it anyway. If you do not provide the server name, the server name will not appear on the Source tab of the table of contents in ArcMap. ◦ In the Service field, you must type either the port number for the ArcSDE service, the name of the ArcSDE service, or the direct connection string specific to the type of DBMS to which you are connecting. (These connection strings are described in the sections on adding a direct connection in this topic.) It is usually simpler to specify the port number when connecting through an ArcSDE service; if you use the service name instead, there must be an entry in the services file on the client machine that contains the service name and its corresponding port number. If you have many clients connecting through an ArcSDE service, keeping these files up–to–date on every client machine would be more time consuming than simply specifying the port number for the service in the Spatial Database Connection Properties dialog box. ◦ Type the name of the database to which you are connecting. If you are connecting to an Oracle database, leave this field blank. Login information There are two login options for creating a connection to a spatial database: database authentication and operating system authentication. ◦ Database authentication If you check Database authentication in the Spatial Database Connection dialog box, you aren't required to type your user name and password to create a connection; however, if you don't, you will be prompted to enter them when a connection is established. Uncheck Save name and password if you prefer not to save your login information as part of the connection; doing this can help maintain the security of the database. However, if you do this, you will have to provide a user name and password every time you connect. ◦ Operating system authentication If you check Operating system authentication, you don't need to type a user name and password in the connection dialog box—the connection will be made with the user name and password used to log into the operating system. If the login used for the operating system is not a valid geodatabase login, the connection will fail. Also note that if you are creating a connection to a geodatabase stored in Oracle, DB2, or Informix using operating system authentication, you have to use a direct connection to the database. For information on direct connections, see Properties of a direct connection to an ArcSDE geodatabase . Connection details In the connection details section of the Spatial Database Connection Properties dialog box, specify the geodatabase version to which you want to connect. The default connection is to a version named sde.DEFAULT.

286

Administering ArcSDE® for Oracle®

Connecting to a geodatabase from ArcGIS Desktop

If you want to connect to a different version, click the Change button. This opens the Connection Details dialog box. From here, you choose either a transactional version or a historical version to which to connect. NOTE: To read what versions are available, ArcCatalog must be able to make a connection to the geodatabase. Therefore, if the server or login information you provided is incorrect, you cannot change versions. If you leave the Save the transactional version name with the connection file box checked, the user will always connect to the specified transactional version using this connection file. If unchecked, the user will be prompted to choose a version to connect to every time he or she reconnects using this connection file. Note that if you have chosen a historical version to connect to, this check box will be labeled Save the historical details with the connection file. If left checked, the user will always connect to the specified historical marker or date and time when using this connection file. Situations for which you would want to save the version are if you are using SQL Server and created your system tables in the dbo schema, you want to create a specific connection file for a user schema geodatabase in Oracle, or you need to connect to the same transactional or historical version the majority of the time. Learn more about versioning . Learn more about historical versions . Learn more about using user-schema geodatabases in Oracle . If you often need to connect to different transactional or historical versions of the geodatabase, you should uncheck the option to save the version with the connection file. Doing so means you will be prompted to enter the missing connection properties every time the connection file is used. Making sure it works After you have specified all the information needed for the spatial database connection, it is recommended that you click Test Connection at the bottom of the Spatial Database Connection dialog box. If the connection test fails, contact the database administrator to ensure the database is operational and all the information you provided in the dialog box is correct. You can still add this connection to ArcCatalog by clicking OK, but you will be unable to retrieve data until the problem is resolved. The following sections provide instructions on how to create a spatial database connection using an ArcSDE service, using direct connect, and connecting to a specific geodatabase version.

How to create spatial database connections Connecting to a spatial database with an ArcSDE service These instructions allow you to connect to an ArcSDE enterprise geodatabase using an ArcSDE service. Instructions for connecting directly to an ArcSDE geodatabase are covered in the "Adding a direct connection to..." sections. 1. Click the Database Connections folder in the Catalog tree. 2. Double-click Add Spatial Database Connection to open the Spatial Database Connection Properties dialog box. 3. Type the name or Internet Protocol (IP) address of the server to which you want to connect in the Server text box. 4. Type the name or port number of the service to which you want to connect in the Service text box. If you want to connect to a geodatabase in a user's schema in an Oracle database, type the port number and schema in the Service text box separated by a colon; for example, 5153:daisy.

287

Administering ArcSDE® for Oracle®

Connecting to a geodatabase from ArcGIS Desktop

5. If the data is stored in a SQL Server, IBM DB2, Informix, or PostgreSQL RDBMS, type the name of the database to which you want to connect in the Database text box. If the data is stored in Oracle, skip this step. 6. If using database authentication, type your user name and password for the database. If you don't want to save the user name and password with this connection file, uncheck Save username and password. 7. If using operating system authentication, click the Operating system authentication button. The database authentication information becomes unavailable. 8. If you are connecting to a geodatabase in a user's schema in an Oracle database or to a dbo-schema geodatabase in SQL Server, you must change the version to which you are connecting by clicking Change in the Connection details section and choosing the geodatabase from the list of transactional versions. For details on connecting to a specific version of a database, see Connecting to a specific version of the database . 9. If you do not want to save the version connection information you provided in the last step, uncheck Save the version with the connection file. 10. Click Test Connection. If the test is successful, the button becomes unavailable. If the test fails, you are unable to retrieve data until you've provided the correct information or the database problem has been resolved. 11. Click OK. 12. Type a new name for the database connection. 13. Press Enter. Tip • When you click OK in the Spatial Database Connection Properties dialog box, a connection file is created on disk and is added to the Catalog. However, ArcCatalog does not automatically establish a connection. Double-click the connection in ArcCatalog to access the database's contents. • If you do not want to save the username/password and version properties with the connection file, uncheck the appropriate check boxes on the Spatial Database Connection dialog box. • If there is an existing connection to an ArcSDE geodatabase in the ArcMap or ArcCatalog instance, any subsequent connections matching the original Server, Instance, and Authentication Mode properties will use the original connections properties. This means that if you connect to the same ArcSDE geodatabase with a connection file that does not save user name and password or version and there is already a connection to the same ArcSDE geodatabase server and instance that does save the user name and password or version, you will not be prompted to fill in the missing properties; the properties from the original connection with the saved login or version properties will be used. • If you want to connect to an Oracle, Informix, or DB2 RDBMS with operating system authentication, you must use direct connect. See the appropriate direct connection section in this topic for information on how to make a direct connection to these databases. • Data stored in a geodatabase in SQL Server Express can only be accessed via a direct connection. The section Adding a direct connection to a geodatabase in SQL Server below also applies to setting up a spatial database connection to a geodatabase in SQL Server Express. • Nonadministrative users of ArcSDE Personal or Workgroup geodatabases stored in SQL Server Express can connect to these geodatabases using a spatial database connection as

288

Administering ArcSDE® for Oracle®

Connecting to a geodatabase from ArcGIS Desktop

described in this topic. Administrators of geodatabases stored in SQL Server Express should access these geodatabases by making a connection to a database server, then connecting to the geodatabase. Connecting through the database server node of ArcCatalog is the only way you can administer both the database server and the geodatabases stored there. Learn more about database servers . Learn how to add a database server .

Adding a direct connection to a geodatabase in Oracle The first set of steps details how to add a direct connection to a geodatabase in Oracle if you are using database authentication. The second set of steps instructs you how to add a direct connection to a geodatabase in Oracle if you are using operating system authentication. The last set of steps instructs you on how to create a connection to a geodatabase in a user's schema.

Making a direct connection using database authentication 1. Double-click the Database Connections folder in the Catalog tree. 2. Double-click Add Spatial Database Connection. 3. In the Server text box, type the name of the server on which the Oracle database resides. 4. If you are connecting to Oracle using an Oracle9 i client, in the Service text box, type: "sde:oracle9i". If you are connecting to Oracle using an Oracle 10 g client, type: "sde:oracle10g". If you are connecting to Oracle using an Oracle 11 g client, type: "sde:oracle11g". 5. Type your user name in the User Name text box. 6. Type your password, followed by @, in the Password text box. 7. Uncheck Save username and password if you don't want your login information saved with the connection. 8. Click OK. 9. Type a new name for the spatial database connection. 10. Press Enter.

Making a direct connection using operating system authentication 1. Double-click the Database Connections folder in the Catalog tree. 2. Double-click Add Spatial Database Connection. 3. In the Server text box, type the name of the server on which the Oracle database resides. 4. If you're connecting to Oracle using an Oracle9 i client, type "sde:oracle9i:/ ;LOCAL=" in the Service text box. If you're connecting to Oracle using an Oracle 10 g client, type "sde:oracle10g:/ ;LOCAL=". If you are connecting to Oracle using an Oracle 11 g client, type "sde:oracle11g:/ ;LOCAL=". The SQL Net alias was set when your computer was configured to use a direct connection. Contact your system administrator if you do not know what value to substitute here.

289

Administering ArcSDE® for Oracle®

Connecting to a geodatabase from ArcGIS Desktop

5. Click the Operating system authentication button. The database authentication information becomes unavailable. 6. Click OK. 7. Type a new name for the spatial database connection. 8. Press Enter.

Making a direct connection to a user-schema geodatabase 1. Double-click the Database Connections folder in the Catalog tree. 2. Double-click Add Spatial Database Connection. 3. In the Server text box, type the name of the server on which the Oracle database resides. 4. If you're connecting to Oracle using an Oracle9 i client, type "sde:oracle9i:/:" in the Service text box. If you're connecting to Oracle using an Oracle 10 g client, type "sde:oracle10g:/:". If you are connecting to Oracle using an Oracle 11 g client, type "sde:oracle11g:/:". 5. Type your user name in the User Name text box. 6. Type your password, followed by @, in the Password text box. 7. Uncheck Save username and password if you don't want your login information saved with the connection. 8. Spatial database connections are made to the sde.DEFAULT version by default. You must change to a user-schema version. Click Change in the Connection details section. 9. When the Connection Details dialog box opens, choose the version of the user-schema geodatabase to which you want to connect. This could be .DEFAULT or any other version of that geodatabase. For example, if the schema the geodatabase is in is tubor, and you want to connect to the qa77 version, choose tubor.qa77 from the transactional version list. 10. Click OK on the Connection Details dialog box to close it. 11. Click OK. 12. Type a new name for the spatial database connection. 13. Press Enter. Tip • You must create an Oracle network service name on your client machine before you can create a direct connection to an Oracle database. • You can create a direct connection to a geodatabase in Oracle using database authentication or operating system authentication. However, if you use operating system authentication, you must use a direct connection and not an ArcSDE service. • Learn more about direct connections . • If you always connect to the same Oracle database using direct connect and operating system authentication, you can set the LOCAL variable in the tnsnames.ora file. Consult your Oracle documentation for details on setting this variable in the tnsnames.ora file. • If you want to make a direct connection from an ArcGIS 9.3 client to a 9.2, 9.1, or 9.0 release geodatabase, you can specify the geodatabase release number in the connection string to

290

Administering ArcSDE® for Oracle®

Connecting to a geodatabase from ArcGIS Desktop

decrease connection times. For example, to connect to an ArcSDE 9.0 geodatabase in Oracle9 i , type "sde90:oracle9i" in the Service text box. You must have the proper direct connect drivers installed with ArcGIS Desktop to make this sort of connection.

Connecting to a specific version of the database 1. Click the Database Connections folder in the Catalog tree. 2. Follow the instructions in one of the previous sections for connecting to a geodatabase. 3. Click Change in the Connection details section of the Spatial Database Connection Properties dialog box. 4. On the Connection Details dialog box, click the version to which you want to save a connection. This can be a transactional version or a historical version. Note that the default geodatabase versions for geodatabases stored in user schemas in Oracle (.DEFAULT) and the default version for the geodatabase versions for dbo schema geodatabases in SQL Server (dbo.DEFAULT) are also transactional versions. For transactional versions, click This connection refers to a transactional version, and choose a version from the list. For a historical version, click This connection refers to a historical version, and click either Connect using a historical marker or Connect using a specific date and time. For each of these options, you need to specify the historical marker or date and time you want to use. 5. Click OK to close the Connection Details dialog box. 6. If you don't want to connect to this version of the database each time you start ArcCatalog, uncheck Save the version name with the connection file. 7. Click OK. 8. Type a new name for the database connection. 9. Press Enter. Tip • If you uncheck Save the version name with the connection file, the next time you connect to the geodatabase through ArcCatalog or ArcMap using this connection file, you will be prompted to choose the desired version. • Learn about versioning .

291

Administering ArcSDE® for Oracle®

Multiversioned views

Appendix D Multiversioned views Section I Using multiversioned views Note: This topic was updated for 9.3.1. This topic contains the following information: ◦ What are multiversioned views? ◦ Creating and deleting multiversioned views ◦ Using multiversioned views in DB2 ◦ Using multiversioned views in Informix ◦ Using multiversioned views in Oracle ◦ Using multiversioned views in PostgreSQL ◦ Using multiversioned views in SQL Server

What are multiversioned views? Multiversioned views incorporate database views, stored procedures, triggers, and functions to access a specified version of data in a geodatabase table using Structured Query Language (SQL). Multiversioned views access a specified version of data in the business table of a dataset. The dataset must be registered as versioned . Each versioned dataset has associated delta tables that record edits made to the dataset. When a versioned dataset is accessed by a multiversioned view, all the records in the business table are selected and merged with records from the delta tables to construct a view that includes all the changes made to the business table in the context of the specified version. Multiversioned views appear to have the same columns and rows as the business table they represent. Unlike database or spatial views, multiversioned views are used not to change the table's schema or limit access to it; rather, they are used to facilitate access to a certain version of the table. Applications that do not support ArcSDE geodatabase versioning can only directly query the business table of a versioned dataset and have no knowledge of the delta tables. Using multiversioned views with these applications provides them with access to the data in the delta tables. Multiversioned views are designed primarily to access attribute columns of a table rather than spatial columns, though it is possible to access the spatial column. Accessing the spatial column with a multiversioned view is more straightforward if you are store your geometry attributes in a spatial type, such as ST_Geometry or SDO_Geometry . It is more involved if you are using a binary geometry storage type, such as the ArcSDE compressed binary or the Open Geospatial Consortium, Inc. (OGC), well-known binary types. It is possible to edit a versioned table using multiversioned views. This is an advanced use of views, is database management system (DBMS) specific, and has the potential to corrupt your geodatabase if not done properly. The steps you take to edit with multiversioned views are as follows and should be performed in the order shown: 1. Create a multiversioned view. 2. Create a version in which to do your edits. 3. Set the multiversioned view to use the new version.

292

Administering ArcSDE® for Oracle®

Multiversioned views

4. Start an edit session. 5. Perform your edits using SQL on the multiversioned view. 6. Commit your edits to the database or roll them back. 7. Stop the edit session. 8. Reconcile and post your edits through ArcGIS. 9. If necessary, you can delete the version you created for your edits. NOTE: Multiversioned views should not be used to access or modify complex features—features that participate in geometric networks, topologies, terrains, cadastral fabrics, network datasets, or relationships or have specific geodatabase behavior. You should use ArcGIS to view and modify these types of features. For instructions on how to set up this type of editing, see the "Editing with multiversioned views" sections for each DBMS.

Creating and deleting multiversioned views Use the administration command sdetable –o create_mv_view to create a multiversioned view on a single business table that has already been registered as versioned through ArcGIS. This example creates a multiversioned view of the parcels feature class. sdetable –o create_mv_view –T mv_parcels –t parcels -i 5100 –D landbase –u bjorn –p a.secret

Notice that you do not choose columns or define a WHERE clause when using the sdetable –o create_mv_view command as you do when you create standard or spatial views using sdetable –o create_view or SQL. Also, be aware that only one multiversioned view can exist per feature class, and you cannot create a multiversioned view on a view. To remove a multiversioned view, use the command sdetable –o delete_mv_view. For example, to delete the multiversioned view created in the last example, type the following: sdetable –o delete_mv_view –t parcels -i 5100 –D landbase –u bjorn –p a.secret

For complete syntax, explanation, and examples of the sdetable –o create_mv_view and sdetable –o delete_mv_view commands, see the Administration Command Reference provided with the ArcSDE component of ArcGIS Server Enterprise.

Using multiversioned views in Oracle Multiversioned views can be used to read the data in a versioned dataset and also to edit the dataset. Reading data with multiversioned views Multiversioned views automatically access the DEFAULT version. Before issuing any queries against the view, you must ensure that they will take place against the correct version. To access a specific version other than the default, execute the ArcSDE set_current_version stored procedure. This procedure validates the supplied version name and sets the corresponding database state internally. It can be executed directly from a SQL client. The syntax for the stored procedure to set the current version is as follows: EXEC sde.version_util.set_current_version('')

For example:

293

Administering ArcSDE® for Oracle®

Multiversioned views

EXEC sde.version_util.set_current_version('edits')

For Oracle user-schema geodatabases EXEC .version_user.set_current_version('')

For example: EXEC usertwo.version_user.set_current_version('edits')

This procedure may be called again to change to other versions as required, and it is called each time the workspace is refreshed to return the current state of the versioned table to the calling application. NOTE: Multiversioned views should not be used to access or modify complex features—features that participate in geometric networks, topologies, or relationships or have specific geodatabase behavior. You should use ArcGIS to view and modify these types of features. Editing with multiversioned views When you edit versioned tables through multiversioned views, changes are made to the delta tables, and row ID (ObjectID) values for new records are automatically generated. However, unlike editing versioned data in an ArcGIS edit session, no internal version reconciliation is done with these edits. Therefore, it is strongly recommended that multiversioned views not be used to edit the DEFAULT version or any version that may be subject to simultaneous editing or reconciliation by other users because conflicts will not be detected. Instead, create your own version specifically for editing with multiversioned views. NOTE: If you need to perform version management operations, such as reconciling , resolving conflicts , and posting , you need to use the ArcGIS software. Improper version management can lead to geodatabase corruption when working with views. Also note that you should never use DBMS tools to update any row ID (ObjectID) field maintained by ArcSDE in the database. These row ID fields are allocated and managed by the geodatabase and should not be altered. There are several stored procedures installed with the ArcSDE component that help you work with multiversioned views. The stored procedure used to set which version the multiversioned view will work with was discussed in the previous section. There are also stored procedures to create a version in which you can do your editing, start and stop an edit session, and delete your edit version. The following set of steps takes you through creating a multiversioned view, creating a version in which to perform edits, setting the version to edit, starting an edit session, performing some edits through the multiversioned view, stopping the edit session, committing your edits to the database, and deleting the version created for the edits. In the examples, the multiversioned view created to perform the edits on the business table is permits_mv; the version created and used for editing is mvedits; and the coordinate system is a geographic coordinate system, datum NAD27, using the Clarke 1866 spheroid and decimal degree units. Remember that the dataset you edit through a multiversioned view must already have been registered as versioned through ArcGIS. For this example, the permits feature class would need to have already been registered as versioned in ArcCatalog to be able to edit it through a multiversioned view. These edits are performed in the master SDE geodatabase (as opposed to being performed in a geodatabase in a user's schema).

294

Administering ArcSDE® for Oracle®

Multiversioned views

1. At a command prompt, execute the sdetable function to create a multiversioned view. sdetable –o create_mv_view –T permits_mv –t permits –i 4400 –u sarja –p not4u

2. Declare a variable to store the version you will create in the next step. VARIABLE ; EXEC : := '';

For example: VARIABLE mv_version NVARCHAR2(10); EXEC :mv_version := 'mvedits';

3. Create a new version in which to perform your edits. EXEC sde.version_user_ddl.create_version ('', :, , , '')

For example:

EXEC sde.version_user_ddl.create_version ('sde.DEFAULT', :mv_version, sde.version_util.C_take_name_as_given, sde.version_util.C_version_private, 'mul

4. Set the version for the edit session to the child version you just created. EXEC sde.version_util.set_current_version('')

For example: EXEC sde.version_util.set_current_version('mvedits');

5. Start an edit session by executing the version_user_ddl.edit_version stored procedure and specifying "1". The 1 indicates an edit session should be started. EXEC sde.version_user_ddl.edit_version('',1)

For example: EXEC sde.version_user_ddl.edit_version('mvedits',1);

6. Perform the necessary edits to the multiversioned view using SQL. In this example, an existing record is updated and a new record is inserted. UPDATE businesses_mvw SET owner_name = 'Cpt. Industry' WHERE business_name = 'Body Electric';

295

Administering ArcSDE® for Oracle®

Multiversioned views

INSERT INTO businesses_mvw (business_name, business_type, owner_name, location) VALUES ('Bionix', 'engineering', 'Anjo Badsu', sde.ST_PointFromText('point (40 40))', 12);

Notice that an objectID value was not specified in the INSERT statement. The multiversioned view automatically gets the next available value and inserts it for the row.* 7. Execute a COMMIT or ROLLBACK statement. In this example, the edits are committed to the database. COMMIT;

8. Stop the edit session by executing the version_user_ddl.edit_version stored procedure, but this time, specify "2". The 2 indicates the edit session should be closed. EXEC sde.version_user_ddl.edit_version('',2)

For example: EXEC sde.version_user_ddl.edit_version('mvedits',2);

After the changes have been reconciled and posted through ArcGIS Desktop, or if you decide you don't want the changes, you can delete the version you created in step 1 by executing the delete_version function. EXEC sde.version_user_ddl.delete_version('')

To delete the version created in step 1, execute the following statement: EXEC sde.version_user_ddl.delete_version('mv_version');

*The objectID for the table you are editing must be a system-maintained objectID. If the table is registered with the geodatabase, this is always the case. However, it is possible (but not recommended) to register the table with ArcSDE using a user-maintained objectID and then version it using ArcSDE commands. In that case, you must specify a value for the objectID when editing through multiversioned views.

296

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Appendix E ArcSDE geodatabase system tables Section I System tables of a geodatabase stored in Oracle Note: This topic was updated for 9.3.1. The system tables for a geodatabase enforce geodatabase behavior, store information about the geodatabase, and keep track of the data stored in the geodatabase. To see a diagram of the geodatabase system tables, click here . (You need Adobe Reader to open this file.) The following is an alphabetical list of the geodatabase system tables as they appear in an Oracle DBMS. You can use the links below to jump to a section of the list. A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

NOTE: The system tables should not be altered using anything other than the ArcGIS software. COLUMN_REGISTRY The COLUMN_REGISTRY table manages all registered columns. NOTE: If you alter column definitions using a SQL interface, the records in the COLUMN_REGISTRY table are not updated. This may cause any subsequent exports of the data to fail. Field name

Field type

Description

TABLE_NAME

NVARCHAR2(160) Name of the table that contains the registered column

OWNER

NVARCHAR2(32) Owner of the table in which the column resides (the user who created the table)

COLUMN_NAME

NVARCHAR2(32) Name of the registered column

NOT NULL NOT NULL NOT NULL

297

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

SDE_TYPE

NUMBER(38)

Code for the column's data type; possible values and their definitions include 1 = SE_INT16_TYPE—2-byte Integer 2 = SE_INT32_TYPE —4-byte Integer 3 = SE_FLOAT32_TYPE—4-byte Float 4 = SE_FLOAT64_TYPE—8-byte Float 5 = SE_STRING_TYPE—Null Term; Character Array 6 = SE_BLOB_TYPE—Variable Length Data 7 = SE_DATE_TYPE—Struct tm Date 8 = SE_SHAPE_TYPE—Shape geometry (SE_SHAPE) 9 = SE_RASTER_TYPE—Raster 10 = SE_XML_TYPE—XML Document 11 = SE_INT64_TYPE—8-byte Integer 12 = SE_UUID_TYPE—A Universal Unique ID 13 = SE_CLOB_TYPE—Character variable length data 14 = SE_NSTRING_TYPE—UNICODE Null Term; Character Array 15 = SE_NCLOB_TYPE—UNICODE Character Large Object 20 = SE_POINT_TYPE—Point UDT 21 = SE_CURVE_TYPE—LineString UDT 22 = SE_LINESTRING_TYPE—LineString UDT 23 = SE_SURFACE_TYPE—Polygon UDT 24 = SE_POLYGON_TYPE— Polygon UDT 25 = SE_GEOMETRYCOLLECTION_TYPE 25 /* MultiPoint UDT */ 26 = SE_MULTISURFACE_TYPE—LineString UDT 27 = SE_MULTICURVE_TYPE—LineString UDT 28 = SE_MULTIPOINT_TYPE—MultiPoint UDT 29 = SE_MULTILINESTRING_TYPE—MultiLineString UDT 30 = SE_MULTIPOLYGON_TYPE—MultiPolygon UDT 31 = SE_GEOMETRY_TYPE—Geometry UDT NOT NULL

COLUMN_SIZE

NUMBER(38)

DECIMAL_DIGITS NUMBER(38) DESCRIPTION

The registered column value's length Number of integers to the right of the decimal in the column value

NVARCHAR2(65) A description of the type of column

298

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

OBJECT_FLAGS

NUMBER(38)

Stores the column properties; properties include ◦ Column has a row ID ◦ SDE controls the row ID column ◦ Column allows NULLS ◦ Column stores Oracle LONG RAW data ◦ Column stores BLOB data ◦ Column stores CLOB data ◦ Column stores ST_GEOMETRY geometry data ◦ Column stores binary geometry data ◦ Column stores UDT geometry data ◦ Column stores Oracle LOB geometry data ◦ Column stores binary raster data ◦ Column stores UDT raster data ◦ Column stores XML data ◦ Column stores dates ◦ Column stores time ◦ Column stores a time stamp ◦ Column stores a unicode string NOT NULL

OBJECT_ID

NUMBER(38)

Set to the rastercolumn_id of the sde.raster_columns table if the column is a raster column or the layer_id of the sde.layers table if this column is a geometry column

COMPRESS_LOG The COMPRESS_LOG table tracks all compress operations performed on the geodatabase. NOTE: This table is not present if the geodatabase has never been compressed. Field name

Field type

Description

SDE_ID

NUMBER(38)

Process identification number of the compress operation; references sde_id column in PROCESS_INFORMATION table NOT NULL

SERVER_ID

NUMBER(38)

System process_id of the ArcSDE server process that performed or is performing the compress operation

DIRECT_CONNECT

VARCHAR2(1) Y (yes) or N (no) if the client is making a direct connection to the geodatabase

NOT NULL NOT NULL COMPRESS_START

DATE

The date and time the compress operation was begun NOT NULL

START_STATE_COUNT NUMBER(38)

The number of states present when compress began NOT NULL

COMPRESS_END

DATE

The date and time the compress operation completed

END_STATE_COUNT

NUMBER(38)

The number of remaining states after the compress operation

COMPRESS_STATUS

VARCHAR2(20) Indicates whether or not the compress operation was successfully completed

DBTUNE The DBTUNE table stores the configuration keywords forArcSDE data objects, such as feature classes.

299

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

KEYWORD

NVARCHAR2(32) The configuration keyword NOT NULL

PARAMETER

NVARCHAR2(32) The configuration parameter NOT NULL

CONFIG_STRING NCLOB

The value of the configuration parameter

GCDRULES The GCDRULES table stores the geocoding rules that are used by address locators to match addresses. Each record in the GCDRULES table corresponds to a geocoding rule file. Field name Field type

Description

ID

NUMBER(9)

The table's primary key

STYLE

VARCHAR(32) Name of the geocoding rule set

TYPE

VARCHAR(3) The type of geocoding rule file; represented by a three-letter code

NOT NULL

cls = Classification table dct = Match key dictionary pat = Pattern stn = Standardization processes mat = Matching specification tbl = Additional tables (optional) DATA

BLOB

The contents of the geocoding rule file

GDB_ANNOSYMBOLS The GDB_ANNOSYMBOLS table contains feature class annotation . Field name Field type ID

Description

NUMBER(38) Uniquely identifies an annotation symbol Primary key NOT NULL

SYMBOL

BLOB

Stores the annotation symbology

GDB_ATTRRULES The GDB_ATTRRULES table contains the attribute rules in the geodatabase. Field name

Field type

Description

RULEID

NUMBER(38)

Identification number of the attribute rule; corresponds to the RuleID column in the GDB_VALIDRULES table

SUBTYPE

NUMBER(38)

FIELDNAME

NVARCHAR2(32) Field with which the rule is associated

Primary key Subtype code associated with the rule

DOMAINNAME NVARCHAR2(160) Name assigned to the attribute domain in the geodatabase; references DomainName field in the GDB_DOMAINS table

GDB_CODEDDOMAINS The GDB_CODEDDOMAINS table contains values for each coded value domain.

300

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

DOMAINID

NUMBER(38) Unique identifier of the domain; corresponds to the ID field in the GDB_DOMAINS table Primary key NOT NULL

CODEDVALUES BLOB

Contains the set of coded values and their descriptions NOT NULL

GDB_DEFAULTVALUES The GDB_DEFAULTVALUES table contains the default values for fields at the subtype or object class level. Field name

Field type

Description

CLASSID

NUMBER(38)

The object class ID; foreign key to the ID field of the GDB_OBJECTCLASSES table NOT NULL

FIELDNAME

NVARCHAR2(32) The name of the field to which the default value applies NOT NULL

SUBTYPE

NUMBER(38)

Subtype code for which the default value is specified for a particular field NOT NULL

DEFAULTSTRING

NVARCHAR2(160) The text that is the default value for a field that is a string type

DEFAULTNUMBER NUMBER(38,8)

The numeric value that is the default for a field that is an integer type

GDB_DOMAINS The GDB_DOMAINS table contains the attribute constraints associated with attribute rules of the GDB_ATTRRULES table. Field name

Field type

Description

ID

NUMBER(38)

Unique identifier of the domain. Primary key. NOT NULL.

OWNER

NVARCHAR2(32) User who created the attribute domain. NOT NULL.

DOMAINNAME NVARCHAR2(160) Name assigned to the attribute domain in the geodatabase. NOT NULL. DESCRIPTION

NVARCHAR(255) Optional text describing the attribute domain.

DOMAINTYPE NUMBER(38)

Code indicating whether this is a range (1) or coded value (2) domain. NOT NULL.

FIELDTTYPE

NUMBER(38)

Code indicating what type of field the domain applies to: 0 = Short integer 1 = Long integer 2 = Float 3 = Double 4 = Text 5 = Date NOT NULL.

301

Administering ArcSDE® for Oracle®

Field name

Field type

ArcSDE geodatabase system tables

Description

MERGEPOLICY NUMBER(38)

Code indicating the policy to use to assign to the resultant feature when two features are merged: 1 = sum values—The attribute of the feature that results from a merge will be the sum of the values of the two original (premerge) features. 2 = geometry weighted—The attribute of the feature that results from a merge is the weighted average of the values of the attributes of the original (premerge) features. The average is based on the original features' geometry. 3 = default value—The attribute of the feature created as a result of the merge will be the same as the default value of the feature class or subtype. (Note: This is the only merge policy value available for nonnumeric fields and coded value domains.) NOT NULL.

SPLITPOLICY

NUMBER(38)

Code indicating the policy to be used for assigning attributes to the features that result from splitting one feature: 1 = Geometry ratio—The attributes of the features resulting from the split are a ratio of the original feature's (presplit) value. The ratio is based on the ratio in which the geometry is divided by the split. 2 = Duplicate—The attribute of the features resulting from the split are the same as the original object's (presplit) attribute value. 3 = Default value—The attributes of features resulting from the split take on the default value for the attribute as defined in the feature class or subtype. NOT NULL.

GDB_EDGECONNRULES The GDB_EDGECONNRULES table contains one record per edge connectivity rule in a geometric network. Field name

Field type

RULEID

NUMBER(38) The unique ID for a rule in the geodatabase and foreign key to the ID field in the GDB_ValidRules table

Description

NOT NULL FROMCLASSID NUMBER(38) The Object Class ID of the from feature class and the foreign key to the ID in the GDB_GeomNetworks table NOT NULL FROMSUBTYE NUMBER(38) The subtype of the from edge feature class NOT NULL TOCLASSID

NUMBER(38) The Object Class ID of the to feature class and the foreign key to the ID in the GDB_GeomNetworks table NOT NULL

TOSUBTYPE

NUMBER(38) The subtype of the to edge feature class

JUNCTIONS

BLOB

NOT NULL Contains information related to the junction feature class NOT NULL

GDB_EXTENSIONDATASETS The GDB_EXTENSIONDATASETS table contains information about the dataset extensions (such as network datasets or terrain datasets) in a geodatabase. Field name

Field type

Description

ID

NUMBER(38)

Unique identification number for the network dataset Primary key NOT NULL

OWNER

NVARCHAR2(32) Owner of the dataset

302

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

NAME

NVARCHAR2(160) Name of the dataset

DATASETID

NUMBER(38)

Foreign key to DATASETID field in related tables NOT NULL

PROPERTIES

BLOB

Properties specific to the dataset

DATASETTYPE NUMBER(38)

The type of dataset within the geodatabase

GDB_EXTENSIONS The GDB_EXTENSIONS table stores the extensions registered with this geodatabase. Field name Field type

Description

ID

Unique identifier of the workspace extension

NUMBER(38)

Primary key NOT NULL NAME

NVARCHAR2(160) Name of the workspace extension NOT NULL

CLSID

NVARCHAR2(38) GUID that uniquely identifies the extension of an object class NOT NULL

GDB_FEATURECLASSES The GDB_FEATURECLASSES table contains information on all the feature classes in the geodatabase. Field name

Field type

Description

OBJECTCLASSID

NUMBER(38)

Foriegn key to the ID field in the GDB_OBJECTCLASSES table

FEATURETYPE

NUMBER(38)

NOT NULL Code representing the type of feature 1 = point, multipoint, line, polygon, or multipatch 7 = junctions 8 = simple edges 10 = complex edges 11 = annotation 13 = dimension 14 = raster NOT NULL GEOMETRYTYPE

NUMBER(38)

Code representing the type of geometry of the feature class 1 = point 2 = multipoint 3 = line 4 = polygon (including annotation and dimension) 9 = multipatch NOT NULL

SHAPEFIELD

NVARCHAR2(32) Name of the shape field in the feature class NOT NULL

GEOMNETWORKID NUMBER(38)

Foreign key to ID field in the GDB_GeomNetworks table

GRAPHID

Foreign key to ID GDB_Networks table

NUMBER(38)

GDB_FEATUREDATASET

303

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

The GDB_FEATUREDATASET table contains the feature datasets (groupings of feature classes) in the geodatabase. Field name Field type

Description

ID

Uniquely identifies the feature dataset

NUMBER(38)

Primary key NOT NULL OWNER

NVARCHAR2(32) User who created the feature dataset

NAME

NVARCHAR2(160) Name of the feature dataset

SRID

NUMBER(38)

NOT NULL Spatial reference ID number; foreign key to SPATIAL_REFERENCES table NOT NULL

GDB_FIELDINFO The GDB_FIELDINFO table contains the field name, default domain names values, and default string and number values for each attribute field associated with a feature class. Field name

Field type

Description

CLASSID

NUMBER(38)

Foreign key to the ID field in the GDB_OBJECTCLASSES table NOT NULL

FIELDNAME

NVARCHAR2(160) Name of the field in the table NOT NULL

ALIASNAME

NVARCHAR2(160) Alternate name assigned to the field (Aliases can be altered after field creation, the field name cannot.)

MODELNAME

NVARCHAR2(160) Alternate name assigned to the field used to identify a type of field without requiring a hard-coded name

DEFAULTDOMAINNAME

NVARCHAR2(160) Name of the domain associated with the field

DEFAULTVALUESTRING

NVARCHAR2(160) If the field is type text, the default value assigned to it

DEFAULTVALUENUMBER NUMBER(38,8)

If the field is a numeric type, the default value assigned to it

ISREQUIRED

NUMBER(38)

0 (not a required field) or 1 (a required field)

ISSUBTYPEFIXED

NUMBER(38)

Denotes whether subtype is set for the field 0 = yes 1 = no

ISEDITABLE

NUMBER(38)

0 (not editable) or 1 (editable)

GDB_GEOMNETWORKS The GDB_GEOMNETWORKS table contains one record per geometric network in the geodatabase. If no standalone logical networks exist in the geodatabase, there will be a one-to-one mapping of the GDB_GEOMNETWORKS and GDB_NETWORKS tables. Field name

Field type

Description

ID

NUMBER(38)

Unique ID and primary key for geometric network in the geodatabase

OWNER

NVARCHAR2(32) The name of the user who created the geometric network

NOT NULL NOT NULL NAME

NVARCHAR2(160) The name of the geometric network, which must be unique in a personal geodatabase NOT NULL

NETWORKTYPE NUMBER(38)

The type of geometric network NOT NULL

304

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

DATASETID

NUMBER(38)

Foreign key to ID field in GDB_OBJECTCLASSES table NOT NULL

GDB_HISTORICALMARKERS The GDB_HISTORICALMARKERS table contains a list of markers used for navigating moments in a historical version. Field name

Field type

HM_NAME

NVARCHAR(64) The name of the historical marker

HM_TIMESTAMP DATE

Description The moment the historical marker references

GDB_JNCONNRULES The GDB_JNCONNRULES contains one record per junction connectivity rule in a geometric network. Field name

Field type

Description

RULEID

NUMBER(38) Primary key; the unique ID for a rule in a geodatabase and the foreign key to the ID field in the GDB_VALIDRULES table

EDGECLASSID

NUMBER(38) The Object Class ID of the edge feature class and the foreign key to the ID field in the GDB_GeomNetworks table

EDGESUBTYPE

NUMBER(38) The subtype of the edge feature class

JUNCTIONCLASSID

NUMBER(38) The Object Class ID of the junction feature class and the foreign key to the ID field in the GDB_GEOMNETWORKS table

JUNCTIONSUBTYPE

NUMBER(38) The subtype of the junction feature class

EDGEMINCARD

NUMBER(38) The minimum edge cardinality (the minimum number of edges to which a junction can connect)

EDGEMAXCARD

NUMBER(38) The maximum edge cardinality (the maximum number of edges to which a junction can connect)

NOT NULL

NOT NULL NOT NULL

NOT NULL NOT NULL

NOT NULL

NOT NULL JUNCTIONMINCARD NUMBER(38) The minimum junction cardinality (the minimum number of junctions to which an edge can connect) NOT NULL JUNCTIONMAXCARD NUMBER(38) The maximum junction cardinality (the maximum number of junctions to which an edge can connect) NOT NULL ISDEFAULT

NUMBER(38) Will contain a value of 0 or 1 indicating if a junction is a default junction and has been created automatically

GDB_NETCLASSES The GDB_NETCLASSES table contains one record per feature class that participates in a geometric network in a geodatabase.

305

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

CLASSID

NUMBER(38)

The Object Class ID of a feature class in a geodatabase and the foreign key to the ID field in the GDB_GEOMNETWORKS table NOT NULL

NETWORKID

NUMBER(38)

The unique ID for a geometric network in a geodatabase NOT NULL

ENABLEDFIELD

NVARCHAR2(32) The Enabled field name for the feature class (usually "Enabled") Every feature class in a geometric network must have an enabled field. NOT NULL

ANCILLARYROLE NUMBER(38)

Indicates whether the junction feature class acts as a source or a sink in a geometric network NOT NULL

ANCILLARYFIELD NVARCHAR2(32) The AncillaryRole field name for the feature class (usually "AncillaryRole") NOT NULL

GDB_NETWEIGHTASOCS The GDB_NETWEIGHTASOCS table contains one record per association between the network classes and the network weights of the geometric networks. Field name

Field type

NETWORKID NUMBER(38)

Description The unique ID for a geometric network in a geodatabase and a foreign key to the ID field in the GDB_GEOMNETWORKS table NOT NULL

WEIGHTID

NUMBER(38)

The unique ID of a weight in a geometric network and the foreign key to the ClassID field in the GDB_NETCLASSES table NOT NULL

TABLENAME NVARCHAR2(160) The name of the table containing the field with which the network weight has been associated NOT NULL FIELDNAME NVARCHAR2(32) The name of the field with which the weight has been associated NOT NULL

GDB_NETWEIGHTS The GDB_NETWEIGHTS table contains one record per weight in a geodatabase. Field name

Field type

Description

OID

NUMBER(38)

The unique ID of a weight in a geodatabase NOT NULL

NETWORKID

NUMBER(38)

The unique ID for the geometric network in a geodatabase and the foreign key to the ID fields in the GDB_GEOMNETWORKS, GDB_NETWORKS, and GDB_EXTENSIONDATASETS tables NOT NULL

NAME

NVARCHAR2(160) The name of the weight, which must be unique in each network

WEIGHTID

NUMBER(38)

WEIGHTTYPE

NUMBER(38)

NOT NULL The unique ID of the weight in the geometric network NOT NULL A value indicating the type of network weight NOT NULL BITGATESIZE

NUMBER(38)

A value from 0 to 31 indicating the size of the BitGate weight (NonBitGate weights have a value of 0.)

306

Administering ArcSDE® for Oracle®

Field name

Field type

ELEMENTTYPES NUMBER(38)

ArcSDE geodatabase system tables

Description Denotes the type of network weight

GDB_NETWORKS The GDB_NETWORKS table contains one record per logical network in the geodatabase. If no stand-alone logical networks exist within the geodatabase, there will be a one-to-one mapping between the GDB_GEOMNETWORKS and the GDB_NETWORKS tables. Field name

Field type

Description

ID

NUMBER(38)

The unique ID and primary key of the logical network in a geodatabase.

OWNER

NVARCHAR2(32) The name of the user who created the logical network.

NAME

NVARCHAR2(160) The name of the logical network.

NOT NULL.

NOT NULL. NETWORKTYPE NUMBER(38)

A value indicating the type of network. All networks created using ArcGIS Desktop will have a value of 1=esriNTUtilityNetwork. NOT NULL.

DATASETID

NUMBER(38)

The ID of the feature dataset in which the geometric network resides. Foreign key to the ID field in the GDB_FEATUREDATASETS table. NOT NULL.

INDEXTYPE

NUMBER(38)

Not currently implemented.

NORMALIZED

NUMBER(38)

A value of either 0 or 2, which indicates whether the network is narrow or wide. Narrow networks contain feature classes with ObjectIDs less than 10,000; wide networks can contain feature classes with ObjectIDs greater than 10,000. NOT NULL.

GDB_OBJECTCLASSES The GDB_OBJECTCLASSES contains all the object classes in the geodatabase. This includes the feature classes, relationship classes, and business (or base) tables. Field name

Field type

Description

ID

NUMBER(38)

Unique identifier for the object class Primary key NOT NULL

OWNER

NVARCHAR2(32) User who owns the object class

NAME

NVARCHAR2(160) Name of the object class

ALIASNAME

NVARCHAR2(160) Alternative name of the object class

MODELNAME

NVARCHAR2(160) Alternate name of the object class; used to identify the type of entity without requiring a hard-coded name

CLSID

NVARCHAR2(38) GUID that uniquely identifies the type of object class

NOT NULL NOT NULL

NOT NULL EXTCLSID

NVARCHAR2(38) GUID that uniquely identifies the extension of an object class

EXTPROPS

BLOB

Stores the properties of the associated class extension

DATASETID

NUMBER(38)

Foreign key to the ID field in the GDB_FEATUREDATASET table

SUBTYPEFIELD NVARCHAR2(32) Name of the field in the object class for defining subtypes NOT NULL

307

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

GDB_RANGEDOMAINS The GDB_RANGEDOMAINS table contains the range of values for each range domain. Field name Field type

Description

DOMAINID

Foreign key to the ID field in the GDB_DOMAINS table

NUMBER(38)

NOT NULL MINVALUE NUMBER(38,8) The lowest allowable value in the range NOT NULL MAXVALUE NUMBER(38,8) The greatest allowable value in the range NOT NULL

GDB_RASTERCATALOGS The GDB_RASTERCATALOGS table stores a reference to each raster catalog in the geodatabase. Field name

Field type

Description

OBJECTCLASSID

NUMBER(38)

Foreign key to the ID field in the GDB_OBJECTCLASSES table NOT NULL

RASTERFIELD

NVARCHAR2(32) Name of the raster field NOT NULL

ISRASTERDATASET NUMBER(38)

0 (not a raster dataset) or 1 (a raster dataset) NOT NULL

GDB_RELCLASSES The GDB_RELCLASSES table contains the table relationships in the geodatabase. All the system metadata required to manage relationships, such as the cardinality and the IDs of the origin and destination classes, is stored in the GDB_RELCLASSES table. Field name

Field type

Description

ID

NUMBER(38)

Unique identifier of the relationship class. Primary key. NOT NULL.

OWNER

NVARCHAR2(32) User who owns the relationship class.

NAME

NVARCHAR2(160) Name of the relationship class.

ORIGINCLASSID

NUMBER(38)

NOT NULL. NOT NULL. ID of the origin object class. NOT NULL. DESTCLASSID

NUMBER(38)

ID of the destination object class. NOT NULL.

FORWARDLABEL

NVARCHAR2(255) Label that describes the relationship when navigating from origin class to destination class.

BACKWARDLABEL

NVARCHAR2(255) Label that describes the relationship when navigating from destination class to origin class.

CARDINALITY

NUMBER(38)

Code representing the type of cardinality of the relationship class: 1 = one to one 2 = one to many 3 = many to many NOT NULL.

308

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

NOTIFICATION

NUMBER(38)

Code indicating the notification direction: 1 = none (no messages propagated) 2 = forward (origin to destination) 3 = backward 4 = both (forward and backward notification) NOT NULL.

ISCOMPOSITE

NUMBER(38)

If a relationship class is composite, destination objects cannot exist independently of their related origin objects. Possible values are 0 (is simple, not composite) or 1 (is composite). NOT NULL.

ISATTRIBUTED

NUMBER(38)

Indicates whether or not this is an attributed relationship. NOT NULL.

ORIGINPRIMARYKEY NVARCHAR2(32) The name of the primary key field of the origin object class. NOT NULL. DESTPRIMARYKEY

NVARCHAR2(32) The name of the primary key field in the destination object class. NOT NULL.

ORIGINFOREIGNKEY NVARCHAR2(32) The name of the foreign key field of the origin object class. NOT NULL. DESTFOREIGNKEY

NVARCHAR2(32) The name of the foreign key field in the destination object class. NOT NULL.

DATASETID

NUMBER(38)

Foreign key to the GDB_FEATUREDATASET table. NOT NULL.

GDB_RELEASE The GDB_RELEASE table stores geodatabase version release information as a single record. Field name

Field type

Description

MAJOR

NUMBER(38) Number of the release for the geodatabase. For example, ArcGIS 8 was the first major release for the geodatabase, 9 was the second. NOT NULL.

MINOR

NUMBER(38) Number indicating the version of the major release. For example, for ArcSDE 9.1, this would be 1. NOT NULL.

BUGFIX NUMBER(38) Not in use at this time. The number of the patch or service pack installed. If 0, no service pack or patch is installed. NOT NULL.

GDB_RELRULES The GDB_RELRULES table contains the object class relationship rules. Field name

Field type

RULEID

NUMBER(38) Unique identifier of the rule and foreign key to the ID field in the GDB_VALIDRULES table

Descripton

Primary key NOT NULL ORIGINSUBTYPE

NUMBER(38) The subtype of the origin feature class NOT NULL

309

Administering ArcSDE® for Oracle®

Field name

Field type

ArcSDE geodatabase system tables

Descripton

ORIGINMINCARD NUMBER(38) Minimum number of origin features to which a destination feature can connect NOT NULL ORIGINMAXCARD NUMBER(38) Maximum number of origin features to which a destination feature can connect NOT NULL DESTSUBTYPE

NUMBER(38) The subtype of the destination feature class NOT NULL

DESTMINCARD

NUMBER(38) Minimum number of destination features to which an origin feature can connect NOT NULL

DESTMAXCARD

NUMBER(38) Maximum number of destination features to which an origin feature can connect NOT NULL

GDB_REPLICADATASETS The GDB_REPLICADATASETS table contains information relating to each dataset that was checked out or replicated. Field name

Field type

Description

ID

NUMBER(38)

The unique ID for each record in the table Primary key NOT NULL

REPLICAID

NUMBER(38)

The ID of the replica in the parent database NOT NULL

DATASETTYPE NUMBER(38)

Code for the type of each dataset in the replica (See esriDatasetType constants on EDN for a list of the codes and their meaning.) NOT NULL

DATASETID

NUMBER(38)

The ID of each dataset in the replica NOT NULL

PARENTOWNER NVARCHAR2(32) The owner of the data in the parent geodatabase NOT NULL PARENTDB

NVARCHAR2(32) The name of the database in the parent database

GDB_REPLICALOG Each time a replica exports or imports changes, information about the operation is stored in the GDB_REPLICALOG table. Field name

Field type

Description

ID

NUMBER(38) Unique identifier for row. NOT NULL.

REPLICAID

NUMBER(38) Foreign key to the ID field in the GDB_REPLICAS table.

EVENT

NUMBER(38) Indicates if an import (1) or an export (2) has been logged.

ERRORCODE

NUMBER(38) The error code associated with the event; you can search the developer help to get the description associated with the error. If the event was successful, a success error code is returned.

LOGDATE

DATE

NOT NULL.

NOT NULL. The date on which the event occurred. NOT NULL.

310

Administering ArcSDE® for Oracle®

Field name

Field type

ArcSDE geodatabase system tables

Description

SOURCEBEGINGEN NUMBER(38) Several generations of data changes may be imported or exported in one event. This value indicates the generation number of the first generation of changes involved. For example, if generations 1 to 3 were imported, this field would have the value 1. NOT NULL. SOURCEENDGEN

NUMBER(38) Several generations of data changes may be imported or exported in one event. This value indicates the generation number of the last generation of changes involved. For example, if generations 1 to 3 were imported, this field would have the value 3. NOT NULL.

TARGETGEN

NUMBER(38) The generation to which changes are to be applied; this value is used to apply changes to the appropriate version in the target replica. NOT NULL.

GDB_REPLICAS The GDB_REPLICAS table contains the metadata for each replica in the geodatabase. Field name Field type

Description

ID

Unique identifier for the replica (child) version

NUMBER(38)

Primary key NOT NULL NAME

NVARCHAR2(32)

Name of the replica (child) version of the geodatabase NOT NULL

OWNER

NVARCHAR2(32)

User who owns the replica (child) version of the geodatabase NOT NULL

VERSION

NVARCHAR2(32)

Name of the replica version in the parent geodatabase NOT NULL

PARENTID NUMBER(38)

ID of the replica in the parent geodatabase NOT NULL

REPDATE

DATE

Date and time the replica was created NOT NULL

DEFQUERY BLOB

Contains the replica description, which describes datasets and filters that define the replica NOT NULL

REPGUID

NVARCHAR2(36)

The GUID value that uniquely identifies the replica across geodatabases NOT NULL

REPCINFO NVARCHAR2(1800) The connection information for the relative replicas geodatabase ROLE

NUMBER(38)

Indicates if a replica has the role of parent or child NOT NULL

GDB_REPLICASEX The GDB_REPLICASEX table has additional information about each replica that is stored in the GDB_REPLICAS table. It also has one record of metadata for each replica. Field name Field type ID

Description

NUMBER(38) Unique identifier for the row. Primary key. NOT NULL.

REPLICAID NUMBER(38) Foreign key to ID field in GDB_REPLICAS table. NOT NULL. RPROPS

BLOB

Extra replica properties, such as generation numbers or replica state, are stored in this field.

311

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name Field type

Description

DPROPS

Replica description parameters.

BLOB

NOT NULL.

GDB_SPATIALRULES The GDB_SPATIALRULES table is not in use at this time. Field name

Field type

Description

RULEID

NUMBER(38)

Primary key NOT NULL

SUBTYPE

NUMBER(38)

NOT NULL

SPATIALREL NUMBER(38)

NOT NULL

DISTANCE

NUMBER(38,8) NOT NULL

REFCLASSID NUMBER(38)

NOT NULL

REFSUBTYPE NUMBER(38)

NOT NULL

GDB_SUBTYPES The GDB_SUBTYPES table contains the valid subtypes of the geodatabase object classes. Field name

Field type

Description

ID

NUMBER(38)

Unique identifier of the subtype NOT NULL

CLASSID

NUMBER(38)

Foreign key to the ID field in the GDB_OBJECTCLASSES table NOT NULL

SUBTYPECODE NUMBER(38)

Numeric code value representing a subtype; foreign key to SUBTYPE field in GDB_DEFAULTVALUES table and DESTCLASSSUBTYPE field in the GDB_TOPORULES table NOT NULL

SUBTYPENAME NVARCHAR2(160) Name of the subtype; corresponds to the Subtype Description on the Subtypes tab of the Feature Class Properties dialog box in ArcCatalog NOT NULL

GDB_TABLES_LAST_MODIFIED The GDB_TABLES_LAST_MODIFIED table is used to validate geodatabase system tables when cached by the client application. Field name

Field type

Description

TABLE_NME

NVARCHAR2(160) Name of the geodatabase system table

LAST_MODIFIED_COUNT NUMBER(38)

Keeps a count of the number of times a system table is modified; incrementally increases each time the system table is modified

GDB_TOOLBOXES The GDB_TOOLBOXES table contains one record of metadata for each toolbox in the geodatabase. Field name

Field type

Description

ID

NUMBER(38)

Unique identifier for the toolbox Primary key NOT NULL

DATABASENAME NVARCHAR2(32) Not used

312

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

OWNER

NVARCHAR2(32) User who created the toolbox in the geodatabase NOT NULL

NAME

NVARCHAR2(160) Name given to the toolbox

DISPLAY_NAME

NVARCHAR2(255) Label for the toolbox

ALIAS

NVARCHAR2(255) Alternative name for the toolbox

HELPFILE

NVARCHAR2(255) Path to the help file containing the help topic for the toolbox

HELPCONTEXT

NUMBER(38)

NOT NULL

Help context ID from the help file for the help topic associated with the toolbox

GDB_TOPOCLASSES The GDB_TOPOCLASSES table contains one record per each feature class in a topology. Field name

Field type

Description

CLASSID

NUMBER(38)

Unique identifier of the topology class; foreign key to ID field in the GDB_OBJECTCLASSES table NOT NULL

TOPOLOGYID

NUMBER(38)

Foreign key to ID field in GDB_TOPOLOGIES table NOT NULL

WEIGHT

NUMBER(38,8) Not in use

XYRANK

NUMBER(38)

ZRANK

NUMBER(38)

The rank in the x,y domain assigned to the feature class in the topology NOT NULL The rank in the z domain assigned to the feature class in the topology NOT NULL

EVENTSONANALYZE NUMBER(38)

Indicates if an event is broadcast when topology is validated NOT NULL

GDB_TOPOLOGIES The GDB_TOPOLOGIES table contains one record per topology in the geodatabase. Field name

Field type

Description

ID

NUMBER(38)

Primary key and the unique ID for the topology in the geodatabase NOT NULL

OWNER

VARCHAR2(32) The owner of the topology (the user who created the topology) NOT NULL

NAME

VARCHAR2(160) The name of the topology NOT NULL

DATASETID NUMBER(38)

The feature dataset in which the topology resides and the foreign key to the ID field in the GDB_FEATUREDATASETS table NOT NULL

PROPERTIES BLOB

Stores information such as the cluster tolerance, max error count, state, and configuration keyword

GDB_TOPORULES The GDB_TOPORULES table contains one record per rule in each topology.

313

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

RULEID

NUMBER(38)

Unique identifier of the topology rule; foreign key to the ID field in the GDB_VALIDRULES table NOT NULL

ORIGINCLASSID

NUMBER(38)

Foreign key to CLASSID field in GDB_TOPOCLASSES table NOT NULL

ORIGINSUBTYPE

NUMBER(38)

Foreign key to SUBTYPECODE field in GDB_SUBTYPES table NOT NULL

ALLORIGINSUBTYPES NUMBER(38)

Indicates if rule applies to all subtypes in the origin feature class NOT NULL

DESTCLASSID

NUMBER(38)

Foreign key to CLASSID field in GDB_TOPOCLASSES table NOT NULL

DESTSUBTYPE

NUMBER(38)

Foreign key to SUBTYPECODE field in GDB_SUBTYPES table NOT NULL

ALLDESTSUBTYPES

NUMBER(38)

Indicates if rule applies to all subtypes in the destination feature class NOT NULL

TOPOLOGYRULETYPE NUMBER(38)

The type of topology rule NOT NULL

NAME

VARCHAR2(160) User-defined name associated with the topology rule

RULEGUID

VARCHAR(38)

GUID that uniquely identifies the topology rule NOT NULL

GDB_USERMETADATA The GDB_USERMETADATA table stores user-defined metadata for all parts of the geodatabase including object classes, feature classes, feature datasets, logical networks, and relationship classes. Field name

Field type

Description

ID

NUMBER(38)

Uniquely identifies the metadata record Primary key NOT NULL

DATABASENAME VARCHAR2(32) Not used OWNER

VARCHAR2(32) The owner of the metadata NOT NULL

NAME

VARCHAR2(160) Name of the dataset to which the metadata refers NOT NULL

DATASETTYPE

NUMBER(38)

Code for the type of dataset to which the metadata refers NOT NULL

XML

BLOB

Metadata content NOT NULL

GDB_VALIDRULES The GDB_VALIDRULES table contains all the valid rules of the geodatabase. This includes the attribute rules, edge connectivity rules, junction connectivity rules, relationship rules, topology rules, geocoding rules, and spatial rules.

314

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

ID

NUMBER(38)

Uniquely identifies a rule Primary key NOT NULL

RULETYPE

NUMBER(38)

The type of validation rule NOT NULL

CLASSID

NUMBER(38)

Foreign key to ID field in GDB_OBJECTCLASSES table NOT NULL

RULECATEGORY NUMBER(38)

Not in use at this time NOT NULL

HELPSTRING

NVARCHAR2(160) Not in use at this time

GEOMETRY_COLUMNS The GEOMETRY_COLUMNS table stores a row for each column of type Geometry in the database that complies with the OpenGIS SQL specification. ArcSDE treats this table as write-only—the only time it is accessed by ArcSDE is when a layer is added or deleted that uses an OpenGIS SQL data format. This table is defined by the OpenGIS SQL specification and may be updated by other applications with geometry columns not managed by ArcSDE. When a new Geometry column is created in an OpenGIS compliant format, the fully qualified table, column name, and spatial reference ID (SRID) are added to the GEOMETRY_COLUMNS table. Each geometry column is associated with a spatial reference system. ArcSDE stores information on each spatial reference system in the SPATIAL_REFERENCES table. Field name

Field type

Description

F_TABLE_CATALOG

NVARCHAR2(32) The database in which the feature table is stored

F_TABLE_SCHEMA

NVARCHAR2(32) Schema in which the business table is stored NOT NULL

F_TABLE_NAME

NVARCHAR2(160) Name of the business table of the dataset NOT NULL

F_GEOMETRY_COLUMN NVARCHAR2(32) Name of the geometry column in the business table NOT NULL G_TABLE_CATALOG

NVARCHAR2(32) The database in which the geometry column is stored

G_TABLE_SCHEMA

NVARCHAR2(32) Schema in which the table that contains the geometry column is stored NOT NULL

G_TABLE_NAME

NVARCHAR2(160) Name of the table that contains the geometry column NOT NULL

STORAGE_TYPE

NUMBER(38)

Code for the storage type of the geometry; code could represent either WKB, WKT, BINARY, or SDO_GEOMETRY

GEOMETRY_TYPE

NUMBER(38)

Code for the geometry type that the column stores; could represent either point, multipoint, linestring, multilinestring, polygon, or multipolygon

COORD_DIMENSION

NUMBER(38)

Code for the coordinate dimension 0 = point 1 = linear 2 = area

MAX_PPR

NUMBER(38)

Maximum points per row (no longer used by ArcSDE)

SRID

NUMBER(38)

Spatial reference ID NOT NULL

315

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

INSTANCES The INSTANCES table is used to track geodatabases stored in a user's (other than the SDE user's) schema. This table is stored in the master SDE geodatabase. Field name

Field type

Description

INSTANCE_ID

NUMBER(38)

Unique identifier for the user-schema geodatabase. Primary key. NOT NULL.

INSTANCE_NAME

NVARCHAR2(32) Name of the user-schema geodatabase. NOT NULL.

CREATION_DATE

DATE

STATUS

NUMBER(38)

Date the geodatabase was created in the user's schema. NOT NULL. The current status of the user-owned geodatabase; will contain one of three values: 1 = The geodatabase is open and currently accepting connections. 2 = The geodatabase is paused or stopped and is currently not accepting connections. 3 = The instance has lost its connection to the DBMS. NOT NULL.

TIME_LAST_MODIFIED DATE

The last time the user-schema geodatabase was modified. NOT NULL.

LAYER_LOCKS The LAYER_LOCKS table maintains the locks on feature classes. Field name Field type

Description

SDE_ID

NUMBER(38) Process identification number of the process that has locked the layer; foreign key to the sde_id column in PROCESS_INFORMATION table

LAYER_ID

NUMBER(38) Foreign key to layer_id field in LAYERS table

NOT NULL NOT NULL AUTOLOCK CHAR(1)

Set to 1 if the layer lock was set internally; otherwise, set to 0 if the layer lock was set by the application NOT NULL

LOCK_TYPE CHAR(1)

The type of layer lock can either be 0 = A read lock on the entire layer 1 = A write lock on the entire layer 2 = A read lock on an area within the layer 3 = A write lock on an area within the layer 4 = A layer autolock NOT NULL

MINX

NUMBER(38) The minimum x-coordinate of the bounding box used to define the features within an area locked during an area lock

MINY

NUMBER(38) The minimum y-coordinate of the bounding box used to define the features within an area locked during an area lock

MAXX

NUMBER(38) The maximum x-coordinate of the bounding box used to define the features within an area locked during an area lock

MAXY

NUMBER(38) The maximum y-coordinate of the bounding box used to define the features within an area locked during an area lock

316

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

LAYERS The LAYERS table maintains data about each feature class in the database. The information helps build and maintain spatial indexes, ensure proper shape types, maintain data integrity, and store the spatial reference for the coordinate data. This table stores a row for each spatial column in the database. Applications use the layer properties to discover available spatial data sources. The layer properties are used by ArcSDE to constrain and validate the contents of the spatial column, to index geometry values, and to properly create and manage the associated DBMS tables. Field name

Field type

Description

LAYER_ID

NUMBER(38)

Unique identifier for the layer Primary key NOT NULL

DESCRIPTION

NVARCHAR2(65) The optional layer description

DATABASE_NAME

NVARCHAR2(32) Not used

OWNER

NVARCHAR2(32) The user who created the layer in the geodatabase NOT NULL

TABLE_NAME

NVARCHAR2(160) Name of the business table of the layer NOT NULL

SPATIAL_COLUMN

NVARCHAR2(32) Name of the spatial column in the layer

EFLAGS

NUMBER(38)

Stores the following layer properties: ◦ Layer stores single precision or double precision coordinates. ◦ Layer stores 3D coordinates. ◦ Layer stores measures. ◦ Layer has autolocking enabled or disabled. ◦ Layer is in load only I/O mode or normal I/O mode. ◦ Layer stores annotation. ◦ Layer stores CAD data. ◦ Layer is a view of another layer. ◦ Layer does not have a spatial index. ◦ The DBMS data type in which the layer data is stored. ◦ The sde types that the layer can accept, which can be such types as points, linestrings, polygons.

LAYER_MASK

NUMBER(38)

Stores additional internal properties about the layer

GSIZE1

FLOAT(64)

Size of first spatial grid

GSIZE2

FLOAT(64)

Size of second spatial grid

GSIZE3

FLOAT(64)

Size of third spatial grid

MINX

FLOAT(64)

Minimum x-coordinate value of the layer

MINY

FLOAT(64)

Minimum y-coordinate value of the layer

MAXX

FLOAT(64)

Maximum x-coordinate value of the layer

MAXY

FLOAT(64)

Maximum y-coordinate vlue of the layer

MINZ

FLOAT(64)

Minimum z-coordinate value of the layer

MAXZ

FLOAT(64)

Maximum z-coordinate value of the layer

MINM

FLOAT(64)

Minimum measure value of the layer

MAXM

FLOAT(64)

Maximum measure value of the layer

CDATE

NUMBER(38)

The layer creation date NOT NULL

LAYER_CONFIG

NVARCHAR2(32) Configuration keyword with which the layer was created

317

Administering ArcSDE® for Oracle®

Field name

ArcSDE geodatabase system tables

Field type

Description

OPTIMAL_ARRAY_SIZE NUMBER(38)

Geometry array buffer size

STATS_DATE

NUMBER(38)

When statistics were last calculated for a layer

MINIMUM_ID

NUMBER(38)

The minimum feature ID value of a binary layer

SRID

NUMBER(38)

Spatial reference identification number; corresponds to srid value in the SPATIAL_REFERENCES table NOT NULL

BASE_LAYER_ID

NUMBER(38)

Stores the base layer's layer_id value for a layer that is actually a view NOT NULL

SECONDARY_SRID

NUMBER(38)

Used to store high precision coordinate reference to project data when the data was basic precision and was converted to high precision

LINEAGES_MODIFIED The LINEAGES_MODIFIED table contains a state lineage ID and its most recent modification time stamp. Field name

Field type

LINEAGE_NAME

NUMBER(38) Foreign key to the lineage_name field in the STATE_LINEAGES table

Description NOT NULL

TIME_LAST_MODIFIED DATE

The date and time the lineage was last modified NOT NULL

LOCATORS The LOCATORS table stores information about locator objects. Field name

Field type

LOCATOR_ID NUMBER(38)

Description Unique identifier of the locator Primary key NOT NULL

NAME

NVARCHAR2(32) The name of the locator

OWNER

NVARCHAR2(32) The name of the user who owns the locator

CATEGORY

NVARCHAR2(32) The category of the locator; address locators have a category value of Address.

NOT NULL NOT NULL NOT NULL TYPE

NUMBER(38)

The type of locator; values in this column are represented as ◦ 0—Defines locator styles ◦ 1—Defines locators ◦ 2—Defines attached locators; in other words, locators that are attached to a geocoded feature class and are a copy of the locator and the geocoding options that were used to create the geocoded feature class NOT NULL

DESCRIPTION NVARCHAR2(64) The description of the locator

METADATA When you add a locator to a geodatabase in a DBMS, a row is added to the METADATA table for each property of the locator. Each row in the METADATA table defines a single property for a locator.

318

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

RECORD_ID

NUMBER(38)

Unique identifier for the record Primary key NOT NULL

OBJECT_NAME

NVARCHAR2(160) The name of the locator to which the property belongs and foreign key to the name column in the LOCATORS table NOT NULL

OBJECT_OWNER NVARCHAR2(32) The name of the user who owns the record NOT NULL OBJECT_TYPE

NUMBER(38)

Always a value of 2 for locator properties NOT NULL

CLASS_NAME

NVARCHAR2(32) Always a value of SDE_internal for locator properties

PROPERTY

NVARCHAR2(32) The name of the locator property

PROP_VALUE

NVARCHAR2(255) The value of the locator property

DESCRIPTION

NVARCHAR2(65) Not used for locator properties

CREATION_DATE DATE

Date and time the locator property was created NOT NULL

MVTABLES_MODIFIED The MVTABLES_MODIFIED table maintains the list of all tables that are modified in each state of the database. This information aids in quickly determining if conflicts exist between versions or states of the database. The MVTABLES_MODIFIED table maintains a record of all tables modified by state. This information allows applications to determine which tables need to be checked for changes when reconciling potential conflicts between versions and states in the database. Any time a feature class or table is modified in a state, a new entry is created in the MVTABLES_MODIFIED table. When two versions are reconciled, the first step in the process is to identify the states these two versions reference—the current edit version’s state and the target version’s state. From these states, a common ancestor state is identified by tracing back through the state lineage of these two versions. Field name

Field type

STATE_ID

NUMBER(38) The ID of the state in which this table was modified; foreign key to the STATES table

Description NOT NULL

REGISTRATION_ID NUMBER(38) The registration ID of the table that was modified in the state; foreign key to the TABLE_REGISTRY table NOT NULL

OBJECT_LOCKS The OBJECT_LOCKS table maintains locks on geodatabase objects. Field name

Field type

SDE_ID

NUMBER(38) Process identification number of the process that locked the geodatabase object; references sde_id column in SDE_process_information table

Description

OBJECT_ID

NUMBER(38) ID from the OBJECT_CLASSES table of the affected dataset

OBJECT_TYPE

NUMBER(38) Object lock type; for example, version,state_tree lock used by internal applications

NOT NULL NOT NULL NOT NULL

319

Administering ArcSDE® for Oracle®

Field name

Field type

ArcSDE geodatabase system tables

Description

APPLICATION_ID NUMBER(38) Application unique identifier NOT NULL AUTOLOCK

CHAR(1)

Set to 1 if the layer lock was set internally; otherwise, set to 0 if the layer lock was set by the application NOT NULL

LOCK_TYPE

CHAR(1)

The type of object lock, which includes "S" for shared "E" for exclusive NOT NULL

PROCESS_INFORMATION The PROCESS_INFORMATION table collects ArcSDE session statistics such as the number of records read and the number of records written while the session was active. Field name

Field type

Description

SDE_ID

NUMBER(38)

Process identification number NOT NULL

SERVER_ID

NUMBER(38)

The operating system process ID of the server process NOT NULL

START_TIME

DATE

Date and time process was started NOT NULL

RCOUNT

NUMBER(38)

The number of reads that have been processed NOT NULL

WCOUNT

NUMBER(38)

OPCOUNT

NUMBER(38)

NUMLOCKS

NUMBER(38)

The number of writes that have been processed NOT NULL Total number of operations a process has executed NOT NULL The number of locks that the process currently has open NOT NULL

FB_PARTIAL

NUMBER(38)

Total number of partial features shipped by the process NOT NULL

FB_COUNT

NUMBER(38)

Total number of buffers loaded by the process NOT NULL

FB_FCOUNT

NUMBER(38)

Total number of features buffered by the process

FB_KBYTES

NUMBER(38)

OWNER

NVARCHAR2(30) The name of the connected user

NOT NULL Total number of kilobytes buffered by the process NOT NULL NOT NULL DIRECT_CONNECT VARCHAR2(1)

Indicates whether process was made with a direct connection: T (true) or F (false) NOT NULL

SYSNAME

NVARCHAR2(32) The operating system that the client machine is running NOT NULL

NODENAME

NVARCHAR2(255) The connected client machine name NOT NULL

320

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

XDR_NEEDED

VARCHAR2(1)

Records whether or not client is using xdr to communicate with the gsrvr T (true) or F (false) NOT NULL

RASTER_COLUMNS The RASTER_COLUMNS table contains a list of raster columns stored in the database. This table references the raster data in the band, block, and auxiliary tables. Field name

Field type

Description

RASTERCOLUMN_ID

NUMBER(38)

The primary key of the raster column table NOT NULL

DESCRIPTION

VARCHAR2(65)

The description of the raster table

DATABASE_NAME

NVARCHAR2(32) Not used

OWNER

NVARCHAR2(32) The owner of the raster column's business table NOT NULL

TABLE_NAME

NVARCHAR2(160) The business table name NOT NULL

RASTER_COLUMN

NVARCHAR2(32) The raster column name NOT NULL

CDATE

NUMBER(38)

The date the raster column was added to the business table

CONFIG_KEYWORD

NVARCHAR2(32) The DBTUNE configuration keyword whose storage parameters determine how the tables and indexes of the raster are stored in the database

MINIMUM_ID

NUMBER(38)

NOT NULL

BASE_RASTERCOLUMN_ID NUMBER(38)

Defined during the creation of the raster, establishes value of the raster table's raster_id column When the raster column is part of a view and not a table, this value is the rastercolumn_id of the base table of the view NOT NULL

RASTERCOLUMN_MASK

NUMBER(38)

Set to 256 for a geodatabase raster NOT NULL

SRID

NUMBER(38)

Spatial reference identifier number, references SRID in the SPATIAL_REFERENCES table

SDE_ARCHIVES The SDE_ARCHIVES table stores the metadata for the archives in a geodatabase. Field name

Field type

Description

ARCHIVING_REGID NUMBER(38)

The table's registration ID

HISTORY_REGID

NUMBER(38)

The archive table's registration ID

FROM_DATE

NVARCHAR2(32) The name of the from date field

TO_DATE

NVARCHAR2(32) The name of the to date field

ARCHIVE_DATE

NUMBER(38)

The creation date of the archive

ARCHIVE_FLAGS

NUMBER(38)

Not currently used

SDE_LOGFILE_POOL The SDE_LOGFILE_POOL table will be present in the geodatabase when it is first created, regardless of what type of log files you use. For a description of this and other log file tables, see Log file tables in a geodatabase in Oracle . 321

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

SDE_TABLES_MODIFIED The SDE_TABLES_MODIFIED table records when changes are made to the system tables. This information is used to eliminate unnecessary reads of tables that have not changed. Field name

Field type

TABLE_NAME

NVARCHAR2(32) Name of the ArcSDE system table that was modified

Description NOT NULL

TIME_LAST_MODIFIED DATE

Date and time the table was modified NOT NULL

SDE_XML_COLUMNS When you add an XML column to a business table, a row is added to the XML columns table. This table occurs once in each ArcSDE geodatabase. Field name

Field type

Description

COLUMN_ID

NUMBER(38)

The XML column's identifier and the table's primary key; this value is assigned by ArcSDE at the time the XML column is created. NOT NULL.

REGISTRATION_ID NUMBER(38)

The identifier of the business table containing the XML column; a foreign key to the ArcSDE table registry. NOT NULL.

COLUMN_NAME

NVARCHAR2(32) Name of the XML column in the business table. NOT NULL.

INDEX_ID

NUMBER(38)

The identifier of the XPath index associated with the XML column, if one exists; a foreign key to the XML indexes table.

MINIMUM_ID

NUMBER(38)

The value of the initial number used in the business table's XML column to identify individual XML documents.

CONFIG_KEYWORD NVARCHAR2(32) The DBTUNE configuration keyword containing parameters that determine how the XML document and the XML XPath index tables and the text indexes created on those tables are defined in the database. XFLAGS

NUMBER(38)

A value indicating whether the original documents in the XML document table are stored compressed or uncompressed; by default, documents are compressed. (Compressed documents provide better performance.)

SDE_XML_INDEX_TAGS An XML column may optionally have an XPath index, which lets people search the content of a specific XML element or attribute in each document. The definition of which elements and attributes are included in or excluded from each XPath index is recorded in this table. This table occurs once in each ArcSDE database. It contains one row for each XPath associated with an XML column's XPath index. Field name

Field type

Description

INDEX_ID

NUMBER(38)

The identifier of the XPath index associated with an XML column, if one exists; foreign key to the XML indexes table. NOT NULL.

TAG_ID

NUMBER(38)

The identifier of an XPath, or tag. NOT NULL.

322

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

TAG_NAME

NVARCHAR2(1024) An absolute XPath identifying an XML element or attribute that may occur in an XML document. (Example: /metadata/mdDateSt identifies an XML element, and /metadata/dataIdInfo/tpCat/ TopicCatCd/@value identifies an XML attribute. These XPaths must not contain asterisks (*) to refer to a group of XML elements or attributes—each element or attribute is matched exactly using the XPaths specified in this table.) NOT NULL.

DATA_TYPE

NUMBER(38)

A value indicating whether the XML element or attribute will be indexed as a string or a number. 1 = The content of the tag will be indexed as text. 2 = The content will be indexed as a number. NOT NULL.

TAG_ALIAS

NUMBER(38)

A number that may be used to identify an XPath. For example, the Z39.50 communication protocol uses numeric codes to refer to content that may be searched. This column is not used by the ArcIMS Z39.50 Connector.

DESCRIPTION NVARCHAR2(64)

Text identifying the content that should be contained in the XML element or attribute.

IS_EXCLUDED NUMBER(38)

A value indicating whether the XML element is included in or excluded from the XPath index. ◦ 0 = included ◦ 1 = excluded NOT NULL.

SDE_XML_INDEXES This table occurs once in each ArcSDE database. It contains one row for each XML column that has an XPath index. Field name

Field type

Description

INDEX_ID

NUMBER(38)

The identifier of the XPath index. Primary key. NOT NULL.

INDEX_NAME NVARCHAR2(32) The name of the XPath index. For XPath indexes associated with an ArcIMS Metadata Service, the name will be "ims_xml#", where # is the identifier of the XML column in the metadata service's business table. NOT NULL. OWNER

NVARCHAR2(32) The database user who owns the XML column. For ArcIMS Metadata Services, this is the user specified in the service's ArcXML configuration file.

INDEX_TYPE NUMBER(38)

A value indicating the type of XPath index. ◦ 1 = index type SE_XML_INDEX_TEMPLATE. ◦ 2 = index type SE_XML_INDEX_DEFINITION. For XPath indexes associated with an ArcIMS Metadata Service, only the index type SE_XML_INDEX_DEFINITION is supported.

DESCRIPTION NVARCHAR2(64) Text identifying the XPath index. If an index definition file was used to create the index, the index's description may be specified at the top of the file.

SERVER_CONFIG

323

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

The SERVER_CONFIG table stores ArcSDE server configuration parameters. These parameters define how the ArcSDE software uses uses memory. Field name

Field type

Description

PROP_NAME

NVARCHAR2(32) The initialization parameter name NOT NULL

CHAR_PROP_VALUE NVARCHAR2(512) The character value of the initialization parameter NUM_PROP_VALUE NUMBER(38)

The integer value of the initialization parameter

SPATIAL_REFERENCES The SPATIAL_REFERENCES table contains the coordinate system and floating-point-to-integer transformation values. Internal functions use the parameters of a spatial reference system to translate and scale each floatingpoint coordinate of the geometry into 64-bit positive integers prior to storage. Upon retrieval, the coordinates are restored to their original external floating-point format. Each geometry column of the GEOMETRY_COLUMNS table is associated with a spatial reference system, the information for which is stored in the SPATIAL_REFERENCES table. The columns of this table are those defined by the OpenGIS SQL Specification (SRID, SRTEXT, AUTH_NAME, and AUTH_SRID) and those required by ArcSDE for internal coordinate transformation. The spatial reference system identifies the coordinate system for a geometry and gives meaning to the numeric coordinate values for the geometry. Field name

Field type

Description

SRID

NUMBER(38)

Spatial reference identifier number NOT NULL

DESCRIPTION

NVARCHAR2(64) The text description of the spatial reference system

AUTH_NAME

NVARCHAR2(256) The name of the standard or standards body that is being cited for this reference system; for example, POSC would be a valid AUTH_NAME

AUTH_SRID

NUMBER(38)

The ID of the Spatial Reference System as defined by the Authority cited in AUTH_NAME

FALSEX

FLOAT(64)

The x offset used when transforming ground coordinates to internal system coordinates NOT NULL

FALSEY

FLOAT(64)

The y offset used when transforming ground coordinates to internal system coordinates NOT NULL

XYUNITS

FLOAT(64)

The scale factor to apply when transforming ground coordinates to internal system coordinates NOT NULL

FALSEZ

FLOAT(64)

The z offset to use when transforming z-values to internal system coordinates NOT NULL

ZUNITS

FLOAT(64)

The scale factor to use when transforming z-values to internal system coordinates NOT NULL

FALSEM

FLOAT(64)

The measure offset to use when transforming measure values to internal system coordinates NOT NULL

MUNITS

FLOAT(64)

The scale factor to use when transforming measure values to internal system coordinates NOT NULL

XYCLUSTER_TOL FLOAT(64)

X,y coordinate cluster tolerance for topological processing

ZCLUSTER_TOL

FLOAT(64)

Z-coordinate cluster tolerance for topological processing

MCLUSTER_TOL

FLOAT(64)

Measure cluster tolerance for topological processing

324

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

OBJECT_FLAGS

NUMBER(38)

Stores object attributes, including precision NOT NULL

SRTEXT

VARCHAR2(1024) Name and descriptor for the spatial reference as seen in the ArcGIS interface NOT NULL

STATE_LINEAGES The STATE_LINEAGES table stores the lineage of each state. A new lineage name is created for each version. Each time a state is added, the lineage name and the state ID are added. When a state is added that is a new version, the ancestry state lineage of the parent state is added with the lineage name. To return the correct view of a version, its state lineage is queried to identify all the states that recorded each change made to that version. From this list of states, the table rows that correctly represent the version can be determined. Field name

Field type

Description

LINEAGE_NAME NUMBER(38) Name that describes a state NOT NULL LINEAGE_ID

NUMBER(38) Unique ID of individual states NOT NULL

STATE_LOCKS The STATE_LOCKS table maintains the version state locks. Field name Field type SDE_ID

Description

NUMBER(38) Process identification number of the process that locked the state; references SDE_ID column in PROCESS_INFORMATION table NOT NULL

STATE_ID

NUMBER(38) ID of the state that is locked NOT NULL

AUTOLOCK CHAR(1)

Set to 1 if the layer lock was set internally; otherwise, set to 0 if the layer lock was set by the application NOT NULL

LOCK_TYPE CHAR(1)

The type of state lock; the following are possible types: 0 = A shared lock on the entire state tree 1 = An exclusive lock on the entire state tree 2 = A shared lock on a state 3 = An exclusive lock on a state 4 = A shared autolock 5 = An exclusive autolock NOT NULL

STATES The STATES table contains the state metadata. It accounts for the states that have been created over time, and the creation time, closing time, parent, and owner of each state. When a state is created, a state ID is assigned and a record is added to this table.

325

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Discussion

STATE_ID

NUMBER(38)

A unique ID for this state, assigned by ArcSDE Primary key NOT NULL

OWNER

NVARCHAR2(32) The user who created this state NOT NULL

CREATION_TIME

DATE

The date/time this state was created NOT NULL

CLOSING_TIME

DATE

PARENT_STATE_ID NUMBER(38)

The date/time that this state was closed This state’s parent's STATE_ID NOT NULL

LINEAGE_NAME

NUMBER(38)

References the state's lineage stored in the STATE_LINEAGES table NOT NULL

ST_COORDINATE_SYSTEMS The ST_Coordinate_Systems table contains all coordinate systems registered with the Spatial Type. This table is updated when ArcSDE is installed and, when needed, upgraded. It can also be updated to include user-defined coordinate systems by using the ST_CSRegister function. Along with the ST_SPATIAL_REFERENCES table, the ST_COORDINATE_SYSTEMS table describes coordinate systems and projections available to the ST_Geometry type. Field name

Field type

NAME

NVARCHAR2(128) Coordinate system name

Description

TYPE

NVARCHAR2(128) Type of coordinate system: PROJECTED, GEOGRAPHIC, or UNSPECIFIED

DEFINITION

NVARCHAR2(2048) Well-known text description of the coordinate system

ORGANIZATION NVARCHAR2(128) Name of the organization that defined the coordinate system ID

NUMBER(38)

Coordinate system ID defined by the organization NOT NULL

DESCRIPTION

NVARCHAR2(256) Description for the coordinate system indicating its application

ST_GEOMETRY_COLUMNS This table holds the schema, geometry type, and spatial reference information for every ST_Geometry column created or added to a table object or view. Inserting ST_Geometry column information to this table is done using stored procedures to register/unregister tables or views. The table/column metadata must be registered to this table before creating a spatial index. Creating a table with an ST_Geometry column does not insert ST_Geometry metadata. When you create a spatial index on a table, an entry will be inserted in the ST_GEOMETRY_COLUMNS and ST_GEOMETRY_INDEX tables. This table is used to perform selections and DML metadata operations. Stored procedures are used to insert and delete entries from the ST_GEOMETRY_COLUMNS table. Field name

Field type

Description

OWNER

NVARCHAR2(32) Schema name owning the table

TABLE_NAME

NVARCHAR2(32) Unqualified table name having one or more spatial types

COLUMN_NAME

NVARCHAR2(32) Name of the geometry column

NOT NULL NOT NULL NOT NULL

326

Administering ArcSDE® for Oracle®

Field name

Field type

ArcSDE geodatabase system tables

Description

GEOMETRY_TYPE NVARCHAR2(32) Geometry types associated with the column PROPERTIES

NUMBER(38)

A bit mask containing application information such as entity, table status, load/normal mode, table, or view

SRID

NUMBER(38)

Spatial reference value from ST_SPATIAL_REFERENCES table NOT NULL

GEOM_ID

NUMBER(38)

Uniquely defines a record; used as reference key to the index_id in ST_GEOMETRY_INDEX table NOT NULL

ST_GEOMETRY_INDEX This table holds the spatial index information for an ST_Geometry column. The spatial index for an ST_Geometry type is a domain index referred to in the CREATE INDEX statement. Grid sizes and SRID are defined in the PARAMETERS clause of the CREATE INDEX statement. When using ALTER INDEX REBUILD, the SRID value should not be changed. If it is, the SRID values for all features will also need to be updated in a separate table UPDATE statement. To specify grid sizes and an SRID, use the st_grids and st_srid keywords: CREATE INDEX shape_idx1 ON SCOTT.PARCELS (shape) INDEXTYPE IS SDE.ST_SPATIAL_INDEX PARAMETERS('st_grids=1,0,0 st_srid=1');

OWNER, TABLE_NAME, and COLUMN_NAME uniquely identify an ST_SPATIAL_INDEX domain index. Field name

Field type

Description

OWNER

NVARCHAR2(32)

Schema owner.

TABLE_NAME

NVARCHAR2(32)

Unqualified table name.

COLUMN_NAME

NVARCHAR2(32)

Name of the geometry column.

INDEX_ID

NUMBER(38)

Uniquely identifies the domain index. NOT NULL.

GRID

SDE.SP_GRID_INFO

Grid type containing multilevel integer grid information. SP_GRID_INFO is a GRID_TYPE column object consisting of three NUMBER grid values.

SRID

NUMBER(38)

SRID and spatial reference information. NOT NULL.

COMMIT_INT

NUMBER(38)

XML commit interval for spatial index rows; the number of rows affected before issuing a COMMIT. The default value is 1000.

VERSION

NUMBER(38)

Domain index version number.

STATUS

NVARCHAR2(10)

Describes the index status (1 = Active or 0 = Disabled). Loading can disable the index for performance reasons.

INDEX_NAME

NVARCHAR2(30)

Name of the ST_SPATIAL_INDEX (domain index).

UNIQUENESS

VARCHAR2(9)

Indicates whether the domain index is UNIQUE or NONUNIQUE.

DISTINCT_KEYS

NUMBER(38)

Number of distinct domain index keys.

BLEVEL

NUMBER(38)

Depth of the domain index from its root block to its leaf block.

LEAF_BLOCKS

NUMBER(38)

Number of leaf blocks for the domain index.

The default is Active.

327

Administering ArcSDE® for Oracle®

Field name

Field type

ArcSDE geodatabase system tables

Description

CLUSTERING_FACTOR NUMBER(38)

Indicates how ordered the rows in the table are based on the values of the index; if the CLUSTERING_FACTOR value is close to the number of blocks, the table is well ordered. In this case, the index entries in a single leaf block tend to point to rows in the same data blocks. If the CLUSTERING_FACTOR value is near the number of rows, the table is randomly ordered, in which case it is unlikely the index entries in the same leaf block point to rows in the same data blocks.

DENSITY

NUMBER(38)

Average number of features per grid cell.

NUM_ROWS

NUMBER(38)

Number of rows in the table containing the ST_Geometry and ST_SPATIAL_INDEX.

NUM_NULLS

NUMBER(38)

Number of NULL ST_Geometry values in the table containing the ST_Geometry and ST_SPATIAL_INDEX.

SAMPLE_SIZE

NUMBER(38)

Size of the data sample used when collecting DBMS statistics.

LAST_ANALYZED

DATE

Date on which the table was most recently analyzed.

USER_STATS

VARCHAR2(3)

Indicates whether statistics were entered directly by the user (YES) or not (NO).

ST_FUNCS

SDE.ST_FUNCS_ARRAY User-defined operator selectivity and cost values; when set, defined values override derived selectivity and system-defined operator costs.

ST_SPATIAL_REFERENCES This table contains all spatial references available to the ST_Geometry type. Spatial tables must be referenced correctly for you to analyze them individually or combine them to see relationships. This means they must have a spatial reference and coordinate system. The ST_SPATIAL_REFERENCES table contains the coordinate system and floating-point-to-integer transformation values. Internal functions use the parameters of a spatial reference system to translate and scale each floating-point coordinate of the geometry into 64-bit positive integers prior to storage. Upon retrieval, the coordinates are restored to their original external floating-point format. Along with the ST_COORDINATE_SYSTEMS table, the ST_SPATIAL_REFERENCES table describes coordinate systems and projections available to the ST_Geometry type. Included in this table schema are scale and offsets for coordinates (x,y,z) and measures (m). This information is used to convert decimal values into integers and negative values into positive values for storage and performance reasons. Field name

Field type

Description

SR_NAME

NVARCHAR2(128) Spatial reference name NOT NULL

SRID

NUMBER(38)

Spatial reference ID NOT NULL

X_OFFSET

FLOAT(126)

Y_OFFSET

FLOAT(126)

XYUNITS

FLOAT(126)

Offset applied to x-coordinate values NOT NULL Offset applied to y-coordinate values NOT NULL Scale factor applied to x- and y-coordinates after applying OFFSET NOT NULL

Z_OFFSET

FLOAT(126)

Offset applied to z-coordinate values NOT NULL

Z_SCALE

FLOAT(126)

Scale factor applied to z-coordinates after applying OFFSET NOT NULL

M_OFFSET

FLOAT(126)

Offset applied to measures NOT NULL

328

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

M_SCALE

FLOAT(126)

Scale factor applied to measures after applying OFFSET NOT NULL

MIN_X

FLOAT(126)

MAX_X

FLOAT(126)

Minimum possible x-value for coordinates NOT NULL Maximum possible x-value for coordinates NOT NULL

MIN_Y

FLOAT(126)

Minimum possible y-value for coordinates NOT NULL

MAX_Y

FLOAT(126)

Maximum possible y-value for coordinates NOT NULL

MIN_Z

FLOAT(126)

Minimum possible z-value for coordinates

MAX_Z

FLOAT(126)

Maximum possible z-value for coordinates

MIN_M

FLOAT(126)

Minimum possible m-value for measures

MAX_M

FLOAT(126)

Maximum possible m-value for measures

CS_ID

NUMBER(38)

Foreign key to the ST_Coordinate_Systems table

CS_NAME

NVARCHAR2(128) Name of the coordinate system for this spatial reference system

CS_TYPE

NVARCHAR2(128) Type of coordinate system: PROJECTED, GEOGRAPHIC, or UNSPECIFIED

NOT NULL NOT NULL ORGANIZATION

NVARCHAR2(128) Name of the organization that defined the coordinate system

ORG_COORDSYS_ID NUMBER(38) DEFINITION

Coordinate system ID defined by the organization

VARCHAR2(2048) Well-known text description of the coordinate system NOT NULL

DESCRIPTION

NVARCHAR2(256) Description for the spatial reference system indicating its application

TABLE_LOCKS The TABLE_LOCKS table maintains the locks on ArcSDE registered tables. Field name

Field type

Description

SDE_ID

NUMBER(38) Process identification number of the process that locked the table; references SDE_ID column in PROCESS_INFORMATION table NOT NULL

REGISTRATION_ID NUMBER(38) Foreign key to registration_id field in the TABLE_REGISTRY table NOT NULL LOCK_TYPE

NCHAR(1)

The type of table lock, which includes "S" for shared "E" for exclusive NOT NULL

TABLE_REGISTRY The TABLE_REGISTRY table manages all registered tables. The values include an ID, table name, owner, and description. Field name

Field type

Description

REGISTRATION_ID

NUMBER(38)

Unique identifier for the registration of the table Primary key NOT NULL

329

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

TABLE_NAME

NVARCHAR2(160) Name of the table NOT NULL

OWNER

NVARCHAR2(32) User who created the table

ROWID_COLUMN

NVARCHAR2(32) Name of the objectID column in the table

DESCRIPTION

NVARCHAR2(65) The text description of the table

OBJECT_FLAGS

NUMBER(38)

NOT NULL

Stores the registration properties of the table, which include ◦ The table has a registered row ID. ◦ SDE controls the row ID. ◦ The table has a geometry column. ◦ The table is a multiversioned view. ◦ The table can be row locked. ◦ The table has a raster column. ◦ The table is a view of another table. ◦ The table has a geocoding locator column. ◦ Data definition language operations are restricted. ◦ Data manipulation language operations are restricted. ◦ The table is hidden. ◦ The table has single row IDs. ◦ The table has an XML column. ◦ The table has a layer that stores double coordinates. ◦ The interior states of this versioned table can be edited. ◦ This is a base save table. ◦ This table has trusted shapes. ◦ This is an archiving table. ◦ This table is in load onlly I/O mode. ◦ This is a history table. NOT NULL

REGISTRATION_DATE NUMBER(38)

The date the table was registered NOT NULL

CONFIG_KEYWORD

NVARCHAR2(32) Configuration keyword with which the table was created

MINIMUM_ID

NUMBER(38)

IMV_VIEW_NAME

NVARCHAR2(32) The name of a multiversioned view of the given table

The minimum row_id value of the table

VERSION The VERSION table maintains information about the version of ArcSDE with which the database expects to operate. The table contains the specific release identification for the most recently installed version of ArcSDE. The VERSION table and other ArcSDE system tables are updated after a new version of ArcSDE is installed. Field name

Field type

Description

MAJOR

NUMBER(38)

Number of the major release; for example, for ArcSDE 9.1, the major release number would be 9.

MINOR

NUMBER(38)

NOT NULL. Number indicating the version of the major release; for example, for ArcSDE 9.1, the minor release number would be 1. NOT NULL.

330

Administering ArcSDE® for Oracle®

ArcSDE geodatabase system tables

Field name

Field type

Description

BUGFIX

NUMBER(38)

Number of the patch or service pack installed. NOT NULL.

DESCRIPTION

NVARCHAR2(96) Description of the ArcSDE installation.

RELEASE

NUMBER(38)

NOT NULL. Complete release number; for example, 92009. NOT NULL. SDE_SVR_REL_LOW NUMBER(38)

Indicates the lowest release number of server allowed to run on this instance. NOT NULL.

VERSIONS The VERSIONS table contains information about versioned geodatabases. Field name

Field type

Description

NAME

NVARCHAR2(64) The unique name of the version NOT NULL

OWNER

NVARCHAR2(32) The version owner NOT NULL

VERSION_ID

NUMBER(38)

The unique ID of the version NOT NULL

STATUS

NUMBER(38)

Specifies whether the version is available to the public or if it is privately accessed by the owner NOT NULL

STATE_ID

NUMBER(38)

The ID of the database state to which this version points NOT NULL

DESCRIPTION

NVARCHAR2(65) An optional text description of the version

PARENT_NAME

NVARCHAR2(64) The name of this version's parent version

PARENT_OWNER

NVARCHAR2(32) The name of the owner of the parent version

PARENT_VERSION_ID NUMBER(38)

The ID of the version which is the parent of this version

CREATION_TIME

The date/time that this version was created

DATE

NOT NULL

331