Проблемы быстродействия Axapta 3.0

[Alexandr A. Osipkin]

Добрый день.

Мы занимаемся внедрением Microsoft Dynamics Axapta 3.0 на крупном предприятии.
Последнее время стали возникать проблемы с быстродействием.

Хотелось бы знать как проходит внедрение в других конторах.
Конкретно очень интересует:
Долго ли формируются отчеты, оборотно сальдовые ведомости.
Возникают ли проблемы с доступом через терминал.
Как часто возникают блокировки в б.д..

На данный момент у нас внедрена версия 3.0 Service Pack 3.
MS SQL 2000 SP4, Microsoft Windows 2003 Server.
Размер базы 20-25 Гб.

Обновление до более поздних версий достаточно сложное (много изменений в коде). Подскажите пожалуйста,
имеет ли большой смысл обновлять SP, устанавливать KR, переходить на MS SQL 2005.

C уважением, Осипкин Александр.

[belugin]

в SP3 болшие проблемы с утечками памяти, насколько я помню. Это может приводить к невозможности разноски больших журналов ГК. В последних KR устранены.

[Torin]

К сожалению все вопросы довольно абстракны. Что бы ответить "вообщем", советую:
1) Перейти на Юкон в режиме совместимости 9 + KR3.
2) Посадить на месяц-два DB администратора + X++ разработчика с ежедневной статистикой по длительным или частым SQL запросам, которую может собирать Аксапта. Надо и индексы перестраивать и где-то код править и схему базы менять
3) Перенести DataAreaID в конец индексов
4) Если мультикомпанейная база - партишионинг Юкона включить.
5) На крайняк, меняйте сервер, но можно на порядок -два "найти" и без оного.

Как минимум, о дедлоках забудете. ;-)

[mazzy]

Цитата:

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

3) Перенести DataAreaID в конец индексов
4) Если мультикомпанейная база - партишионинг Юкона включить.

Можно дурацкий вопрос задать?
А стоит ли делать пункты 3) и 4) одновременно?

[Alexandr A. Osipkin]

Цитата:

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

К сожалению все вопросы довольно абстракны. Что бы ответить "вообщем", советую:
1) Перейти на Юкон в режиме совместимости 9 + KR3.
2) Посадить на месяц-два DB администратора + X++ разработчика с ежедневной статистикой по длительным или частым SQL запросам, которую может собирать Аксапта. Надо и индексы перестраивать и где-то код править и схему базы менять
3) Перенести DataAreaID в конец индексов
4) Если мультикомпанейная база - партишионинг Юкона включить.
5) На крайняк, меняйте сервер, но можно на порядок -два "найти" и без оного.

Как минимум, о дедлоках забудете. ;-)

Извините за глупый вопрос. А что есть Юкон?

[Vadik]

Цитата:

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

Как минимум, о дедлоках забудете. ;-)

Не стоит так категорично, наверное
Включите, к примеру, автоматическое сопоставление по клиентам/поставщикам

[belugin]

юкон это ms sql 2005

[Alexandr A. Osipkin]

Цитата:

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

юкон это ms sql 2005

Спасибо. Уже понимаю, что этого видимо не избежать.

[Vadik]

Цитата:

Сообщение от Alexandr A. Osipkin

Спасибо. Уже понимаю, что этого видимо не избежать.

Юкон - не панацея. Но вкусностей действительно много

[Torin]

Цитата:

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

Можно дурацкий вопрос задать?
А стоит ли делать пункты 3) и 4) одновременно?

нее, конечно
Это навскидку советы так, чтобы вообщем..

[Torin]

Цитата:

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

Не стоит так категорично, наверное
Включите, к примеру, автоматическое сопоставление по клиентам/поставщикам

Возможно, честно - пока непользовались. Мы только торговые операции, складские опреации и логистику делали. Ну и есть такая "радость" как импорт данных с филиалов (другая система) - кажды день залетает до 4 тыс заказов в среднем (в месяц около миллиона строк заказов)

[Torin]

Цитата:

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

Юкон - не панацея. Но вкусностей действительно много

Row level locking + версионность + партишионниг - отчасти панацея. Например, помогает одновременно считать своные планы срзу по нескольким компаниям и тому подобное..

[Torin]

Цитата:

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

Юкон - не панацея. Но вкусностей действительно много

А за возможность получать такую инфу http://www.microsoft.com/technet/scr....mspx?mfr=true
Вообще, убить можно

[Torin]

sukhanchik, Вы правы, все логично. Но мы пошли по пути максимально использования фич Юкона. Например, партишионинг по DataArea полностью исключает блокировки в мультикомпанейной базе.
Сначала я перенес DataArea в конец, потому что отключили хинтование и нужна была правильная селективность + минимизация IO. После того, как поставили KR3 хинтование стало обязательным, и индексный план опять переделывали - и пришлось больше править в коде.
Но, в любом случае, использование партишининга, пересмотр индексов, где-то отключение page lock для конкурентных индексов, родная версия драйвера, использование статистики, которую умеет выдавать Юкон - и за месяц -два производительность растет на порядок-два, а не 30-40%.

Можно подробнее про непрерывность номерных серий ? - честно говоря, еще не сталкивались с этим, как с проблемой.

P.S. Кстати, - не зная броду, по мере работ у нас тоже "под боком" стоял Оракл - думали, чуть что - сразу перейдем. Не пригодился, слава богу.

[Torin]

В унисон.
Тормозит прогнозное планирование

[sergeypp]

2 Torin

Цитата:

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

3) Перенести DataAreaID в конец индексов

А что это даст?

[Torin]

Цитата:

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

2 Torin

А что это даст?

В теории - индекс будет "быстрее" - так как наименее селективное поля держать в начале не соответвует рекомендациям. ДУмаю, Даамгадовцы сделали упор на конкурентность, за счет производительности - в случае с SQL 2000, dataareaid первым сегментом, как раз, улучьшает возможности конкурентного доступа.
Для SQL 2005 - это все припарки, - у него есть партишионинг.

[Vadik]

Цитата:

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

В теории - индекс будет "быстрее" - так как наименее селективное поля держать в начале не соответсвует рекомендациям

А Вы на практике данную рекомендацию проверяли? Один из выходных посвятил эксперименту - каких-либо существенных бонусов в случае использования одной компании не нашел (IO одинаковый или увеличивается), в случае нескольких компаний - только хуже, причем значительно (IO увеличивается в N раз, где N - число компаний)

В случае же одной компании куда как полезнее было бы просто отключение SAVEDATAPERCOMPANY или NODATAAREAID. IMHO, разумеется

[Андре]

Цитата:

В теории - индекс будет "быстрее" - так как наименее селективное поля держать в начале не соответвует рекомендациям.

А ссылку на теорию можно?

[Андре]

Про ms sql сходу не найду, но по поводу Оракла у Кайта есть такая статья: "Миф: столбцы с максимальным количеством разных значений должны указываться первыми"

Цитата:

Кажется, это следует из соображений здравого смысла. Если предполагается созда-
ние индекса по столбцам С1, С2 таблицы со 100000 строк, при этом столбец С1 имеет
100000 уникальных значений, а столбец С2 — 25000, индекс создается по столбцам
Т(С1,С2). Это означает, что столбец С1 должен указываться первым, что соответствует "здравому смыслу". Фактически при сравнении векторов данных (пара значений Cl, C2 задает вектор) порядок столбцов не имеет значения. Рассмотрим следующий пример.
.....