FAQ: How is the work of a spatial query shared between the client program, ArcSDE, and the RDBMS?


How is the work of a spatial query shared between the client program, ArcSDE, and the RDBMS?


There are three main participants in every spatial query: the client application, the ArcSDE gsrvr process, and the relational database management system (RDBMS).

The client application specifies the query to be performed. The gsrvr receives the query from the client and builds an appropriate query to the RDBMS. The RDBMS processes the query built by the gsrvr. The gsrvr completes the query by performing the remainder of the processing. The client program receives from the gsrvr only the features that satisfy the query.

How is the work of a spatial query shared between the gsrvr and the RDBMS?

With ArcSDE binary feature classes (ArcSDE for Oracle and SQL Server), calculations are done by the gsrvr to determine which spatial index grid cells should contain candidate features. This is based on figuring out which grid cells would be occupied by the filter shape if it were part of the feature class. Features that occupy grid cells in common with the filter shape are queried by the gsrvr and returned by the RDBMS as candidate features to gsrvr.

With Oracle Spatial, the RDBMS is passed a filter shape. The RDBMS performs an Oracle Spatial primary filter to return a set of candidate features from the feature class. The type of comparison performed depends on the type of spatial index used for that feature class. If a fixed (grid) spatial index is used, the primary filter is very much like the ArcSDE binary spatial index model. If r-tree spatial indexing is used, the minimum bounding rectangles (MBRs) are compared. Because MBRs are what the r-tree index is indexing, this comparison is very quick.

With ArcSDE for Oracle (including Oracle Spatial) and SQL Server, all further filtering to find the final set of spatially selected features is done by gsrvr. Oracle Spatial's secondary filter is not used.

With ArcSDE for Informix and DB2, the gsrvr's role in the spatial query is limited. The RDBMS does the basic spatial filtering, providing a final set of features to the gsrvr. The gsrvr process passes these features to the client application. In this case the gsrvr's main job is devising the SQL to send to the RDBMS.

With a two-tiered direct connect, the gsrvr resides with the client application. When a three-tiered connection is used, the gsrvr stays with the RDBMS unless you are using TWO_TASK. The TWO_TASK option allows the application server (giomgr and gsrvr) to run on a separate machine from the RDBMS. Regardless of where the gsrvr resides,the portion of the work that the gsrvr performs to support spatial queries depends on the RDBMS, not on the gsrvr’s location.

The giomgr listens for connection requests and spawns gsrvr tasks to handle those connections. If direct connect is used, the gsrvr residing with the client application communicates directly to the RDBMS, bypassing the giomgr altogether.