Jak wiadomo, aby używać Firebird, nie trzeba go jakoś specjalnie konfigurować po zainstalowaniu. Zaawansowani użytkownicy mogą wpływać na działanie serwera modyfikując jego plik konfiguracyjny. Zmiany w pliku konfiguracyjnym mają wpływ na wszystkich użytkowników korzystających z tego serwera. Istnieją również parametry zależne od bazy danych. Jedną z takich cech bazy danych jest atrybut baz danych
Forced Writes. Jeżeli jest ustawiony, wszelkie zmiany w bazie danych są natychmiast zapisywane na dysk. W takim trybie każda zmiana zawartości bazy danych powoduje, że Firebird wymusza natychmiastowe zapisanie zmienionej zawartości na dysk. Takie pomijanie standardowych mechanizmów buforowania operacji zapisu na dysk przez system operacyjny powoduje wprawdzie wolniejsze działanie Firebird, ale za to prawdopodobieństwo uszkodzenia bazy danych jest zredukowane do minimum.
Okazuje się jednak, że nie jest to takie proste i oczywiste. Począwszy od Firebird 1.0, ten atrybut jest domyślnie ustawiony w Windows. Dlaczego tylko w Windows? Dlatego, że system Linux zapisuje dane na dysk najszybciej, jak tylko można. Natomiast Windows zapisuje dane na dysk wtedy, gdy musi. Jeżeli Firebird pracuje bez przerwy, to może się okazać, że w Windows niektóre dane nie były zapisywane na dysk przez wiele godzin lub nawet przez wiele dni. Aby zapobiec takim sytuacjom, w Firebird 1.5 wprowadzono dwa dodatkowe parametry konfiguracyjne serwera:
- MaxUnflushedWrites oraz
- MaxUnflushedWriteTime.
Mają one znaczenie tylko w przypadku baz z wyłączonym atrybutem
Forced Writes. W systemie operacyjnym Windows pierwszy parametr domyślnie ma wartość 100. Informuje on, co ile zmian danych Firebird ma wymusić zapisanie ich na dysku. Drugi parametr w Windows domyślnie ma wartość 5. Informuje on, ile sekund zmienione lub nowe dane mogą pozostać nie zapisane na dysk. Po upłynięciu tego czasu Firebird wymusza zapisanie ich na dysku. W innych systemach operacyjnych oba parametry domyślnie są nieaktywne, ponieważ analogiczne działanie zapewniają te systemy operacyjne.
Podczas prac nad nowymi wersjami Firebird odkryto, że w systemie Linux atrybut Forced Writes był ignorowany. Nawet jeżeli był ustawiony, nowe i zmienione dane i tak były buforowane przez system operacyjny. Błąd ten został naprawiony w Firebird 2.1 (oraz w Firebird 2.0.4).
Jak już napisałem, w systemie Windows nowe lub zmienione dane mogą pozostać w pamięci stosunkowo długo, zanim zostaną zapisane na dysk. Dlatego większość autorów rekomenduje, aby w tym systemie atrybut
Forced Writes zawsze był ustawiony. Dzięki temu Firebird wymusi zapisanie zmian na dysku. Ewentualne zagrożenia, wynikające z nieustawienia tego atrybutu, dobrze zostały
opisane w blogu Sinatica. Jako zagrożenia autor wymienia:
- utratę zasilania przez komputer, na którym działa Firebird
- problemy ze sprzętem
- problemy z systemem operacyjnym
- problemy z Firebird
Każde z tych zagrożeń może doprowadzić do uszkodzenia bazy danych. Zastanówmy się chwilę nad tymi zagrożeniami.
Jeżeli niespodziewanie komputer utraci zasilanie, to oczywistym jest, że pliki zapisywane przez działające w tym czasie programy mogą być uszkodzone (niekompletne). Nie inaczej jest w przypadku serwera Firebird. Można temu zaradzić zasilając komputer przez sprawny
zasilacz awaryjny (UPS).
Moim zdaniem pozostałe zagrożenia w wielu przypadkach nie są wystarczającym powodem do ustawiania atrybutu Forced Writes (wolniejsze działanie Firebird). Problemy ze sprzętem mogą się oczywiście zdarzyć. W takim przypadku istnieje ryzyko uszkodzenia bazy danych. Jako serwer zazwyczaj stosuje się markowe komputery. Nie eliminuje to możliwości awarii sprzętu, ale prawdopodobieństwo takiego zdarzenia jest, moim zdaniem, znikome.
Problemy z systemem operacyjnym zdarzają się. Jednak na serwerze na ogół nie uruchamiamy co chwilę jakichś programów — nie pracujemy w taki sposób, jak na stacjach roboczych. Uważam, że prawdopodobieństwo awarii systemu operacyjnego, prowadzącej do uszkodzenia bazy danych, jest znikome.
Problemy z Firebird oczywiście mogą się zdarzyć. Jak wiadomo, programy bezbłędne nie istnieją. Używam Firebird począwszy od wersji 1.5. Nie przypominam sobie żadnej awarii Firebird. Wiem, że takie się zdarzają, ale — moim zdaniem — prawdopodobieństwo ich wystąpienia jest znikome.
Uważam, że jeżeli Firebird działa na stacji roboczej, to lepiej jest ustawić atrybut Forced Writes w bazach danych. Jeżeli jednak Firebird działa na dedykowanym serwerze, zasilanym przez zasilacz awaryjny, to — moim zdaniem — można w miarę bezpiecznie wyłączyć ten atrybut. Zadziałają wtedy opisane wyżej parametry MaxUnflushedWrites i MaxUnflushedWriteTime. Kosztem minimalnie większego ryzyka uszkodzenia bazy danych zyskujemy większą wydajność serwera.
Warto jeszcze zwrócić uwagę na trzy ważne elementy. Po pierwsze, bez względu na wartość atrybutu
Forced Writes należy pamiętać o regularnym wykonywaniu
kopii bazy danych. Jakakolwiek będzie wartość tego atrybutu, i tak może się zdarzyć, że baza danych ulegnie uszkodzeniu. Wtedy jedynym ratunkiem może być odtworzenie jej na podstawie wykonanej wcześniej kopii.
Po drugie, decyzję o ewentualnym wyłączeniu atrybutu Forced Writes należy przeanalizować uwzględniając specyfikę danego zastosowania. Jeżeli Firebird działa wystarczająco wydajnie, to lepiej zostawić ten atrybut ustawiony. Zmniejszamy w ten sposób ryzyko uszkodzenia bazy danych. W niektórych zastosowaniach konieczność odtwarzania bazy danych na podstawie jej kopii, a następnie ponowne wprowadzenie wszystkich danych lub modyfikacji, które były zrealizowane po wykonaniu tej kopii bazy danych, sprawiałoby duży kłopot. W takim przypadku również lepiej zostawić atrybut Forced Writes ustawiony.
Po trzecie, jeżeli jesteś programistą, najpierw zabierz się za optymalizację zapytań oraz pozostałych działań na bazie danych. Doświadczenie pokazuje, że tym sposobem można uzyskać przyspieszenie działań wielokrotnie większe, niż wyłączenie atrybutu Forced Writes.
Jeżeli plik bazy danych ulegnie uszkodzeniu, pozostaje odbudować bazę danych na podstawie ostatnio wykonanej kopii. Następnie trzeba od nowa wprowadzić brakujące dane lub modyfikacje. Możemy również próbować
odzyskać dane z uszkodzonej bazy danych. Nie ma gwarancji, że z uszkodzonej bazy da się odzyskać dane. Dlatego
pamiętajmy o regularnym wykonywaniu kopii bazy danych!
