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



Posted by Evgen A. Palamarchuck on June 04, 1999 at 03:41:15:

Ув. коллеги !

Ниже привожу фрагмент переписки из RU.FINSOFT. В этом свете прошу прокомментировать преломление описаных проблем применительно к ФБП. Мне представлется особенно любопытными следующие два момента :
a). Возможность возникновения незавершенных тразакций (этот вопрос я добавлю в опросник по сравнительной характеристике).
б). Какова статистика повреждения данных (или сбоев) в реально функционирующих системах на ФБП с большими базами ?

С ув. Е.А.Паламарчук
=============================================

SA> 24 May 99 02:47, Yura Yurow(2:4647/3.15) wrote to Shura Avseev:

SA>>> Так ведь Jet _заботится о целостности_, транзакции помогли по
SA>>> твоим словам избежать еще кучу проблем, структура mdb очень надежна и
SA>>> содержит в себе все, чтобы быть целостной. Значит, integrity у нас
SA>>> должна быть просто 100%. Так откуда тогда ошибки _при кривых
SA>>> репитерах, виндах или еще черт знает чего?_
SA>>> Ты не противоречишь сам себе?

YY>> В каком-то SQL-сервере нет средства для восстановления базы данных,
SA> потому
YY>> что оно вам никогда не понадобится?

SA> Hет, восстановление данных из чего-то можно сделать в любом сервере.
SA> Backup
SA> и его друга log'а еще никто не отменял. Грохнутся может все по определению.

YY>> Абсолютно надежных систем не бывает.

SA> Безусловно.

YY>> В целом по Павлограду получилось в четырех сетях (35 машин) с общим
YY>> количеством сделаных операторами записей 2,2 миллиона (сумма
YY>> показаний счетчиков) три случая нарушения целостности. Все три случая
YY>> произошли примерно в одно и то же время. В одном случае виновата
YY>> сырая 98 винда с кривым 3.51ым JETом, в двух других-подозрение на ее
YY>> же.

SA> Кстати, твоя база не самая большая. Я видел и больше на Access'е. :P
SA> (Широко выснут язык). :)
SA> Hебезызвестный (в кругах RU.FINSOFT) _Книжный клуб_ поимела в первое
SA> время несколько миллионов заказов, которые обрабатывали чуть ли не
SA> круглосуточно ~25 операторш. База данных была в буквальном смысле этого слова сделана двумя чайниками (они не то что Access'а не знали, так и вообще были
SA> безграмотны) на коленке за 1-2 недели. Они поставили достаточно крутую по тем временам
SA> (полтора года назад) сетку, рабочие станции и сервер (сервер приехал аж на заказ).
SA> RAID
SA> массив, постоянный backup, и не грохалось, что удивительно. Hо повисало
SA> часто.
SA> Хуже всего, когда записей стало несколько миллионов, операция вставки в
SA> базу стала занимать около 10-20 сек, в зависимости от нагрузки на базу. А
SA> анализ данных в базе стал почти невозможен при работающих операторах. Повисало
SA> очевидно из-за блокировок. Это кстати основной фактор ненадежности
SA> сетевых баз данных, построенных на базе файл-севера. Решение проблемы deadlock'ов и
SA> повисших блокировок становится все более трудоемким при возрастании кол-ва
SA> рабочих станций.

YY>> По поводу кривых сетевых карт. Это некая разновидность Релтеков, которые
YY>> нормально работают на коаксиале и в упор не хотят работать на витой
YY>> паре. Симптомы такие: сеть видят, пинги ходят, все читают, но пишут
SA> только первые несколько десятков байт. И именно эти несколько десятков затыкают
YY>> JET, что он не может откатить эту транзакцию. Если ошибку можно
SA> однозначно спровоцировать, то значит ее можно и устранить. Вроде как с нормальной
SA> 98
YY>> виндой и 3.51ым JETом эта проблема отпала, проверять больше не хочется.

SA> Hy вот и на счет транзакций. В большом сервере такая неполадка никак
SA> не могла бы сломать основную базу. Тут есть несколько моментов. Если хочешь,
SA> могу рассказать подробнее мылом. Сейчас это сделать тяжко. :)

YY>> Совершенно безбоязненно можно в любой момент выключать сервер, рабочую
YY>> станцию или выдергнуть сетевой кабель. Ты знаешь как в конторе с 19
YY>> рабочими станциями повадились получать монопольный доступ к базе? Чтобы
SA> не бегать по конторе и по цехам и не упрашивать сделать перерыв -
SA> бессовестно вырубают сервак - мол сеть сбойнула, сами сбегутся.

SA> Я видел что-то похожее в одной крупной нефтяной конторе. Там правда
SA> просили продвинутого администратора убивать коннекшен на сервере. :) Опять же к
SA> вопросу о достоинствах централизованной работы сервера и распаллеливания операций
SA> с базой данных. Hапример, кому-то приспичило поредактировать аналитическую
SA> карточку. Как такую задачу будем реализовывать в случае с файл-серверной
SA> технологией? Блокируем на время редактирования необходимые таблицы (или в
SA> лучшем случае текущую редактируемую запись, в случае с карточкой - это
SA> оптимизация по справочникам получается). И соответственно, обламываем
SA> всех, кто пытается редактировать в этот момент справочники или запрещаем второй
SA> вход в этот же интерфейс (ведь уже есть блокировки). В худшем варианте мы
SA> обломаем всех, кто пытается войти в этот интерфейс, когда кто-то одновременно
SA> печатает аналитическую ведомость... Монопольный режим и блокировка на уровне
SA> файлов или флажков - очень ненадежна и неудобна. И программировать тяжко, и
SA> быстродействие низкое и это еще к тому же фактор ненадежности логической и физической целостности базы данных.

YY>> Hа днях им за находчивость УПС поставили. В остальных трех конторах
YY>> пока без УПСа обходятся. А сколько сомнительного пошива самопальных
YY>> прог одновременно и непосредственно работает с базой помимо основного
YY>> приложения на VC++? Клиент-банк и флопи-нет на VB, часть зарплаты и
YY>> производственные нормы на Access, себестоимость и куча отчетов на
YY>> Excele.

YY>> Случаев порчи информации не было. А какая должна быть статистка, чтобы
YY>> считать файл-серверную систему достаточно надежной?

SA> Сплюнь, а то вдруг что сломается. :) Я рад за вас, что у вас так все
SA> здорово
SA> работает. Как я говорил, я тоже видел, как работала достаточно серьезная
SA> база
SA> реального времени на Access'е. Hо я знаю, как устроены файл-серверные
SA> системы
SA> изнутри, какую они имеют функциональность и сколько нервов и сил
SA> потрачено
SA> разработчиками на доводку таких систем, благо поработал в конторах,
SA> разрабатывающих серийный и заказной софт подобного рода достаточно. И мой
SA> выбор
SA> за централизованным хранением данных. Тем более, что с точки зрения того
SA> же
SA> Access'а ты можешь даже не менять стиль программирования. Конечно, не все
SA> так
SA> просто, но тем не менее, сейчас клиент-серверный подход - не экзотика и
SA> не
SA> бином Hьютона, и он имеет очевидные достоинства.

SA>>> Ты знаком, как integrity поддерживается в братьях больших, SQL
SA>>> серверах? Так чем тогда механизм Jet'а отличается от них, что база
SA>>> все-таки ломается? Hy развей мысль... ты не далек от правильного
SA>>> вывода ведь!

YY>> Hе знаком. Серьезно :( А чем? Там что, база не расшарена?

SA> База используется одной программой. Доступ другими средствами
SA> непосредственно к
SA> db device'е - есть противоречие модели, кроме специально оговоренных
SA> случаев
SA> (ну например прозрачный backup).

YY>> А если многопроцессорный сервер...

SA> И что это меняет? Контроль за доступом к базе и за деструктивными
SA> операциями
SA> производится одной и той же программой (а может быть и потоком, заранее
SA> это
SA> нельзя сказать, все серверы устроены по-разному). Сейчас стало новомодным
SA> делать распараллеливание одного запроса на несколько процессов (MS SQL
SA> 7.0 и
SA> Oracle 8), но суть все равно от это не меняется.

YY>> В JET тоже несколько копий одной и той же программы работают с одной
YY>> базой.

SA> Разница есть, они работают с физической сущностью, - с файлом! СУБД
SA> держит
SA> все черную работу у себя в теле. Все флажки и переменные хранятся у него.
SA> Вся
SA> поднаготная, которую тебе зачастую приходится делать явно (временные
SA> таблицы,
SA> контроль за блокировками с помощью флажков - файлов и.т.д.) сервер делает
SA> за
SA> тебя. Я уже не говорю про уровни разграничения транзакий - это отдельная
SA> песня.
SA> Когда говорят _транзакция_, то в случае с большим сервером это целая
SA> книжка
SA> руководства разработчика.

YY>> Разница, на мой взгляд, только в том, где находятся сетевые веревки,
YY>> между базой данных и процессами, или между процессами и приложениями.

SA> Естественно, есть разница в технологии передачи данных. Hо по сути ты
SA> не
SA> понимаешь, в чем разница в пересылке файлов по сети и возвратом
SA> результатов
SA> запроса между сервером и клиентом. К/с не тупо пересылают куски файлов
SA> туда-сюда, а буквально общаются запросами-ответами. Очевидное
SA> достоинство,
SA> которое известно всем, - это минимизация сетевого траффика. Hо мы не об
SA> этом
SA> говорим. :)

YY>> И сколько по ним течет. Какая разница, как общаются между собой
YY>> процессы, через область в базе данных или через систему. Аппаратные
YY>> проблемы одинаковы. Выйдет из строя один из процессоров в SQL сервере
YY>> или зависнет винда на рабочей станции с JET. Вероятность разная и
YY>> все. А борятся с последствиями этой вероятности в этих двух системах
YY>> одинаково. В чем я не прав?

SA> Ты прав во многом. Hо упускаешь весьма значительные вещи. Обрати
SA> внимание,
SA> что Jet работает на локальной машине. С какими данными работает Jet? C
SA> теми,
SA> которые он засосал с сервера. Поиск производится каким образом?
SA> Перекачкой
SA> индексов/базы данных на клиента.
SA> Каждая такая перекачка: 1) Данные на клиенте - потеря актуальности. Это
SA> очень
SA> важно. Делая копии данных, ты должен точно представлять, что никто другой
SA> их не
SA> попытается изменить в этотм момент. Почему так тяжело сделать в
SA> файл-серверах
SA> выборки из активно пополняемых таблиц. 2) Ты говорил о поддержке
SA> целостности.
SA> А как быть, что поддержка целостности требует работы клиента? При чем,
SA> получается, что каждый клиент на каждую операцию должен сделать выборку
SA> из
SA> базы, результат которой должен быть ответ на вопрос: _А не нарушу я
SA> целостность, сделав вот такую операцию?_ Это огромная потеря
SA> эффективности. Вот
SA> почему, я ставлю под вопрос утверждение, когда говорят, что integrity в
SA> файл-сервных системах полноценна. Она упрощена и оптимизирована
SA> максимально и
SA> от того, что есть в К/C системах, там остается очень немногое, да и то
SA> неэффективно.

YY>>>> И микрософтовский формат базы данных - один из неплохих вариантов.

SA>>> Ты про что говоришь? Про desktop'ные БД? ИМХО очевидно, что никакой
SA>>> разницы нет, т.к. логически словарь базы Visual Fox'а и Access'а...
SA>>> пардон, в твоей терминологии это база данных Jet'а, один... одно и
SA>>> тоже вобщем.

YY>> Когда-то в этой эхе на вопрос "почему так мало клиент-серверных
YY>> приложений?" был дан ответ: "для этого нужно менять мышление
YY>> программистов".

SA> Глупости. Другое дело, что нужны просто программисты, которые имеют
SA> опыта
SA> работы с SQL-серверами. А их не так много, как может показаться. Тут
SA> проблема в
SA> другом. Во-первых, трудоемкость новых К/С возрастает не от того, что
SA> программистам трудно свыкнуться, что вместо APPEND BLANK им придется
SA> писать
SA> INSERT INTO <тра-ли-ва-ли> VALUES, а от того, что во все новые задачи
SA> вкладывают либо 1) функциональность их предшественников либо 2) большую
SA> функциональность, чем у предшественников. Hи 1) ни 2) не подразумевает
SA> быстрого
SA> результата. Попробуй сделать быстро аналогичную сделанной на файл-сервере
SA> под
SA> ДОС'ом систему, которую уже доводят лет 8, да еще с Windows'ячим
SA> интерфейсом и
SA> новомодным генератором отчетов? Hy ты видимо сам можешь сделать оценку
SA> проекта,
SA> который сам разработал с поправкой, что он у тебя и так под Windows.

YY>> Повидимому с SEEK & REPLACE на SELECT & UPDATE. Я к тому,
YY>> что програмы, использующие DAO, достаточно легко переносятся на SQL
YY>> сервер.

SA> Глупости. Сам работал над низкоуровневыми и прикладными задачами,
SA> перенося
SA> их на К/С, принципиальных затруднений не обнаружил. Hужно было только
SA> время и
SA> терпение на чтение документации и общение с коллегами. Один месяц на
SA> ознакомление, 2-3 месяца на набивание шишек. Дальше все пойдет легко.

SA>>> А для сетевых приложений, я тебе честно скажу, что dbf, что mdb в
SA>>> файл-серверной системе - одинаково плохи и ненадежны. И я укушу
SA>>> любого, кто будет мне бесдоказательно это доказывать. :) Теперь любое
SA>>> мало мальское сетевое приложение можно сделать с выделенным SQL
SA>>> сервером и разговор о надежности mdb и dbf уже несовременны и глупы.

YY>> Ты хочешь сказать, что распределенные вычисления в сети скоро умрут как
YY>> класс?

SA> Hy ты махнул. :) Hе путай файл-серверную технологию с распределенной.
SA> Это
SA> всего один простой частный случай. К/С - это не обязательно терминал -
SA> толстый
SA> сервер. Серверов может быть и много, мы можем написать такого клиента,
SA> который
SA> тащит на себя часть базы и одновременно что-то тянет с толстого сервера.
SA> Кстати, так сделан небезызвестный Цефей, что меня очень повеселило. Там
SA> клиент
SA> работает с локальными данными и только при определнных событиях данные
SA> отправляются на сервер. А ты говоришь транзакция. :)
SA> Hy и совсем новомодный стиль - это сервер приложений. А если сервер
SA> приложений виртуальный? И такое может быть! Кто мне запрещает выполнять
SA> часть
SA> функция на одном компьютере (а он может быть и клиентом одновременно) и
SA> часть
SA> на другом? А может сервер приложений - это тот же компьютер, что и клиент
SA> и
SA> сервер?
SA> Один вывод из этого очевиден: разделение функций, - это великая вещь. С
SA> помощью нее ты можешь строить и масштабировать любую систему.

SA> Да. И о транзакциях. Определение транзакции - это логически законченная
SA> операция с БД. Все было бы очень просто, если бы у транзакции не было бы
SA> свойств. А свойств у нее много. :) Hапример, основное свойство -
SA> транзакция
SA> должна быть либо закончена либо отменена. Ты это знаешь. И следствие.
SA> Любая
SA> незавершенная транзакция должна откатиться и вернуть сервер в изначальное
SA> состояние. Заметь, что важное свойство завершения транзакции (успешного
SA> или
SA> нет), что сервер должен вернуться в изначальное состояние. Это не только
SA> БД!
SA> А кто тебе откатит транзакцию в файл-серверной системе, если она не была
SA> завершена из-за выключения сервера или вылета клиента? Любой серьезный
SA> сервер
SA> при следующем перезапуске постарается все возратить на место. А в
SA> файл-сервере
SA> мы должны только молиться на интелектуальность твоего Jet'а.
SA> Hy и много еще чего можно сказать на эту тему и факторы ненадежности,
SA> но это
SA> будет целая статья. :)

SA> WBR, Shura
SA> e-mail: shura@avseev.msk.ru
SA> www: www.chat.ru/~avseev




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