#firebird

Firebird to serwer relacyjnej bazy danych: program przyjmujący połączenia od aplikacji, wykonujący zapytania w języku SQL i pilnujący, żeby dwie osoby zapisujące ten sam rekord nie zniszczyły sobie nawzajem pracy. Cały kod jest otwarty, a używanie go nie wiąże się z opłatą, także wtedy, gdy producent dołącza go do własnego programu sprzedawanego za pieniądze.

Firmy trafiają na tę nazwę rzadko z własnego wyboru. Częściej odkrywają ją w chwili, gdy program magazynowy albo serwisowy kupiony osiem lat temu przestaje działać, a dostawca już nie odbiera telefonu.

Skąd wzięła się ta baza

Rodowód sięga systemu InterBase, używanego w produkcji pod różnymi nazwami od 1981 roku. W lipcu 2000 roku firma Inprise, znana wcześniej i później jako Borland, udostępniła kod źródłowy, a wokół niego zawiązał się niezależny zespół programistów, który prowadzi projekt do dziś. Zaplecze finansowe daje osobna fundacja utrzymywana ze składek i sponsoringu.

Licencja jest odmianą Mozilla Public License w wersji 1.1 i występuje w dwóch wariantach, zależnie od tego, czy fragment kodu pochodzi z pierwotnego wydania, czy powstał później.

Projekt jest żywy. Linia 5.0 dostaje wydania poprawkowe, ostatnie z kwietnia 2026 roku, a serwer działa na Linuksie, Windowsie i na kilku systemach z rodziny Unix.

Odpis wydany przy okienku

Właściwością odróżniającą tę bazę od wielu innych jest sposób radzenia sobie z jednoczesnym czytaniem i pisaniem. Zmiana rekordu nie nadpisuje go w miejscu. Powstaje nowa wersja, a stara zostaje, dopóki ktokolwiek może jej potrzebować.

Wygląda to jak okienko wydające odpisy dokumentów. Interesant dostaje odpis stanu z chwili, w której złożył wniosek, i ten odpis się nie zmienia, choćby urzędnik minutę później nanosił poprawki na oryginał. Nikt nikomu nie każe czekać: czytający nie blokuje piszącego, a piszący nie blokuje czytającego.

Praktyczny zysk widać w programach, w których ktoś generuje długie zestawienie z całego roku, podczas gdy reszta biura wystawia dokumenty. Zestawienie liczy się na stanie z momentu startu, spójnym i niezmiennym, a sprzedaż idzie dalej bez czekania.

Cztery tryby, w których chodzi serwer

Ta sama baza uruchamia się na kilka sposobów i wybór bywa zapisany w konfiguracji sprzed lat, o której nikt już nie pamięta.

Tryb klasyczny uruchamia osobny proces dla każdego połączenia. Odmiana jednoprocesowa obsługuje połączenia wątkami wewnątrz jednego procesu. Trzeci wariant również jest jednoprocesowy, ale trzyma wspólną pamięć podręczną stron dla wszystkich klientów, co przy wielu połączeniach zmienia zapotrzebowanie na pamięć. Czwarty to wersja wbudowana, uruchamiana jako biblioteka wewnątrz aplikacji, bez osobnej usługi w systemie.

Ustalenie, który tryb pracuje, wypada przeprowadzić przed jakimkolwiek strojeniem wydajności, bo ustawienia pamięci znaczą w każdym z nich co innego.

Plik, który wygląda na zwykły plik

Baza mieści się zwykle w jednym pliku i to jest źródłem najkosztowniejszego nieporozumienia w całej tej historii.

Skopiowanie tego pliku przy działającym serwerze daje kopię uszkodzoną. Dokumentacja mówi wprost, że narzędzi do kopiowania i pakowania nie używa się na bazie, która jest uruchomiona. Powód jest prosty: część zmian siedzi w pamięci serwera, a plik na dysku jest w tym momencie w stanie pośrednim.

Do kopii służą dwa narzędzia dostarczane razem z serwerem. Pierwsze wykonuje kopię logiczną, czyli zapisuje zawartość w formacie własnym i pozwala odtworzyć bazę od zera. Drugie robi kopię przyrostową na poziomie stron pliku. Kopia zrobiona przez program do wykonywania obrazów maszyny wirtualnej nie zastępuje żadnego z nich, bo widzi ten sam plik w tym samym stanie pośrednim.

Odtworzenie kopii logicznej ma efekt uboczny: baza powstaje na nowo, uporządkowana i mniejsza.

Rosnący plik i wymiatanie starych wersji

Stare wersje rekordów nie znikają same z siebie. Usuwa je porządkowanie uruchamiane w tle oraz osobny przebieg przez całą bazę, wykonywany cyklicznie.

Jedna rzecz potrafi to całkowicie zablokować. Transakcja otwarta i niezamknięta, na przykład przez aplikację, w której ktoś wyszedł na urlop z otwartym oknem raportu, każe zachować wszystkie wersje powstałe od chwili jej rozpoczęcia. Plik rośnie wtedy z dnia na dzień, a zapytania zwalniają, bo silnik przegląda coraz dłuższe łańcuchy wersji tego samego rekordu.

Objaw jest mylący, ponieważ wygląda na problem z wydajnością dysku albo z ilością danych. Przyczyną bywa jedno stanowisko, którego nikt nie wyłączył na noc.

Co zwykle kryje się w odziedziczonej instalacji

Konto administracyjne bardzo długo zakładało się z hasłem domyślnym, a nowsze instalatory pytają o nie albo generują losowe i zapisują w pliku obok programu. Sprawdzenie, który wariant zastosowano, jest jednym z pierwszych zadań przy przejmowaniu takiego środowiska.

Druga typowa rzecz to plik bazy leżący na udziale sieciowym, do którego stanowiska sięgają przez system plików zamiast przez serwer. Taki układ wygląda na działający i kończy się uszkodzeniem bazy, zwykle przy zaniku zasilania.

Trzecia to zestaw znaków ustawiony przy zakładaniu bazy. Zła wartość daje polskie litery wyświetlane poprawnie w jednym programie i uszkodzone w drugim, a poprawia się to przy odtwarzaniu kopii, nie w locie.

Kiedy przepisywanie na inną bazę mija się z celem

Chęć przeniesienia danych do bazy popularniejszej jest zrozumiała, tylko rzadko opłacalna. Aplikacja korzystająca z tej bazy zawiera zwykle procedury składowane i wyzwalacze napisane w jej własnym dialekcie, a przeniesienie samych tabel bez tej logiki daje zbiór danych, a nie działający program.

Do nowego projektu Firebird bywa wyborem trudnym do obrony z innego powodu: mniejsza społeczność oznacza mniej gotowych bibliotek, mniej odpowiedzi w sieci i węższy rynek osób, które to znają. Do analityki na dużych zbiorach również lepiej nadają się narzędzia projektowane pod odczyt kolumnami. Tam, gdzie działający program branżowy stoi na tej bazie od lat, sensowniejsze jest opanowanie kopii, transakcji i porządkowania niż wymiana fundamentu pod czymś, co działa.