Не удалось перейти на 3-звенку

[Atani]

Хочу вынести на ваше обсуждение одну ситуацию, после которой нам пришлось отказаться от использования AOS и работать в двухзвенке.
Прошу не закидывать шапками.

Axapta 2.5 SP1,
MS SQL Server 2000

Все пользователи работали двухзвенке. Через некоторое время запустили AOS и примерно 15 пользователей были переведены на AOS Fat-client.
В такой конфигурации работали прмерно 1,5 месяца (примерно раз в неделю приходится перегружать SQL-сервер - это, наверное, отдельная лебединая песня). Потом на AOS Fat-Client была переведена большая группа пользователей.
Но не все. После этого всё стало жутко тормозить с зависаниями на операциях update.
Была запущена операция реиндексации базы, которая благополучно зависла и была снята, после чего база SQL-сервера отказалась открываться.
В воздухе витали фразы типа "база запорчена" и "AOS портит индексы при большом количестве пользователей"
Полечилось это, включая тормоза, так:
1. Файлы .mdf и .ldf скопировали в другое место;
2. Убили базу и создали её заново;
3. Подложили файлы на своё место и прикрутили к базе. После этого база "ожила".
4. Всех пользователей перевели обратно на толстого клиента, т.к. существование в двух архитектурах не устраивает по некоторым соображениям.

Вопросы:
Ваши оценки, предположения, что же реально произошло и с чем это было связано.
Может, моя ситуация уже давно известна и описана в Troubleshooting?..
Каковы должны были быть правильные действия по исправлению ситуации.
Каковы должны быть дейстия при следующей попытке перехода с 2- на 3-звенную архитектуру и каковы должны быть начальные условия (например, надо ли это делать глубокой ночью, когда все пользователи спят :-)).

Ну, и любые другие конструктивные комментарии приветствуются.

P.S. История отказа от AOS Thin-client мне известна хуже, поэтому её здесь не привожу.

[mazzy]

А при чем здесь AOS?
MS SQL любит ласку, чистоту и смазку. Ухаживать за ним надо

По существу:
FAT-Client... это... В общем, при чем здесь AOS?
Как AOS влияет на работу update и как он может "портить индексы", если у вас FAT-клиент?

[Atani]

Зависания начались сразу после перевода значительного числа пользователей на AOS. Зависания шли на операциях update, как показала отладка. В общем-то, больше они ничем не связаны...

[mazzy]

и вы смотрели в EM или в профайлере имя хоста, который долго отрабатывал update?
и это был AOS?

[Atani]

Нет, в EM и профайлер не лазили. Сконфигурили Аксапту для входа через AOS, вошли под программистским логином и трассировали код.

[Vadik]

Quote:

Изначально опубликовано Atani
Зависания начались сразу после перевода значительного числа пользователей на AOS. Зависания шли на операциях update, как показала отладка. В общем-то, больше они ничем не связаны...

Запросы, посылаемые любыми видами клиента - одинаковые. Так что AOS скорее всего не при чем, надо искать дальше. Индексы он, понятное дело, испортить неспособен. Перезагрузка SQL сервера раз в неделю - это, мягко скажем, нонсенс. То, как "подымали" БД - вообще говоря неверно, но будем считать, повезло.

Что делать? Последний SP на операционку сервера, SP3а на MSSQL и клиентов (MDAC 2.8 тоже лишним не будет). Обновить статистики, настроить Maintnance plan. Убедиться, что места на диске с журналом транзакций достаточно.

Это так, для начала

[Atani]

Да...
Обновление информации:
Базу не убивали и других операций не делали. Просто дождались таки, пока при запуске SQl-сервера она сама восстановится (recovery).
Возможно, свалилась база из-за того, что запустили реиндексацию и тоже, не дождавшись, сняли.
Но мне по-прежнему непонятно, почему при большом количестве пользователей именно в трёхзвенке (подключений к серверу сколько было, столько и осталось) Аксапта начала дико тормозить.

[mazzy]

Quote:

Изначально опубликовано Atani
Возможно, свалилась база из-за того, что запустили реиндексацию и тоже, не дождавшись, сняли.

Скорее всего, MS SQL у вас не свалился, а начал откатывать транзакицю.
Размер файла транзакций динамический?
Начальный размер какой? Размер дисков какой? Размер базы какой?
Файл транзакций находится на том же диске, что и сами данные?

[Vadik]

Quote:

Изначально опубликовано Atani
Но мне по-прежнему непонятно, почему при большом количестве пользователей именно в трёхзвенке (подключений к серверу сколько было, столько и осталось) Аксапта начала дико тормозить.

Сравните настройки в закладках Database в обоих конфигурациях. Где-то там у вас собака порылась. Например, в настройках юникода

[komar]

Насколько я понял, часть пользователей работала в двухзвенке, а часть - в трехзвенке с толстым клиентом? Это что за такое за извращение??
Может, у них еще и Application был разный?

[glibs]

Quote:

Изначально опубликовано komar
...Это что за такое за извращение??...

А можно узнать, почему это "извращение"? А если несколько АОСов в кластере (в их понимании этого термина) с одним приложением работают, это извращение или нет?

[Atani]

Совершенно верно, два Application'а.
Могло ли это аукнуться?

И вообще, известны ли какие-то особенности при работе в одновременно и в двухзвенке, и в трёхзвенке с разными Application? Только недавно на форуме узнал особенность, что список активных пользователей показывается для каждой архитектуры свой. А ещё?

[glibs]

Quote:

Изначально опубликовано Atani
...Только недавно на форуме узнал особенность, что список активных пользователей показывается для каждой архитектуры свой...

Не для архитектуры, а для приложения. Будет у вас 10 приложений — будет десять разных списков активных пользоватеоей. Сам не читал, но ходят слухи, что лицензионное соглашение запрещает использовать больше одного приложения (и, по-моему, трех баз, рабочей из которых м.б. только одна).

[mazzy]

Quote:

Изначально опубликовано Atani
Могло ли это аукнуться?

а то!

да, лицензионное соглашение запрещает.

но технически это можно провернуть.
правда, когда вы используете несколько приложений, требования к КОРРЕКТНОСТИ администрирования многократно возрастают. Поскольку на двух приложениях рассогласовать базы и приложения гораздо легче, чем на одном.

[glibs]

Quote:

Изначально опубликовано Atani
...После этого всё стало жутко тормозить с зависаниями на операциях update...

Уточните, наконец, что именно у вас тормозит (сервер СУБД или сами клиенты, причем только толстые или оба варианта) и в чем это проявляется.

[komar]

Извращение это потому, что разные приложения, как тут уже верно заметили, могут содержать разную бизнес-логику. Еще извращение потому, что смысла в одновременном использовании двухзвенки и толстых клиентов не видится никакого.
Варианты, которые мне понятны с точки зрания здравого смысла:
1. Двухзвенка. Пользователи в локальной сети, мощные клиентсике машины, нету АОСа.
2. Трехзвенка. Тонкие клиенты на "дохлых" или удаленных машинах, "толстые" - в хорошей сети.

А двухзвенка в сочетании с толстым клиентом - это для каких целей? Как в анекдоте про бензопилу?

[Atani]

2 Mazzy:
Для КОРРЕКТНОСТИ администрирования достаточно ли подменить второе приложение первым (т.е. сделать их одинаковыми по содержанию)? Есть ещё что-то?

2 glibs:
Тормозили клиенты в обоих вариантах, нагрузка на сервер была незначительная.

2 komar:
1. ....
2. ....
3. Постепенный перевод пользователей из двухзвенки в трёхзвенки в связи с постепенным прекращением горячих апдейтов ПО.
Кроме того слухи, что АОС "не работает"/"неправильно работает"/"глючит" на конфигурации Axapta 2.5 SP1.
Извините, слухи мной непроверенные, да и неоткуда взять пока информацию, кроме как из форума и доков.

[AKIS]

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

Проверьте, стоИт ли галка Initialize databze for Unicode на закладке Database параметров вашего АОСа. Проверьте также, указывали ли вы использование Юникодов в базе изначально. Если стоИт и если указывали (оба условия должны быть верными!) - уберите нафиг. Как выяснилось, это весьма распространенная бага. Суть в том, что "и там и там" должно быть одинаково, причем лучше всего, как я понял, если Юникоды вообще не используются. Возможно (мой humble бред), когда вы создали базу заново - она создалась с Юникодами, и все срослось, а до этого была без, и от этого висла...

[glibs]

Quote:

Изначально опубликовано komar
...Извращение это потому, что разные приложения, как тут уже верно заметили, могут содержать разную бизнес-логику...

Вообще я говорил об использовании одного приложения. Но даже в общем случае ваше утверждение одинаково применимо и для следующей ситуации.

Quote:

Изначально опубликовано komar
...Варианты, которые мне понятны с точки зрания здравого смысла:
1. Двухзвенка. Пользователи в локальной сети, мощные клиентсике машины, нету АОСа...

Что касается того, что приложения могут содержать различную бизнес-логику, то с Mazzy я полностью согласен. Все дело в администрировании (сюда я отношу и то, какая в компании политика относительно ведения разработки на рабочем приложении).

Quote:

Изначально опубликовано komar
...Еще извращение потому, что смысла в одновременном использовании двухзвенки и толстых клиентов не видится никакого...

...А двухзвенка в сочетании с толстым клиентом - это для каких целей? Как в анекдоте про бензопилу?...

Хм... я ожидал услышать объективные аргументы, например, что есть технические проблемы или баги. Если у вас такие данные есть или встретятся в дальнейшем, буду благодарен за информацию.

PS. На всякий случай убедительная просьба не расценивать это как наезд или что-либо еще в этом роде. Просто проблема мне довольно интересна.

PS2. Прошу прощения за offtopic.

[komar]

Просто само по себе это не есть целесообразно. То есть подумать не "почему бы не сделать вот эдак" а сначала "зачем делать вот эдак".


А про возможные глюки - это сюда

http://technet.navision.com/workspac...tribId=1&wso=1

Опять-таки была информация, что смешанная конфигурация как минимум добавляет головной боли
http://www.axforum.info/forums/showt...=&threadid=697

Я просто не вижу никакой причины, которая могла бы вынудить использовать толстый клиент и двухзвенку одновременно. Тонкий клиент и двухзвенка теоретически может возникнуть из желания сэкономить на лицензиях на AOS.
Про апдейты не понял - а зачем все-таки одновременно их держать?? Ну, разрабатывали на двухзвенке, теперь хотите использовать на трехзвенке....опять-таки - зачем, если все равно тонкого клиента не будет никогда??? я логики не вижу в такой архитектуре.
Она и не должна работать, по-моему, раз смысла в ней нет.
К создателю темы вопрос - а если запускать все только через AOS, без двухзвенки, проблема остается?