04.09.2003, 13:55 | #1 |
Участник
|
тормоза
плана счетов открывается около минуты, очень долго считается сальдо, особенно по итоговым счетам , прокрутка вниз - опять минута, а то и больше
может кто нибудь уже сталкивался с подобной проблеммой ? Axapta 3.0, размер базы ~ 1,3 Гб, строк в LedgeTtrans ~ 250 тыс. |
|
04.09.2003, 14:19 | #2 |
Moderator
|
Цитата:
плана счетов открывается около минуты
select * from LedgerTable ? |
|
04.09.2003, 14:22 | #3 |
Участник
|
работает, практически мгновенно,
но в select * from LedgerTable не расчитывается сальдо |
|
04.09.2003, 14:25 | #4 |
Участник
|
в момент "тормозов" sql забирает 96% процессорного времени, складывается впечатление, что axapta пересчитывает сальдо по всем периодам, в т.ч. и закрытым
|
|
04.09.2003, 14:40 | #5 |
Шаман форума
|
Модификации были? Какое оборудование? Какая конфигурация (2-зв, 3-зв)?
И т.д., и т.п...... |
|
04.09.2003, 14:59 | #6 |
Участник
|
2-зв., модификации были, оборудование скорее всего тут не причем
axapta тоже... вот такой job работает так-же долго: PHP код:
|
|
04.09.2003, 15:14 | #7 |
Шаман форума
|
Простой способ проверки - если стандартная версия на то же самом работает с нормальной скоростью, значит дело в модификациях. Если нет - значит, яйца тут не при чем.....
|
|
04.09.2003, 15:55 | #8 |
Модератор
|
PHP код:
Индекс по AccountNum, PeriodCode строить пробовали? Перестройку индексов, обновление статистик в MSSQL делали? |
|
05.09.2003, 06:05 | #9 |
Участник
|
Привет!
У меня была похожая проблема, когда включил трассировку в ODBC да и забыл отключить. Все тормозило жутко и файлик лога на 500МБ создался ...Хотя это, вероятно, не твой случай...
__________________
Успехов! Андрей Беседин |
|
05.09.2003, 12:08 | #10 |
Участник
|
кто нибудь знает на что влияет значение Fill factor в SQL ?
|
|
05.09.2003, 17:49 | #12 |
Шаман форума
|
Еще акзаптовским логом базы данных нужно уметь пользоваться... Системные таблицы там быть не должны.
|
|
05.09.2003, 18:04 | #13 |
Модератор
|
Интересная получается ветка. Человек задает вопрос, ответить на который, не зная некоторых деталей, нельзя. На наводящие вопросы он не отвечает, зато вступает в диалог с самим собой. А потом возникают обвинения в том, что от форума нет толка
Прошу не воспринимать как наезд |
|
08.09.2003, 10:13 | #14 |
MCTS
|
Цитата:
в момент "тормозов" sql забирает 96% процессорного времени, складывается впечатление, что axapta пересчитывает сальдо по всем периодам, в т.ч. и закрытым
Это следует сделать даже если AOS и SQL установлены вместе, только предварительно убедитесь, что именно SQL пожирает ресурсы. Согласен с Цитата:
Простой способ проверки - если стандартная версия на то же самом работает с нормальной скоростью, значит дело в модификациях. Если нет - значит, яйца тут не при чем.....
Цитата:
У меня была похожая проблема, когда включил трассировку в ODBC да и забыл отключить. Все тормозило жутко и файлик лога на 500МБ создался
Не используются ли у Вас на SQL какие-либо встроенные процедуры или тригеры? Если да, обратите на них повышенное внимание. В такой ситуации именно они могут оказаться источником проблемы.
__________________
Удачи. |
|
08.09.2003, 12:26 | #15 |
Участник
|
Может быть, все гораздо проще. Есть такое понятие клиент-серверная архитектура. И эта архитектура предпологает, что клиент находится на одной машине, а сервер на другой. Если суп и мухи оказываются вместе, то тут и возникают страшные тормоза. (Неоднократно проверено на собственном опыте )
Это утверждение, кстати, касается и .Net и любителей, которые любят тестировать эту технологию на локале, а потом удивляются, чего она так тормозит
__________________
Александр Игнатьев |
|