Не удалять индексы при синхронизации

[Logger]

Проблема :
При синхронизации аксапта удаляет индексы созданные админом БД (не прописанные в AOT).

Кто нибудь знает как обойти такую фичу ?

Ситуация смешная : Синхронизация длится 5 минут а работа скрипта по созданию индексов, которые прописал наш админ длится 20 минут

[twilight]

А что мешает завести индексы в AOT?

[Logger]

Например то, что индекс начинается не с поля dataareaid - этот индекс создавал наш админ по ораклу. Утверждает что оптимален именно тот набор полей и именно в том порядке который он указал. У меня нет причин ему не доверять. Кроме того есть bitmap индексы. Аксапта кажется их не могет строить...

[MironovI]

Стало интересно, глянул - стало неинтерсно - функция синхронизации dbSynchronize класса Application уходит корнями в глубокий super куда простым сметрным заказано.. Но можнов принципе пропускать такие таблицы при синхронизации списком и синхронизировать вручную, что несколько утомительно (слабо сказано, если вспомнить еще про таблицу sqldictionary)..

[AndyD]

Честно сказать в Oracle у меня ну удаляются "лишние" индексы. Единственное что заметил - идет запрос к view user_constraints c условием на Primary Key при синхронизации таблицы. Может ваш индекс PK и по-этому он удаляется из базы?

В MS SQL такое поведение наблюдал, но оно обходится довольно просто.
При синхронизации идет вызов системной процедуры sp_statistics, находящейся в схеме master. Все индексы, не входящие в AOT или не соответствующие ему - удаляются.
Обходится так - создал копию этой процедуры в б/д Axpta'ы и в выборку по sysindexes добавил условие -
and (x.name like 'I!_%' escape '!')
Теперь индексы, не начинающиеся с I_ (т.е. кроме создаваемых самой Axapta'ой) ей не "видны".

Правда возникает вопрос - кто помимо Axapta'ы использует эту sp и не аукнется ли?

[AndyD]

Прошу прощения - про Oracle я написал неправильно (смотрел не ту схему )

Но принцип такой-же как и для MS SQL, единственное отличие - использование системных view.

При синхронизации Axapta отправляет на сервер такой запрос

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('INVENTTABLE') AND a.index_name=b.index_name AND 
b.index_name=c.index_name(+) AND b.column_position=c.column_position(+)
ORDER BY b.index_name,b.column_position

Т.е. в данном случае надо перенести в свою схему из схемы sys просмотр (view) user_ind_columns и в нем добавить условие на таблицу sys.obj$ idx
"and (idx.Name like 'I!_%' escape '!')"
Для того, чтобы создать такой view необходимо добавить пользователю Axapta грант на select для таблиц из схемы sys attrcol$, col$, icol$, ind$, obj$

[DmitrySt]

Цитата:

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

А что мешает завести индексы в AOT?

Сам не проверял, но пришло в голову (как развитие предыдущей идеи):
завести индексы в АОТ, отключить их использование (Enabled = NO), а затем - подменить напрямую на сервере на свои? Будет Аксапта отключенные индексы удалять / перестраивать?

[Logger]

Цитата:

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

Сам не проверял, но пришло в голову (как развитие предыдущей идеи):
завести индексы в АОТ, отключить их использование (Enabled = NO), а затем - подменить напрямую на сервере на свои? Будет Аксапта отключенные индексы удалять / перестраивать?

Если не воспользоваться советом AndyD то Аксапта при синхронизации может их удалить. Для запуска синхронизации иногда достаточно безобидной компилции метода на таблице.

[mazzy]

Цитата:

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

Для запуска синхронизации иногда достаточно безобидной компилции метода на таблице.

Для запуска синхронизации достаточно выполнить любую правку любого объекта внутри ветки Data Dictionary.

Другими словами, Axapta считает что внутри ветки Data Dictionary собраны объекты, которые так или иначе влияют на отображение таблиц в СУБД.

[usp]

Господа! А не проще ли создать индексы в схеме другого пользователя, не владельца таблиц Аксапты? С соответствующим ограничением прав на Oracle... Ведь оптимизатор базы использует любые индексы, созданные по запрашиваемым таблицам.

[Logger]

Цитата:

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

Господа! А не проще ли создать индексы в схеме другого пользователя, не владельца таблиц Аксапты? С соответствующим ограничением прав на Oracle... Ведь оптимизатор базы использует любые индексы, созданные по запрашиваемым таблицам.

А аксапта увидит эти таблицы ?

[Ax1D]

Цитата:

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

Например то, что индекс начинается не с поля dataareaid - этот индекс создавал наш админ по ораклу. Утверждает что оптимален именно тот набор полей и именно в том порядке который он указал. У меня нет причин ему не доверять.

Существует параметр конфигурационной утилиты:

-internal=CROSSCOMPANY

с ним можно добавлять поле DataAreaID в индекс и вручную определить порядок полей в индексе.

[usp]

Таблицы остаются на месте, у владельца, скрываются только индексы. Аксапта их не видет, а оптимизатор Oracle "всегда пожалуйста".

[Logger]

Цитата:

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

Существует параметр конфигурационной утилиты:

-internal=CROSSCOMPANY

с ним можно добавлять поле DataAreaID в индекс и вручную определить порядок полей в индексе.

Спасибо за ценную инфу.

[AndyD]

Обратите внимание на совет Максима Горбунова
aEremenko: Порядок полей в индексе для DAX 3.0

[Lazy_Tiger]

0) сохраните скрипт процедуры sp_statistics в файлик

1) Нужно зайти в режиме single mode, для этого останавливаем сервис. далее start->Run-> "C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\sqlservr.exe" -sMSSQLSERVER -m (главное тут ключик -m, а путь к exe посмотрите у себя)

2) открываем заранее сохраненный скрипт, дополняем его в начале строчками:
use mssqlsystemresource
GO
alter database mssqlsystemresource set read_write

удаляем строку USE MASTER , поскольку это неправда и оно теперь вовсе не там лежит
правим код процедуры (см. сообщения выше)

в конце добавляем строчки:
alter database mssqlsystemresource set read_only
GO

ЗАПУСКАЕМ.

НАВОРОТИЛИ БЛИН.

ВНИМАНИЕ! После накатывания очередного SP на MS SQL - процедурку придется повторить. Ибо оно тупо перепишет вам ресурсы

[DocSerzh]

Цитата:

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

0) сохраните скрипт процедуры sp_statistic в файлик

1) Нужно зайти в режиме single mode, для этого останавливаем сервис. далее start->Run-> "C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\sqlservr.exe" -sMSSQLSERVER -m (главное тут ключик -m, а путь к exe посмотрите у себя)

2) открываем заранее сохраненный скрипт, дополняем его в начале строчками:
use mssqlsystemresource
GO
alter database mssqlsystemresource set read_write

удаляем строку USE MASTER , поскольку это неправда и оно теперь вовсе не там лежит
правим код процедуры (см. сообщения выше)

в конце добавляем строчки:
alter database mssqlsystemresource set read_only
GO

ЗАПУСКАЕМ.

НАВОРОТИЛИ БЛИН.

ВНИМАНИЕ! После накатывания очередного SP на MS SQL - процедурку придется повторить. Ибо оно тупо перепишет вам ресурсы

sp_statisticS? или я не в теме...

[Lazy_Tiger]

Цитата:

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

sp_statisticS? или я не в теме...

ну естественно. Описка, бывает

[Андре]

Насколько я помню, у одного из клиентов, работающих с Oracle мы реализовывали подобную штуку. Разбираться можно начать с формы SysSqlSetup и с того, как система преобразует параметры с этой формы в ddl - запросы.
Могу ошибаться, но мне помнится, что система позволяет протаскивать свои параметры с этой формы на запросы, посылаемые на Oracle при синхронизации.