Форум » Clipper » ADS 8.0 TRIAL for Win2000. После сбоя сервера НЕ накатывает незавершенную TRN. Почему ? » Ответить
ADS 8.0 TRIAL for Win2000. После сбоя сервера НЕ накатывает незавершенную TRN. Почему ?
p519446: Всем доброго GMT. Кто-нибудь делал эксперименты по способности АДС восстановить данные после сбоя СЕРВЕРА, если при этом на сервере имелась транзакция в фазе СБРОСА (COMMIT’a) данных на диск ? Документация утверждает, что АДС после восстановления сервера допишет данные в таблицы, которые НАЧАЛ обновлять после получения команды COMMIT, но НЕ успел обновить до конца. Я провёл эксперимент и пришёл к выводу, что он НЕ выполняет этого. А именно: если была дана команда COMMIT’a транзакции с «серьёзным объемом» сделанных изменений и до завершения этой команды сервер упал, то после его восстановления и перезапуска АДС он НЕ «накатит» оставшиеся изменения в таблицы! Вот содержание моего опыта (на ADS 8.0 TRIAL for Win2000, клиент + сервер на 1 машине, коннект через «родной» новелловский IPX): 1) параметр запуска службы АДС переводим в разряд «Вручную» (чтобы посмотреть после рестарта содержимое dbf-ника, в котором шла запись сбрасываемой на диск транзакции); 2) открываем dbf-ник, имеющий char- и memo-поля. Устанавливаем большое кол-во блокировок dbRlock(). На этой версии АДС я смог установить не более 4679 строковых блокировок (дальше – вываливается по GPF). 3) Объявляем начало транзакции: ax_Transaction(1) 4) Обходим все ранее заблокированные строки и пишем в char-поля и в memo-поле новые данные (я их генерил через RANDOM()) /* здесь обнаружился эффект: если memo-поле перед началом транзакции было пустым, то запись в него оказывается ВИДИМОЙ еще до завершения этой TRN!! С остальными типами полей этого не происходит; также этого изменения в memo-поле не будет видно «извне», если оно перед началом транзакции было Непустым */ 5) Объявляем точку останова (WAIT), за каторым сразу идёт ax_Transaction(2) (т.е. COMMIT). Этот commit на числе обновленных строк = 1500 выполняется примерно 10 секунд (машина: 2.4MHz/512RAM/80Gb HDD). При этом CPU нагружается почему-то только на 15-20 процентов, не больше (тоже «странность»: что мешает напрячь камень посильнее ?!) 6) Нажимаем any key, начинается COMMIT. Не дожидаясь его окончания, тыркаем в RESTART на передней панели системного блока :-). 7) После перезагрузки виндузы открываем .dbf-ник и смотрим его содержимое: у меня «волна commit’a” дошла до какой-то промежуточной записи и видны ПОЛОВИНЧАТЫЕ результаты. Обновлено несколько сот строк, но бОльшая часть строк оказалась НЕ обновлённой. Причем, memo-поля обновились на 4-5 строк «вперёд» по сравнениюс char-полями. 8) Выходим из dbf-файла, чтобы дать его на монопольный доступ АДСу 9) Запускаем службу ADS. Он запускается около 20 секунд, при этом открывает монопольно «недоделанный» dbf-ник и свой журнал (.TPS). То, что он открыл оба этих файла, показывает FAR manager - он не смог их в это время открыть по F3. Диспетчер задач при этом показывает, что ADS чего-то куда-то пишет. 10) По окончании запуска ADS’a смотрим в dbf-ник: и видим, что в нём НИЧЕГО не «доработалось» до конечной точки, всё так и осталось в промежуточном положении. Т.е. получается, что в случае сбоя файл-сервера АДС НЕ будет «накатывать» недоделанные изменения! ВОПРОС: у кого-нибудь такое было ?
Ответов - 7
suv2: Вряд ли) Ты пионер. В хорошем смысле ) То есть первопроходец. 100% людей используют АДС как наиболее простой путь получения стабильности баз и снижения сетевой нагрузки. Новыми возможностями не пользуется никто. )) В ФЫСе только есть... )) Да и то без транзакций. В транзакциях - ты один, как Дункан Маклауд в последней серии.
p519446: "используют АДС как наиболее простой путь получения стабильности баз..." "Стабильность" без юзания TPS - тряпочная, и ты это знаешь (но молчишь :)). Если твой большой блок кода, записывающий данные в несколько таблиц, сбойнёт по причине: а) программной ошибки (var not found, lock required etc); b) разрыва сети (напр., умрёт гнездо в хабе или строители перережут кабель) с) уборщицы, случайно выключившей шваброй юсеровский комп во время "влажной уборки помещения"; d) электрика-идиота, который обожает без предупреждения лезть в щитовую и всех вырубать e) зависания собственно сервака (не дай бог!!) f) ... чего угодно еще... -- то разбираться затем с обрывками данных придется именно тебе! И делать это надо будет долго. Мне это, например, периодически приходится делать и я очень хочу уйти от этого. По кр. мере, пункты a)...d) из вышеперечисленных при юзании TPS будут уже не страшны. С пунктиком "e)", конечно, всё не так просто... :-) Тут только бэкап спасёт, конечно. =========== Кстати. Повтор эксперимента прошедшей ночью дал уже другой, "нормальный" результат: АДС накатил транзакцию до упора, т.е. довёл таблицу до того состояния, в каком она и должна была бы оказаться при успешном завершении commit'a. Отличие второго эксперимента от первого было только в одном: я не стал менять параметры запуска службы ADS со startup'a на manual, оставил всё как есть -- т.е. startup. И когда виндуза запустилась, то вместе с ней стартовала АДС-служба. И чего-то там всё долго "шуршало", прежде чем выдать мне подсказку для логина в систему. Когда же я вошёл, то увидел, что таблица "доведена до ума", т.е. все строки обновились. Получается, что АДС ведёт себя "хорошо" (накатывает оставшуюся в незаконченном commit'e транзакцию) только когда стартует ВМЕСТЕ с виндузой, что ли ? BTW, количество блокировок, которое можно установить на 1 таблицу, открытую АДСом (ADS 8.x for Win2000), равно 4679. Это явно больше клипперного 2048. Странно...
suv2: p519446 пишет: Стабильность" без юзания TPS - тряпочная, и ты это знаешь (но молчишь :)). ок, "для некоторого увеличения стабильности" p519446 пишет: BTW, количество блокировок, которое можно установить на 1 таблицу, открытую АДСом (ADS 8.x for Win2000), равно 4679. Это явно больше клипперного 2048. Странно... Ни то, ни другое неверно. Есть стандартная функция, которая возвращает кол-во блокировок в массиве. Следовательно, кол-во блокировок не может превышать макс длину массива - 4096. Пользуясь внутренними функциями можно слепить массив и больше, чем 4096, я это делал, но при этом происходит кирдык, т.к. это приводит к затиранию других данных. Так что если в АДС можно сделать 4679 блокировок - лучше все равно этого не делать.
p519446: Скачай триальный АДС 8.x for Win2000, подцепись к нему и сделай вот это вот: USE TEST VIA "DBFCDXAX" SHARED NEW // RECC() must be greater than 4700 FOR I=1 TO 4679 DBRLOCK( I ) NEXT ?'LEN(AX_GETLOCKS())=',LEN(AX_GETLOCKS()) WAIT УТВЕРЖДЕНИЕ: программа НЕ вылетит, она выдаст результат = 4679. ВОПРОС: какими внутренними структурами я тут пользовался ? К чему всё-таки обращается ф-ция AX_GETLOCKS() ? К клипперному массиву или к чему-то там еще ?
suv2: сделай после своего кода вызов ax_GetLocks() будет GPF
p519446: В смысле ? ЕЩЁ один раз сделать, повторно, после WAIT ? Хорошо, попробую...
suv2: а чо там пробовать)))) к бабке не ходи - вылетит все нах) чо я - не знаю что ли)
полная версия страницы