Firebird zarządzanie

Wprowadzenie

• Pełna obsługa procedur przechowywanych i wyzwalaczy,
• Pełna zgoda z standardem ACID,
• Więzy integralności,
• Multi Generational Architecture,
• Bardzo mały rozmiar,
• W pełni funkcjonalny wewnętrzny język procedur przechowywanych i wyzwalaczy (PSQL)
• Wsparcie dla zewnętrznych funkcji (UDF),
• Niewiele lub brak potrzeby specjalistycznych DBA,
• Prawie nie wymaga konfiguracji - wystarczy zainstalować i zacząć używać!
• Duża społeczność i wiele miejsc, gdzie można uzyskać bezpłatną wsparcie,
• Opcjonalna wersja jedno plikowa - świetna do tworzenia katalogów CD, pojedynczego użytkownika lub wersje aplikacji do oceny,
• Dziesiątki narzędzi firm trzecich, w tym graficznych narzędzi administracyjnych, narzędzi replikacji itp,
• Ostrożne zapisy - szybki odzyskiwanie, nie wymagane logi transakcji,
• Wiele możliwości dostęp do bazy danych: native/API, sterowniki dbExpress, ODBC, OLEDB, .Net, JDBC, Python moduł, PHP, Perl, etc,
• Natywny wsparcie dla wszystkich głównych systemów operacyjnych, włączając Windows, Linuks, Solaris, OS X, HP-UX i FreeBSD,
• Przyrostowe kopie zapasowe,
• 64-bitowa architektura,
• Pełna implementacja kursorów w PSQL,
• Monitorowanie tabel,
• Wyzwalacze połączeń i transakcji,
• Tabele tymczasowe,
• TraceAPI - monitorowanie stanu serwera.

Źródło: Get to know Firebird in 2 minutes

Podstawy

Serwer InterBase/Firebird

InterBase - wysoce wydajnym, wielkoformatowym serwerem bazodanowym SQL przeznaczonym dla aplikacji biznesowych, mobilnych i opartych na internecie platform: Windows NT, UNIX, Solaris i MacOS. Od 1985, InterBase dostarcza sprawdzone technologicznie rozwiązania dla baz relacyjnych dla takich przedsiębiorstw jak: Motorola, Nokia, MCI, Northern Telecom, Bear Stearns, Money Store, US Army, NASA, Boeing. Popularność serwera InterBase wynika z łatwości użycia, niskich kosztów utrzymania i uproszczenia procesów wdrożeniowych.

Firebird - wszechstronna relacyjna baza danych SQL, pozwalająca na wykorzystanie architektury klient-serwer, pracująca w wielu środowiskach operacyjnych, włączając Windows, Linux, UNIX. Jej ważną zaletą, jest dostępność na zasadzie licencji Open Source.

Dystrybucje InterBase

InterBase, znany i ceniony serwer baz danych, od pewnego czasu dostępny jest na licencji Open Source. Wersja ta jest wersją darmową, co oznacza, że jej użytkowanie i wykorzystywanie we własnych programach nie pociąga za sobą dodatkowych kosztów. Co więcej, wersję tą można rozprowadzać w dowolny sposób zgodnie z zasadami licencji IBM Public License i Initial Developer's Public License.

Równocześnie jednak firma Borland, wychodząc naprzeciw życzeniom klientów, postanowiła udostępnić płatną wersję InterBase-a 6 na najpopularniejsze platformy. Od niedawna dostępna jest zatem wersja certyfikowana tej bazy danych na następujące rodziny systemy operacyjnych: Linux, Microsoft Windows, Mac OS X i Solaris.

Certyfikacja tego produktu oznacza, że firma Borland dołożyła wszelkich starań aby współpraca z tymi systemami nie sprawiała żadnych problemów, a przede wszystkim dawała pewność co do bezpieczeństwa przechowywanych danych.

Wersja komercyjna InterBase'a 6 Server Edition zawiera dodatkowo kilka funkcji i programów niedostępnych inną drogą. Jest to m.in. uaktualniona i w pełni przetestowana wersja InterClientTM 2, IBXTM, IBConsoleTM, sterowniki ODBC, program IBReplicatorTM oraz pełną dokumentację projektu w wersji elektronicznej i drukowanej.

Równolegle tworzona jest niezależna wersja serwera, zwana Firebird, dostępna stronie http://www.firebirdsql.org/.

Wersje serwera Firebird

Serwer Firebird może zostać zainstalowany do pracy w trzech trybach, różniących się architekturą samego serwera. Aplikacje klienckie mogą komunikować się z poszczególnymi rodzajami serwerów, bez konieczności wprowadzanie jakichkolwiek modyfikacji.

Classic server

Classic server jest historycznie pierwszą wersją. Zaprojektowany pod koniec lat 80-tych, kiedy zasoby komputerów były ograniczone i programy zmuszone były wykorzystywać je w sposób bardzo ekonomiczny. Model Classic server przeznaczony jest dla systemów, dla których wielowątkowość jest niedostępna lub ograniczona, czyniąc niemożliwym wykorzystanie Superserver. Classic server pozostaje najlepszym rozwiązaniem dla środowisk, gdzie wysoka wydajność pozostaje głównym kryterium, a zasoby systemowe są przygotowane na liniowy wzrost obciążenia wraz ze wzrostem liczby użytkowników bazy danych.

Classic Server działa w odrębnym procesie dla każdego połączenia z bazą danych, uruchamianym na żądanie. Gdy klient bazy danych próbuje nawiązać połączenie z bazą, inicjowany jest nowy, oddzielny proces serwera do jego obsługi, który pozostaje dedykowany do wyłącznej obsługi danego klienta przez cały czas jego połączenia z bazą. Kiedy klient kończy połączenie z bazą, jego proces serwera kończy swoje działanie. Każdy nowy klient bazy danych ma wobec tego własne, dedykowane obszary pamięci w ramach serwera, zwiększając w ten sposób liniowo ogólne zapotrzebowanie na zasoby systemowe.

Classic jest zalecany do używania w komputerach wieloprocesorowych oraz w niektórych innych, specyficznych sytuacjach.

SuperClassic

Wersja SuperClassic jako jedyna oferuje tryb pracy Guardian w środowisku Linuks.

Superserver

Wielowątkowy model Superserver lepiej wykorzystuje zaawansowane możliwości nowych serwerów i sieci. Możliwości modelu Superserver do podzielenia procesów serwera na niezależne wątki oraz dynamiczna alokacja pamięci podręcznej czynią go wydajniejszym od Classic Server w zastosowaniach z dużą liczbą współpracujących użytkowników i ograniczonymi zasobami sprzętowymi.

Proces serwera w tym modelu jest jeden, uruchamiany najczęściej wraz ze startem systemu, i pozostaje aktywny aż do zamknięcia systemu lub jawnego żądania zamknięcia serwera.

Model Superserver rezerwuje do komunikacji z bazą danych wspólny obszar pamięci dla wszystkich klientów bazy, zwiększając tym samym efektywność wykorzystania zasobów systemowych. Dodatkowo, Superserver pozwala na komunikację z bazą danych wyłącznie przy wykorzystaniu mechanizmów sieciowych (Classic serwer umożliwia bezpośrednie operacje na plikach lokalnych baz danych), nawet dla baz danych wykorzystywanych lokalnie – połączenia są wykonywane standardowo poprzez serwer localhost (IP 127.0.0.1).

Embedded

Wersja Embedded jest odmianą serwera - w pełni funkcjonalna, dostępna w postaci kilku plików. Łatwa do uruchomienia, z racji na brak konieczności instalacji Firebird-a.

Embedded server

Model Embedded jest odmianą Superserver dla systemu operacyjnego Windows, zawierającą własną instalację klienta, odwołującą się bezpośrednio i wyłącznie do zarządzanej przez niego bazy danych. Aplikacja korzystająca z takiego serwera bazy danych może wykorzystywać wyłącznie połączenia lokalne, dostępne jest połączenie tylko z jednym procesem klienta - jedna baza danych może być wykorzystywana tylko przez jedną aplikację.

Ochrona danych

Programowa

Dostęp do systemu komputerowego powinien być możliwy jedynie dla osób powołanych. W sieciach komputerowych wymagane jest stworzenie układu kont i haseł, umożliwiającego dostęp do poszczególnych zasobów sieci określonym użytkownikom.

Istnieje możliwość zdefiniowania systemu haseł na potrzeby każdego systemu, możliwego do wykorzystywania na pojedynczych komputerach, nie chronionych przez zabezpieczenia sieci komputerowych, lub też jako uzupełnienie zabezpieczeń wynikających z instalacji sieci. Każdy operator posiada unikalny kod, rejestrowany podczas każdej modyfikacji przez niego poszczególnych zakresów danych. Oprogramowanie użytkowe Pakietu dla Administracji potrafi rozpoznać użytkowników i przypisać im odpowiednie uprawnienia w zakresie dostępu do poszczególnych funkcji.

Dodatkowo, podczas edycji danych, danych oprogramowanie dba o poprawność i wzajemną spójność podawanych informacji.

Przez użytkownika

Podczas codziennej pracy z programami zaleca się częste wykorzystywanie ich dokumentacji - w celu przypomnienia pewnych informacji, podpowiedzi o sposobie przetwarzania danych, znalezienia wyjaśnienia zaistniałych problemów. Najlepszym uzupełnieniem dokumentacji jest serwis oprogramowania - możliwość natychmiastowego kontaktu telefonicznego i uzyskania wyczerpującej odpowiedzi, a także wizyta kompetentnej osoby w siedzibie użytkownika, w celu rozwiązania powstałych problemów.

Równolegle z elektronicznym przetwarzaniem danych należy zadbać o sporządzanie dokumentacji tej działalności w postaci wydruków. Oprogramowanie umożliwia tworzenie szerokiego zestawu wydruków danych, zarówno syntetycznych jak i analitycznych. Utworzenie niektórych jest wymagane (np. dzienniki obrotów, rejestry), warto jednak przeanalizować i inne zestawienia i wykonywać je w regularnych okresach czasu.

Instalacja

Wymagania sprzętowe i programowe

• Procesor. Jeśli serwer posiada kilka fizycznych procesorów lub procesor wielordzeniowy, instalujemy Firebirda w wersji Classic Server (lub SuperClassic dla >= Firebirda 2.5). Monitorujemy obciążenia procesora, może okazać się, że będzie konieczna wymiana CPU na wydajniejszy,
• Dysk twardy,
  • Plik z bazą danych najlepiej jeśli jest umieszczony na dedykowanym dysku. Dla dużych danych macierz RAID lub dyski SSD. Można plik bazy umieścić bezpośrednio w pamięci RAM (w Linuksie montowanie przez fstab, w Windowsie dodatkowe programy) i włączyć shadowing/rsync,
  • Zabezpieczamy dostęp do pliku bazy danych nie udostępniając dysku i/lub pliku.
• Sieć:
  • Zapora sieciowa. Firebird korzysta z portu TCP 3050 i 3051. Jeśli są duże opóźnienia w dostepie do bazy, można wyłączyć chwilowo zaporę,
  • Wydajność sieci sprawdzamy poprzez polecenie ping do serwera Firebirda z parametrem -l 8192. Opóźnienie nie powinno być większe niż 2 ms. Przykład:

ping -l 8192 192.168.1.2

• Oprogramowanie:
  • Program antywirusowy jeśli serwer Windows. Dodaje serwera firebirda do zaufanych aplikacji. Skanowanie pliku bazy danych może również wpłynąć na wydajność (wykluczamy lokalizację),
  • Aktualny system operacyjny wraz z aktualnym sterownikami,
  • Okresowo przeglądamy logi serwera dostępne w pliku Firebird.log,
  • Aliasy bazy Firebird.
• Nie uruchamiamy wygaszacza ekranu (lepiej wyłączać monitor),
• Na komputerze obsługującym bazę danych nie zalecamy wykonywania normalnej pracy – osłabia to wydajność systemu, lepiej jest wykorzystywać komputer dedykowany wyłącznie do obsługi serwera:
  • Jeżeli komputer jest wykorzystywany do pracy sporadycznie, wylogowujemy się z systemu (Windows NT/2000/ itd.).

Serwera

Windows

Pobieramy ze strony internetowej www.firebirdsql.org aktualną wersję serwera dla systemu operacyjnego, na którym będzie przechowywana baza danych. Następnie uruchamiamy pobrany plik i instalujemy serwer jako usługę. W celu zainstalowania, będziemy potrzebowali uprawnień administratora systemu. Po zainstalowaniu uruchamiamy ponownie komputer. W liście usług Menadżera zadań widnieje uruchomiona usługa Firebird.

Po zainstalowaniu programu może wystąpić błąd niezgodności sterownika baz danych. Należy wówczas:

• Uruchomić BDE Administrator w Panelu Sterowania,
• Wybrać alias IS_PDA,
• Zmienić LANGDRIVER na dowolny,
• Zapisać zmiany,
• Następnie powtórnie ustawić na Paradox Polish 852.

Ponadto należy sprawdzić, czy wartość ENABLED BCD jest ustawiona na true. Standardowym użytkownikiem bazy is_pda.gdb jest:

• Użytkownik - SYSDBA
• Hasło - masterkey

W przypadku włączenia opcji Kontrola uprawnień standardowym użytkownikiem jest:

• Użytkownik: Administrator
• Hasło: a

Wskazówki

Nie zalecamy:

• Instalacji serwera Firebird-a na systemach Windows 95/98/ME.
• Korzystania z Firebird-a w wersji 1.5 (programy w wersji 2011 nie będą działać) i 2.0 (wersja ta działa niestabilnie).
• Programy antywirusowe mogą poważnie uszkodzić pliki bazodanowe, powodując utratę danych. Konfigurujemy je tak, by nie skanowały plików z bazami danych.
• W sytuacji instalacji Firebirda na komputerze wyposażonym w procesor wielordzeniowy, korzystamy z wersji Classic Serwer.
• Instalowanie serwera w systemach Windows Vista/ 7
  • Przed instalacją serwera i aplikacji upewniamy się czy wyłączona jest opcja Kontrola konta użytkownika (UAC) w Panel sterowania > Użytkownicy.
• Na systemach 64-bitowych instalujemy wersję Firebird dla systemów 32-bitowych. W razie występowania problemów z instalacją BDE (Borland Database Engine) pobieramy i instalujemy BDE w wersji 5.1.
• Parametry baz danych:
  • Rozmiar strony. Standardowo strona bazy danych ma 1K – zwiększenie jej rozmiaru do 4K zwiększa całkowity rozmiar bazy danych, ale może przynieść wiele korzyści:
  • Mniej rekordów danych jest dzielonych pomiędzy strony bazy danych, odczytywanie danych jest znacznie szybsze,
  • Indeksy tablic mają efektywniejszą strukturę, przyspiesza to odszukiwanie danych,
  • Rozmiar strony możemy zmienić tylko w wyniku operacji backup-restore bazy danych,
  • Pamięć cache serwera bazy danych. Standardowo pamięć cache odpowiada 256 stronom bazy danych – jeżeli jest taka możliwość, zalecamy zwiększenie rozmiaru tej pamięci w celu zwiększenia wydajności. Zmianę wykonujemy poleceniem gfix (wielkość pamięci określa się w stronach bazy danych):

Gfix.exe –buffers 3000 baza_danych.gdb

Jednocześnie pamiętamy, aby nie ustawić zbyt dużego rozmiaru cache – może bowiem zajść sytuacja, w której Firebird zacznie część tej pamięci zapisywać na dysku, co spowoduje spowolnienie działania. Serwer alokuje oddzielny obszar cache dla każdej obsługiwanej bazy danych.

Linuks

Instalacja zależna jest od dystrybucji systemu Linuks. Dla dystrybucji opartej o paczki typu RPM serwer Firebird instalujemy poleceniem rpm –Uvh <nazwa_paczki_firebird> jako root (lub podnosimy uprawnienia użytkownika poleceniem sudo).

Uwaga!

Jeśli posiadamy wcześniejszą wersję to musimy ją bezwzględnie od instalować przed instalacją nowej wersji.

Należy również sprawdzić wymaganą wersję jądra i biblioteki glibc (czasami nie ma możliwości upgrade [np. dla dystrybucji Centos 5.X] i konieczna będzie pełna instalacja nowszej wersji Linuksa).

W trakcie instalacji serwera bazy Firebird w wersji 2.5. na platformie Linux automatycznie generowane jest losowe hasło dostępu do serwera dla użytkownika sysdba. Hasło znajduje się w pliku:

/opt/firebird/SYSDBA.password

Aby móc połączyć się z bazami INFO-SYSTEM należy zmienić hasło na standardowe masterkey. Aby dokonać zmiany hasła należy uruchomić poniższy skrypt:

/opt/firebird/bin/changeDBAPassword.sh script

Po uruchomieniu zostaniemy zapytani o aktualne hasło użytkownika SYSDBA - należy je odczytać z pliku SYSDBA.password następnie zostaniemy poproszeni o podanie nowego hasła więc wpisujemy nasze hasło masterkey. Następnie restartujemy serwer Firebird poleceniem:

/etc/init.d/firebird reload

Wszystkie czynności wymagają poświadczeń administracyjnych.

W przypadku problemów z połączeniem przez sieć (działa połączenie lokalne, zapora wyłączona, uprawnienia sprawdzone) zalecamy przełączyć się na tryb SuperClassic za pomocą skryptu changeMultiConnectMode.sh i odpowiedzieć thread.

Bazy danych

Czysta baza danych dostarczana jest wraz z instalatorem programów INFO-SYSTEM.

Lokalizacja bazy danych

Programy z instalatora posiadają skonfigurowaną ścieżkę do pliku bazy danych. Jeśli baza danych jest w innej lokalizacji, to w pliku XML danej aplikacji podajemy ścieżkę do bazy danych. W celu uniknięcia jawnego podawania ścieżki do bazy danych w pliku XML, można użyć aliasu bazy. Alias podaje się w pliku aliases.conf, zlokalizowanym w katalogu z instalacją Firebird – należy dokonać wpisu:

ALIAS_BAZY = ścieżka_do_bazy_danych

Po podaniu aliasu, w pliku konfiguracyjnym w miejsce ścieżki należy wprowadzić alias.

Generowanie nowej bazy danych

Czysta baza danych dołączana jest przez dystrybutora do każdej wersji oprogramowania. Generowanie nowej bazy odbywa się poprzez:

• Skopiowanie czystej bazy,
• Rozszerzanie nowej bazy danych o tabele nowej aplikacji. Pełen opis znajduje się w instrukcji programu Admin,
• Sprawdzanie wersji aplikacji i bazy danych.

W każdej aplikacji, po kliknięciu odpowiedniej ikony, lub wybraniu z menu Informacje o środowisku, program pokazuje okno z informacjami o wersji programu, wersji bazy danych, połączeniu z bazą danych i jej lokalizację, oraz ogólne informacje o tabelach, dając pogląd o rozmiarze danych w bazie.

Upgrade aplikacji - modyfikacje bazy danych

Kolejne wersje aplikacji mogą wymagać modyfikacji bazy danych (struktury tabel, procedury wbudowane). W tym celu razem z aplikacją dostarczane są pliki SPT. Wykonywane są one automatycznie przez program, bezpośrednio po jego uruchomieniu.

Wersja bazy danych, wykorzystywana przez aplikację przechowywana jest w polu DBVERSION w tabeli IS_REJESTR. Wpis powinien mieć format rrmmdd np. 040831, natomiast skrypty aktualizacyjne dodatkowo mają rozszerzenie spt, np. 040901.spt i powinny być przechowywane w podkatalogu SPT głównego katalogu programu. Program wykonuje tylko skrypty z datą wcześniejszą, niż odczytana wersja bazy danych.

Aplikacji

Aplikację instalujemy z instalatora. Jeśli nie mamy lub nie istnieje instalator, to wykionujemy kroki opisane w sekcji Brak instalatora programu.

Protokoły komunikacyjne

Wyboru protokołu komunikacyjnego dokonuje się poprzez odpowiednią specyfikacje bazy danych w pliku DBPATH.SQN.

TCP/IP

Architektura protokołu TCP/IP sprawia, że pakiety sieciowe są kierowane bezpośrednio do odbiorców, nie powodując nadmiernego obciążenia sieci, w związku z czym korzystanie z tego protokołu pozwala na jednoczesną wydajną pracę większej liczby użytkowników.

Standardowo komunikacja odbywa się przy wykorzystaniu portu 3050, jednak poprzez odpowiednia konfigurację serwera i zainstalowanych klientów, istnieje możliwość zmiany tego ustawienia.

NetBEUI

NetBEUI zaprojektowany do niewielkich sieci lokalnych, nie jest protokołem wydajnym z punktu widzenia zastosowań bazodanowych. Wykorzystanie tego protokołu powinno zostać ograniczone do niewielkich baz danych, wykorzystywanych przez co najwyżej kilku użytkowników.

Uwaga!

Serwer Firebird alokuje oddzielny obszar cache dla każdej obsługiwanej bazy danych.

Baza haseł

Baza haseł nosi nazwę ISC4.GDB, i jest instalowana w katalogu serwera InterBase. Wszyscy użytkownicy, chcący korzystać z jakiejkolwiek bazy danych, obsługiwanej przez serwer, są zdefiniowani w tej bazie. Baza ta jest obsługiwana wyłącznie przez serwer InterBase.

Klucze aktywacyjne

Po zainstalowaniu lub zaktualizowaniu do nowej wersji aplikacji, program automatycznie wygeneruje tymczasowy klucz, pozwalający na pracę z programem przez okres 30 dni. W tym czasie, po uruchomieniu aplikacji, ukazywać się będzie okno, przypominające o konieczności rejestracji i umożliwiające natychmiastowe przejście do wprowadzenia kodu. Klucze aktywacyjne generowane są w firmie INFO-SYSTEM, po przekazaniu niezbędnych informacji:

• Pełna nazwa użytkownika (bez odróżniania małych i dużych liter),
• Wykorzystanej nazwy użytkownika, dla której należy wygenerować kod (jeżeli jest inna niż wcześniej podana),
• Nazwy programu oraz parametrów instalacji (liczby końcówek).

Klucz aktywacyjny to pięć grup znaków alfanumerycznych, liczących po cztery znaki każda, np. QR65-W98U-XC45-W5T7. Klucz aktywacyjny jest generowany na podstawie:

• Nazwy użytkownika oprogramowania,
• Nazwy (kodu) programu,
• Wersji/ liczby stanowisk.

Jakakolwiek zmiana tych danych wymaga przygotowania nowego klucza. Klucz aktywacyjny jest zapisywany w pliku XML konfiguracji aplikacji, jeżeli więc aplikacja jest wykorzystywana na kilku stacjach roboczych, na każdej z nich należy podać ten sam klucz.

Uwaga!

Podana przy instalacji nazwa użytkownika będzie opatrzona komentarzem o nie zarejestrowaniu użytkowanej aplikacji!

Zgłoszenie użytkownika można dokonać faksem, mailem (na adres email aktywacja@groszek.pl) lub przy wykorzystaniu strony internetowej. Po zalogowaniu na stronie groszek.pl w menu należy wybrać stronę Aktywacja – program umożliwi podanie danych nowego klienta oraz sprawdzenie już wygenerowanych kluczy.

Należy pamiętać o wprowadzeniu pełnej, prawidłowej nazwy użytkownika do pliku XML – konfiguracji aplikacji, korekta nazwy po wygenerowaniu klucza uniemożliwi pracę i będzie wymagała zmiany klucza aktywacyjnego.

Uwaga!

W wyjątkowych wypadkach może zostać przygotowany klucz tymczasowy, umożliwiający pracę bez zarejestrowania przez krótki okres czasu.

Po wejściu w menu Pomoc > Drukuj licencję funkcja umożliwia wydrukowanie wniosku o przygotowanie klucza aktywacyjnego, zawierającego m.in. podaną nazwę użytkownika – wniosek taki łatwo przesłać faksem.

Borland Database Engine (BDE)

Wstęp

BDE jest zestawem bibliotek DLL pozwalającym na dostęp do baz danych zarówno typu desktop (np. dBase, Paradox), jak i klient/serwer (za pomocą sterowników SQL Link albo ODBC). Architektura BDE bazuje na sterownikach napisanych dla każdego stosowanego systemu obsługi baz danych (DBMS). Standardowa instalacja BDE zawiera sterowniki do Paradoxa, dBase-a, MS Accessa, FoxPro i tabel tekstowych.

Dostęp do konkretnych baz danych realizowany jest poprzez tzw. aliasy. Każdy alias określony jest przez unikalną nazwę i zawiera zestaw parametrów definiujących podłączenie do bazy (np. ścieżkę dostępu). Liczba parametrów zależy od rodzaju bazy danych (sterowniki standardowe mają tylko trzy parametry, podczas gdy sterowniki SQL Links i ODBC – kilkanaście).

Instalacja

Zestaw bibliotek składających się na BDE jest zapisywany w katalogu \Program Files\Common Files\Borland Shared\Bde. Dane konfiguracyjne zapisywane są w pliku IDAPI.CFG (zawiera on m.in. informacje o założonych aliasach).

Typowe błędy przy starcie aplikacji

Błąd przy starcie aplikacji oznacza brak połączenia programu z serwerem Firebird-a. Problemy mogą dotyczyć działania serwera F. bądź połączenia z komputerem na którym znajduje się baza danych.

• Sprawdzić, czy serwer F. jest uruchomiony. W tym celu na komputerze, na którym znajduje się baza danych, uruchamiamy w menu Panel sterowania > Firebird i sprawdzamy, czy pojawia się informacja: Firebird service is running. Jeżeli tak, to przechodzimy do następnego punktu. Jeżeli zamiast tego pojawia się komunikat Firebird service is not running, należy kliknąć przycisk Start, aby uruchomić F. Sprawdzamy poprawność ścieżki do bazy danych.
• Otwieramy plik .XML dla danej aplikacji i w sekcji link sprawdzamy poprawność ścieżki do bazy danych. Jeżeli na serwerze baza danych znajduje się na dysku C:\ to podajemy w ścieżce adres IP serwera oraz literę dysku C:
  Przykładowa poprawna ścieżka ma format:

192.168.1.10:c:\info-sys_groszek\info-sys_db\is_pda.gdb

• Sprawdzamy poprawność połączenia sieciowego poleceniem ping,
• Następnie sprawdzamy ustawienia zapory internetowej (firewall) i programu antywirusowego. Programy te mogą blokować dostęp do serwera Firebird. W celu odblokowania dostępu, programy antywirusowe i firewalle tak konfigurujemy, aby zezwalały programom na dostęp do sieci oraz otwieramy port 3050.

Konfiguracja

Rozmiar strony

Standardowo strona bazy danych ma 1K – zwiększenie jej rozmiaru do 4K zwiększa całkowity rozmiar bazy danych i przynosi wiele korzyści:

• Mniej rekordów danych jest dzielonych pomiędzy strony bazy danych, odczytywanie danych jest znacznie szybsze,
• Indeksy tablic mają efektywniejszą strukturę, przyspiesza to odszukiwanie danych.

Zmiana rozmiaru strony bazy danych może zostać przeprowadzona tylko w wyniku operacji backup-restore bazy danych.

Pamięć cache serwera bazy danych

Standardowo pamięć cache odpowiada 256 stronom bazy danych – jeżeli jest taka możliwość, zalecane jest zwiększenie rozmiaru tej pamięci w celu zwiększenia wydajności. Operację wykonujemy poleceniem gfix (wielkość pamięci określa się w stronach bazy danych):

Gfix.exe -buffers 3000 baza_danych.gdb

Jednocześnie pamiętamy, aby nie ustawić zbyt dużego rozmiaru cache – może bowiem zajść sytuacja, w której Firebird zacznie część tej pamięci zapisywać na dysku, co spowoduje spowolnienie działania.

Definiowanie operatorów aplikacji

Po zainstalowaniu aplikacji zdefiniowany jest jeden operator o:

• nazwie administrator
• hasłem a

Po zainstalowaniu aplikacji i zdefiniowaniu operatorów hasło administratora należy zmienić. Zarządzanie operatorami i uprawnieniami odbywa się z poziomu programu Admin.

Po wywołaniu programu należy wybrać z menu Ustawienia > Rejestr operatorów. W oknie dostępne są trzy zakładki:

• Grupy – program umożliwia zdefiniowanie grup, do których przypisani są poszczególni operatorzy. Grupom można przypisywać uprawnienia, każdy operator otrzymuje (dziedziczy) takie uprawnienia, jakie mają grupy, do których należy. Definiując grupę podajemy jej nazwę skrótową, nazwę opisową, wybieramy operatorów do niej należących oraz uprawnienia, które posiada grupa,
• Operatorzy – program umożliwia zdefiniowanie dowolnie wielu operatorów. Każdy operator może należeć do jednej lub wielu grup. Operator dziedziczy uprawnienia grup, do których należy, można także podać uprawnienia dodatkowe – uzupełniające. Podczas definiowania nowego operatora należy najpierw podać jego nazwę, nazwę opisową oraz hasło, zapamiętać dane, a dopiero wówczas ponownie wybrać dane do edycji i nadać uprawnienia. Podczas logowania do aplikacji program automatycznie podpowiada nazwę pracującego operatora, otrzymywaną od Windows lub sieci – definiując nowych operatorów dobrze jest więc nadawać im nazwy zgodne z sieciowymi,
• Uprawnienia – przypisywane są funkcjonalnościom aplikacji – określonym działaniom w obrębie aplikacji, do wykonania których jest uprawniony użytkownik. Definicje uprawnień są wprowadzane podczas generowania bazy danych, i zasadniczo nie ma potrzeby ich modyfikowania.

Definiowanie użytkowników bazy danych

Ze względu na niemożność powiązania zakresu uprawnień poszczególnych operatorów z uprawnieniami do obiektów bazy danych, przyjęto zasadę rozstrzygania uprawnień na poziomie dostępu do funkcjonalności aplikacji. Każda aplikacja wymaga, aby zalogowanie do bazy danych (z parametrami, podawanymi w pliku XML) odbywało się dla operatora z pełnym dostępem do jej obiektów (a dokładniej: do obiektów, wykorzystywanych przez daną aplikację, o ile z bazy korzysta więcej niż jeden program). Po zalogowaniu się operatora do programu odczytywane są jego uprawnienia, a następnie udostępniane odpowiednie funkcje aplikacji. Standardowo instalowana baza danych ma zdefiniowanego jednego użytkownika:

• Użytkownik: SYSDBA
• Hasło: masterkey

Posiada on pełne uprawnienia do wszystkich zdefiniowanych tabel w bazie danych. Zmiana danych użytkownika bazy dokonuje się z poziomu programu Admin. Należy przy tym odróżnić użytkownika bazy danych od operatora aplikacji:

• Istnieje możliwość zmiany domyślnego użytkownika bazy danych – po zdefiniowaniu użytkownika na poziomie bazy danych i dodaniu mu pełnych uprawnień do wszystkich tabel i procedur aplikacji,
• Do tabeli systemowej IS_REJESTR powinni mieć pełny dostęp wszyscy użytkownicy bazy danych,
• Użytkownicy, zdefiniowani dla systemów korzystających z bazy osobowej powinni mieć zdefiniowane pełne prawa do tabel bazy osobowej.

Konfiguracja BDE

Do konfigurowania BDE służy aplikacja BDE Administrator wywoływana z Panelu Sterowania (skrót do pliku bdeadmin.exe). Po uruchomieniu programu wyświetlane jest okno z dwoma zakładkami:

• Databases,
• Configuration.

Pierwsza zakładka pozwala na zakładanie, modyfikowanie i usuwanie aliasów dających dostęp do konkretnych baz danych. Druga pozwala na skonfigurowanie zainstalowanych sterowników oraz samego motoru BDE.

Parametry motoru BDE

Ustawienia motoru DBE są dostępne po wybraniu zakładki Configuration i rozwinięciu obiektu INIT.

Uwaga!

Najważniejsze parametry zostały zaznaczone pogrubioną czcionką!

Z prawej strony zostaną wyświetlone następujące parametry:

• AUTO ODBC – jeżeli wartość jest równa:
  • TRUE, to podczas inicjowania BDE zostaną odczytane wszystkie zainstalowane sterowniki ODBC i źródła danych (data sources) (ustawienie tego parametru na TRUE nie jest zalecane),
  • FALSE (wartość domyślna),
• DATA REPOSITORY – nazwa aktywnego słownika danych (przydatne podczas programowania),
• DEFAULT DRIVER – sterownik, który będzie użyty (wypróbowany) jako pierwszy do otwarcia tabeli bez podanego rozszerzenia; dotyczy tylko sterowników typu FILE (np. dBase, Paradox),
• LANGDRIVER – nazwa sterownika językowego; powinna być zgodna z ustawieniami Windows (w przypadku strony kodowej numer 1250 stosowanej w polskiej wersji Windows można wybrać Pdox ANSI Polish),
• LOCAL SHARE – jeżeli baza danych może być otwierana przez programy nie korzystające z BDE (np. w przypadku baz dBase przez programy napisane w Clipper-ze) wartość tego parametru powinna być ustawiona na TRUE,
• LOW MEMORY USAGE LIMIT,
• MAXBUFSIZE – maksymalna ilość pamięci w kB do buforowania danych z bazy; podana liczba musi być wielokrotnością 128 (maksimum: 65535),
• MAXFILEHANDLES – maksymalna liczba uchwytów plików używanych przez BDE; liczba całkowita od 5 do 4096; większe wartości poprawiają wydajność, ale zużywają więcej zasobów Windows,
• MEMSIZE – maksymalna ilość pamięci używanej przez BDE (w MB); liczba nie większa niż 205,
• MINBUFSIZE – minimalna ilość pamięci w kB do buforowania danych z bazy; liczba całkowita od 32 do 65535,
• MTS PULLING,
• SHAREDMEMLOCATION – zalecany adres, pod którym zostanie załadowany zarządca pamięci dzielonej oraz zarządca dzielonego bufora (shared memory manager, shared buffer manager),
• SHAREDMEMSIZE – maksymalna ilość pamięci w kB, której BDE używa do dzielonych zasobów (shared resources); minimalna wartość to 2048,
• SQLQRYMODE – metoda, w jaki obsługiwane są zapytania do baz SQL; dostępne wartości to: NULL, SERVER, LOCAL; parametr jest dostępny tylko wtedy, gdy jest zainstalowany co najmniej jeden ze sterowników SQL Link,
• SYSFLAGS,
• VERSION – wersja BDE.

Obiekt Formats w zakładce Configuration zawiera parametry wykorzystywane podczas zamiany łańcuchów znakowych (napisów) na datę, czas i liczby. Są to (najpierw data):

• FOURDIGITYEAR – określa sposób w jaki BDE traktuje daty z dwiema cyframi roku; jeżeli parametr jest równy:
  • FALSE, to daty od 01/01/00 do 31/12/49 są traktowane jako należące do XXI wieku (np. data 25/03/02 zostanie rozwinięta do postaci 25/03/2002), a daty z zakresu 01/01/50 do 12/31/99 – jako należące do XX wieku (np. data 11/10/98 zostanie rozwinięta na 11/10/1998); parametr ten nie jest brany pod uwagę w zapytaniach SQL,
• LEADINGZEROD – kontroluje, czy jednocyfrowy numer dnia ma mieć wiodące zero; jeżeli wartość jest równa TRUE, to podanie daty 3/12/2001 zostanie zinterpretowane jako 03/12/2001,
• LEADINGZEROM – tak samo jak LEADINGZEROD, ale w odniesieniu do miesiąca,
• MODE – kontroluje kolejność w jakim występują w dacie dzień (D), miesiąc (M) i rok (R): 0 (MDR), 1 (DMR), 2 (RMD),
• SEPARATOR – znak używany do oddzielenia dnia, miesiąca i roku,
• YEARBIASED – stosowane w przypadku wprowadzenia daty z dwoma cyframi roku; jeżeli TRUE, to podanie tylko dwóch cyfr roku spowoduje, że BDE uzupełni je dwoma cyframi wieku, określonymi w ten sam sposób, jaki został podany przy parametrze FOURDIGITYEAR.

Następujące parametry odnoszą się czasu:

• AMSTRING – ciąg znaków na określenie porannych godzin (od północy do południa); parametr wykorzystywany tylko wtedy, gdy TWELVEHOUR jest równe TRUE,
• MILSECONDS – czy czas ma być wyświetlany z dokładnością do milisekund,
• PMSTRING – ciąg znaków na określenie godzin wieczornych (od południa do północy); parametr wykorzystywany tylko wtedy, gdy TWELVEHOUR jest równe TRUE,
• SECONDS – czy czas ma być wyświetlany z dokładnością do sekund,
• TWELVEHOUR – czy czas ma być rozwijany z wykorzystaniem zegara 12 godzinnego (TRUE), czy 24 godzinnego (FALSE).

Następujące parametry odnoszą się do liczb:

• DECIMALDIGITS – maksymalna liczba cyfr dziesiętnych,
• DECIMALSEPARATOR – znak służący jako separator oddzielający część całkowitą liczby od jej części dziesiętnej,
• LEADINGZERON – czy liczby z przedziału (-1.0;1.0) mają mieć wyświetlane wiodące zero (np. .14 będzie wyświetlone jako 0.14 wtedy, gdy parametr jest równy TRUE),
• THOUSANDSEPARATOR – znak służący jako separator grupujący po trzy cyfry z części całkowitej liczby (jeżeli separatorem będzie , to liczba 1950421.45 zostanie wyświetlona jako 1,950,421.45).

Parametry sterowników

Parametry związane z zainstalowanymi sterownikami znajdują się w części Drivers zakładki Configuration. Jest ona podzielona na dwie grupy: Native, zawierająca sterowniki dedykowanymi BDE oraz ODBC, zawierająca sterowniki odczytane przez ODBC Driver Socket. Poniższy opis będzie dotyczył tylko wybranych sterowników z części Native.

Pod nazwą DBASE umieszczone są parametry sterownika służącego do obsługi baz danych opartych na tabelach dBase (od wersji dBase III do Visual dBase 7). Są to:

• VERSION – numer wersji sterownika,
• TYPE – typ serwera, który jest obsługiwany przez sterownik (w tym przypadku FILE),
• LANGDRIVER – sterownik językowy używany do określenia zestawu znaków wykorzystywanych w bazach danych oraz do określenia kolejności podczas sortowania,
• LEVEL – typ formatu danych używany do tworzenia tabel tymczasowych; dostępne wartości:
  • 7 (dBase 7.0),
  • 5 (dBase 5.0),
  • 4 (dBase 4.0),
  • 3 (dBase III i dBase III PLUS),
• MDX BLOCK SIZE – rozmiar w bajtach bloków używanych do tworzenia indeksów .MDX; liczba całkowita będąca wielokrotnością 512,
• MEMO BLOCK FILE SIZE – rozmiar w bajtach bloków używanych do tworzenia plików .DBT obsługujących pola typu memo; liczba całkowita będąca wielokrotnością 512. Tylko jedna wartość parametru LANGDRIVER obsługuje polskie znaki diakrytyczne – jest to dBASE PLK cp852. Obsługuje ona stronę kodową numer 852 (Latin 2). Jeżeli tabele są zapisane przy użyciu innego zestawu znaków (np. Mazovia), należy użyć sterownika ascii ANSI.

Pod nazwą PARADOX znajdują się parametry sterownika służącego do obsługi baz danych typu Paradox. Są to:

• NET DIR – położenie pliku PDOXUSRS.NET używanego do kontrolowania dostępu do bazy; jeżeli baza danych ma być jednocześnie wykorzystywana przez wielu użytkowników, to plik powinien znajdować się w katalogu sieciowym dostępnym dla tych użytkowników (w trybie z uprawnieniami do zapisu i odczytu),
• VERSION – numer wersji sterownika,
• TYPE – typ serwera, który jest obsługiwany przez sterownik (w tym przypadku FILE),
• LANGDRIVER – sterownik językowy używany do określenia zestawu znaków wykorzystywanych w bazach danych oraz do określenia kolejności podczas sortowania,
• BLOCK SIZE – rozmiar w bajtach bloków dyskowych używanych do tworzenia tabel; wielokrotność liczby 1024,
• FILL FACTOR – procent wypełnienia bloku dyskowego plików indeksowych, którego przekroczenie powoduje dodanie nowego bloku; liczba całkowita od 1 do 100; im mniejsza wartość, tym większa wydajność indeksów, ale także ich rozmiar,
• LEVEL – typ tabel tymczasowych,
• STRICTINTEGRT – określa, czy tabele mogą być modyfikowane przez programy, które nie zapewniają integralności referencyjnej (od klucza obcego); wartość TRUE nie pozwala na takie zmiany (zalecane).

Dostępne są dwa sterowniki językowe obsługujące polską stronę kodową: Paradox Polish 852 (strona kodowa 852) i Pdox ANSI Polish (strona kodowa używana w systemie Windows).

Parametry sterownika zapewniającego dostęp do baz Interbase umieszczone są pod nazwą INTERBASE. Są to między innymi:

• ENABLE BCD – określa sposób konwersji pól typu numerycznego; jeżeli parametr jest równy TRUE, to wartości są przekształcane do formatu BCD (Binary Coded Decimal); dzięki temu można uniknąć błędów zaokrąglania związanych z reprezentacją zmiennoprzecinkową,
• LANGDRIVER – nazwa sterownika językowego używana przez BDE do konwersji łańcuchów znakowych odczytywanych z bazy i zapisywanych do bazy; strona kodowa używana w bazie może być inna niż strona kodowa używana w systemie Windows; nazwa sterownika językowego musi odpowiadać stronie kodowej, w jakiej dane są przechowywane w bazie,
• MAX ROWS – maksymalna liczba rekordów, jakie sterownik może pobrać dla każdego z zapytań wysłanych do bazy; za pomocą tego parametru można zapobiec nieuważnej próbie ściągnięcia na końcówkę zbyt dużej liczby wierszy; z drugiej strony zbyt mała wartość tego parametru może blokować próbę otwarcia tabeli, ponieważ ilość informacji związana z definicją tabeli (schema information) będzie przekraczała narzucone ograniczenie (wartość -1 oznacza brak ograniczeń),
• OPEN MODE – określa tryb otwarcia bazy przez sterownik: READ/WRITE (do zapisu i odczytu) albo READY ONLY (tylko do odczytu),
• SERVER NAME – pełna nazwa serwera.

Definiowanie aliasów BDE

Dostęp BDE do danej bazy jest definiowany przez aliasy. Każdy z nich zawiera pewną liczbę parametrów, zależną od rodzaju bazy, której alias dotyczy. Standardowe aliasy używane są do podłączenia do baz typu desktop (dBase, Paradox, FoxPro, tabele tekstowe). Zawierają następujące parametry:

• DEFAULT DRIVER – określa typ plików (a jednocześnie rodzaj sterownika) składających się na bazę (do wyboru: PARADOX, DBASE, FOXPRO, ASCIIDRV),
• ENABLE BCD – określa sposób konwersji pól typu numerycznego; jeżeli parametr jest równy TRUE, to wartości są przekształcane do formatu BCD (Binary Coded Decimal); dzięki temu można uniknąć błędów zaokrąglania związanych z reprezentacją zmiennoprzecinkową,
• PATH – ścieżka dostępu do bazy danych.

Podłączeniu do baz typu Interbase służą aliasy typu INTERBASE. Parametry aliasów tego typu są takie same, jak opisane w części Parametry sterowników. Parametr SERVER NAME powinien zawierać pełną nazwę pliku (razem z nazwą katalogu), w którym znajduje się baza danych.

Serwisowanie

Narzędzia administracyjne

Konsola

• fbtracemgr - Interaktywny wiersz poleceń do wykonywania komend i skryptów DDL i DDM,
• gbak:
  • Tworzenie kopii zapasowej,
  • Przywracanie.
• gfix:
  • Naprawa,
  • Uruchomienie i zatrzymanie serwera,
  • Rozwiązanie stanu zawieszenia transakcji pomiędzy wieloma bazami,
  • Zmianę liczby buforów i stron.
• gsec - Zarządzanie użytkownikami,
• gstat - Statystki dotyczące zawartości bazy danych,
• isql - Interactive SQL,
• nbackup - Przyrostowe kopie zapasowe,
• nbak - Moduł wsparcia silnika bazy danych.

Graficzny interfejs użytkownika

• Workbench DB Workbench,
• EMS SQL Manager for InterBase/Firebird,
• Firebird SQL Studio,
• FlameRobin,
• IB Expert.

Błędy aplikacji

Po wystąpieniu błędu system pokazuje okno z jego opisem:

Okno z opisem błędu z uwidocznionymi szczegółami - w tym wypadku w konfiguracji programu podano niepoprawną nazwę pliku bazy danych. W dolnej części okna znajdują się przyciski:

• Szczegóły – klikniecie powoduje wyświetlenie szczegółowych informacji o przyczynie błędu, co umożliwia wyjaśnienie jego przyczyny,
• Drukuj opis – kliknięcie powoduje wydrukowanie formularza z opisem błędu, który użytkownik powinien przesłać faxem do INFO-SYSTEM.
• Wyślij opis – powoduje przesłanie informacji o wystąpieniu błędu wraz z jego opisem i własnym komentarzem do INFO-SYSTEM (wymaga połączenia internetowego). Kolejne opisy błędów zapisywane są w pliku ERROR_LOG.XML – plik ten można przesłać mailem na adres serwis@groszek.pl w celu wyjaśnienia powstałych problemów. Poniżej zapis odpowiadający błędowi z powyższego przykładu:

<?xml version="1.0" encoding="windows-1250" ?>
<exceptions created="2004-10-13T08:46:14" ><exception date="2004-10-13T08:46:14" type="EIBInterBaseError" msg="Błąd InterBase (IB Code=335544344, SQL Code=-902)" excMessage="I/O error for file &quot;C:\BAZA\PLACE\XIS_PLACE.GDB&quot,
Error while trying to open file
Nie można odnaleźć określonego pliku.
" >
<systemInfo id="2" name="KADRY I PŁACE" systemVer="2004.3.11.8.31" >
<connection id="sqn_link0" alias="C:\BAZA\PLACE\XIS_PLACE.GDB" kind="Interbase" protocol="Lokalny" />
</systemInfo>
</exception>
</exceptions>

W sytuacji powstania błędu wykonania programu należy:

• Zapisać funkcję i wykonywaną czynność, w trakcie której wystąpił błąd, ew. ustalić powtarzalność niepoprawnej sytuacji,
• Kliknąć Wyślij opis w celu wysłania opisu błędu przez Internet, lub wydrukować opis błędu, zgłaszanego przez program i przesłać go faksem do INFO-SYSTEM,
• Przesłać mailem plik ERROR_LOG.XML, zapisywany w katalogu aplikacji.

Administrowanie aplikacjami

W celu zarządzania konfiguracją aplikacji przygotowany został specjalny program Admin. Pozwala on na:

• Zdefiniowanie nazwy domyślnego użytkownika bazy danych i jego hasła,
• Wprowadzenie parametrów aplikacji,
• Wprowadzenie nazwy klienta, pojawiającej się np. na wydrukach z programu,
• Wprowadzenie operatorów, uprawnionych do pracy z aplikacją, i podanie zakresu ich uprawnień.

Wprowadzając nowego operatora, należy najpierw podać dane operatora (nazwę, pełną nazwę i hasło) i zapamiętać te dane, a następnie powtórnie wywołać dane operatora i podać jego uprawienia.

Optymalizacja

W katalogu głównym programu znajduje się plik back_db.bat, który wraz z plikami gbak.exe i gfix.exe (można je znaleźć w katalogach instalacyjnych Firebirda) kontroluje poprawność bazy. Działa on na zasadzie usuwania zbędnych elementów z bazy danych, ponadto odświeża indeksy, pomniejsza plik bazy i poprawia szybkość działania programu na bazie danych. Wykonywanie operacji back_db szczególnie często (nawet codziennie), zalecane jest przy dużych instalacjach, gdzie baza danych może mieć wielkość powyżej 100 MB oraz jednocześnie pracuje na niej wielu operatorów (należy również wziąć pod uwagę operatorów innych systemów pracujących na tej samej bazie).

Aby przeprowadzić kontrolę poprawności należy wykonać następujące czynności: 1. Z katalogu z programem Admin, należy skopiować plik back_db do folderu w którym znajduje się baza (domyślnie C:\info-sys_groszek\info-sys_db), 2. Teraz należy skopiować z katalogu bin Firebird-a plik gbak i gfix, do folderu z bazą, 3. Następnie uruchamiamy plik back_db z linii komend bądź przy pomocy programu Windows Commander (lub innego menadżera plików) i jako parametr podajemy nazwę bazy (bez rozszerzenia). Powinno to wyglądać następująco: back_db is_pdk, (gdzie is_pdk to nazwa bazy).

Uwaga!

• Podczas działania skryptu inni użytkownicy nie mogą korzystać z bazy,
• Po wykonaniu powyższych czynności w folderze z bazą pojawią się nowe pliki. Jest to efekt działania procesu kontroli poprawności. Plik $olddb$ jest kopią bazy tworzoną automatycznie przed całym procesem. Dzięki temu możliwe jest odtworzenie bazy na wypadek gdyby baza docelowa została uszkodzona,
• Ważny jest plik z rozszerzeniem *.GBK - zawiera on kopię zapasową bazy danych i jest pomocny przy archiwizacji bazy.

Przyśpieszenie pracy z bazą

1. Wykonać porządkowanie bazy danych opisanym wyżej skryptem,
2. Sprawdzić zgodność i aktualność oprogramowania serwera bazy danych oraz klientów na poszczególnych stacjach roboczych - różnice ich wersji mogą powodować spowolnienia,
3. Dodać pliki *.ini programu do wykluczeń w oprogramowaniu antywirusowym.

Archiwizacja

Archiwizacja jest ważnym elementem pracy z programem. Umożliwia odzyskanie danych na wypadek nieprzewidzianych awarii systemu bądź też w sytuacji pomyłek ludzkich. W momencie, gdy baza znajduje się na jednym komputerze (serwerze) to przy uruchamianiu programu tworzą się jej kopie. Kopie bazy zapisywane są w tym samym folderze, co baza główna, a różnią się od niej, nieznacznie zmienionym rozszerzeniem. I tak:

• IS_PDA.GDB - jest to baza główna, na której pracujemy,
• IS_PDA.GDBk1 – jest kopią bazy danych z dnia wczorajszego,
• IS_PDA.GDBk2 – jest kopią bazy danych z dnia dzisiejszego (w momencie uruchamiania programu).

Dzięki częstym kopią bazy możliwy jest powrót do jej wcześniejszej wersji bez utraty wszystkich zapisanych danych.

Tworzenie kopii bazy danych

Kopię bazy danych tworzymy w jeden z wymienionych poniżej sposobów.

Uwaga!

Użytkownicy bazy danych przed przystąpieniem przez administratora bazy danych do tworzenia kopii, powinni dokończyć rozpoczęte operacje na programie, a następnie wyłączyć program. Pod żadnym warunkiem nie można przejść do tworzenia kopii bazy danych w sytuacji, kiedy użytkownicy wykonuję na niej operacje bądź nie wykonują operacji, ale program cały czas jest włączony.

Następnie możemy przejść do kroków podanych w punktach poniżej.

• Metoda kopiowania, wykonujemy:
  • Wyłączamy serwer bazy danych,
  • Otwieramy lokalizację na dysku zawierającą plik bazy danych,
  • Kopiujemy plik bazy danych do innej lokalizacji.
• Wykorzystanie narzędzia gbak
  • Z Program Files\Firebird\Firebird_2_5\bin kopiujemy plik gbak.exe do lokalizacji w której jest plik bazy danych.
  • Uruchamiamy CMD i przechodzimy do lokalizacji w której jest plik gbak.exe i baza danych.
  • W oknie konsoli wpisujemy polecenie:

gbak -b <nazwa_pliku_kopii_bazy_danych>.<gdb> <nazwa_pliku_z_ktorego_kopia_jest_tworzona>.gdb -user <nazwa_uzytkownika_bazy_danych> -pas <haslo_uzytkownika_bazy_danych>

Standardowa nazwa użytkownika to: SYSDBA, a hasło: masterkey. Przykład:

C:\baza_danych\gbak_test>gbak -b  is_pda.gdb is_pda_new.gdb -user sysdba -pas masterkey

Uwaga!

• Istnieje także możliwość tworzenia kopii bazy danych przy użyciu narzędzia FlameRobin. Program ten dostarcza interfejs graficzny, dzięki któremu możemy łatwo stworzyć kopię bazy danych.

Odtwarzanie bazy danych z kopii

• Odtwarzanie z kopii wykonanej z poziomu programu:

Odtwarzanie powinno być wykonywane z aplikacji, pracującej z pustą bazą danych, bez zdefiniowanych powiązań referencyjnych. Po wskazaniu katalogu z kopią danych program automatycznie pobiera dane wykonując ich ewentualne odszyfrowanie. Po odtworzeniu danych należy z poziomu programu WISQL wykonać skrypt z pliku GENERATOR.SQL, powodujący odpowiednie ustawienie generatorów bazy danych, a także skrypt, definiujący powiązania relacyjne tabel – oddzielny dla każdej aplikacji.

• Odtwarzanie danych z poziomu kopii wykonane narzędziem gbak:

gbak -R <nazwa_kopii> <nazwa_bazy> -user <nazwa_użytkownika> -pas <hasło>

Automatyczne tworzenie kopii danych

Automatyczne tworzenie kopii danych, wykonywane przez program, ma miejsce jedynie dla instalacji pracujących na lokalnej bazie danych. W takiej sytuacji, podczas pierwszego odwołania do bazy w danym dniu, program kopiuje plik z bazą do pliku o nazwie <nazwa_bazy>.gdbk1. Jeżeli plik taki istnieje, otrzymuje nowa nazwę <nazwa_bazy>.gdbk2. W ten sposób na dysku zawsze znajdują się fizyczne kopie pliku bazy danych z ostatnich dwóch dni roboczych - odtworzenie takiej kopii to po prostu zmiana nazwy pliku.

Shadowing

Serwer Firebird pozwala na wykorzystywanie usługi tworzenia cienia bazy danych (ang. shadow), stanowiącego jej dokładną kopię. Cień jest uaktualniany równolegle z bazą, w sposób niezauważalny dla użytkownika – stanowi zawsze identyczną kopię bazy danych. Cień bazy jest dobrym zabezpieczeniem przed uszkodzeniem dysku lub przypadkowym usunięciem pliku bazy danych, nie stanowi jednak rozwiązania problemu wewnętrznych uszkodzeń bazy danych (mogących powstać wskutek np. awarii zasilania) – do cienia zapisywana jest dokładnie taka sama informacja, jak do bazy danych. Podstawowe polecenie, uruchamiające usługę tworzenia cienia bazy danych jest następujące:

CREATE SHADOW 1 ''C:\info-sys_groszek\info-sys_db\is_pdk.shd''

Polecenie można wykonać z poziomu programu WISQL.EXE lub DBVIEWER.EXE, po uprzednim nawiązaniu połączenia z bazą danych. Widoczny w poleceniu plik – wraz z pełną ścieżką – jest cieniem bazy danych – warto go zlokalizować na oddzielnym dysku, musi być jednak umieszczony na komputerze, na którym pracuje serwer bazy danych. Odtworzenie bazy danych z cienia polega na skopiowaniu go do odpowiedniej lokalizacji i zmianie nazwy pliku.

Uwaga!

Wykorzystywanie usługi tworzenia cienia bazy danych nie może być traktowane jako jedyna metoda zabezpieczenia bazy danych, wykonywanie kopii jest dalej konieczne!

Kontrola spójności i poprawności bazy danych

Dla ułatwienia wykonania porządkowania bazy danych przygotowano skrypt o nazwie BACK_DB.BAT, który należy skopiować do katalogu z bazą danych. Konieczne jest także skopiowanie programów GBAK.EXE i GFIX.EXE z katalogu instalacyjnego Interbase/ Firebird (dla Firebird 1.5 wymagana jest biblioteka fbclient.dll). Skrypt należy wykonywać z linii poleceń, podając jako parametr nazwę pliku bazy danych bez rozszerzenia (przyjęto także standardową nazwę i hasło użytkownika bazy danych). Oczywiście, w czasie wykonywania skryptu baza nie może być wykorzystywana.

Kolejne fazy skryptu zamykają niedokończone transakcje, wykonują kontrolę i porządkowanie struktury bazy danych, a następnie pełną kopią bazy danych i przywrócenie bazy danych.

del  $olddb$.ib
copy %1.GDB    $olddb$.ib
gfix -sh -force 60 -user sysdba -password masterkey %1.GDB
gfix -v  -f -   i  -user sysdba -password masterkey %1.GDB
gfix -commit all   -user sysdba -password masterkey %1.GDB
gfix -mend -i      -user sysdba -password masterkey %1.GDB
gbak -B            -user sysdba -pas      masterkey %1.GDB %1.GBK
gbak -R            -user sysdba -pas      masterkey %1.GBK %1.GDB 
gfix -o            -user sysdba -password masterkey %1.GDB

Zalecamy regularne wykonywanie skryptu porządkującego – oprócz uporządkowania bazy i utworzenia kopii, podczas procesu odtwarzania tworzone są na nowo indeksy tabel, oraz usuwane są stare, niepotrzebne i niewykorzystywane dane. Wykonanie skryptu może więc dobrze wpłynąć na efektywność korzystania z bazy danych, dając krótsze czasy dostępu do danych, a także zmniejsza rozmiar pliku bazy danych.

Zmiana hasła użytkownika SYSDBA

Domyślnym administratorem serwera bazy danych jest użytkownik SYSDBA, a jego domyślne hasło to: masterkey. Tylko ten użytkownik ma prawo tworzenia nowych użytkowników bazy danych oraz nadawania praw użytkowników. Domyślne hasło możemy zmienić. W celu zmiany domyślnego hasła super użytkownika korzystamy z dowolnego programu do obsługi serwera (np. IBConsole, Flamerobin) lub w oknie poleceń przechodzimy do folderu, w którym zainstalowany jest F. (domyślnie jest to ścieżka: C:\Program Files\Firebird \Firebird_2_5\bin) i wydajemy polecenie:

gsec -user SYSDBA -pa stare_haslo -modify SYSDBA -pw nowe_haslo

Migracja do Firebird 2.5

Dlaczego Firebird w wersji 2.5?

Wersja 2.5 Firebirda zawiera nową architekturę SuperClassic. Przebudowana architektura owocuje zwiększeniem wydajności, szczególnie na wieloprocesorowych serwerach (serwery jednoprocesorowe, ale wielordzeniowe, również zyskują na wydajności). Na 32-bitowym (x86) systemie operacyjnym instalujemy w wersji SuperSerwer, a na 64-bitowym (x64) instalujemy w wersji SuperClassic (przy instalacji wybieramy ClassicSerwer, a w następnym okienku opcję: use SuperClassic).

Serwer Firebird 2.5 pobieramy ze strony.

Istotne zmiany

1. ALTER VIEW i CREATE OR ALTER VIEW
   1. Widoki mogą pobierać dane z procedury wbudowanej,
   2. Użycie zmiennej w update: Wcześniej: Update op_oper set nazwa = Rafał; Update op_oper set opis = nazwa; Teraz: Update op_oper set nazwa = Rafał, opis = nazwa.
2. Autonomous trans action Umożliwia uruchomienia kodu w autonomicznej transakcji w module PSQL. Wyjątek w bloku w autonomicznej transakcji spowoduje jej cofnięcie. Jeśli blok dobiegnie do końca, transakcja zostanie zatwierdzona.
3. Zapytania między dwoma bazami, niestety bez możliwości JOIN-owania: execute block returns (kod_oper smallint) as Begin FOR EXECUTE STATEMENT 'select kod_oper from op_oper' ON EXTERNAL DATA SOURCE 'localhost:budzet AS USER 'sysdba' PASSWORD 'masterkey' INTO :kod_oper DO SUSPEND; end

Dla zainteresowanych lista zmian.

Kroki migracji

1. Koniecznie przed migracją na FB 2.5 należy wykonać indeksowanie bazy używając pliku: back_db_frs.bat (poniżej kod).
   1. Nie wykonanie indeksowania spowoduje na bazie błąd: malformed string. Błąd związany jest z kontrolą zgodności kodowania znaków bazy danych, wymagana konwersja pozwala używać polskich znaków np. w procedurach wbudowanych.
   2. Przeprowadzenie indeksowania na FB 2.5 zmienia ODS bazy – nie ma możliwości powrotu serwera do niższej wersji.
2. Back_db dla FB 2.5 (listing w sekcji poniżej), uruchomienie:
   1. Pobieramy archiwum i je rozpakowujemy,
   2. Do jednego katalogu przenosimy:
      1. Bazę danych,
      2. Skrypt back_db_frs.bat,
      3. Pliki fbclient.dll, gbak.exe, gfix.exe. Znajdują się w %Program Files%\Firebird\Firebird_2_5\bin.
   3. Uruchamiamy konsolę (naciskamy WIN + R, wpisujemy cmd, naciskamy ENTER),
   4. Polecaniem cd <nazwa_katalogu>, gdzie nazwę katalogu wybieramy klawiszem TAB po wpisaniu cd przechodzimy do katalogu, w którym zgromadziliśmy pliki. Literę dysku zmieniamy poprzez d:, e:, f:, g: itd.,
   5. Wpisujemy back_db_frs.bat <nazwa_bazy_danych> (np. back_db_fb2.5.bat IS_PLACE) i naciskamy ENTER.
   6. Konsola zwraca informację o wykonanych operacjach.
3. Migracja dla innego hasła niż masterkey - kopiujemy plik security2.fdb z katalogu firebird_2_1 do katalogu firebird_2_5.
4. Przed przeniesieniem baz danych na serwer 64-bitowy (x64) wykonujemy indeksowanie na serwerze 32-bitowym (x86) z zainstalowany FB 2.1 lub 2.5 – baza z ODS < 11 (czyli nieindeksowana na serwerze w ver. 2.1) nie będzie działać na serwerze FB 2.5 x64.
5. Dla programów: Kasa i KSZOB należy w pliku konfiguracyjnym XML dopisać w sekcji link parametr: charset=WIN1250, np:

<link id="1" alias="C:\IS_pdk.GDB" user="s3uMfJd3" password="qLmsrLq/3dDk" kind="Interbase" protocol="Lokalny" owner="TEST" name="podatki" charset="WIN1250" >

back_db_frs.bat

Uwaga!

Uruchamiany na bazie jednorazowo przy migracji z FB 2.1 na FB 2.5

rem ----------------------------------------------------------------------
rem Kontrola poprawności bazy
rem U.I. INFO-SYSTEM, 2015
rem ----------------------------------------------------------------------
rem Wykonanie kopii bazy , Odtworzenie z kopii
rem Parametr - nazwa bazy (bez rozszerzenia !!!)
rem Przed całą akcją tworzona jest kopia bazy o nazwie $olddb$.ib
rem Podczas działania inni uzytkownicy nie mogą korzystać z bazy !
rem ----------------------------------------------------------------------
copy %1.GDB $olddb$.ib
gfix -sh -force 60 -user sysdba -password masterkey %1.GDB
gfix -v  -f -i -user sysdba -password masterkey %1.GDB
gfix -commit all -user sysdba -password masterkey %1.GDB
gfix -mend -i  -f -user sysdba -password masterkey %1.GDB
gbak -B -i -user sysdba -pas masterkey %1.GDB %1.GBK 
move %1.GDB  $olddb$.ib
gbak -rep -fix_fss_metadata WIN1250 -page 8192 -user sysdba -password masterkey %1.GBK %1.GDB
gfix -sh -force 60 -user sysdba -password masterkey %1.GDB
gfix -o -user sysdba -password masterkey %1.GDB
pause

back_db_sec.bat

Uwaga!

Uruchamiany na bazie, która jest w wersji FB 2.5.

rem ----------------------------------------------------------------------
rem Kontrola poprawności bazy
rem U.I. INFO-SYSTEM, 2015
rem ----------------------------------------------------------------------
rem Wykonanie kopii bazy , Odtworzenie z kopii
rem Parametr - nazwa bazy (bez rozszerzenia !!!)
rem Przed całą akcją tworzona jest kopia bazy o nazwie $olddb$.ib
rem Podczas działania inni uzytkownicy nie mogą korzystać z bazy !
rem ----------------------------------------------------------------------

gfix -sh -force 60 -user sysdba -password masterkey %1.GDB
gfix -v  -f -i -user sysdba -password masterkey %1.GDB
gfix -commit all -user sysdba -password masterkey %1.GDB
gfix -mend -i  -f -user sysdba -password masterkey %1.GDB
gbak -B -i -user sysdba -pas masterkey %1.GDB %1.GBK 
move %1.GDB  $olddb$.ib
gbak -rep -page 8192 -user sysdba -password masterkey %1.GBK %1.GDB
gfix -sh -force 60 -user sysdba -password masterkey %1.GDB
gfix -o -user sysdba -password masterkey %1.GDB
pause

Migracja do Firebird 3

Dlaczego Firebird w wersji 3?

Firebird 3.0 jest najważniejszą wersją serwera od czasu jego powstania. Wprowadzono znaczące zmiany - od efektywnego wykorzystania wielowątkowości na wieloprocesorowych komputerach (SuperServer) do zwiększenia bezpieczeństwa wprowadzając uwierzytelnianie w ramach bazy danych i szyfrując komunikację między klientem a serwerem.

Architektura serwera

Dostępne są trzy rodzaje architektury serwera: Classic, SuperClassic i SuperServer. Różnice między nimi zostaną opisane poniżej - najpierw drobne wyjaśnienia odnośnie podręcznej pamięci stronicowej (page cache).

Pamięć stronicowa

Firebird-owa baza danych składa się z logicznych bloków zwanych stronami. Każda strona ma ten sam rozmiar, który określany jest podczas tworzenia bazy lub podczas odtwarzania jej z kopii poleceniem gback. Gdy serwer podłącza się do bazy, rezerwuje pewną ilość pamięci RAM jako tzw. cache (pamięć podręczna). Dzięki temu może przyspieszyć dostęp do stron, które były przed chwilą wczytane z bazy. Serwer dysponuje dwoma pamięciami podręcznymi na każdą aktywną bazę danych - Metadata cache i Page cache. Pierwsza gromadzi informacje o metadanych, druga - gromadzi strony ostatnio odczytane. Rozmiar pamięci stronicowej (page cache) dla wszystkich baz danych określa parametr w pliku firebird.conf (podawany jest jako liczba stron). Ilość alokowanej pamięci jest zatem iloczynem liczby stron i rozmiaru pojedynczej strony. Rozmiar pamięci stronicowej może być także określona dla każdej bazy z osobna (używając gfix -buffers).

Różnice między rodzajami architektur serwera

Architektura	Tryb pracy	Page Cache
Classic (CS)	Każde połączenie z bazą danych obsługiwane jest jako oddzielny proces serwera.	Każdy proces serwera, a więc każde połączenie z bazą, ma oddzielną, niewspółdzieloną pamięć podręczną. Wymagana jest synchronizacja tych samych stron w różnych połączeniach (dotyczy połączeń do tej samej bazy danych). Połączenia są od siebie odseparowane. Oznacza to, że dane połączenie może zostać zakończone bez zaburzania pracy pozostałych połączeń. Duża liczba aktywnych połączeń może powodować znaczne wymagania pamięciowe (iloczyn liczby połączeń i rozmiaru pamięci podręcznej).
SuperClassic (SC)	Każde połączenie z bazą danych obsługiwane jest jako oddzielny wątek pojedynczego procesu serwera.	Każde połączenie z bazą ma swoją własną pamięć podręczną. Bardziej efektywna synchronizacja stron niż w przypadku architektury Classic - synchronizacja odbywa się w ramach pojedynczego procesu.
SuperServer (SS)	Każde połączenie z bazą danych obsługiwane jest jako oddzielny wątek pojedynczego procesu serwera.	Pamięć podręczna bazy danych jest współdzielona przez wszystkie, skierowane do niej, połączenia. Nie jest wymagana synchronizacja tych samych stron pobranych przez różne połączenia. Wszystkie połączenia działają w ramach pojedynczego procesu. Jeżeli któreś z połączeń przeciąży serwer powodując jego zamknięcie, to spowoduje to zakończenie wszystkich pozostałych połączeń. Wątki obsługujące połączenia działają równolegle w przypadku wielordzeniowych procesorów.

Wybór rodzaju architektury serwera

Classic

Może być stosowany na wieloprocesorowych/wielordzeniowych serwerach utrzymujących dużą liczbę jednoczesnych połączeń. Serwer Classic jest szczególnie zalecany wtedy, gdy aplikacje wymagają maksimum stabilności - zerwanie pojedynczego połączenia nie wpływa na pozostałe.

SuperClassic

Może być stosowany na wieloprocesorowych/wielordzeniowych serwerach, ale zalecane jest instalowanie wersji 64-bitowej. Z powodzeniem obsłuży dużą liczbę jednoczesnych połączeń zużywając mniej zasobów niż wersja Classic. Także lepsza skalowalność, ponieważ synchronizacja pamięci podręcznej nie wymaga komunikacji między procesami. Jednak awaria jednego połączenia zamknie wszystkie pozostałe połączenia.

SuperServer

Od wersji 3.0 architektura SuperServer, to architektura standardowa (zalecana). Korzysta ze wszystkich procesorów/rdzeni dostępnych na komputerze i ma współdzieloną pamięć podręczną (synchronizacja nie jest potrzebna). Rodzaj wybranej architektury określany jest w pliku firebird.conf za pomocą parametru ServerMode. Może on przybierać następujące wartości:

• Super - wybór domyślny dla wersji 3. Pojedynczy proces serwera otwiera plik bazy na wyłączność. Połączenia obsługiwane przez proces współdzielą stronicową pamięć podręczną. Każda baza ma pojedynczą pamięć podręczną,
• SuperClassic - pojedynczy proces serwera otwiera plik bazy w trybie współdzielonym. Każde połączenie ma własną stronicową pamięć podręczną,
• Classic - dla każdego połączenia uruchamiany jest oddzielny proces serwera. Każdy proces otwiera plik bazy danych w trybie współdzielonym. Każde połączenie ma własną stronicową pamięć podręczną.

Instalowanie serwera Firebird 3

Rodzaj instalacji

Wybieramy pełną instalację - Full instalation of Server and development tools. Zostaną zainstalowane: serwer Firebird, klient i programy użytkowe gbak, gfix, isql, itp.

Architektura serwera

Wybieramy SuperServer. Możemy zaznaczyć użycie Firebird Guardian do uruchamiania i restartowania serwera, o ile wybierzemy uruchamianie serwera jako aplikacji. W przypadku usługi nie jest zalecane używanie Guardian-a.

32 czy 64 bity

Na 64 bitowych systemach operacyjnych można instalować obydwie wersje serwera. Wersja 64 bitowa serwera zużywa około 30% więcej pamięci RAM niż wersja 32-bitowa. Instalując 64-bitową wersję należy zapewnić odpowiednią ilość pamięci RAM. Ograniczenie pamięciowe wersji 32-bitowa: do 2 GB pamięci RAM.

Problem funkcji UDF zewnętrznych autorów (o ile są używane) - instalując 64 bitowe należy mieć 64 bitowe wersje używanych UDF-ów. Zestaw funkcji UDF dostarczany wraz z instalatorem ma obydwie wersje. Aplikacje klienckie w wersji 32-bitowej muszą używać 32-bitowej biblioteki klienckiej (fbclient.dll).

Instalator umieszcza 32-bitowe wersje bibliotek i programów narzędziowych w dedykowanym katalogu o nazwie WOW64 (w ramach katalogu, w którym został zainstalowany Firebird).

Jeżeli używamy wersji instalacyjnej do zainstalowania klienta Firebird to zawsze na końcówce instalujemy wersje 32-bitową.

Usługa czy aplikacja?

Serwer Firebird powinien być uruchamiany jako usługa. Jedynie w szczególnych przypadkach, w których zależy nam na łatwym zatrzymywaniu i restartowaniu serwera, wybieramy aplikację (np. w przypadku systemów deweloperskich). Uruchamianie serwera jako usługi nie wymaga zalogowania się w Windows, aby Firebird wystartować i eliminuje możliwość uruchomienia go z niewłaściwego konta.

Uruchamianie automatyczne

W przypadku serwera produkcyjnego powinniśmy wybrać automatyczne uruchamianie usługi.

Biblioteka kliencka

Aplikacje firmy INFO-SYSTEM domyślnie używają biblioteki klienckiej o nazwie GDS32.DLL. Powinniśmy zaznaczyć kwadrat Generate client library as GDS32.DLL for legacy Interbase support? aby biblioteka została utworzona i znalazła się w katalogu systemowym.

Jeżeli aplikacje INFO-SYSTEM znajdują się na wydzielonym serwerze plików i używają własnych kopii biblioteki klienckiej, to musimy pamiętać, aby je podmienić na nową wersję. Jeżeli aplikacje zainstalowane są na każdym stanowisku z osobna, to powinniśmy zainstalować na tych stanowiskach biblioteki klienckie (rodzaj instalacji: Minimal client install - no server, no tools).

Uwierzytelnienie dla klientów poprzednich wersji Firebird-a (Authorization for legacy Firebird clients)

Jeżeli to możliwe, to unikamy ustawienia tych parametrów, ponieważ znacznie zmniejszają bezpieczeństwo serwera. Opcja konfiguracyjna pozwala określić parametry: AuthServer, AuthClient, UserManager i WireCrypt. Będą one używane w do komunikacji z bibliotekami klienckimi z poprzednich wersji.

Hasło Administratora Systemu Bazodanowego (SYSDBA)

Okno pozwala określić nazwę Administratora i jego hasło. Jeżeli pozostawimy pola puste, to utworzony zostanie konto administratora o nazwie SYSDBA i haśle masterkey. Uwaga! Należy unikać stosowania hasła masterkey, ponieważ jest ono wszystkim znane. Koniecznie musimy zmienić hasło administratora na inne.

Sprawdzenie poprawności instalacji

Stan instalacji serwera można sprawdzić uruchamiając polecenie:

instsvc q

Polecenie wyświetli informacje o stanie instalacji serwera Firebird. Polecenie powinno zostać wykonane z wiersza poleceń uruchomionego jako administrator. Uwaga! Serwer Firebird używa protokołu TCP/IP i portu o numerze 3050. Gdy używana jest zapora ogniowa (firewall), to musimy pozwolić serwerowi na otwarcie tego portu.

Powiązanie usługi z innym użytkownikiem

Proces instalacji serwera jako usługi kojarzy ją z użytkownikiem LocalSystem. W celu lepszej ochrony i zwiększenia bezpieczeństwa serwera możemy związać usługę z innym, specjalnie w tym celu stworzonym, użytkownikiem. Przeprowadzamy to za pomocą programu użytkowego instsvc. Użytkownik musi mieć uprawnienie odczytu/zapisu do wszystkich plików bazodanowych i do pliku firebird.log. Ze względów bezpieczeństwa użytkownik nie powinien mieć praw do zmiany zawartości pliku firebird.conf.

Polecenie wiążące usługę serwera z użytkownikiem myuser i hasłem mysecret:

instsvc i -g -login myuser mysecret

Polecenie instsvc może służyć do uruchomienia i zatrzymania serwera:

instsvc start
instsvc stop

INSTREG

Program narzędziowy instreg modyfikuje rejestr Windows tworząc klucz HKLM\SOFTWARE\Firebird Project\Firebird Server\Instances. Wskazuje on katalog, w którym został zainstalowany Firebird. Klucz nie jest potrzebny serwerowi, ale aplikacjom klienckim, włączając w to programy narzędziowe Firebird-a. Program instreg tworząc wartość klucza bierze nazwę katalogu, w którym sam się znajduje. Dlatego ważne jest, aby program był przechowywany i uruchamiany z katalogu, w którym umieścił go instalator.

Polecenie tworzące klucz:

instreg i[nstall]

Polecenie usuwające klucz:

instreg r[emove]

INSTCLIENT

Program narzędziowy instclient umieszcza kopię biblioteki klienckiej w katalogu systemowym systemu Windows:

instclient i[nstall] [ -f[orce] ] library

gdzie library może przyjąć jedną z wartości: f[bclient] lub g[ds32].

Dodatkowe opcje: r[emove] - usuń zainstalowaną bibliotekę, q[uery] - odpytaj o wersję zainstalowanej biblioteki.

Migracja bazy do Firebird 3

Wersja trzecia Firebird-a wprowadza nową strukturę baz danych i tylko tę obsługuje. Oznacza to, że bazy utworzone poprzednimi wersjami stały się dla wersji trzeciej nieczytelne. W związku z tym, aby przenieść bazę danych z poprzednich wersji należy najpierw utworzyć jej kopię, a następnie odtworzyć ją z tej kopii używając programów narzędziowych z wersji 3.

ODS (On Disk Structure)

ODS określa wersję struktury bazy danych. Zapisany jest na stronie definiującej nagłówek bazy danych. Tabela poniżej wiąże wersję Firebird-a z przypisaną jej numerem ODS.

Firebird	ODS
1.0	10.0
1.5	10.1
2.0	11.0
2.1	11.1
2.5	11.2
3.0	12.0

Serwer Firebird 3 obsługuje tylko bazy danych z numerem ODS równym 12.

Przed migracją

Nim przystąpimy do konwersji bazy do wersji trzeciej musimy sprawdzić jej spójność.

Używając bieżącej wersji serwera, wykonujemy (gdzie: usr - nazwa użytkownika, psw - hasło, database - pełna ścieżka do pliku bazy danych, backupfile - pełna ścieżka do tworzonej kopii bazy)

gbak -user usr -pas psw -b -v -g -se service_mgr database backupfile

Jeżeli kopia bazy nie zostanie utworzona z powodu błędów wskazujących na możliwe uszkodzenie bazy, to odłączamy bazę, tworzymy jej fizyczną kopię i uruchamiamy polecenie:

gfix -v -full -user usr -pas psw database

Jeżeli po wykonaniu polecenia w dalszym ciągu zgłaszane są błędy, to powinniśmy odtworzyć bazę z ostatniej kopii. Jeżeli jest to niemożliwe, to wykonujemy polecenie:

gfix -m database

biorąc pod uwagę to, że może ono prowadzić do utraty części danych, które będą przyczyną kolejnych błędów (natury logicznej, np. naruszeń więzów integralności referencyjnej). Gdy już mamy utworzoną kopię bazy danych, to przystępujemy do jej odtworzenia. Wykonujemy polecenie:

gbak -user usr -pas psw -c -v -se service_mgr backupfile database1

Dokładnie sprawdzamy informacje drukowane przez program gbak. Zgłaszane błędy, np. duplikaty kluczy głównych (primary keys, unique keys), naruszenia więzów integralności referencyjnej (foreign key), nie zatrzymują programu. Finalnie wszystkie indeksy, których nie udało się utworzyć z powodu błędów są oznaczane jako nieaktywne (inactive), a baza jest zamykana w trybie pojedynczego użytkownika (single usermode). Naszym zadaniem jest usunąć błędy ręcznie, doprowadzając bazę do pełnej spójności. Jeżeli nam się to uda, to włączamy bazę wykonując polecenie:

gfix -online normal -user usr -pas psw database

Problemy z kodowaniem znaków (wersje do 2.1 włącznie)

Serwer Firebird używa kodowania UNICODE_FSS do danych przechowywanych w tabelach systemowych (RDB$...) w postaci łańcuchów znaków oraz kodu źródłowego obiektów takich jak procedury wbudowane, wyzwalacze itp.

Wersje przed 2.1 miały błąd, który polegał na tym, że dane przychodzące od klienta nie były konwertowane do UNICODE_FSS. W efekcie dane były zapisywane w niewłaściwym formacie w kolumnach oznaczonych jako unicode_fss.

Wersja 2.1 serwera odrzucała takie dane, jako wadliwe (malformed strings). Aby ten problem rozwiązać do polecenia gbak zostały dodano dwa parametry: -fix_fss_metadata i -fix_fss_data. Wystarczyło utworzyć kopię bazy danych, a następnie odtworzyć ją używając tych parametrów ze wskazaniem, jakie kodowanie było użyte podczas wstawiania danych do bazy, przykładowo:

gbak -user usr -pas psw -b -v -g -se service_mgr -fix_fss_metadata WIN1250 database backupfile

Uwaga! Poleceń z parametrami -fix_fss_metadata i -fix_fss_data należy użyć na danej bazie tylko jeden raz.

Problemy z zastrzeżonymi słowami

Wersja trzecia Firebird-a dodaje nowe słowa zastrzeżone. Może się zdarzyć, że zostały one użyte do nazwania kolumn w tabelach lub w kodzie procedur wbudowanych czy wyzwalaczy. Aby sprawdzić, czy tak jest w przypadku naszej bazy powinniśmy utworzyć na podstawie metadanych skrypt tworzący nową bazę. Skrypt wykonujemy w nowej wersji serwera sprawdzając, czy nie zgłosi błędów. W przypadku błędów konieczne jest przygotowanie skryptów aktualizujących metadane ze słowami zastrzeżonymi i wykonanie ich w starej wersji Firebird-a (przed migracją).

Migracja

Po pozytywnym zakończeniu sprawdzeń/weryfikacji istniejącej bazy możemy przystąpić do jej konwersji do struktury ODS 12.

Mając zainstalowaną bieżącą wersję Firebird-a wykonujemy następujące kroki:

1. Pobieramy najnowsze wersje programów wraz ze skryptami aktualizującymi (spt). Uruchamiamy programy, aby wykonać aktualizację bazy danych. Dotyczy to tylko tych programów, których tabele znajdują się w bazie danych. Aktualizacja bazy danych powinna być wykonana przed zmianą wersji serwera, ponieważ skrypty aktualizacyjne mogą modyfikować tabele systemowe. A od wersji 3.0 tabele systemowe są tylko do odczytu.
2. Zatrzymujemy serwer (np. wykonując polecenie instsvc stop).
3. Zmieniamy nazwę bazy danych (unikamy w ten sposób przypadkowego podłączenia do bazy).
4. Przenosimy bazę do innego katalogu, w którym będzie wykonywana kopia i odtworzenie bazy.
5. Uruchamiamy serwer (np. wykonując polecenie instsvc start).
6. Wykonujemy polecenie tworzące kopię bazy: gbak -user usr -pas psw -b -v -g -se service_mgr database backupfile

Instalujemy i uruchamiamy Firebird-a 3 (wcześniej odinstalowujemy bieżącą wersję). Wykonujemy następujące kroki:

1. Odtwarzamy bazę z kopii: gbak -user usr -pas psw -c -v -se service_mgr backupfile database1
2. Jeżeli nie zostały zgłoszone błędy, to mamy naszą bazę zapisaną w strukturze ODS 12. Możemy przenieść ją do katalogu roboczego (nazwa powinna być taka, jaka była używana w poprzedniej wersji serwera).

Jak przyspieszyć proces tworzenia kopii i ich odtwarzania

Proces tworzenia kopii i odtwarzania baz z kopii można przyspieszyć, stosując się do następujących wskazówek:

1. Używamy przełącznika -g podczas tworzenia kopii, który wyłącza 'odśmiecanie' (garbage collector).
2. Używamy przełącznika -se service_mgr zarówno przy tworzeniu kopii, jak i odtwarzaniu. Powoduje on wykonywanie polecenia w ramach procesu serwera.
3. Używamy dysków SSD.
4. Zablokowanie innych czynników, które mogłyby używać dyskowych operacji I/O.
5. Jeżeli serwer dysponuje dużą ilością pamięci RAM, to na czas odtwarzania bazy z kopii możemy zwiększyć parametr TempCacheLimit znajdujący się w pliku firebird.conf. Dzięki temu serwer może użyć więcej pamięci potrzebnej przy tworzenia indeksów.