Проблемы быстродействия 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) одновременно?

[Torin]

Цитата:

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

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

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

[Alexandr A. Osipkin]

Цитата:

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

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

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

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

[Vadik]

Цитата:

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

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

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

[Torin]

Цитата:

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

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

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

[sergeypp]

2 Torin

Цитата:

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

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

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

[Torin]

Цитата:

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

2 Torin

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

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

[Vadik]

Цитата:

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

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

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

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

[Torin]

Цитата:

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

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

По поводу теории практики отвечу позже. А это SAVEDATAPERCOMPANY или NODATAAREAID отключать советуете, если у нас 6 компаний ? ;-)

[Torin]

Цитата:

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

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

Мне трудно сейчас, на рабочей базе проверять, но проверю еще раз, просто сам факт необходимости перекомпиляции.. База уже большая, на нот не влезет. Тем более, что наличие партишининга подсказывает, что количество dataareaid влиять не будет.

Заодно отвечу и Андре:
Господа, "священные войны" устраивать не хочу. Я не DBA, но были случаи в жизни, когда приходилось плотно изучать теорию и практику. Как я могу сослаться на теорию и практику за 6 лет по SQL, DB2 и Oracle ? :-)
Тем более, Андре, если вы оперируете опровежениями, но наверняка знаете и предмет, который опровергают ?
По сути - перенос DataAreaID в конец был сдела сразу (по экспертному мнению) и эффект от него не считался. Да я и не настаиваю на этом, как на панацее.

[sergeypp]

2 Vadik

Цитата:

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

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

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

[belugin]

юкон это ms sql 2005

[Alexandr A. Osipkin]

Цитата:

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

юкон это ms sql 2005

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

[Vadik]

Цитата:

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

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

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

[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. Кстати, - не зная броду, по мере работ у нас тоже "под боком" стоял Оракл - думали, чуть что - сразу перейдем. Не пригодился, слава богу.