RE: Klopoty z archiwizacja plikow AI

["Siergiej Szablykin" <SSzablykin@lukas.com.pl>]

> 1. czy takie zachowanie programu _rfutil jest "normalne"
  Jest to chyba normalne zachowanie sie. Na ile wiem przy podlaczeniu bazy w trybie single-user lub przez pamiec dzielona wykonuje sie proba otwarcia wszystkich plikow bazy. Dlatego pliki ktore udalo sie otworzyc maja nowsza date otwarcia od tych ktore nie udalo sie otworzyc. Co w konsekwencji wymusza uzycie "prostrct unlock". Natomiast pozbyc sie komunikatu "Database was damaged." mozna, na ile dobrze pamietam, przebudowujac 0 indeksow.
> 2. Jak bezspornie mozna stwierdzic ze baza jest uruchomiona i wszystkie > jej elementy sa na miejscu.
  Mozna probowac np. proutil <db-name> -C busy albo innych podobnych komend. Natomiast chyba nie istnieje takie narzedzie o ktore Pan pyta.
> 3. Czy server Progress'a jest w stanie informowac o zapelnieniu pliku AI i > automatycznie uruchamiac skrypt do jego archiwizacji?
  Moglby, ale tego nie robi i nie wiadomo kiedy Progress to zaimplementuje.

Z powazaniem,
Siergiej Szablykin.


>>> sapinskij@poczta.fm 10/19 2:45  >>>
Witam i prosze o rade,

Od roku opiekuje sie baza Progressa z wlaczonym mechanizmem AI i dotej pory nie mialem z tym zadnych klopotow. Az do ostatniego czwartku.
Oto szczegoly. 

Sprzet: 2x Server IBM S80 w klastrze HACMP
System operacyjny: AIX 4.3 
Progress 9.1a

Do uzytku bazy przeznaczone sa trzy systemy plikow, kazdy na osobnym wolumenie logicznym:
/baza 	- pliki bazy 
/AI 	-pliki AI
/kopie 	- kopia bazy oraz kopie pelnych plikow Ai


Co dziesiec minut "cron" uruchamia skrypt, ktory archiwizuje pelne pliki AI i oznacza je jako puste. Skrypt ten dziala niezaleznie od tego czy baza dziala czy nie. Nawet jezeli serwer bazy nie dziala to i tak skrypt sprawdza czy sa jakis pelne pliki AI. W skrypcie wykorzystuje polecenie "_rfutil baza -C aimage full".
We czwartek baza zostala zatrzymana, odmontowane tez zostaly wszystkie trzy systemy plikow, z ktorych korzysta baza (oprogramowanie HACMP zalatwia to wszystko automatycznie). Nastepnie administrator Unix'a recznie zamontowal system plikow   zawierajcy pliki bazy (/baza) w celu przeprowadzenia pewnych prac. 
W tym czasie zostal automatycznie uruchomiony skrypt do archiwizacji plikow AI. Poniewaz pliki AI nie byly dostepne (filesystem /AI nie byl podmontowany), polecenie "_rfutil baza -C aimage full" zwrocilo blad. I takie zachowanie wydawaloby sie byc normalne. Jednakze po zamontowaniu katalogu /AI i przy probie uruchomienia servera bazy okazalo sie, baza jest niedwracalnie uszkodzona.
Oto komunikat jaki pojawil sie w pliku komunikatow:

22:25:00 Last open date mismatch. (9215)
22:25:00 Extent /AI/baza.a58 has a different last opened date Wed Oct 10 19:42:38 2001, (9213)
22:25:00 Control Area has a last open date of Wed Oct 17 22:15:01 2001. (9217)
22:25:00 Probable backup/restore error. (605)
22:25:00 Database is damaged, see documentation. (1486)

Taka sekwencja komunikatow zostala powtorzona dla kazdego z plikow AI (a jest ich 80). 

Bazy nie dalo sie juz uruchomic.  Mozliwe byly tylko dwa rozwiazania:
1) prostrct baza unlock.
   Pozwolilo to co prawda na uruchomienie bazy ale w logu komunikatow caly czas pojawial sie wpis "Database was damaged." Progress zaleca wtedy wykonanie dump/load.
2) odtworzenie bazy z backupu. 
  Wybralem to rozwiazanie, obylo sie bez problemow.

W zwiazku z ta sytuacja nasuwa mi sie kilka pytan:
1. czy takie zachowanie programu _rfutil jest "normalne"
2. Jak bezspornie mozna stwierdzic ze baza jest uruchomiona i wszystkie jej elementy sa na miejscu.
3. Czy server Progress'a jest w stanie informowac o zapelnieniu pliku AI i automatycznie uruchamiac skrypt do jego archiwizacji?

Z gory dziekuje za pomoc.


Pozdrowienia,

Jacek Sapinski
------
Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm 
Obsluga listy:  listserv@zeto.bydgoszcz.pl 
Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html 
------

------
Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm
Obsluga listy:  listserv@zeto.bydgoszcz.pl
Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html
------