Аксапта сильно тормозит

[komar]

Расчет простой - а если это "барахло" упадет, то каковы будут результаты для фирмы?
Приятного аппетита!

[Lazy_Tiger]

мдя. намекаю
1) рекомендации МБС по железу носят минимальный характер. я бы их умножал на некий коэффициент, зависящий от фин. возможностей компании

2) Эти рекомендации не включают в себя те доп. сервисы которые вы на бедную железку навесили. В частности задачи контроллера домена, почтовика, файло-помойки. наверняка там же висит DHCP, DNS, Wins и еще кучка всего интересного.
Еще бы прокси поставили для полного кайфа

3) не нада Оракл... у вас некому MS SQL администрировать даже на примитивном уровне и руководству жалко денег на 2 (ДВА!) курса по MS SQL стоимостью максимум в 500 баксов каждый. Чего уж говорить про оракл, курсы по которому стоят от 1000$ за штуку и которых отнюдь не два, а ближе к десятку... а готовый админ оракловый (приличный, коих в России совсем немного) стоит от 1500$ в месяц, часто больше 2000$

вообщем задача действительно сводится к арифметической. посчитать сколько денег компания потеряет от простоя этого компота в течении скажем дня. и я уверен, выяснится что стоимость 2-х нормальных серверов вместе с курсами по SQL вполне сравнима с возможными потерями. То, что рано или поздно оно рухнет я думаю доказывать не нужно

[Lazy_Tiger]

Цитата:

Изначально опубликовано Recoilme
"
Пишу сообщение, а справа слышу возглас программиста "этот долбанный SQL"
Дело в блокировках, не хотите мучаться ставьте Оракл, лучше мучаться с администрированием, чем с производительностью.

MS SQL (равно как и Оракл), экскалирует блокировки с уровня строк на страницы или даже таблицы, в основном когда ему памяти не хватает. Если конечно его специально не просить лочить сразу таблично например Так что не SQL долбанный, а просто памяти нехватает.

Perfomance monitor вместе с Enterprise Manager'ом внесет ясность в картину...

[Recoilme]

Цитата:

Изначально опубликовано Lazy_Tiger


MS SQL (равно как и Оракл), экскалирует блокировки с уровня строк на страницы или даже таблицы, в основном когда ему памяти не хватает. Если конечно его специально не просить лочить сразу таблично например Так что не SQL долбанный, а просто памяти нехватает.

Perfomance monitor вместе с Enterprise Manager'ом внесет ясность в картину...

Мдя....
Снимаю шляпу, я то всю жизнь заблуждался и думал что механизмы блокировки сиквеле и оракле носят принципиальные отличия... Вы ещё добавьте что и от парадокса оракл вобщем то только ценой отличается, да и между файл- сервером и клиент сервером разницы нет, главное железяк побольше да покруче напихать в серверную, а там прорвемся. Удачи.
Памяти не хватает, блин, поэтому он и блокирует
Вы случайно, сиквел не сэйлзите в свободное от работы время? (вопрос риторический)

[Lazy_Tiger]

да хоть чо снимайте мне цитаты из курсов и книжек по тюнингу MS SQL приводить или чо?

Да, я знаю что Оракл блокирует немного по другому, что он "почти версионник", но сути дела это вообщем то не меняет. Я намеренно упрощаю, чтобы не вдаваться в тех. подробности, которые людям на этом этапе не помогут, а только запутают

Как правило основная причина - нехватка памяти или если режим блокировок указываем руками. В _ИХ_ случае - нехватка памяти более чем очевидна.

P.S. Весь остальной стеб - пропущу мимо ушей, отмечу лишь что обладаю сертификатами MCDBA и OCP и знаю чем они (сервера) отличаются
P.P.S. знания SQL server 6.5-7.0 не помогут вам в случае SQL2000, там все маленько по другому. А судя по всему именно ими вы и обладаете.. Ничего личного

[Vadik]

Recoilme, того, что механизмы блокирования разные, никто не отрицает. Вот только не надо так презрительно фыркать по поводу зависимости блокировок от количества доступной памяти - поищите в BOL по словам Lock escalation и Locks option, может быть, Вы измените свое мнение.

P.S. все наши споры тут - немного шаманство. Представьте себе какой-нибудь форум, где тусуются медики. Туда приходит человек и говорит: "Ох, чтой-то у меня стреляет в ухе и колет в боку". И все, то есть симптомы - самые общие. Тот, кто скажет "у Вас, батенька, грипп" - наверное, немного поторопится

P.P.S. "долбаный MS SQL", "ацтой", "сакс" и "маздай" - не аргументы

[Recoilme]

Цитата:

Изначально опубликовано Vadik

P.P.S. "долбаный MS SQL", "ацтой", "сакс" и "маздай" - не аргументы

Ок, умолкаю, наверно просто наболело... и хочется уже изъясняться именно в этих терминах

[Lazy_Tiger]

плохому танцору все время что-то мешает. Вспомнилось

Впрочем, наверное это у меня неадекватная реакция на слово "Колумбус". Сорри

[Vadik]

нежнее, Виктор, нежнее (с)
давайте жить дружно

[May]

-"Идентификатор сессии должностн" - тоже отключаем, и в накладных, и в кассе

А где в Axapta 2.5. sp5 это можно сделать?

[Андре]

Цитата:

Да, я знаю что Оракл блокирует немного по другому, что он "почти версионник" ...

А если учесть, что новая версия MS SQL (а если Вы ориентируетесь на будущее, то следует учитывать и ее особенности ) тоже немного "версинник" - то спор вообще теряет смысл

[Lazy_Tiger]

а что, удалось посмотреть бету юкона? делитесь с общественностью

[Андре]

Если коротко то так: версионность там не состояние сервера, а скорее состояние конкретной базы - то есть, для каждой бд можно включить и отключить эту функциональность.
Версии транзакций собираются в специальном хранилище, которое расположено в tempdb. Собственно, благодаря особенностям tempdb и отсутствию журналирования для хранилища версий при обслуживании и чтении копий данных, нагрузка на операции ввода/вывода обещает быть минимальной.
Насчет уровней изоляции - в режиме версинника:
* read uncommited - не поддерживается ибо не нужно;
* read commited - все запросы на чтение работают как версионные, то есть если при чтении натыкаемся на заблокированную записть, то читается предыдущая версия из tempdb; при обновлении там несколько сложнее - если пытаться обновить записи, которые изменены но не зафиксированны - то ждать пока другая транзакция вроде как нельзя - так как после изменения запись может перестать удовлетворять критериям запроса. Чтоб этого не произошло многие реализации версионников просто перечитывают запись заново. Как я понял, в Yukon реализовывать таких сложностей, и все изменения делаются так же, как и в блокировочнике. Вплоть до побочного эффекта, связанного с блокированием всей таблицы по причине отсутствия индекса.
* repeatable read - в базе с включенной поддержкой версионности все работает точно так же, как и без оной.
* snapshot - как я заметил, работает так же как и в других версионниках - транзакция получает согласованный срез данных, начиная с первого обращения к данным, и все последующие изменения ее не касаются.
* serializable - похоже на то, что по механизму этот уровень изоляции является чисто блокировочным и никакие версионные запросы, даже на чтение, здесь не поддерживаются, если конечно, не давать специальных указаний оптимизатору.

Из остальных замеченных новшеств - хранимые процедуры на net языках, возможность создания своих агрегаирующих функций, все метаданные хранятся не в системных таблицах, а доступны из view (как в Oracle), была обещана row level security, но я ее не нашел; наконец-то разделены понятия схемы и владельца объекта (опять же как в Oracle ).

p.s. Вся информация относительно беты версии и ms не гарантирует правомерность всего вышесказанного в final версии.

[Lazy_Tiger]

ага... забавненько... бум ждать

[Recoilme]

По поводу блокировок: http://support.microsoft.com/default...b;en-us;323630

[Toner]

Кстати, на каком из массивов располагается SYSVOL? Уж не вместе ли с БД SQL? На физических дисках, на которых хранится Active Directory принудительно отключается кеширование записи. На производительность о-го-го как влияет между прочим. А вообще, конечно, для каждой серьезной задачи нужен отдельный сервер. Как интересно Вы Аксапту купили-внедрили, при таких скромных ресурсах?

[AKIS]

Здравствуйте!

Решил не заводить новую ветку, т.к. вопрос у меня близок к теме... хотя если модераторы очень будут настаивать, то заведу

Итак, в выходные попытались переключить рабочую базу с 2.5 на 3.0. Собственно миграция данных прошла вроде ничего - но дальше началась полная жэ.

При попытке стартовать 3.0 в нормальной 3-звенной структуре, на том же самом железе на котором до этого работала 2.5 - Аксапта просто УМИРАЕТ. 3 минуты грузится список заказов на покупку! При попытке создать новый - ваще уходит в отказ, висит глухо. Самое интересное - SQL Server. С 2.5 я НИ РАЗУ не видел чтобы он ощутимо замедлялся. Тут же он не просто висит - даже мышкой двинуть невозможно!

И это все - при ОДНОМ подключившемся клиенте!!!!

Надо сказать, что железо у нас конечно не ах, - но 2.5, повторяю, как-то работала. SQL сервер на Xeon 1Ггц, 1.5 Гб памяти, RAID 5. АОС послабже - 700 Мгц, 1 Гб - но, как я выяснил, он вообще не приделах, т.к. загружен был масксимум на 10%!

Ладно, я сперва все ж таки решил что виновато железо. Хрен с ним думаю, есть еще два сервака (ксати все - ИБМ-овские, не какое-то фуфло!). Поставил базу данных на Xeon 2.8 2 Гб, а АОС - на двух (!!) процессорный Xeon 2.6 2.5 Гб. Думаете сильно полегчало? НИ-ФИ-ГА! Точно также сиквел-сервер "лег" вмертвую!

Самое интересное: с "толстым" клиентом начинает кое-как шевелиться, а в двухзвенке ваще летает (правда это все, повторяю, для малого числа подключенных юзеров, до 5). Я почему-то считал что усе должно быть наоборот: трехзвенка должна быть самая шустрая, т.к. клиентские машины довольно слабые по сравнению с сервером.

В общем, это все даже не вопрос а скорее крик души. Меня конечно предупреждали, что трешка медленнее чем 2.5 - но чтобы НАСТОЛЬКО!!!!

Сейчас вот переключил все назад на 2.5 - небо и земля!

Я конечно проведу исследования методом "глубокого бурения" - посмотрю что конкретно тормозит, потрассирую запросы и т.п. Но все равно, не пойму я, почему так. Если все дело в сиквеле - получается, в 3.0 на него существенно возросла нагрузка? Засчет чего?

[Vadik]

Статистики в новой БД обновляли?
Попробуйте на ней sp_updatestats прогнать
Оять же Maintance paln натравить на новую базу не помешает
На большой БД да без статистик - вполне может съехать крыша у оптимизатора

дальше все стандартно:
- показатели perfmon-а
- долгие запросы
- блокировки
- версия MSSQL
- версия MDAC

[AKIS]

Собственно, база-то как бы не новая: взяли 2.5 рабочую, проапгрейдили стандартными средствами Аксапты... Я так подозреваю, что статистику она сама должна обновить, нет?

Maintenance plan на ней стоит...

Чувствую - не в этом дело

[AKIS]

Показатели perfmona - я ж говорю, мышкой шевельнуть не можу... 100% наверное...

Блокировки еще не смотрел.

MSSQL 2000 c 3-м сервиспаком.

MDAC - где, на клиенте? Вроде для трехзвенки не имеет значения? Хотя я его все равно обновил...