Oracle LocatorとOracle Spatial 11gのベスト・プラクティス

Transcription

1 Oracle テクニカル ホワイト ペーパー 2008 年 8 月

2 はじめに... 3 一般的なベスト プラクティス... 4 Oracle パッチ セット... 4 データ モデリング... 4 メタデータ トレランス 座標系... 4 空間データと空間索引を備えたトランスポータブル表領域... 6 データのロード... 6 SDO_GEOMETRY オブジェクトの SDO_POINT 属性内のポイント データ... 6 ジオメトリの検証... 7 空間索引の作成... 8 ローカル パーティション空間索引... 9 空間問合せ... 9 アプリケーションの考慮事項 ESRI ARCGIS でのベスト プラクティス DBTUNE ファイル D データの重要な注意点 ESRI クライアント ツールを使用した空間索引の作成 ArcSDE の主キー ESRI クライアント ツールで作成されていない空間レイヤーの登録 14 ArcSDE からのレイヤーの登録解除 ESRI クライアント ツールのパフォーマンス

3 はじめに このテクニカル ホワイト ペーパーでは Oracle Databaseのベクトル データを格納するためのネイティブ データ型であるSDO_GEOMETRYを使用したOracle LocatorとOracle Spatialのベスト プラクティスについて説明します また Oracle LocatorとOracle SpatialでESRI ArcGISソフトウェアを実行するためのガイダンスを示します Oracle Spatial は Oracle Locator を拡張したものです Oracle Locator は すべての Oracle データベースに含まれる ロケーション機能のコアに相当します そのため Oracle Locator と Oracle Spatial の両方に該当するベスト プラクティスを説明する際は このドキュメントでは Oracle Locator と記載します Oracle Spatial だけに該当する場合は Oracle Spatial と記載します このホワイト ペーパーでは Oracle Spatial テクノロジーを使用するアプリケーションの設計と開発に役立つベスト プラクティスとヒントに重点を置いて説明します 記載されている多くの推奨事項は Oracle Locator だけに当てはまるものではなく 顧客はそれぞれの環境で既存の Oracle Database に関する知識を活用できます GIS ロケーション ツール およびアプリケーションによってサポートされている標準としてのOracle Locator: すべての主要なGISおよびロケーション サービス テクノロジー ベンダー マッピングおよび画像データ プロバイダは Oracle Locatorを直接統合しています 各ベンダーやプロバイダは 機能やパフォーマンスを落とすことなく OracleのネイティブSDO_GEOMETRYデータ型をサポートしています オラクルは OGC(Open Geospatial Consortium) とISO SQL/MM 標準で提唱されている 空間とロケーション サービス分野における最新のオープン標準の形成 促進 実施 支持に一貫して取り組んでいます Oracle LocatorとOracle Spatialは Oracle Databaseのネイティブ機能であり 空間データを含むすべてのデータにセキュリティ 高可用性 耐障害性 管理性 パフォーマンスを提供します オラクルのネイティブ空間データ型を使用しているユーザーだけが パーティション化 ローカル パーティション空間索引 空間索引のパーティション交換 空間データと空間索引に対するトランスポータブル表領域のサポート レプリケーション Workspace Manager( バージョニングと有効期間 ) 索引のパラレル作成と問合せ 空間主導マルチレベル セキュリティといった機能のすべての利点を最大限に活用できます これらの機能は LONG RAWまたはBLOBデータ型を使用すると 利用できない場合や機能が制限される場合があります Oracle DBA と開発者は それぞれ既存の Oracle Database に関する知識を活用でき 3

4 ます Oracle Spatialテクノロジーは この段落と前の段落に記載されているOracle Databaseの中核となるユーティリティと機能に統合されています つまり Oracle Databaseの知識があれば Oracle Locatorを知らなくても すでにこの機能の 80% 以上を理解していることになるのです 非空間データに使用されるのと同じOracle Databaseの中核ユーティリティ (impdp expdp import export sqlldr) は 空間データでも使用されます オラクルは 企業内において空間データをメインストリームに押し上げ 蓄積されたOracle Databaseの知識を最大限に活用することを可能とします 一般的なベスト プラクティス Oracle パッチ セット可能な場合は Oracle Database の最新のパッチ セットにアップグレードします これにより Oracle Spatial の最新機能を利用することが可能となり 最適化されたパフォーマンスを得ることができます データ モデリング空間データを扱う際には 従来のRDBMSデータ モデルの概念を適用できます Oracle Databaseは 文字のVARCHAR2 型 日付のDATE 型 数値のNUMBER 型 空間的特徴の座標を格納するためのSDO_GEOMETRYデータ型を含む 多くのデータ型をサポートしています Oracle Databaseには空間データに特化した特別な表は存在せず 通常のOracle Database 表に 1 つまたは複数のSDO_GEOMETRY 列を設定するだけです 表を正規化する場合は 表にSDO_GEOMETRY 列を含め その表のほかのすべての列に SDO_GEOMETRY 列と 1 対 1 の関係をもたせることを推奨します 次に 道と川の空間的特徴をモデリングする例について考えます 道の情報には 車線の数や通りの住所の範囲などがあります 川の情報には 塩度や最大深度などがあります これらはいずれも線形の特徴ですが 道の情報には川との関連性がなく 川の情報には道との関連性がないので これらの座標を 1 つの表の同じ SDO_GEOMETRY 列に格納することは推奨できません 正規化データ モデルでは 道の空間的特徴をRoad 表に格納し そのほかの列には 道の座標との 1 対 1 の関係をもたせます Rivers 表にも同様の正規化データ モデルを使用することを推奨します 道の情報を川の情報と別に格納すると 問合せの実行時にその利点がより明白になります 道の情報だけを検索している場合 道と川の両方のエントリを含む表を参照する必要はありません メタデータ トレランス 座標系表内の各 SDO_GEOMETRY 列は Oracle Locatorメタデータ ディクショナリ (USER_SDO_GEOM_METADATA) 内のエントリを必要とします このメタデータには次の情報が含まれます SDO_GEOMETRY 型の列を含む表の名前 SDO_GEOMETRY データ型で定義されている列の名前 4

5 SDO_GEOMETRY 列の軸 ( ディメンション ) 数 各軸の下限と上限 各軸のトレランス値 ( 通常は すべての軸に同じ値を指定 ) 空間参照識別子 (SRID) 各軸の下限と上限は SDO_GEOMETRY 列内のデータの最小外接矩形 (MBR: Minimum Bounding Rectangle) ではありません 軸の境界は 現在と将来のジオメトリのすべてを含められる値にする必要があります 最初に定義する軸は常にX で 2 番目の軸はYです オプションで Z 軸とメジャー軸を定義することもできます 測地データ ( 経度 / 緯度のデータ ) を扱う場合 最初の軸は ( ) の範囲で 2 番目の軸は (-90 90) の範囲でそれぞれ定義する必要があります 一般的に X 軸と Y 軸のトレランスは同じです トレランスは 2 つの座標が異なる点であると見なされるための距離です Oracle のジオメトリ検証ルーチン 空間演算子 空間関数は すべてトレランスを使用します そのため トレランスの定義は重要です トレンラスは データが収集される際の解像度を反映したものになります 経度 / 緯度ではないデータを格納する場合 トレランス単位は空間データに関連づけられている座標系単位と同じです 経度 / 緯度データを格納する場合 トレランス単位はメートルです Oracle Locatorでサポートされているすべての座標系は MDSYS.CS_SRSと呼ばれるディクショナリ表に定義されています さらに Oracle Database 10g Release 2 では 欧州石油調査グループ (EPSG: European Petroleum Survey Group) 標準の座標系を表すデータ モデルが導入されています EPSGで定義されている各座標系には MDSYS.CS_SRS 内に対応するエントリがあります Oracle Locator には 事前設定済みの 1,000 を超える座標系があります 事前設定済みの座標系は 多くのユーザーの要件を満たすものです 自分のニーズに合う事前設定済みの座標系がない場合は 独自のカスタム座標系を追加できます Oracle Database 10g Release 2 以降 カスタム座標系は Oracle Databaseで定義した EPSGデータ モデルを使用して入力する必要があります 各カスタムEPSGエントリは MDSYS.CS_SRS 表に自動的にエントリを生成します カスタム座標系を追加する方法については Oracle Spatial ユーザーズ ガイドおよびリファレンス を参照してください MDSYS.CS_SRSディクショナリでは SRIDと呼ばれる数値の主キーによって サポートされている各座標系が識別されます ディクショナリ表には OGC(Open GIS Consortium) によって定義されているWKT(Well Known Text) 文法で記述された各座標系の定義も含まれています 空間データと座標系の関連付けは 空間データとSRID 値の関連付けと同様に簡単なものです 空間データは SRID と関連づけることを推奨します とくに データが地理的 つまり地球と関連している場合に推奨されます 地理的データは 測地 ( 経度 / 緯度データ ) と投影 ( 非経度 / 緯度データ ) の 2 つのカテゴリに分類できます Oracle Database では 測地 SRID で定義された連続するジオメトリの座標間の測地距離が考慮されます 5

6 空間データと空間索引を備えたトランスポータブル表領域 1 つのデータベース インスタンスからほかのインスタンスへ 大量の空間データと空間索引を移動する場合 トランスポータブル表領域の使用を検討することを推奨します Oracle Database 10g 以降 トランスポータブル表領域による空間索引の転送がサポートされています ( ただし ソース プラットフォームとターゲット プラットフォームが同じエンディアンである必要があります ) 空間索引ではなく空間データだけを転送する場合は ソース プラットフォームとターゲット プラットフォームが同じエンディアンである必要はありません 表領域の転送を計画する際 表領域へのデータと索引のマップ方法を再検討すると 転送戦略の最適化に役立ちます データのロードバルク ロードは 従来の Oracle Database のユーティリティである sqlldr imp impdp などを使用して実行できます バルク アンロードは Oracle Database のエクスポート ユーティリティである exp expdp などを使用して実行できます これらのユーティリティでは 空間データに固有の構文を使用する必要はありません 非空間データで推奨されているように 大量のバルク ロードまたはバルク アンロードを実行する場合は 索引 ( 存在する場合は空間索引も含む ) を削除してから バルク トランザクションを実行し トランザクション完了後に索引を再作成することを推奨します バルク ロードまたはバルク アンロード前に索引を削除しない場合 トランザクションの実行中も索引は維持されます SQL*Loaderは 空間データをロードすることはできますが ESRIシェイプファイル MapInfo Tabファイル Autodesk DWGファイル Microstation DGNファイルといったGIS(Geographic Information System) ベンダー交換形式を認識しません 主要な各 GISベンダーには それぞれの交換形式をOracleのSDO_GEOMETRY 形式にインポートする独自のツールがあります 多数のベンダーの形式をSDO_GEOMETRYデータ型にロードできる Safe SoftwareのFME(Feature Manipulation Engine) のような一般的な変換をサポートする製品もあります FMEを使用すると Oracleの SDO_GEOMETRYデータ型に格納されているデータを抽出して FMEがサポートしている任意のGISベンダーの形式に変換することもできます ESRIシェイプファイルは 非常に一般的な交換形式であるため オラクルはシェイプファイルをロードするための無料 JavaユーティリティをOracle Technology Network に掲示しています このユーティリティは 次のURLからダウンロードできます このユーティリティは優れたツールであり 広範囲にわたってテスト済みです このユーティリティは シェイプファイル ジオメトリとそれらの属性を読み取り レコードを Oracle 表にロード ( または追加 ) します SDO_GEOMETRY オブジェクトの SDO_POINT 属性内のポイント データ 可能な場合は SDO_ORDINATE 属性の代わりに SDO_GEOMETRYオブジェクトの SDO_POINT 属性にポイント データを格納します 6

7 ジオメトリの検証空間分析をおこなう際に正確な結果を得るには 空間データが有効である必要があります SDO_GEOMETRY 列に空間索引がつけられている場合 空間データがその列に挿入される際にいくつかのチェックがおこなわれます ただし 完全な検証は SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXTプロシージャまたは SDO_GEOM.VALIDATE_LAYER_WITH_CONTEXTプロシージャのいずれかを実行した場合にのみおこなわれます データのロード前にデータの有効性が確認された場合 検証の必要はありません それ以外の場合は 検証をおこなうことを強く推奨します 無効なジオメトリは 修正または削除する必要があります SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXTとSDO_GEOM.VALIDATE_ LAYER_WITH_CONTEXTでは Simple Feature Specification for SQLに基づき OGC (Open GIS Consortium) によって定義されたルールに従いジオメトリが検証されます 無効なジオメトリ ( 自己交差ポリゴンなど ) が報告されると 交差しているエッジなどの追加のコンテキスト情報も報告されます 追加のコンテキスト情報は 無効なジオメトリの修正にたいへん役立ちます 一般的な検証エラーの一部は次のとおりです 報告されたエラー ORA ジオメトリ内の隣接する繰返しポイントが冗長である ORA ポリゴンの境界自体が交差している ORA 内部 / 外部リングのローテーションが不正である 考えられる原因と修正アクショントレランスの設定が粗すぎる可能性があります トレランスの設定を細かくするとエラーを修正できます ポイントが実際に繰り返されている可能性があります 重複する頂点を削除してください トレランスの設定が粗すぎる可能性があります トレランスの設定を細かくするとエラーを修正できます ポリゴン自体が実際に交差しています 交差するエッジをなくして ポリゴンを修正してください ポリゴン リングのローテーションを修正してください 外部リングは反時計回りに 内部リングは時計回りにする必要があります 検証ルーチンによって報告される追加のコンテキスト情報は 以下のルーチンに提供することで 無効なジオメトリを修正することができます SDO_UTIL.REMOVE_DUPLICATE_VERTICIES SDO_UTIL.EXTRACT SDO_UTIL パッケージには 以下のようなジオメトリの点検に役立つユーティリティが含まれています 7

8 SDO_UTIL.GETNUMELEM - ジオメトリ内の要素の数を返します SDO_UTIL.GETNUMVERTICES - ジオメトリ内の頂点の数を返します SDO_UTIL.GETNUMRINGS - ジオメトリ内のリングの数を返します 追加のユーティリティについては ドキュメントを参照してください 空間索引の作成 空間索引を作成する際には 以下のパラメータを指定することを推奨します WORK_TABLESPACE - 空間索引の作成時に このプロセスは 索引が完成すると削除される中間表を作成します 中間表は 最終的な索引のサイズの最大 2 倍のスペースを使用します WORK_TABLESPACE を指定しないと 中間表は最終的な索引と同じ表領域に作成され 断片化が発生し パフォーマンスが低下する場合があります SDO_TUNE.ESTIMATE_RTREE_INDEX_SIZE を使用して 得られた結果を 2 倍し 作業表領域のサイズに関するガイダンスを提供できます 作業表領域は ほかの空間索引を作成するために再使用できます LAYER_GTYPE - このパラメータは とくにポイントのみのレイヤーで作業する場合に指定する必要があります ポイントのみのレイヤーがそのポイントをSDO_ORDINATE_ARRAYに格納する場合でも 空間索引の作成時にLAYER_GTYPE=POINTを指定できます これにより 空間分析実行時の問合せのパフォーマンスが向上します SDO_NON_LEAF_TBL - このパラメータは 大きな空間索引に対して指定すると効果的です ( 小さな空間索引には必要ありません ) このパラメータは 1 つではなく 2 つの空間索引を生成します 小さな空間索引表は 非リーフ表で 空間分析中にもっとも頻繁に横断されます 非リーフ表は もっとも頻繁にアクセスされるので バッファ プールに固定するとパフォーマンスは向上します 以下の例を参照してください -- 索引の作成 CREATE INDEX geod_counties_sidx ON geod_counties(geom) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS ('sdo_non_leaf_tbl=true'); -- 非リーフ索引表名の検索 SELECT sdo_nl_index_table FROM user_sdo_index_metadata WHERE sdo_index_name='geod_counties_sidx'; MDNT_A930$ -- メモリに表を固定 ALTER TABLE MDNT_A930$ STORAGE(BUFFER_POOL KEEP); 8

9 ローカル パーティション空間索引 パーティション化された表にローカル パーティション空間索引をパラレル作成する際には 次のアプローチを使用することを推奨します このアプローチでは いずれかの ALTER INDEX コマンドが失敗しても すでに正常に作成されているローカル パーティション索引を再構築する必要はありません UNUSABLE キーワードを指定して ローカル パーティション空間索引を作成します この処理は非常に速く 索引に関連づけられているメタデータのみが作成されます CREATE INDEX sp_idx ON my_table (location) INDEXTYPE IS mdsys.spatial_index PARAMETERS ( tablesapce=tb_name work_tablespace=work_tb_name ) LOCAL UNSUABLE; 個々のスクリプトを作成します 仮に 100 個のパーティションと 10 個のプロセッサがある場合は それぞれの 10 個の ALTER INDEX REBUILD 文があるスクリプトを 10 個作成します ただし PARALLEL パラメータは使用しません 次に例を示します ALTER INDEX sp_idx REBUILD PARITION ip1; ALTER INDEX sp_idx REBUILD PARITION ip2; など 10 個のスクリプトをすべて同時に実行します 各プロセッサは 単一の索引パーティションを処理しますが すべてのプロセッサは それぞれの ALTER INDEX 文の一連の処理も引き続きおこないます 注 : パーティション化された表に空間索引をパラレル作成する際 PARALLEL キーワードを使用することは推奨できません これは ローカル パーティション空間索引を作成する場合に ( 表領域が一杯 またはそのほかの理由により ) いずれかの索引パーティションの作成に失敗すると 最初からやり直す必要があるためです ( 失敗した時点から続行することはできません ) 空間問合せ Oracle Locator と Oracle Spatial には 一連の空間演算子と関数が含まれています 空間演算子と関数のいずれでも空間分析を実行できます 違いは 演算子は空間索引を活用しますが 関数は活用しない点にあります 演算子には以下が含まれます SDO_FILTER (search_column, window) SDO_RELATE (search_column, window, operator specific parameters ) SDO_ANYINTERACT (search_colunn, window) SDO_INSIDE (search_column, window) 9

10 SDO_WITHIN_DISTANCE (search_column, window, operator specific parameters ) SDO_NN (search_column, window, operator specific parameters ) その以外の多くの演算子については ドキュメントを参照してください 関数には以下が含まれます SDO_GEOM.SDO_AREA SDO_GEOM.SDO_LENGTH SDO_CS.TRANSFORM SDO_LRS.PROJECT_PT それ以外の多くの関数については ドキュメントを参照してください 空間演算子はすべて 同様のパラメータをもっています 空間演算子の 1 番目の引数は 常に検索される列であり 空間索引が作成されている必要があります 2 番目の引数は常に問合せウィンドウまたは影響範囲です 3 番目の引数 ( ある場合 ) は その演算子に固有のパラメータのリストを含む文字列です 空間演算子を含む SQL 文を記述する際には オプティマイザによる よりよい実行計画の選択に役立つ Oracle のヒントが表示されます Oracle のヒントは Oracle Locator に固有のものではなく 空間演算子を含まない SQL 文の実行計画を向上できるものであり 空間演算子を含む SQL 文の実行計画にも役立ちます 最適な実行計画を得るには 表の問合せウィンドウ ( 空間演算子の 2 番目の引数 ) が表示されたときに常に /*+ ordered */ ヒントを指定します たとえば 次の問合せは 5 マイル以内の汚染された鉱泉にあり ID 値が 1 と 2 であるすべての化学プラントを検索します SELECT /*+ ORDERED */ b.chemical_plant_name FROM well_table a, chemical_plants b WHERE sdo_within_distance (b.geom, a.geom, 'distance=5 unit=mile') = TRUE AND a.id in (1,2); この例では 鉱泉の位置 ( 鉱泉 ID 1 および 2) が well_tableの演算子の 2 番目の引数に渡されます これは /*+ ordered */ ヒントを指定する必要がある典型的な例です orderedヒントを指定する場合は FROM 句へ処理順に表名を記入します 空間演算子の 2 番目の引数を提供する表は FROM 句内で検索列を含む表の前に記載する必要があります この例では well_tableは FROM 句のchemical_ plantsの前に記載されています 10

11 空間演算子は 演算子 ( 検索列 ) の最初の引数に関連づけられている表から行を除外することで 結果の候補を絞り込みます 問合せの結果が空間演算子によって絞り込まれ 空間演算子の最初の引数を提供する同じ表のほかに索引づけされた列が WHERE 句に表示される場合は no_index ヒントの使用を推奨します これは そのほかの索引づけされた列があまり選択的ではない場合にとくに役立ちます たとえば 化学プラントの問合せが 5 マイル以内の汚染された鉱泉にあり ID 値が 1 と 2 の " クロムを処理する " すべての化学プラントを返すように変更され chemical_plants 表に "T" または "F"(true または false) の値が設定された processes_ chromium という列があるとします この場合 processes_chromium 列にビットマップ索引があるとしても 問合せに使用する索引としてはあまりよい選択とはいえません processes_chromium 索引に no_index ヒントを提供することで Oracle Optimizer によって選択的な空間索引と 非選択的で非空間的索引がマージするのを回避できます SELECT /*+ ORDERED NO_INDEX (b processes_chromium_index_name) */ b.chemical_plant_name FROM well_table a, chemical_plants b WHERE sdo_within_distance (b.geom, a.geom, 'distance=5 unit=mile') = 'TRUE' AND a.id in (1,2) AND processes_chromium = 'T'; オラクルは コストベースの最適化 表と索引に関する統計情報の収集をおこなうことを推奨します 統計情報は 以下のプロシージャを実行して収集できます DBMS_STATS.GATHER_TABLE_STATISTICS DBMS_STATS.GATHER_SCHEMA_STATISTICS SDO_GEOMETRYデータ型を含む表は その表に関する統計情報を収集することで利点を得ることができますが CREATE INDEXコマンドによって暗黙的に作成された空間索引表に関する統計情報の収集は必須ではありません アプリケーションの考慮事項可視化がアプリケーションの主要部分である場合は この項の内容を参考にしてください ディスプレイが遠くにズームアウトされている場合 詳細なレイヤーを有効にするのはよい方法ではありません たとえば 米国全体を表示するようにディスプレイがズームアウトされている場合 細かい通りの表示を有効にしても表示上のメリットはありません このようなズーム レベルでは 細かい通りは画面上に黒い点として表示されます 通りの表示を有効にするのは 東西 1 キロの地域をズームインして表示するような場合に現実的となります 11

12 別の例を示します 非常に詳細なポリゴン領域 ( 各ポリゴンに約 300 頂点 ) をもつレイヤーがあるとします 遠くにズームアウトされている場合 このような詳細なポリゴンを表示しても意味がありません このようなポリゴンの多くの座標は ごくわずかなピクセルとして表示されてしまうため ポリゴンの詳細はわかりません より現実的なシナリオは 適度な範囲にズームインされているときにズーム コントロールを使用して 詳細なポリゴンの表示を有効にすることです 別の現実的なアプローチは 汎用レイヤー ( 詳細なポリゴンの汎用バージョン ) を作成することです 汎用レイヤーは 遠くにズームアウトされているときに表示され 詳細なレイヤーは より近くにズームインされているときに表示されます ズーム コントロールと汎用レイヤーの使用は 表示アプリケーションではよく知られている概念です ズーム コントロールと汎用レイヤーを正しく使用することで パフォーマンスをさらに向上できます 詳細な各ジオメトリの座標の大部分は ごくわずかなピクセルとして表示されてしまうので サーバーから詳細なジオメトリを不必要にフェッチすることは とくに避ける必要があります ESRI ARCGIS でのベスト プラクティス ESRI は ESRI とオラクルの ( 共通の ) 数千の顧客に対して Oracle Database を 12 年以上サポートしてきています ESRI は 1995 年以来 すべての Oracle Database リリースのベータ サイトとなっています ESRIのGeodatabaseは Oracle LocatorとOracle Spatialを完全にサポートしており ArcGISの機能と実環境のアプリケーションで必要とされるパフォーマンスを備えています 膨大な相互の顧客ベースが このことを実証しています パフォーマンスは GITA(Geospatial Information Technology Association) の 2008 年度のGeospatial Infrastructure Solutions Conferenceにおいて Idea IntegrationのKevin S. Larson 氏が発表した論文 Spatial Database Speed Comparisons に数値で示されています この論文の目的は ESRI ArcGIS でもっとも優れたパフォーマンスを発揮するデータベースとデータ型を判定することにありました ESRI SDE on Oracle Database でサポートされているすべてのデータ型を使用して ESRI ArcGIS version 9.2 を Oracle Database でテストしています この調査では 異なる地理的領域とデータ規模に分布するさまざまな密度で ホット キャッシュとコールド キャッシュ 優れたポイントの表現 ラインとポリゴン データ 空間データをテストしています ジオメトリ データのみを伴う空間データだけの問合せや ジオメトリ データとリレーショナル データの両方を伴うビジネス問合せといった 2 つのセットの問合せのワークロードが実行されました この調査では Oracle LocatorとそのネイティブOracle SDO_GEOMETRYデータ型の組合せが ESRI ArcGIS on Oracle Databaseに対してもっとも一貫性があり スケーラブルなパフォーマンスを提供することがわかりました また 大きなデータ セット ( より小さなデータ規模 ) に対して大幅なパフォーマンスの向上を示し データ密度が少ない場合には事実上同じパフォーマンスを示しました SDO_GEOMETRYのパフォーマンス上の利点は 空間のみの問合せでより明白になります これらの結果は 顧客から報告された結果と一致しています 12

13 次は カスタマー エクスペリエンスによって確定された ESRI ArcGIS と Oracle Locator をチューニングするための具体的なベスト プラクティスをいくつか説明します DBTUNE ファイル以下は SDO_GEOMETRY 機能クラスに関連づけられているDBTUNEキーワードに追加するための推奨属性です 次に示す値は例です 属性値は 自分のSDO_GEOMETRY 機能クラスに適した値を設定する必要があります データにポイントごとの値 たとえば (x y) とメジャー (xyz) がある場合は DBTUNEキーワードにSDO_LB_3 属性 SDO_UB_3 属性 SDO_TOLERANCE_3 属性を必ず追加してください データにポイントごとに 4 つの数値 たとえば (x y z) とメジャーがある場合は DBTUNEキーワードにSDO_LB_4 属性 SDO_ UB_4 属性 SDO_TOLERANCE_4 属性を必ず追加してください 3D データの重要な注意点 データが 3Dの場合は ジオメトリを調べて Z 縦座標が常に 0 であるかどうかを確認します これは CADデータをSDO_GEOMETRYにロードするユーティリティを実行した結果として生じることがあります Z 縦座標が常に 0 の場合は ジオメトリからすべてのZ 縦座標を削除することを推奨します Z 縦座標を削除しない場合 3 分の 1 を超える必要以上のジオメトリ データがネットワーク上に転送されます つまり Z 縦座標の転送には その値が常に 0 の場合でも時間がかかります CADデータをSDO_GEOMETRYにロードするユーティリティには 通常 データを 2Dとしてアップロードするための設定フラグがあります SDO_INDEX_SHAPEでは ESRIクライアント ツールがSDO_GEOMETRY 機能クラスの空間索引を作成するシナリオのSDO_GEOMETRY CREATE INDEXパラメータを指定できます GEOMETRY_STORAGE "SDO_GEOMETRY" SDO_DIMNAME_1 "x" SDO_DIMNAME_2 "y" SDO_LB_ SDO_LB_ SDO_SRID 8307 SDO_TOLERANCE_ SDO_TOLERANCE_ SDO_UB_ SDO_UB_ SDO_VERIFY "FALSE" SDO_INDEX_SHAPE "tablespace=value WORK_TABLESPACE=value etc.." DBTUNEパラメータは データベースに格納されています 現在のDBTUNEファイルを抽出するには 次のコマンドを実行します これで dbtune_orig.outin SDEHOME etc dbtune.origというファイルが配置されます 13

14 sdedbtune -o export -f dbtune_orig.out -u sde -p sde_password copy dbtune_orig.out dbtune.out 上述のSDO_GEOMETRYに固有のDBTUNEパラメータをdbtune.outファイルに追加します 次に 新しいdbtune.outファイルをデータベースにロードします 次を参照してください sdedbtune -o import -f dbtune.out -u sde -p sde ESRI クライアント ツールを使用した空間索引の作成 索引作成のベスト プラクティスを参照してください ESRIクライアント ツールでデータをロードする場合 通常 オプションで空間索引を作成するかしないかを選択できます ESRIクライアント ツールで空間索引を作成する場合は このドキュメントのDBTUNEの項で説明してあるDBTUNE 属性を適切に設定してください とくに 空間索引の作成に関係する属性は重要です ArcSDE の主キー ArcSDE では 登録されているすべて表の NUMBER(38) 型として宣言されている数値列に一意な索引が必要となります ESRI クライアント ツールで作成されていない空間レイヤーの登録 以下は ESRI クライアント ツールと ArcSDE データ ディクショナリ表で作成していない空間レイヤーを登録するポイント ライン ポリゴンの例です ポイントの例 sdelayer -o register -l bts,shape -e p -C oid_,user -i esri_sde -u oracle_username -p oracle_password ラインの例 sdelayer -o register -l road_geo,shape -e sl+ - C objectid,user -i esri_sde -u oracle_username - p oracle_password ポリゴンの例 sdelayer -o register -l buildings,shape -e a+ - C objectid,user -i esri_sde -u oracle_username - p oracle_password ArcSDE からのレイヤーの登録解除 ESRIクライアント ツールでレイヤーを作成した場合 sdelayer -o deleteを指定すると 表が登録解除されて削除されます 14

15 ESRIクライアント ツールで表を作成していない場合 sdelayer -o deleteを指定すると レイヤーが登録解除され USER_SDO_GEOM_METADATA 内のエントリが削除されますが 表は削除されません 空間レイヤーを再登録する場合は USER_SDO_GEOM_METADATAを再移入する必要があります 次に ビルディング レイヤーの登録解除の例を示します sdelayer -o delete -l buildings,shape -i esri_sde -u oracle_username -p oracle_password ESRI クライアント ツールのパフォーマンス ESRIクライアント ツールのパフォーマンスに疑問を感じる場合は まず索引作成のベスト プラクティスを参照してください 次に ほかの視覚化ツールを使用してレンダリングをおこない ツールセット間で動作が一致しているかどうかを確認します ツール間でパフォーマンスの相違がある場合 このドキュメントのベスト プラクティスを参照して ESRI/SDO_GEOMETRY 環境を最適な状態にしてください では 空間索引をもつSDO_GEOMETRY 列における編集のパフォーマンスが大幅に向上しています これもテストする価値がある領域です 15

16 Oracle Locator と Oracle Spatial 11g のベスト プラクティス 2008 年 8 月 Oracle USA World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. 海外からのお問い合わせ窓口 : 電話 : ファクシミリ : Copyright 2008, Oracle. All rights reserved. 本文書は情報提供のみを目的として提供されており ここに記載される内容は予告なく変更されることがあります 本文書は一切間違いがないことを保証するものではなく さらに 口述による明示または法律による黙示を問わず 特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み いかなる他の保証や条件も提供するものではありません オラクル社は本文書に関するいかなる法的責任も明確に否認し 本文書によって直接的または間接的に確立される契約義務はないものとします 本文書はオラクル社の書面による許可を前もって得ることなく いかなる目的のためにも 電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません Oracle は米国 Oracle Corporation およびその子会社 関連会社の登録商標です その他の名称はそれぞれの会社の商標です