Отправлено: 09.09.06 17:20. Заголовок: ADS 8.0 TRIAL for Win2000. После сбоя сервера НЕ накатывает незавершенную TRN. Почему ?

Всем доброго 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-ник: и видим, что в нём НИЧЕГО не «доработалось» до конечной точки, всё так и осталось в промежуточном положении. Т.е. получается, что в случае сбоя файл-сервера АДС НЕ будет «накатывать» недоделанные изменения!

ВОПРОС: у кого-нибудь такое было ?

 Отправлено: 14.09.06 10:45. Заголовок: Re:

Вряд ли) Ты пионер. В хорошем смысле ) То есть первопроходец. 100% людей используют АДС как наиболее простой путь получения стабильности баз и снижения сетевой нагрузки. Новыми возможностями не пользуется никто. )) В ФЫСе только есть... )) Да и то без транзакций. В транзакциях - ты один, как Дункан Маклауд в последней серии.

 Отправлено: 14.09.06 14:23. Заголовок: Re:

"используют АДС как наиболее простой путь получения стабильности баз..."

"Стабильность" без юзания 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. Странно...

 Отправлено: 14.09.06 14:31. Заголовок: Re:

p519446 пишет:

цитата:

Стабильность" без юзания TPS - тряпочная, и ты это знаешь (но молчишь :)).

ок, "для некоторого увеличения стабильности"

p519446 пишет:

цитата:

BTW, количество блокировок, которое можно установить на 1 таблицу, открытую АДСом (ADS 8.x for Win2000), равно 4679. Это явно больше клипперного 2048. Странно...

Ни то, ни другое неверно.

Есть стандартная функция, которая возвращает кол-во блокировок в массиве. Следовательно, кол-во блокировок не может превышать макс длину массива - 4096. Пользуясь внутренними функциями можно слепить массив и больше, чем 4096, я это делал, но при этом происходит кирдык, т.к. это приводит к затиранию других данных. Так что если в АДС можно сделать 4679 блокировок - лучше все равно этого не делать.

 Отправлено: 14.09.06 15:11. Заголовок: Re:

Скачай триальный АДС 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() ? К клипперному массиву или к чему-то там еще ?

 Отправлено: 14.09.06 16:05. Заголовок: Re:

сделай после своего кода вызов ax_GetLocks()

будет GPF

 Отправлено: 14.09.06 16:57. Заголовок: Re:

В смысле ? ЕЩЁ один раз сделать, повторно, после WAIT ? Хорошо, попробую...

 Отправлено: 14.09.06 17:08. Заголовок: Re:

а чо там пробовать)))) к бабке не ходи - вылетит все нах) чо я - не знаю что ли)