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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 13.02.2008, 17:21   #1  
dmites is offline
dmites
Участник
Аватар для dmites
 
221 / 14 (1) ++
Регистрация: 10.08.2005
задача насколько абстрактная, настолько же реальная
сеть из 100 магазинов, 100 пользователей через терминал подключаются к базе Navision (Nav4SP3 SQL2005).
Основная деятельность - учет товародвижения (транзитные перемещения, реализация, инвентаризация)
Скорость учета док-та из 1000 строк в монопольном режиме 1,5 минуты
Перемещения (3-5 по 50 строк в день )учитываются равномерно в течении рабочего дня
реализация (1 док-т 50 строк) всеми - с 9 до 11 каждый день

Как бы проверить - а будет ли работоспособна вся эта кухня ?
Старый 13.02.2008, 18:15   #2  
RedFox is offline
RedFox
Участник
 
1,441 / 10 (0) +
Регистрация: 28.12.2004
Адрес: Киев
Цитата:
Сообщение от dmites Посмотреть сообщение
задача насколько абстрактная, настолько же реальная
сеть из 100 магазинов, 100 пользователей через терминал подключаются к базе Navision (Nav4SP3 SQL2005).
Впечаляет, но уж как-то скомпоновато все странно. Почему не используется распределенная схема построения?
А может все-таки попытаться "разнести" на разные сервера?
И я не представляю себе какой именно сервер нужно будет соорудить, чтобы 100 Терминальных сессий нормально работали даже на 2003.
Цитата:
Основная деятельность - учет товародвижения (транзитные перемещения, реализация, инвентаризация)
Скорость учета док-та из 1000 строк в монопольном режиме 1,5 минуты
Перемещения (3-5 по 50 строк в день )учитываются равномерно в течении рабочего дня
реализация (1 док-т 50 строк) всеми - с 9 до 11 каждый день

Как бы проверить - а будет ли работоспособна вся эта кухня ?
Кухня может быть работоспособна, если слегка модифицировать NAV и разнести работы во времени и по периодичности в пространстве.
И при этом "отключить" или переделать всякого рода аналитики и переименовки. А так же провести в соответствие последовательность заполнения полей. А потом еще провести, по модному щас скажу, тюнинг самого SQL.
А если этого не сделать - будут ну просто постоянные блокировки. {аж страшно представить себе какие}
Старый 13.02.2008, 18:33   #3  
Fordewind is offline
Fordewind
Участник
 
1,134 / 10 (3) +
Регистрация: 01.12.2005
Цитата:
Сообщение от RedFox Посмотреть сообщение
И я не представляю себе какой именно сервер нужно будет соорудить, чтобы 100 Терминальных сессий нормально работали даже на 2003.
В этом то как раз не проблема... отдельный терминальный сервак с 12 - 16 Гиг оперативки и запуском Nav (без рабочего стола).
А вот одновременный учет стольких документов.... Хм.. интересно..

А за какой период они должны все это учесть? Т.е. насколько важно учесть реализацию в 10 утра, а не в час ночи
Я бы предложил повесить весь учет на NAS, а менеджеры собственно проставляли бы тогда "галочки", какие документы учитывать. И блокировок не будет Надо будет еще оперативно рассылать сообщения юзерам, что у них в документе ошибка. В итоге вопрос сведется к необходимости "неотложного" учета и далее скорости учета через NAS
Старый 13.02.2008, 20:58   #4  
dmites is offline
dmites
Участник
Аватар для dmites
 
221 / 14 (1) ++
Регистрация: 10.08.2005
Цитата:
Сообщение от RedFox Посмотреть сообщение
Впечаляет, но уж как-то скомпоновато все странно. Почему не используется распределенная схема построения?
А может все-таки попытаться "разнести" на разные сервера?
От распределенной (каждый магазин - своя база) как раз и уходим. Репликация через центральную базу - от всех все(учетн. таблицы, транзакции, документы) загрузи,
всем все (справочники, учетные записи постановки на транзит, документы для учета) выгрузи, умножаем на 50 реальных и процесс
уже с трудом умещается в рамки светового дня. А ожидается еще 50 .. Модный "Тюнинг Sql" уже юзается..
Как выход такая вот задумка с терминальной работой
Старый 13.02.2008, 21:03   #5  
dmites is offline
dmites
Участник
Аватар для dmites
 
221 / 14 (1) ++
Регистрация: 10.08.2005
Цитата:
Сообщение от Fordewind Посмотреть сообщение
В этом то как раз не проблема... отдельный терминальный сервак с 12 - 16 Гиг оперативки и запуском Nav (без рабочего стола).
А вот одновременный учет стольких документов.... Хм.. интересно..

А за какой период они должны все это учесть? Т.е. насколько важно учесть реализацию в 10 утра, а не в час ночи
Я бы предложил повесить весь учет на NAS, а менеджеры собственно проставляли бы тогда "галочки", какие документы учитывать. И блокировок не будет Надо будет еще оперативно рассылать сообщения юзерам, что у них в документе ошибка. В итоге вопрос сведется к необходимости "неотложного" учета и далее скорости учета через NAS
Про терминальчик в яблочко, правда не один, а два предполагается ну да не в том проблема.
А вто про отложенный пакетный учет оч-ч-ч-ень интересно, это не с той же оперы когда народ учет перелопатил
все проверки перед учетом отдельно, а пакетный учет отдельно ? Не совсем правда понятно как быть, если 1 яблоко на остатке,
а двоим жаждущим (учесть) проверка сначала скажет, что нормуль - можете забирать, а ночью одного пошлет - извините - нема уже.
Старый 14.02.2008, 09:26   #6  
DA_NEAL is offline
DA_NEAL
Участник
Аватар для DA_NEAL
Лучший по профессии 2017
Лучший по профессии 2009
 
788 / 54 (3) ++++
Регистрация: 05.08.2002
Адрес: Королев
Резервирование используйте.
__________________
Want to believe...
Старый 14.02.2008, 10:00   #7  
dmites is offline
dmites
Участник
Аватар для dmites
 
221 / 14 (1) ++
Регистрация: 10.08.2005
Итак однозначно проблемы будут с блокировками (без переделки) и не факт ,что юзвери в конец не озвереют от постоянных зависаний
проверить эмпирически не представляется возможным,а опыт подобного у кого-либо нет...
Старый 14.02.2008, 10:03   #8  
dmites is offline
dmites
Участник
Аватар для dmites
 
221 / 14 (1) ++
Регистрация: 10.08.2005
Цитата:
Сообщение от DA_NEAL Посмотреть сообщение
Резервирование используйте.
А одновременное резервирование не приведет к тем же блокировкам ?
Старый 14.02.2008, 10:14   #9  
Fordewind is offline
Fordewind
Участник
 
1,134 / 10 (3) +
Регистрация: 01.12.2005
Цитата:
Сообщение от dmites Посмотреть сообщение
А вто про отложенный пакетный учет оч-ч-ч-ень интересно, это не с той же оперы когда народ учет перелопатил
все проверки перед учетом отдельно, а пакетный учет отдельно ?
в общем-то из этой... Можно подумать еще о такой схеме: с 9 до 11 создаются документы и ставятся галочки к учету. Где то в 13 (так что б на обед попасть) запускается NAS первый раз и пытается все учесть. Если где нашел ошибку, то шлет письма счастья составителям документов. Ну и потом второй учет ночью. Но это все теория.. надо смотреть "ближе к телу".

Цитата:
Сообщение от dmites Посмотреть сообщение
А одновременное резервирование не приведет к тем же блокировкам ?
но этих блокировок будет на порядок меньше, если они вообще возникнут
Старый 14.02.2008, 11:10   #10  
RedFox is offline
RedFox
Участник
 
1,441 / 10 (0) +
Регистрация: 28.12.2004
Адрес: Киев
Цитата:
Сообщение от Fordewind Посмотреть сообщение
но этих блокировок будет на порядок меньше, если они вообще возникнут
Вот как раз резервирование я бы не советовал делать под НАВ. Просто был проект, на котором было 50 пользователей и переделывали (доизобретали "упрощенную схему") именно резервирование, чтобы сделать меньше блокировок.

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

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

P.S. Вы сможете гарантировать себе, что связь у Вас не пропадет ни при каких обстоятельствах?
Старый 14.02.2008, 16:38   #11  
rmv is offline
rmv
Участник
 
481 / 11 (1) +
Регистрация: 15.02.2005
Цитата:
Сообщение от dmites Посмотреть сообщение
А одновременное резервирование не приведет к тем же блокировкам ?
Не думаю если за учет будет отвечать отдельный процесс (NAS) или учет будет происходит по вечерам.
Если все же возникнут проблемы с блокировками с ними гораздо проще бороться нежели с блокировками при учете.
Вплоть до разделения диапазонов Entry No. в Reservation Entry для филиалов (если каждый филиал будет отгружать со своего склада).
Старый 14.02.2008, 17:19   #12  
RedFox is offline
RedFox
Участник
 
1,441 / 10 (0) +
Регистрация: 28.12.2004
Адрес: Киев
Цитата:
Сообщение от rmv Посмотреть сообщение
Не думаю если за учет будет отвечать отдельный процесс (NAS) или учет будет происходит по вечерам.
Извините, но не понял как разнесенный (отсроченное) учет и резервирование связано?
Вот именно, - когда начнут все эти 100 пользователей колбасить заказы, то мы просто получил залоченную 337 таблицу!
Цитата:
Если все же возникнут проблемы с блокировками с ними гораздо проще бороться нежели с блокировками при учете.
Ну возможно вообще создать временную таблицу со строками, связанными с 37, 5740 и просто заносить туда строки с товарами, которые еще можно продавать. И при этом производить сравнение наличия и резерва. А потом уже, отдельным процессом все скопом резервировать..

Можно еще много чего придумать под требования.

Цитата:
Вплоть до разделения диапазонов Entry No. в Reservation Entry для филиалов (если каждый филиал будет отгружать со своего склада).
А зачем разделять там по диапазонам, если там все под Заказы и так разделяется?
Старый 14.02.2008, 17:46   #13  
Fordewind is offline
Fordewind
Участник
 
1,134 / 10 (3) +
Регистрация: 01.12.2005
Цитата:
Сообщение от RedFox Посмотреть сообщение
Вот именно, - когда начнут все эти 100 пользователей колбасить заказы, то мы просто получил залоченную 337 таблицу!
А вот это уже надо будет проверить. Ведь строки вбиваются по одной и резервируются по одной.
Старый 14.02.2008, 18:03   #14  
rmv is offline
rmv
Участник
 
481 / 11 (1) +
Регистрация: 15.02.2005
Цитата:
Сообщение от RedFox Посмотреть сообщение
Извините, но не понял как разнесенный (отсроченное) учет и резервирование связано?
Вот именно, - когда начнут все эти 100 пользователей колбасить заказы, то мы просто получил залоченную 337 таблицу!
При учете резервы снимаются. Подозреваю что не без LockTable.
Но даже если и без - Locktable на резервировании будет мешать снятие резервов. Вывод - при одновременном учете и резервировании
вероятность блокировать увеличивается.

Цитата:
Сообщение от RedFox Посмотреть сообщение
Ну возможно вообще создать временную таблицу со строками, связанными с 37, 5740 и просто заносить туда строки с товарами,
которые еще можно продавать. И при этом производить сравнение наличия и резерва.
А потом уже, отдельным процессом все скопом резервировать..
Можно еще много чего придумать под требования.
Если правильно понял Вы предлагаете использовать temporary table.
Интересное решение . Яблок конечно всем хватит.. но токо до момента учета .
Или есть способ юзеру залесть во временную таблицу другого юзера?
В противном случае чем Ваше предложение отличается 32 таблицы (Positive=true - товар которые еще можно продавать)
+ 337 - резервы на эти товары?


[quote=RedFox;364169]
А зачем разделять там по диапазонам, если там все под Заказы и так разделяется?
[quote=RedFox;364169]

К сожалению (или счастью?) номера документа не включен в PK 337 таблицы.
Напоминаю тему обсуждения - уменьшить вероятность блокировок.
Поясняю свою мысль:
1. Принимаем решение - разделяем 337 на диапазоны по филиалам
А - 0..1000000
Б - 10000000..20000000

2. Везде в резервировании заменяем код поиска последнего Entry No. с одновременной блокировкой таблицы
(LockTable; Find('+); )
на примерно след.
(setfilter("Entry No.", GetFilialFilter); :Locktable; Find('+'));

Что получили
А и Б одновременно резервируют
A:
setfilter(0..1000000);
find('+');
последняя запись 300 (только ее и (или) на Сиквеле экстент залочит сервер)

Б:
setfilter(1000000..2000000);
find('+');
последняя запись 10000500 (только ее и (или) на Сиквеле экстент залочит сервер)
А и Б мешать друг другу не будут.
Заметьте - другие пользователи из филиалов буду ждать освобождения своих диапазонов.

Вывод:
У каждого филиала 337 таблица будет залочена только в своем диапазоне (кроме случаев когда последние записи 2 филиалов будут
в одном экстенте - такое будет только при небольшом числе записей в 337, обойти можно также вставив пустышки)
и возможно одновременное резервирование

Ремарка про склад - locktable все же хорошая функция, позволяет не зарезервировать 2 раза один и тот же товар.
Старый 14.02.2008, 19:07   #15  
RedFox is offline
RedFox
Участник
 
1,441 / 10 (0) +
Регистрация: 28.12.2004
Адрес: Киев
Цитата:
Сообщение от Fordewind Посмотреть сообщение
А вот это уже надо будет проверить. Ведь строки вбиваются по одной и резервируются по одной.
Я уже 1 раз проверял и мне достаточно ;-) как по мне - не учень приятное зрелище. И особенно когда вокруг тебя куча "веселых" Торговых.
Если хотите, то можете организовать "показательные работы". Заодно может и поделитесь Вашей статистикой.

Цитата:
Сообщение от rmv
При учете резервы снимаются. Подозреваю что не без LockTable. Но даже если и без - Locktable на резервировании будет мешать снятие резервов. Вывод - при одновременном учете и резервировании вероятность блокировать увеличивается.
Согласен, что при учете БУДУТ блокировки. Но я имел ввиду блокировки еще те блокировки, когда пользовать еще только набирает Заказ. Удаление из 337 таблицы будет "быстрее", чем "вставка".

Цитата:
Если правильно понял Вы предлагаете использовать temporary table...
К сожалению, Вы не правильно меня поняли. Я имел ввиду именно временную таблицу для занесения строк резерва, а не Свойство Таблицы = Temporary. И проверка тут на 100% покрытие (НЕ резервирование) и на сравнение по наличному кол-ву в системе на текущий момент.
Да и идея была за 5 минут ;-) Если нужен 100% работоспособный быстро-модифицируемый оптимизированный механизм - это другое совсем дело! Там не только 1 таблица, но еще несколько полей в другой

Кстати, при желании можно залезть в не системную таблицу средствами SQL и вставка 1 строки в незагруженную таблицу будет быстрее, чем дополнительное прочтение (кстати, опять с блокировками) из другой (будет JOIN)

Цитата:
... У каждого филиала 337 таблица будет залочена только в своем диапазоне ...
Идея очень хорошая, но она все равно приводит к блокировкам записей в таблице, которых я бы не стал делать..
Но советую еще кроме таких изменений зайти в SSProfiler+DTA и поотпимизировать. + Чтобы не вылазить за диапазон, изменять периодически номера в данной таблице (иначе можно не угадать с размерность диапазона).
Старый 15.02.2008, 09:50   #16  
dmites is offline
dmites
Участник
Аватар для dmites
 
221 / 14 (1) ++
Регистрация: 10.08.2005
С диапазоне уже работаем, каждый работает в своем и всё это сливается в общую базу. Кстати проверяли на одновременный учет - был достигнут немного нестандартным способом. Допустим База общая + две базы Магазин1 и магазин 2. Убиваем в магазине учетные таблицы
32, 5802 и т.д. Делаем View этих таблиц, берущую нужный диапазон соответствующей таблицы из общей базы и вуаля- все работает. счастье возможно, но
если сделать общим справочник Item надо отключать коррекцию себестоимости в карточке иначе лочка
во базе где используется View надо либо убрать все sift-поля, либо на все делать view
И счастье заканчивает как только общей становится 83 таблица, где записей мало и лочка цепляет "соседа"
Старый 15.02.2008, 10:49   #17  
RedFox is offline
RedFox
Участник
 
1,441 / 10 (0) +
Регистрация: 28.12.2004
Адрес: Киев
Цитата:
Сообщение от dmites Посмотреть сообщение
С диапазоне уже работаем, каждый работает в своем и всё это сливается в общую базу. Кстати проверяли на одновременный учет - был достигнут немного нестандартным способом. Допустим База общая + две базы Магазин1 и магазин 2. Убиваем в магазине учетные таблицы 32, 5802 и т.д. Делаем View этих таблиц, берущую нужный диапазон соответствующей таблицы из общей базы и вуаля- все работает. счастье возможно, но
ну правильно - все будет работать... Это же 2005 и потому что Представление это нехранимая/хранимая процедура с условиями на таблицу. Правда если пропадает связь, то будет проблемка
Цитата:
если сделать общим справочник Item надо отключать коррекцию себестоимости в карточке иначе лочка
Можно попробовать включить версионность (хранение в TempBD), но пока они сделали только для всей БД, а не таблиц. Но я думаю, что в след. версии уже будет такое.
Цитата:
во базе где используется View надо либо убрать все sift-поля, либо на все делать view
И счастье заканчивает как только общей становится 83 таблица, где записей мало и лочка цепляет "соседа"
Да... и в таком случае нужно делать каждый раз новый Раздел
Старый 15.02.2008, 11:27   #18  
rmv is offline
rmv
Участник
 
481 / 11 (1) +
Регистрация: 15.02.2005
Цитата:
Сообщение от dmites Посмотреть сообщение
С диапазоне уже работаем, каждый работает в своем и всё это сливается в общую базу. Кстати проверяли на одновременный учет - был достигнут немного нестандартным способом. Допустим База общая + две базы Магазин1 и магазин 2. Убиваем в магазине учетные таблицы
32, 5802 и т.д. Делаем View этих таблиц, берущую нужный диапазон соответствующей таблицы из общей базы и вуаля- все работает. счастье возможно, но
если сделать общим справочник Item надо отключать коррекцию себестоимости в карточке иначе лочка
во базе где используется View надо либо убрать все sift-поля, либо на все делать view
И счастье заканчивает как только общей становится 83 таблица, где записей мало и лочка цепляет "соседа"
Тоже разделял учет на одном из проектов и тоже для консолидации.
Но пошел на мой взгляд более простым путем -
изменил учетные кодеюниты, так чтобы номера операции брались из своих диапазонов.
Старый 15.02.2008, 12:31   #19  
dmites is offline
dmites
Участник
Аватар для dmites
 
221 / 14 (1) ++
Регистрация: 10.08.2005
так вот и думаем - с view-ми огород городить накладно, нестандартно и т.д. Если диапазоны сохранить да запустить всех в 1 базу, с учетными таблицами проблем нет - записей за несколько лет позволяют физически разделяют экстенты пользователей. В каждом диапазоне работает 1 чел.
Но справочники и журналы то одни,тут блокировок не избежать...
Старый 15.02.2008, 13:02   #20  
RedFox is offline
RedFox
Участник
 
1,441 / 10 (0) +
Регистрация: 28.12.2004
Адрес: Киев
Цитата:
Сообщение от dmites Посмотреть сообщение
... - записей за несколько лет позволяют физически разделяют экстенты пользователей. В каждом диапазоне работает 1 чел.
Извините не догнал полет мысли (честно, без обид, не придираюсь ), но общий смысл понятен.
Цитата:
Но справочники и журналы то одни,тут блокировок не избежать...
Ага, и первым делом получите на 36+37 при создании и резервировании, а потом при учете на журналах и измерениях
 

Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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