AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 26.01.2007, 13:26   #1  
Alexandr A. Osipkin is offline
Alexandr A. Osipkin
Участник
Аватар для Alexandr A. Osipkin
 
71 / 10 (1) +
Регистрация: 29.06.2006
Проблемы быстродействия Axapta 3.0
Добрый день.

Мы занимаемся внедрением 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 уважением, Осипкин Александр.
Старый 26.01.2007, 13:51   #2  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2925 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
в SP3 болшие проблемы с утечками памяти, насколько я помню. Это может приводить к невозможности разноски больших журналов ГК. В последних KR устранены.
Старый 26.01.2007, 14:01   #3  
Torin is offline
Torin
Участник
 
127 / 31 (2) +++
Регистрация: 10.03.2003
Адрес: Odessa, Ukraine
К сожалению все вопросы довольно абстракны. Что бы ответить "вообщем", советую:
1) Перейти на Юкон в режиме совместимости 9 + KR3.
2) Посадить на месяц-два DB администратора + X++ разработчика с ежедневной статистикой по длительным или частым SQL запросам, которую может собирать Аксапта. Надо и индексы перестраивать и где-то код править и схему базы менять
3) Перенести DataAreaID в конец индексов
4) Если мультикомпанейная база - партишионинг Юкона включить.
5) На крайняк, меняйте сервер, но можно на порядок -два "найти" и без оного.

Как минимум, о дедлоках забудете. ;-)
Старый 26.01.2007, 14:37   #4  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Torin Посмотреть сообщение
3) Перенести DataAreaID в конец индексов
4) Если мультикомпанейная база - партишионинг Юкона включить.
Можно дурацкий вопрос задать?
А стоит ли делать пункты 3) и 4) одновременно?
__________________
полезное на axForum, github, vk, coub.
Старый 26.01.2007, 15:23   #5  
Alexandr A. Osipkin is offline
Alexandr A. Osipkin
Участник
Аватар для Alexandr A. Osipkin
 
71 / 10 (1) +
Регистрация: 29.06.2006
Цитата:
Сообщение от Torin Посмотреть сообщение
К сожалению все вопросы довольно абстракны. Что бы ответить "вообщем", советую:
1) Перейти на Юкон в режиме совместимости 9 + KR3.
2) Посадить на месяц-два DB администратора + X++ разработчика с ежедневной статистикой по длительным или частым SQL запросам, которую может собирать Аксапта. Надо и индексы перестраивать и где-то код править и схему базы менять
3) Перенести DataAreaID в конец индексов
4) Если мультикомпанейная база - партишионинг Юкона включить.
5) На крайняк, меняйте сервер, но можно на порядок -два "найти" и без оного.

Как минимум, о дедлоках забудете. ;-)
Извините за глупый вопрос. А что есть Юкон?
Старый 26.01.2007, 16:00   #6  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Torin Посмотреть сообщение
Как минимум, о дедлоках забудете. ;-)
Не стоит так категорично, наверное
Включите, к примеру, автоматическое сопоставление по клиентам/поставщикам
__________________
-ТСЯ или -ТЬСЯ ?
Старый 26.01.2007, 16:00   #7  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2925 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
юкон это ms sql 2005
Старый 26.01.2007, 16:11   #8  
Alexandr A. Osipkin is offline
Alexandr A. Osipkin
Участник
Аватар для Alexandr A. Osipkin
 
71 / 10 (1) +
Регистрация: 29.06.2006
Цитата:
Сообщение от belugin Посмотреть сообщение
юкон это ms sql 2005
Спасибо. Уже понимаю, что этого видимо не избежать.
Старый 26.01.2007, 16:42   #9  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Alexandr A. Osipkin Посмотреть сообщение
Спасибо. Уже понимаю, что этого видимо не избежать.
Юкон - не панацея. Но вкусностей действительно много
__________________
-ТСЯ или -ТЬСЯ ?
Старый 26.01.2007, 17:13   #10  
Torin is offline
Torin
Участник
 
127 / 31 (2) +++
Регистрация: 10.03.2003
Адрес: Odessa, Ukraine
Цитата:
Сообщение от mazzy Посмотреть сообщение
Можно дурацкий вопрос задать?
А стоит ли делать пункты 3) и 4) одновременно?
нее, конечно
Это навскидку советы так, чтобы вообщем..
Старый 26.01.2007, 17:15   #11  
Torin is offline
Torin
Участник
 
127 / 31 (2) +++
Регистрация: 10.03.2003
Адрес: Odessa, Ukraine
Цитата:
Сообщение от Vadik Посмотреть сообщение
Не стоит так категорично, наверное
Включите, к примеру, автоматическое сопоставление по клиентам/поставщикам
Возможно, честно - пока непользовались. Мы только торговые операции, складские опреации и логистику делали. Ну и есть такая "радость" как импорт данных с филиалов (другая система) - кажды день залетает до 4 тыс заказов в среднем (в месяц около миллиона строк заказов)
Старый 26.01.2007, 17:18   #12  
Torin is offline
Torin
Участник
 
127 / 31 (2) +++
Регистрация: 10.03.2003
Адрес: Odessa, Ukraine
Цитата:
Сообщение от Vadik Посмотреть сообщение
Юкон - не панацея. Но вкусностей действительно много
Row level locking + версионность + партишионниг - отчасти панацея. Например, помогает одновременно считать своные планы срзу по нескольким компаниям и тому подобное..
Старый 26.01.2007, 17:37   #13  
Torin is offline
Torin
Участник
 
127 / 31 (2) +++
Регистрация: 10.03.2003
Адрес: Odessa, Ukraine
Цитата:
Сообщение от Vadik Посмотреть сообщение
Юкон - не панацея. Но вкусностей действительно много
А за возможность получать такую инфу http://www.microsoft.com/technet/scr....mspx?mfr=true
Вообще, убить можно
Старый 27.01.2007, 13:06   #14  
Torin is offline
Torin
Участник
 
127 / 31 (2) +++
Регистрация: 10.03.2003
Адрес: Odessa, Ukraine
sukhanchik, Вы правы, все логично. Но мы пошли по пути максимально использования фич Юкона. Например, партишионинг по DataArea полностью исключает блокировки в мультикомпанейной базе.
Сначала я перенес DataArea в конец, потому что отключили хинтование и нужна была правильная селективность + минимизация IO. После того, как поставили KR3 хинтование стало обязательным, и индексный план опять переделывали - и пришлось больше править в коде.
Но, в любом случае, использование партишининга, пересмотр индексов, где-то отключение page lock для конкурентных индексов, родная версия драйвера, использование статистики, которую умеет выдавать Юкон - и за месяц -два производительность растет на порядок-два, а не 30-40%.

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

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

Последний раз редактировалось Torin; 27.01.2007 в 13:09.
Старый 27.01.2007, 13:53   #15  
Torin is offline
Torin
Участник
 
127 / 31 (2) +++
Регистрация: 10.03.2003
Адрес: Odessa, Ukraine
В унисон.
Тормозит прогнозное планирование
Старый 05.02.2007, 10:09   #16  
sergeypp is offline
sergeypp
Ищу людей. Дорого.
Аватар для sergeypp
 
433 / 174 (6) ++++++
Регистрация: 08.11.2003
Адрес: Казань
2 Torin
Цитата:
Сообщение от Torin Посмотреть сообщение
3) Перенести DataAreaID в конец индексов
А что это даст?
Старый 05.02.2007, 11:08   #17  
Torin is offline
Torin
Участник
 
127 / 31 (2) +++
Регистрация: 10.03.2003
Адрес: Odessa, Ukraine
Цитата:
Сообщение от sergeypp Посмотреть сообщение
2 Torin

А что это даст?
В теории - индекс будет "быстрее" - так как наименее селективное поля держать в начале не соответвует рекомендациям. ДУмаю, Даамгадовцы сделали упор на конкурентность, за счет производительности - в случае с SQL 2000, dataareaid первым сегментом, как раз, улучьшает возможности конкурентного доступа.
Для SQL 2005 - это все припарки, - у него есть партишионинг.
Старый 05.02.2007, 12:05   #18  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Torin Посмотреть сообщение
В теории - индекс будет "быстрее" - так как наименее селективное поля держать в начале не соответсвует рекомендациям
А Вы на практике данную рекомендацию проверяли? Один из выходных посвятил эксперименту - каких-либо существенных бонусов в случае использования одной компании не нашел (IO одинаковый или увеличивается), в случае нескольких компаний - только хуже, причем значительно (IO увеличивается в N раз, где N - число компаний)

В случае же одной компании куда как полезнее было бы просто отключение SAVEDATAPERCOMPANY или NODATAAREAID. IMHO, разумеется
__________________
-ТСЯ или -ТЬСЯ ?
Старый 05.02.2007, 12:54   #19  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
В теории - индекс будет "быстрее" - так как наименее селективное поля держать в начале не соответвует рекомендациям.
А ссылку на теорию можно?
Старый 05.02.2007, 12:59   #20  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Про ms sql сходу не найду, но по поводу Оракла у Кайта есть такая статья: "Миф: столбцы с максимальным количеством разных значений должны указываться первыми"

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

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Формирование прайс-листа в Axapta. Проблемы производительности. Lucky13 DAX: Программирование 12 04.12.2007 13:18
Проблемы cо шрифтами в терминалом сервере у Axapta 3.0 SKULL DAX: Прочие вопросы 1 18.06.2005 21:46
Проблемы с установкой SP3 на axapta 2.5 Zick-Zibn DAX: Администрирование 1 23.06.2004 12:45
Проблемы с работой Axapta Nevskij DAX: Администрирование 7 01.12.2003 14:21
Введение в Аксапту Роман Кошелев DAX: Прочие вопросы 0 18.12.2001 14:00

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 07:06.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.