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

[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") ; 


[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.