Re: Незавершенная транзакция



Posted by Анатолий Анимица on June 05, 1999 at 11:05:56:

In Reply to: Незавершенная транзакция posted by Evgen A. Palamarchuck on June 04, 1999 at 03:41:15:

Незавершенные транзакции и статистика отказов в системах на платформе ФБП

В ответ на вопрос Евгения Паламарчука о надежности контроля целостности транзакций в ФБП попытаюсь изложить имеющиеся у меня данные (за последние два-три года, 1996-1999, более ранние уже не актуальны), и опишу эксперимент сегодня.
1. Сначала о незавершенных транзакциях.
В "чистых" клиент-серверных системах, к которым относится ФБП, проблема целостности транзакций стоит, но совсем не так, как в файл-серверах (далее ФСС).
В ФБП, если запрос клиента, в том числе групповой, принят сервером, информация о запросе запоминается в одном единственном месте - в файле *.f3p, *.a3p, или extrd.dat. Если в запросе сервер не обнаружил ошибок, если при при обработке запроса не выключат Днепрогэс, транзакция будет принята сервером, и с этого момента ответственность за сохранность данных лежит уже на операционной системе, а не на сервере ФБП. Тем не менее, в моей практике есть два почти одинаковых случая, которые не удалось надежно воспроизвести, когда сервер (тогда V.2.17. или V.2.23, уже не помню) от клиента clw.exe принял групповой запрос, причем в одной из операций было задано недопустимое значение переменной. Сервер ФБП, вместо того, чтобы отвергнуть всю группу, принял все операции, кроме содержащей ошибку, и зарегистрировал соотвественно не все заявленные операции. То есть не был произведен "откат" транзакции, и вместо этого была зарегистрирована ошибочная транзакция.
Следовательно, риск регистрации неполной (ошибочной) транзакции не опровергнут.
К сожалению, это вся имеющаяся у меня статистика. Исследование, предпринятое тогда (в 1997 г.) совместно с Хакерс Дизайн, не дало результатов. Моделирование ситуации было повторено сегодня. Операция - один вопрос без указания типа данных в баллоне (переменная вопроса Q1), одно @-обращение, один файл-коэффициент, который контролирует [type Q1] и выдает ошибку, если [type Q1]=1. Груповая операция - несколько @-отборов, всем Q1=1, кроме одного Q1='не1'.
Результат: сервер (29h,20.04.99) сообщил об ошибке, ни одной операции не зарегистрировал, правда, скобки { и }
остались в 199906.f3p на память о безуспешной попытке обмануть сервер.
Резюме: тщательно контролируйте фильтры типов и диапазон значений входных данных, тогда меньше будет случаев браковки транзакций сервером. ФБП надежнее любых файл-серверов с любыми механизмами блокировок, но синтаксическая корректность входящего запроса упрощает задачу донельзя.Так как структура запроса формируется пользователем (с фильтрацией в настройках), анализ надежности запрета синтаксически ошибочных запросов требуется
производить при проектировании конструкций запросов.
2. А теперь о повреждениях, разрушениях, отказах в обслуживании и так далее. Я практически работаю с несколькими десятками систем (не сто, а, скорее, 20). В основном используются серверы fn2win95, но число пользователей различное, от 1 до 10..15 клиентов на сервер. И несолько fnt с тем же числом клиентов. Не скажу, чтоб очень большие базы данных, попробую привести максимумы по отдельным.
2.1. Количество контрагентов (60,62,76) - несколько тысяч (скажем, 1500..2000) справочно - это довольно крупный магазин, 10 отделов, 20..40 накладных в день, до 100 платежей на сч.60 в день. Работает 3 машины, причем часто вместо сервера запускают ultraF, иногда с копированием текущей базы на остальные машины (для анализа и прочего, не для внесения данных в базу). 2..3 бухгалтера и 3..6 менеджеров делят эти три машины и все успевают. Система требует моего обслуживания только в режиме "давно не был, соскучились". За три года эксплуатации - ни ОДНОГО разрушения базы или отказа в обслуживании. Я их постоянно пугаю жареными петухами, но архивируют ежедневно только первую неделю после посещения или по напоминанию, а так - от случая к случаю.
2.2. Количество единиц номенклатурного учета (01,10,12,SKLAD,SKLADS)-около 20000. Автобаза, около 200 автомобилей, не круглосуточная работа. 4 машины. Fn2win95. 3 бухгалтера, кладовщик и сменный диспетчер (их четверо, но клиент 1). Очень большая номенклатура запчастей, естественно. Итоги те же. Разрушения данных - 3 раза за три года. Два из-за выключения машины на ходу сервера (с питанием у них плохо, помехи, и не очень надежное вообще, но UPS так и не поставили) в момент создания счета: acn.a3p - недозаписан(2-8МБ) при acnt.bak около 30 МБ.
В первый раз, когда это у них произошло, пришлось консультировать по телефону, во второй раз справились сами - потом хвастались, что восстановились за пять минут. И один раз по собственной неосторожности - с тем же итогом и результатом. ДРУГИЕ ДАННЫЕ НЕ РАЗРУШАЛИСЬ НИ РАЗУ.
2.3. Количество транзакций. Вообще в моих системах, даже в достаточно крупных, операций ФБП не так много - несколько (мало) тысяч в месяц, но зато каждая операция - в дело идет каждый байт из 380 (один байт на вольт примерно). Предприятие медснаба. Примерно столько же позиций учета, как в 2.2., помноженное на количество серий (лотов приема медпрепаратов, в среднем умножить на 3..4). Сводная картотека движения медпрепаратов - одна форма, несолько тысяч карточек, по карточке на каждую серию. Не удается выполнить вывод за один раз, потому что получается около 200000 строк, а клиент больше 16000 строк не показывает. Так что выводятся группами, от случая к случаю, никогда на бумагу (на бумагу - только по одной карточке на одну серию или все серии одного препарата по запросу, а так машине доверяют всецело. ). В остальном ничего особенного. 5 машин, fn2win95. Ни одного разрушения данных за 2.5 года работы.
2.4. Количество фактов и экстрапараметров. Впервые мною была реализована система автоматического учета выпуска продукции и списания материалов по нормативам на выпуск продкуции. Маленький заводик (производство мебели), около тысячи единиц номенклатуры продукции, несколько десятков позиций материалов и полуфабрикатов в изделии, несколько сотен покупателей, несколько десятков поставщиков, несколько сотен счет-фактур в месяц, несколько миллионов расчетных индексов параметрического учета. Система еще не завершена, в ней впервые был применен метод принудительного автоматического архивирования баз данных - каждые 5 минут, каждый час, каждый день и вручную по запросу. Работает с января 1999 года. Разарботка ведется на действующей системе без ее остановки. До сих пор ни один архив не был востребован.

Сводные итоги об имеющихся у меня сведениях о разрушениях целостности баз данных и отказе в обслуживании - не более 10 за последние три года на 20 системах с общим количеством операций 600000..1000000. Ни одного отказа, не обеспеченного процедурой полного восстановления данных из архивных копий.

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

Можно сделать вывод - ФБП устойчиво поддерживает целостность данных, но поиск "дыр деструкции транзакций" не помешает. Буду признателен за любую информацию о разрушении целостности транзакций, а Евгению Анатольевичу - отдельное спасибо за поднятый вопрос.




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