Re: Dlugie transakcje

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

  Wydaje mi się, że Pan Jacek Sapinski mówiąc o zastopowaniu bazy w momencie zapełnienia pliku BI mał na myśli uzycie pary parametrów -bithold i -bistall . Pierwszy parametr powoduje ograniczenie wzrostu rozmiaru pliku BI (ew. obszaru zajętogo zapełnionymi kłastrami) do pewnej wartości, a drugi spowoduje że serwer bazy wciąż bedzie chodził (normalnie serwer bazy jest stopowany).
   Mogę powiedzieć że jest to naprawda przydatna para parametrów. Jeden raz zdarzyło mi się stracić bazę z powodu długotrwałej transakcji (3 dni). Normalnie zapobiegamy powstaniu duzych transakcji, ale niestety oprócz rozmiaru jest też ważny czas trwania transakcji. Tak jak wcześniej opisywano niezamkniety claster bi może w krótszym lub dłuższym czasie doprowadzić do tragedii.
   Pomysł o monitorowaniu czasu transakcji jest dobry. Natomiast raczej bym próbował monitorować rozmiar (zajetość) pliku(ów) BI w stosunku do wartości parametru -bithold.


Pozdrawiam,
Siergiej Szabłykin.


>>> slatka@computerland.pl 02/04 3:02  >>>


Wydaje mi się że chodzi tu o wyczerpanie parametru -B dla danej transakcji.
Należy zwiększyć ten parametr w pliku pf bazy.





Henryk Jusza @zeto.bydgoszcz.pl on 2002-02-04 14:40:56

Please respond to progress@zeto.bydgoszcz.pl 

Sent by:  owner-progress@zeto.bydgoszcz.pl 


To:   progress@zeto.bydgoszcz.pl 
cc:
Subject:  Re: Dlugie transakcje



opiekuje sie baza Progress 9.1 na systemie AIX 4.3.  Ostatnio zdarzylo mi
sie kilka razy, ze baza danych zatrzymala sie. Powodem tego bylo
zapelnienie pliku BI.  Prawdopodobnie przyczyna tego byla "dluga
transakcja". Ktos rozpoczal transakcje i .. poszedl do domu.
Witam !

Nie bardzo rozumiem co to znaczy "zapełnienie pliku bi". Plik ten zmienia
swoją wielkość w miarę potrzeb i nie bardzo wiem jak się może "zapełnić'.

Jeśli sformułowanie to oznacza, że na dysku zabrakło miejsca na ten plik i
serwer nie mógł go rozszerzyć, to przyczyna tego jest raczej inna niż to,
że ktoś poszedł do domu. To sugeruje raczej, że któryś z programów
aplikacji korzystających z bazy zbyt dużo danych aktualizuje w jednej
transakcji. Jest to czasami efekt nie zamierzony, jeśli programista piszący
ten program zrobił to nie myśląc co z tego wyniknie. Taki program trzeba
poprawić, chyba że rzeczywiście jedna transkacja musi zawierać bardzo dużo
aktualizacji bazy, to wtedy należy plik .bi  umieścić na innym dysku z
większą ilością wolnego miejsca (lub na kilku dyskach - wiele woluminów).
Jeśli taka transakcja zajmuje dużo różnych zapisów, to ochroną przed tym
może być ustawienie parametru startowego serwera -L (ilość blokad) na
mniejszą wartość. Wtedy program, który chce zająć dużo zapisów upadnie i
będzie wiadomo który to program jest przyczyna problemów.

Gdyby ktoś poszedł do domu i zostawił otwartą transakcję (w której nie
wykonuje się zbyt dużej ilości aktualizacji), to plik .bi by nie rósł, a
pracę innych programów korzystających z bazy wstrzymywałyby raczej blokady
EXCLUSIVE-LOCK niektórych zapisów, do których chciałyby się dostać
wstrzymane programy.

Pozdrawiam,


Henryk Jusza               mailto:henju@pg.gda.pl 
-------------------------------------------------
Ośrodek Informatyczny Politechniki Gdańskiej
Pracownia Rozwoju Oprogramowania
tel (058) 347-28-01          fax (058) 347-24-63



------
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
------