Долгая синхронизация

[CDR]

Всем здравствуйте!
Подскажите, плиз, что-нибудь, по следующем проблеме: полная синхронизация всех таблиц в Axapta занимает 30-40 минут, хотя по идее должна занимать минут 5. Скорее всего, что проблема кроется в БД - Oracle.
Конфигурация следующая: Axapta 3.0 SP4 + Oracle 10g.

[savel]

Скорей всего была изменена EDT, или индекс изменён на табличке занимающей серьёзный объём. Ведь, после такой долгой синхронизации последующие опять проходят быстро?

[mazzy]

Или делается попытка синхронизации таблицы, которая используется кем-то другим - блокировка схемы ждет завершения всех остальных блокировок.

[CDR]

Нет, каждый раз синхронизация длится столько времени, причем число активных пользователей == 1

[itfs]

У нас та же ситуация на Oracel 10. Уже почти привыкли. А откуда информация, что должно быть 5 минут?

С уважением, itfs.

[Davido]

Коллеги, первый раз ставлю Axapta на Oracle, та же проблема - слишком долгая синхронизация. Кто-нибудь выяснил причину этой беды?

[db]

Цитата:

Сообщение от Davido

Коллеги, первый раз ставлю Axapta на Oracle, та же проблема - слишком долгая синхронизация.

Кто-нибудь выяснил причину этой беды?

Вчера нарвался на то же самое при переходе на 10-ку.
Причина - запрос, который выдает ядро аксапты для определения списков полей индексов таблицы, например

SELECT a.index_name, b.column_name, c.column_expression, a.index_type, a.uniqueness
FROM user_indexes a, user_ind_columns b, user_ind_expressions c
WHERE b.table_name=UPPER('INVENTLOCATION') AND a.index_name=b.index_name
AND b.index_name=c.index_name(+) AND b.column_position=c.column_position(+) ;

10-ка уходит в себя на 2-3 секунды на каждом таком запросе

Помогло бы индексирование системных таблиц (OBJ$ и прочих) по которым построены эти вьюхи по полю NAME, но

оракл на такие провокации не поддается "ORA-00701 object necessary for warmstarting database cannot be altered"

В итоге создал материализованные вьюхи USER_INDEXES и USER_IND_COLUMNS и проиндексировал их прямо в схеме юзера под которым работает аксапта. Синхронизация после этого 4-5 минут. Никаких побочных эффектов пока не найдено, но гарантий дать не могу

Скрипт для создания вьюшек

PHP код:

CREATE MATERIALIZED VIEW "USER_INDEXES"
  AS select "INDEX_NAME","INDEX_TYPE","TABLE_OWNER","TABLE_NAME","TABLE_TYPE",
    "UNIQUENESS","COMPRESSION","PREFIX_LENGTH","TABLESPACE_NAME",
    "INI_TRANS","MAX_TRANS","INITIAL_EXTENT","NEXT_EXTENT",
    "MIN_EXTENTS","MAX_EXTENTS","PCT_INCREASE","PCT_THRESHOLD",
    "INCLUDE_COLUMN","FREELISTS","FREELIST_GROUPS","PCT_FREE",
    "LOGGING","BLEVEL","LEAF_BLOCKS","DISTINCT_KEYS",
    "AVG_LEAF_BLOCKS_PER_KEY","AVG_DATA_BLOCKS_PER_KEY",
    "CLUSTERING_FACTOR","STATUS","NUM_ROWS","SAMPLE_SIZE",
    "LAST_ANALYZED","DEGREE","INSTANCES","PARTITIONED",
    "TEMPORARY","GENERATED","SECONDARY","BUFFER_POOL",
    "USER_STATS","DURATION","PCT_DIRECT_ACCESS","ITYP_OWNER",
    "ITYP_NAME","PARAMETERS","GLOBAL_STATS","DOMIDX_STATUS",
    "DOMIDX_OPSTATUS","FUNCIDX_STATUS","JOIN_INDEX",
    "IOT_REDUNDANT_PKEY_ELIM","DROPPED" FROM "SYS"."USER_INDEXES";

  CREATE MATERIALIZED VIEW "USER_IND_COLUMNS"
  AS select "INDEX_NAME",
    "TABLE_NAME","COLUMN_NAME","COLUMN_POSITION","COLUMN_LENGTH",
    "CHAR_LENGTH","DESCEND" FROM "SYS"."USER_IND_COLUMNS";

CREATE UNIQUE INDEX "T_USER_IDX_1" 
    ON "USER_INDEXES"  ("INDEX_NAME") ;

CREATE INDEX "T_USER_IND_COLUMNS_IDX_1" 
    ON "USER_IND_COLUMNS"  ("INDEX_NAME", "COLUMN_POSITION");

CREATE INDEX "T_USER_IND_COLUMNS_IDX_2" 
    ON "USER_IND_COLUMNS"  ("TABLE_NAME") ; 


[Alex05507]

Кстати, 10ка официально не поддерживается с 3.0

[Андре]

Насколько я знаю, с 4 SP1 вполне

[Dron AKA andy]

Цитата:

Сообщение от Alex05507

Кстати, 10ка официально не поддерживается с 3.0

А откуда такая инфа, если не секрет?

[Alex05507]

Если взять с Partner Source Kernel Rollup 3 и прочитать readme.doc, то там есть упоминание, что поддерживаемая версия 9.2.0.2
А 10 ка только с 4.0

[itfs]

Цитата:

Сообщение от db

В итоге создал материализованные вьюхи USER_INDEXES и USER_IND_COLUMNS
[/PHP]

Идея интересная, но ведь MV refresh-ить надо иначе они устареют.

С уважением, itfs.

[db]

Цитата:

Сообщение от itfs

Идея интересная, но ведь MV refresh-ить надо иначе они устареют.

С уважением, itfs.

Ясен хрен надо. Совсем задолбался со всем этим переосом - забыл аксаптовский код приложить. Надо немного подправить appl.dbSynchronize. Вьюшки будут рефрешиться перед каждой синхронизацией. Созданы они с параметром REFRESH по умолчанию, т.е. FORCE (по изменениям, если не выйдет, то целиком) - рефрешатся обе вместе около одной секунды. Синхронизацию аксапта вызывает при любом сохранении объекта в АОТ, но ИМХО лучше помечтать секунду при сохранении объекта, чем мечтать почти час при полной синхронизации. Прикрутить автоматическое обновление прям на сервере ON COMMIT к этим вьюшкам у меня не получилось (хотя надо признать не очень то и старался). Если кто все таки сделает обновление ON COMMIT, расскажите пжл

boolean dbSynchronize(tableId tableId         = 0,   // 0 = all tables, non-zero is a valid table handle
                      boolean syncAsNeeded    = true,  // true = objects touched in the AOT, false = unconditional synchronize
                      boolean continueOnError = true,
                      boolean showProgress    = true ) // true = report all problems, but throw only after all tables are synchronized, false = stop synchronize after first error/problem
{
    SqlSyncPending  sqlSyncPending = new SqlSyncPending();
    boolean         ok;
    ;

    setPrefix("@SYS22807");

    if (SqlSystem::databaseBackendId() == DataBaseId::Oracle)
    {
        new Connection().createStatement().executeUpdate("BEGIN DBMS_MVIEW.REFRESH('USER_IND_COLUMNS, USER_INDEXES'); END;");
    }

    ok = super(tableId, syncAsNeeded, continueOnError, showProgress);

    if (ok && this.isRunningMode())
    {
        SysApplicationSetup::saveApplicationVersion(SysApplicationSetupMode::Synhronize);
    }


    return ok;
}

[itfs]

Цитата:

Сообщение от db

Если кто все таки сделает обновление ON COMMIT, расскажите пжл

SYS.USER_INDEXES увы, всего лишь вьюха. На нее ON COMMIT не подействует. Но даже если сделать MV на основе скрипта этой veiw, у ON COMMIT - ограничение, действует только на "основную" таблицу запроса, так что ваш вариант по обновлению, видимо, единственный.

С уважением, itfs.

[Eldar9x]

а все, нашел

вобщем, при сохранении в AOT или в проекте уходит долгое время. Это для тех, кто на оракле сидит. Оказалось, дело было в этом Долгая синхронизация, там же и ответил.

[Eldar9x]

Небольшая модификация для разработчиков:

boolean dbSynchronize(tableId tableId         = 0,   // 0 = all tables, non-zero is a valid table handle
                      boolean syncAsNeeded    = true,  // true = objects touched in the AOT, false = unconditional synchronize
                      boolean continueOnError = true,
                      boolean showProgress    = true ) // true = report all problems, but throw only after all tables are synchronized, false = stop synchronize after first error/problem
{
    SqlSyncPending  sqlSyncPending = new SqlSyncPending();
    boolean         ok;
    ;

    setPrefix("@SYS22807");

    if (!syncAsNeeded && SqlSystem::databaseBackendId() == DataBaseId::Oracle)
    {
        new Connection().createStatement().executeUpdate("BEGIN DBMS_MVIEW.REFRESH('USER_IND_COLUMNS, USER_INDEXES'); END;");
    }

    ok = super(tableId, syncAsNeeded, continueOnError, showProgress);

    if (ok && this.isRunningMode())
    {
        SysApplicationSetup::saveApplicationVersion(SysApplicationSetupMode::Synhronize);
    }


    return ok;
}

иначе тормозит сохранение объектов