Одноврем. работа 100 юзеров с одинак.фун-лом

[RedFox]

Цитата:

Сообщение от dmites

задача насколько абстрактная, настолько же реальная
сеть из 100 магазинов, 100 пользователей через терминал подключаются к базе Navision (Nav4SP3 SQL2005).

Впечаляет, но уж как-то скомпоновато все странно. Почему не используется распределенная схема построения?
А может все-таки попытаться "разнести" на разные сервера?
И я не представляю себе какой именно сервер нужно будет соорудить, чтобы 100 Терминальных сессий нормально работали даже на 2003.

Цитата:

Основная деятельность - учет товародвижения (транзитные перемещения, реализация, инвентаризация)
Скорость учета док-та из 1000 строк в монопольном режиме 1,5 минуты
Перемещения (3-5 по 50 строк в день )учитываются равномерно в течении рабочего дня
реализация (1 док-т 50 строк) всеми - с 9 до 11 каждый день

Как бы проверить - а будет ли работоспособна вся эта кухня ?

Кухня может быть работоспособна, если слегка модифицировать NAV и разнести работы во времени и по периодичности в пространстве.
И при этом "отключить" или переделать всякого рода аналитики и переименовки. А так же провести в соответствие последовательность заполнения полей. А потом еще провести, по модному щас скажу, тюнинг самого SQL.
А если этого не сделать - будут ну просто постоянные блокировки. {аж страшно представить себе какие}

[Fordewind]

Цитата:

Сообщение от RedFox

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

В этом то как раз не проблема... отдельный терминальный сервак с 12 - 16 Гиг оперативки и запуском Nav (без рабочего стола).
А вот одновременный учет стольких документов.... Хм.. интересно..

А за какой период они должны все это учесть? Т.е. насколько важно учесть реализацию в 10 утра, а не в час ночи
Я бы предложил повесить весь учет на NAS, а менеджеры собственно проставляли бы тогда "галочки", какие документы учитывать. И блокировок не будет Надо будет еще оперативно рассылать сообщения юзерам, что у них в документе ошибка. В итоге вопрос сведется к необходимости "неотложного" учета и далее скорости учета через NAS

[dmites]

Цитата:

Сообщение от Fordewind

В этом то как раз не проблема... отдельный терминальный сервак с 12 - 16 Гиг оперативки и запуском Nav (без рабочего стола).
А вот одновременный учет стольких документов.... Хм.. интересно..

А за какой период они должны все это учесть? Т.е. насколько важно учесть реализацию в 10 утра, а не в час ночи
Я бы предложил повесить весь учет на NAS, а менеджеры собственно проставляли бы тогда "галочки", какие документы учитывать. И блокировок не будет Надо будет еще оперативно рассылать сообщения юзерам, что у них в документе ошибка. В итоге вопрос сведется к необходимости "неотложного" учета и далее скорости учета через NAS

Про терминальчик в яблочко, правда не один, а два предполагается ну да не в том проблема.
А вто про отложенный пакетный учет оч-ч-ч-ень интересно, это не с той же оперы когда народ учет перелопатил
все проверки перед учетом отдельно, а пакетный учет отдельно ? Не совсем правда понятно как быть, если 1 яблоко на остатке,
а двоим жаждущим (учесть) проверка сначала скажет, что нормуль - можете забирать, а ночью одного пошлет - извините - нема уже.

[Fordewind]

Цитата:

Сообщение от dmites

А вто про отложенный пакетный учет оч-ч-ч-ень интересно, это не с той же оперы когда народ учет перелопатил
все проверки перед учетом отдельно, а пакетный учет отдельно ?

в общем-то из этой... Можно подумать еще о такой схеме: с 9 до 11 создаются документы и ставятся галочки к учету. Где то в 13 (так что б на обед попасть) запускается NAS первый раз и пытается все учесть. Если где нашел ошибку, то шлет письма счастья составителям документов. Ну и потом второй учет ночью. Но это все теория.. надо смотреть "ближе к телу".

Цитата:

Сообщение от dmites

А одновременное резервирование не приведет к тем же блокировкам ?

но этих блокировок будет на порядок меньше, если они вообще возникнут

[RedFox]

Цитата:

Сообщение от Fordewind

но этих блокировок будет на порядок меньше, если они вообще возникнут

Вот как раз резервирование я бы не советовал делать под НАВ. Просто был проект, на котором было 50 пользователей и переделывали (доизобретали "упрощенную схему") именно резервирование, чтобы сделать меньше блокировок.

По поводу MERGE-репликации (по описанию вроде как напоминает это "ВСЕ-ВСЕМ") - по моему мнению не очень правильно. Так как я не знаю всех тонкостей, то могу только предположить, что основные справочники например, товары, должны быть введены в основную БД, а потом реплицироваться. Далее транзиты можно реплицировать по определенному справочнку (небольшая доделка на триггерах).

Можно попытаться продумать многоуровнеую звезду, если все завязано на регионах.
Продажи можно собирать в ЦО и центральном офисе.

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

[dmites]

Цитата:

Сообщение от RedFox

Впечаляет, но уж как-то скомпоновато все странно. Почему не используется распределенная схема построения?
А может все-таки попытаться "разнести" на разные сервера?

От распределенной (каждый магазин - своя база) как раз и уходим. Репликация через центральную базу - от всех все(учетн. таблицы, транзакции, документы) загрузи,
всем все (справочники, учетные записи постановки на транзит, документы для учета) выгрузи, умножаем на 50 реальных и процесс
уже с трудом умещается в рамки светового дня. А ожидается еще 50 .. Модный "Тюнинг Sql" уже юзается..
Как выход такая вот задумка с терминальной работой