ArcSDE

0 голосов
спросил 19 Ноя, 04 от scorp (120 баллов) в категории Программные продукты Esri

Здраствуйте.

Я новичок в ArcSde помогите разобраться. РСУБД Oracle 8.1.7. У меня возникла проблема: данные, передаваемые пользователями из приложении ArcGis, медленно сохраняются на сервере или выходит ошибка : FDO error-2147216072.

Я примерно знаю, что при начале каждого сеанса редактирования создается временная таблица для "версии" или пр., как посмотреть размер таблиц/изменить?

Заранее спасибо!

7 Ответы

0 голосов
ответил 28 Ноя, 04 от Grigoriy (127,020 баллов)

Посмотрите ERROR!!!!!!!!!!!!!!!!!!!!!!!!!!!! help! там описывается ошибка под SQL, но рекомендации общие для редактирования в SDE

0 голосов
ответил 29 Ноя, 04 от Гость (210,080 баллов)

Григорий.

Я протрассировала  период работы оператором.

BEGIN sde.version_util.delete_states (:state_list); :sql_code :=
  sde.sde_util.SE_SUCCESS; EXCEPTION WHEN OTHERS THEN :sql_code := SQLCODE;
  :error_string := SQLERRM; END;


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.52       1.33       3444       3782         25           1
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.52       1.33       3444       3782         25           1

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 494 
********************************************************************************

DELETE FROM SDE.STATE_LINEAGES
WHERE
 LINEAGE_ID = :b1  AND LINEAGE_ID != :b2


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute      1      0.50       1.25       3422       3751         13           1
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        1      0.50       1.25       3422       3751         13           1
=====================================================================================
Видно, что процессор нагружается только в половину времени общего выполнения запроса
на удаление. Т.е. процессор выполняет запрос быстро, после чего ждет завершения
чего-то. К сожалению, выяснить завершения чего именно мне пока не удалось,
подозреваю, что дело либо в вводе-выводе, либо в неоптимизированном плане
выполнения запроса (для того, чтобы удалить одну строку, сервер почему-то
"пролапатил" много блоков).
Следующий запрос (подобный запросу на удаление) показывает:
======================================================================================
SQL> select * from sde.state_lineages where lineage_id = 5 and lineage_id != 10;


no rows selected


Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=570 Card=1 Bytes=2)
   1    0   TABLE ACCESS (FULL) OF 'STATE_LINEAGES' (Cost=570 Card=1 B
          ytes=2)

Statistics
----------------------------------------------------------
          0  recursive calls
          6  db block gets
       3752  consistent gets
       3750  physical reads
         60  redo size
        274  bytes sent via SQL*Net to client
        315  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          0  rows processed

Если есть предположения помогите.

Заранее спасибо!

0 голосов
ответил 01 Март, 05 от Erkesh (1,080 баллов)

Я протрассировала  период работы оператором.

Scorp - плагиатчица. :)

0 голосов
ответил 01 Март, 05 от Гость (210,080 баллов)

Господин Кувшиников как всегда Ооочень помог! (отослал к хелпу другоо он не может)

0 голосов
ответил 03 Март, 05 от Grigoriy (127,020 баллов)

А Господин Olegs даже этого не можетimage.

 

0 голосов
ответил 23 Март, 05 от igorstr (6,660 баллов)

А что за версия, какие SP стоят?

В списке исправленных багов для 9.0 SP2:

CQ00248852 - Zoom to map cache gives FDO error when labeling with an SQL query on a layer being cached via the Map Cache.

Я, конечно, понимаю, что тут дело наоборот, но, может помочь. А про Григория писать нехорошие слова не стОит, он помогает и даже очень.

А иногда и в хелпе пишут не совсем тупые рекомендации.

0 голосов
ответил 31 Март, 05 от Гость (210,080 баллов)

Посмотрите ERROR!!!!!!!!!!!!!!!!!!!!!!!!!!!! help! там описывается ошибка под SQL, но рекомендации общие для редактирования в SDE

 

уважаемый Григорий будьте добры укажите более точно куда надо смотреть в случае возникновения такой ошибки. Заранее благодарен!!!

<!-- Signature -->
Добро пожаловать на сайт Вопросов и Ответов, где вы можете задавать вопросы по GIS тематике и получать ответы от других членов сообщества.
...