Детальные пояснения помогают дать дополнительные советы



Posted by Анатолий Анимица (194.177.32.67) on February 28, 2001 at 10:49:52:

In Reply to: Поясняю детальнее ... posted by Алексей Смирнов on February 28, 2001 at 06:33:04:

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

1. Поясняю еще раз вопрос по пересбивке баланса (возможно, происходит и не пересбивка, а реинициализация сервера, Аркадию Водянику лучше знать). Журнал операций вкратце выглядит так:


Номер Дата Штамп
1 1 AAAA-001
2 1 AAAA-002
3 1 AAAA-003
4 2 AAAA-004
........

и т.д., причем кол-во операций за 2 число не имеет значения.
Важно то, что операции за 2 число последние в журнале, за ними нет
ничего.

Оператором удаляются все операции за 2 число и после этого вводится
операция по порядку за 1 число. Сервер начинает что-то впустую пересчитывать,
принимая операции null за введенные оператором.
Почему нельзя в данном случае что-то предусмотреть?

Ответ. Даже если удалить тысячу операций (они заменятся на null - так устроен сервер ФБП), правильно сконструированная система пройдет эти 1000 null при пересбивке баланса не более чем через одну-две миллисекунды. Следовательно, если удалена тысяча последних операций, задержка в получении баланса против такой же базы с удаленными null составит дополнительно эту самую миллисекунду. Вывод: если это заметно глазу, система занимается чем-то не тем, и удаление null в хвосте журнала операций мало от чего спасет. Я поисследовал Ваш случай ограничением объема ОП в моей машине до 64Мб на базе, которая обычно работает в PIII-700 (как у меня) с 256Мб ОП и получил примерно Ваши результаты - 100 операций в секунду после процедуры, какжется, впервые детально описанной здесь на WWWBOARD Александром Гратулевичем:
старт сервера - % - %- - p mc=1 dc=1 - %
, т.е. заранее очищены все счетчики профилера, отключены затраты на контроль дескрипторов первичных документов и т.п.

Я уже писал о том, что отвлечение сервера на радикальную реконфигурацию файлов (в данном случае - усечение *.f3p "с хвоста") потребует гораздо больших затрат времени.

Но Ваше предложение можно сформулировать лучше: неплохо заложить в архитектуру сервера запрос "кондиционировать null". Такой запрос мог бы быть монопольным и приоритетным, т.е. требовать предварительного включения m on. В этом случае можно было бы не прибегать к утилитам типа dnu.exe. Это да. С Вашего позволения такую формулировку я и оставлю для обсуждения.

Но (начинаем обсуждение): в так называемых боевых системах процент удаленных операций по моему опыту редко поднимается выше 10(%). Это а) ошибки операторов, б) ошибки классификации, т.е. ошибки бухгалтеров, и в) улучшения базы данных - бухгалтеру иногда не сразу удается найти наилучшее отражение бухгалтерского события в виде одной или группы операций ФБП.
Все, что выше - это обычно или не законченная настройка системы, или обучение оператора, или виртуальная реальность. Четвертого не дано. Можно оценить с этой точки зрения, нужен ли прямо сейчас механизм отсечения хвоста у ящерицы 200101.f3p, или раньше нужно сделать что-то еще. Вопрос оставляю открытым.

И еще. Я давал совет, но не увидел ответа: Алексей, я не нашел в Вашем сообщении, а Вы нашли еще 128Мб, чтобы попробовать свою систему на машине с 256Мб ОП?

2. ...есть 300 и более операций за день ... 101-ю операцию случайно у д а л и л и. Имеем
299 операций и null. Вопрос заключается в том, как теперь вставить 101-ю
операцию, уже имея для нее зарезервированное место (тот самый null).

Ответ. Теперь вопрос четко сформулирован! В первом сообщении такой формулировки не было. Очевидно, такая жесткость требования даже избыточна. Вместо данного конкретного null можно использовать любой рядом находящийся null - лишь бы положение вновь введенной операции не изменилось по отношению к оставшимся в живых. То есть это даже не вопрос, а предложение - некоей "суперкорзины" - очевидно, операция будет возвращена на место не всегда точно в том виде, в котором она была перед удалением. Нет, правда, мне понравилось. Надо обсудить.
А пока рецепт (или совет): а попробуйте удаление заменить редактированием операции - вместо "Касса приход напишите операцию NULL! (или null+, или вообще ---), без проводок с суммой 0.
То есть в дереве должна быть ветка null! с проводкой x x (0). Конечно, в клиенте Windows для этого потребуется вместо F8-Enter нажать Enter-null!-комментарий-Enter. Штамп останется - и тем самым вправду останется место для ввода случайно удаленной операции. Понятно, если свободной ветви первого уровня нет, можно взять N-ю, будет на N-1 Enter больше.

3.Что касается [ir]. Сообщение об ошибке на Доску не выставлялось.

Ну так выставьте, народ интересуется.

Все остальное мало существенно.
1. Полемики на тему Вашего сообщения не было. Это Вы зря. Есть обсуждение ряда интересных вопросов попутно у меня с Александром - ну так мы просто ждали, когда Вы напишете про то, как система отзовется на дополнительные 128Мб.
2.... Я представился как п р о г р а м м и с т, а не как программист т о л ь к о ФБП.
Э, батенька, здесь немного не так. В наше непростое время программистами называют себя (речь не о Вас - ни в коем случае) люди, умеющие собрать в одном месте несколько объектов и сумевшие заставить их работать. В случае с ФБП как минимум требуются еще и алгоритмические основы ремесла. Именно эту сторону труда программиста я и имел в виду, коротко изложив требования к профессиональному программисту, который требуется для работы с ФБП. Кажущаяся легкость программирования на "Финансах без проблем" исчезает, когда дело доходит до ресурсоемких алгоритмов, и здесь, бывает, необходимо применить весь или мировой, или свой опыт оценки сложности алгоритма. Ну, я об этих штучках много писал - всякие там циклы в цикле, N-квадраты и так далее. Эти сообщения - как и мой первый ответ на Ваше сообщение - следует рассматривать в единственном контексте. Я хочу, чтобы: а) настройки, которые производят наши пользователи и дилеры, были компактными, быстрыми и правильными - алгоритмически правильными, если быть точным, и б) чтобы пользователи и дилеры не тратили на это все свои силы и время, а дилеры за единицу времени могли запустить не одну систему, а две. Или больше. А для этого опять же требуется не заниматься непроизводительным трудом.

Ну вот и все пока. Спасибо за внимание.
ААА




Пpишедшие ответы: