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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 02.12.2009, 11:56   #21  
BokarevSS is offline
BokarevSS
Участник
 
63 / 12 (1) ++
Регистрация: 13.01.2009
А каким же тогда способом лучше решить проблему медленного формирования отчетов?
Ведь исходя из вышесказанного, от выравнивания вправо лучше отказаться, тогда при этом сортировка не будет правильной.
Старый 02.12.2009, 12:18   #22  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Вообще высокая загрузка SQL не всегда означает что именно запрос тормозит!
Для начала я бы сделал "обследование" сервера на предмет узких мест - счетчики пописать и проанализировать, а потом уже смотреть на запросы.
Старый 02.12.2009, 23:45   #23  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,737 / 858 (32) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Записей в блоге: 7
Цитата:
Сообщение от BokarevSS Посмотреть сообщение
..от выравнивания вправо лучше отказаться, тогда при этом сортировка не будет правильной.
ну почему же, если у вас счета ГК настроены "как обычно", то останется правильной
Старый 03.12.2009, 00:54   #24  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,275 / 3476 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от BokarevSS Посмотреть сообщение
А каким же тогда способом лучше решить проблему медленного формирования отчетов?
Общая рекомендация - заняться оптимизацией БД. Включить трассировку запросов SQL (средствами Аксапты), посмотреть какие запросы наиболее тормознутые, попытаться создать более оптимальные индексы, нежели есть в штатной функциональности. В т.ч. задуматься о выравнивании влево.
Посмотреть на другие запросы других пользователей. Ведь неоптимизированный запрос, который одновременно выполняется большим количеством народа хорошо грузит систему в целом.
Посмотреть на загрузку диска (ов) с БД - может БД стоит на одном единственном физическом диске - который попутно выполняет еще какую-нибудь роль типа общей файлопомойки. А еще есть любители программы PGP, которые ставят эту программу на файловые диски и удивляются - почему увеличивается при этом нагрузка на диски.
Можно (но это уже когда все остальное проделано) попытаться вынести отдельные наиболее громоздкие таблицы в БД в отдельные файлы на отдельные физические диски.

В общем - советов по оптимизации можно давать много - суть одна - любой БД нужно заниматься при мало-мальским наполнении ее данными чтобы она нормально работала. Думаю, что смена платформы БД может дать эффект при нагрузке на БД под 100-200 одновременных (конкурентных) пользователей. И то, когда уже измучен каждый запрос, отправляемый к БД, а сервер оснащен "по последнему слову техники".
__________________
Возможно сделать все. Вопрос времени
Старый 04.12.2009, 15:20   #25  
somebody is offline
somebody
Участник
 
128 / 30 (2) +++
Регистрация: 30.04.2003
Адрес: Москва
Цитата:
Сообщение от BokarevSS
MS Dynamics Axapta медленно формирует отчеты, из-за больших объемов БД.
ВСЕ отчёты?
Так не бывает. Вы посмотрите конкретные отчёты, к-рые тормозят, помониторьте запросы, к-рые отправляются на SQL-сервер, посмотрите планы этих запросов.
Может, всего лишь каких-то индексов не хватает... Проверьте блокировки при создании отчётов - например, кто-то меняет данные, используемые отчётом, из-за чего отчёт может тормозить.

В общем, разберитесь сначала с SQL-сервером, помониторьте затратные запросы, ожидания, блокировки.

Бывает, отчёты, выполненные средствами Аксапты, работают медленно, приходится через прямое обращение к SQL-серверу заливать временные таблицы, это в разы или даже на порядки быстрее. Говорю по собственному опыту.

Да может, Вы вообще в Excel заливаете неоптимальным образом, тогда получите огромные тормоза (здесь на форуме обсуждалось неоднократно).

В общем, не спешите Вы на Оракл переходить, и даже на SQL 2005.

Цитата:
Сообщение от BokarevSS
из-за больших объемов БД
Объём БД какой? У Вас, может, бОльшую его часть занимают SysdatabaseLog и таблицы, связанные с закрытием склада?
Могуть быть тормоза и на мизерной БД, и может летать на нескольких сотнях Гб.
Теги
ax3.0, oracle, sql server, оптимизация, производительность, холивар

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Установка Dynamics 4.0 под Oracle Paul_ST DAX: Администрирование 6 20.04.2007 16:36
aEremenko: История об установке Microsoft Dynamics Ax 4.0 и Oracle 10G Blog bot DAX Blogs 0 28.10.2006 16:01
AOS + Oracle не стартует yuranio DAX: Администрирование 8 26.11.2004 14:24
Знатокам Oracle listener DAX: Администрирование 1 23.01.2004 10:53
"On MSSQL" or "On Oracle" alpine DAX: Прочие вопросы 5 19.03.2002 11:38
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

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

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