非常に遅いArcSDE 10.1データ表示の回避策はありますか

8

ArcgisエンジンアプリケーションからのデータとArcSDEデータベースの表示が非常に遅いので、SDEデータベースはローカルホストにあるため、ネットワークの問題はありません。しかし、私はまだこの問題を解決する方法も理由もわかりません。

2 CPUのXeon 3.4 GHzと2 GbのRAMを搭載した64ビットマシンで作業しています。

データベースには20のフィーチャクラスが含まれていますが、一部のフィーチャクラスではフィーチャの最大数が100 000を超えていません。データの表示を待つ場合、10分間待つ必要があります。

データベースのインデックスを圧縮して再構築しようとしましたが、改善はまったくありません。

ArcMapからデータを表示しようとしましたが、同じ問題が見つかりました。

パフォーマンスモニターを使用して、CPUとネットワーク側のいくつかのボトルネックを指摘しました。

SDEINTERCEPTの詳細：

@travisアドバイスを試したので、Arcmapを使用してsdeでmxd参照データを開き、この部分に7分かかると述べました。

[W 10:34:37.710] Command:      QueryWithInfo
[R 10:34:37.710] Long:         1
[R 10:34:37.710] Query Info: 
    Num Columns:   1
    Columns:       "shape"
    SQL_Construct: [1]
    Tables:        "gebase.sde.point"
    WhereClause:   "type_point_id<3"
    Query Type:    4
    Num Hints:     0
    Num Parameter markers: 0
    Logfile:       <null>
[W 10:34:37.718] Long:         0
[W 10:34:37.718] Col_Defines:  [1]
    Name                                 Type    Width nDec  NULL?   RowID
    -------------------------------- ----------- ----- ---- -------- -----
    shape                            SE_SHAPE        0   0      NULL      
    -------------------------------- ----------- ----- ---- -------- -----
[W 10:34:37.718] Long:         71303299
[W 10:34:37.718] Long:         0
[W 10:34:37.718] CoordRef:
    XY False Origin:       -37644800,, -28128500,
    XY System Units:       10000,
    XY Half SysUnit:       0,00005
    XY Round:              0,0001
    XY Cluster Tolerance:  0,001
    Z  Offset:             -100000,000000
    Z  Units:              10000,000000
    Z  Half SysUnit:       0,000050000
    Z  Round:              0,000100000
    Z  Cluster Tolerance:  0,001
    Measure Offset:        -100000,000000
    Measure Units:         10000,000000
    Measure Half SysUnit:  0,000050000
    Measure Round:         0,000100000
    Measure Cluster Tol:   0,001
    Coordinate System ID:  0
    Coordinate System:     "PROJCS["Nord_Maroc_Degree",GEOGCS["GCS_Merchich_Degree",DATUM["D_Merchich",SPHEROID["Clarke_1880_IGN",6378249.2,293.46602]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",300000.0],PARAMETER["Central_Meridian",-5.4],PARAMETER["Standard_Parallel_1",33.3],PARAMETER["Scale_Factor",0.999625769],PARAMETER["Latitude_Of_Origin",33.3],UNIT["Meter",1.0]]"
    Spatial Reference ID:  102191
    Precision              High [64]
========================================
[W 10:34:37.719] Command:      SetSpatialConstraints
[R 10:34:37.719] Long:         1
[R 10:34:37.719] Short:        2
[R 10:34:37.719] Long:         0
[R 10:34:37.720] Filter Array: [1]
    Table:        gebase.sde.point
    Column:       shape
    SearchMethod: SM_ENVP
    Truth:        Must Pass
    FilterType:   SE_SHAPE_FILTER
          FilterShape:
          XY False Origin:       -37644800,, -28128500,
          XY System Units:       10000,
          XY Half SysUnit:       0,00005
          XY Round:              0,0001
          XY Cluster Tolerance:  0,001
          Z  Offset:             -100000,000000
          Z  Units:              10000,000000
          Z  Half SysUnit:       0,000050000
          Z  Round:              0,000100000
          Z  Cluster Tolerance:  0,001
          Measure Offset:        -100000,000000
          Measure Units:         10000,000000
          Measure Half SysUnit:  0,000050000
          Measure Round:         0,000100000
          Measure Cluster Tol:   0,001
          Coordinate System ID:  0
          Coordinate System:     "PROJCS["Nord_Maroc_Degree",GEOGCS["GCS_Merchich_Degree",DATUM["D_Merchich",SPHEROID["Clarke_1880_IGN",6378249.2,293.46602]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",300000.0],PARAMETER["Central_Meridian",-5.4],PARAMETER["Standard_Parallel_1",33.3],PARAMETER["Scale_Factor",0.999625769],PARAMETER["Latitude_Of_Origin",33.3],UNIT["Meter",1.0]]"
          Spatial Reference ID:  102191
          Precision              High [64]
          Feature Number:        0
          Feature Entity Type:   Area        
          Number of Points:      5
          Feature Envelope:
            MinX:    328133,48150, MaxX:    384094,63650
            MinY:    133834,78230, MaxY:    159869,12210
          Polygon Perimeter:        163990,98960
          Polygon Area:          1456911724,87047
---------------------------------------------------------------
Point          X                Y               2D Distance 
---------------------------------------------------------------
    1     328133,48150     133834,78230
    2     384094,63650     133834,78230        55961,155
    3     384094,63650     159869,12210        26034,340
    4     328133,48150     159869,12210        55961,155
    5     328133,48150     133834,78230        26034,340

[W 10:34:37.721] Long:         0
========================================
[W 10:34:37.721] Command:      ExecuteSpatialQuery
[R 10:34:37.721] Long:         1
[W 10:34:37.727] Long:         0
========================================
[W 10:41:17.554] Command:      NextBuffer
[R 10:41:17.554] Long:         1
[W 10:41:17.554] Long:         0
[R 10:41:17.554] Long:         16416
[W 10:41:17.554] Long:         456
[W 10:41:17.554] Short:        -1
[W 10:41:17.554] Long:         0
[W 10:41:17.554] Long:         0
[W 10:41:17.554] Block:
    BufferInfo: [25/16416]  Address@0x26fb0000 
    BufferInHex:    "02008A850100010000000100140000000C0000000100000082..."

ExecuteSpatialQuery7分かかるのに何が遅いのでしょうか？

問題の説明をいたします。

助けてください。

arcgis-10.1  postgresql  enterprise-geodatabase  arcgis-engine  performance 
— Geogeek
ソース
1
システムアーキテクチャ、編集ワークフロー、データ特性、および問題を診断して解決するためにすでに実行した手順を詳しく説明すると、応答が得られる可能性が高くなると思います。あいまいな質問をすると、おそらくあいまいな回答が得られるか、まったく得られないでしょう。
— blah238 2013
詳細を含む編集を行いました
— geogeek 2013
2
「ArcMapと比較して、非常に高速に実行する必要がある」とはどういう意味ですか？あなたが与える時間は遅く聞こえます。データベースサーバーで他のものが実行されている場合は、そこで問題が発生する可能性があります。通常、開始編集/停止編集はそれほど頻繁に呼び出されません-通常、それらの間に挿入カーソルを使用する（または更新や削除など）と言います。featureclass.create（）は超高速の呼び出しではないと私は思います。ラベリングを使用して20のレイヤーを更新する場合、更新が完全に不合理に聞こえることはありません。
— awesomo 2013
一度に複数のフィーチャクラスを表示しようとしている場合、そのうちのいくつかには100 000レコードが含まれていますが、もちろん時間がかかります。このデータ量では、10秒が非常に妥当です。
— Devdatta Tengshe 2013年
1
時間のかかる操作を正確に知りたい場合は、DBMSトレースまたはSDEインターセプト（support.esri.com/en/knowledgebase/techarticles/detail/35704）を実行してみてください。何がいつもかかっているのかがわかれば、それを解決するための具体的な助けが得られるかもしれません。
— トラビス2013年

回答:

6

ラベリング、レイヤースケールレンダリング、透明度などの一般的なパフォーマンスの問題があると思います。ArcGIS for Serverライセンスをお持ちの場合は、サービスエディターの[分析]ボタンを使用して、これらのパフォーマンス警告についてマップドキュメントをテストすることができます。

Service Editorは、対処する必要がある潜在的なパフォーマンスのボトルネックとエラーを特定するのに役立ちます

GISリソースの分析

次に、固定マップドキュメントレイヤー構成をモデル化して、ArcEngineアプリ内で使用し、パフォーマンスを向上させることができます。

— アートワーク21
ソース
0

ArcSDEのパフォーマンスが非常に遅い原因を発見しました。いくつかのArcpadチェックアウトチェックイン操作とXMLへのワークスペースのエクスポートが原因でデータベースが古くなっているようです。これはビッグデータが原因ではありません。

そこで、新しいジオデータベースを作成してXML_workspaceをインポートしました。これは、古いデータベースと比較して高速に実行されます。したがって、すべてのフィーチャクラスを削除してXML_workspaceをインポートしても、データベースは更新されないようです。

データベースを更新する方法はありますか？

ダーティな方法とは別に、データベースを削除し、新しいジオデータベースを作成してから、XML_workspaceをインポートします。

— Geogeek
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.