Firebird zarządzanie: Różnice pomiędzy wersjami

(Nie pokazano 23 wersji utworzonych przez 5 użytkowników)

Linia 146:

: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).

Należy również sprawdzić wersję jądra i biblioteki glibc (czasami nie ma możliwości ~~upgradu~~ np. dla ~~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:

Linia 163:

Linia 162:

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)

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

~~proponuje~~ przełączyć się na tryb SuperClassic:

za pomocą skryptu changeMultiConnectMode.sh i odpowiedzieć ~~“thread”~~

===Bazy danych===

Linia 412:

Linia 409:

*''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 [mailto:serwis@groszek.pl serwis@~~groszke~~.pl] w celu wyjaśnienia powstałych problemów. Poniżej zapis odpowiadający błędowi z powyższego przykładu:

*''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 [mailto:serwis@groszek.pl 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" ?>

Linia 449:

Linia 446:

* 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ą====

#Wykonać porządkowanie bazy danych opisanym wyżej skryptem,

#Sprawdzić zgodność i aktualność oprogramowania serwera bazy danych oraz klientów na poszczególnych stacjach roboczych - różnice ich wersji mogą powodować spowolnienia,

#Dodać pliki *.ini programu do wykluczeń w oprogramowaniu antywirusowym.

===Archiwizacja===

Linia 454:

Linia 456:

*''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).

*''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.

Linia 541:

Linia 543:

====Kroki migracji====

#Koniecznie przed migracją na FB 2.5 należy wykonać indeksowanie bazy używając ~~nowego~~ pliku bat (poniżej kod).

#Koniecznie przed migracją na FB 2.5 należy wykonać indeksowanie bazy używając pliku: ''back_db_frs.bat'' (poniżej kod).

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

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

##Przeprowadzenie indeksowania na FB 2.5 zmienia ODS bazy – nie ma możliwości powrotu serwera do niższej wersji.

#Back_db dla FB 2.5 (listing w sekcji poniżej), uruchomienie:

Linia 548:

Linia 550:

##Do jednego katalogu przenosimy:

###Bazę danych,

###Skrypt ~~back_db_fb2.5~~.bat,

###Skrypt ''back_db_frs.bat'',

###Pliki fbclient.dll, gbak.exe, gfix.exe. Znajdują się w %Program Files%\Firebird\Firebird_2_5\bin.

###Pliki ''fbclient.dll'', ''gbak.exe'', ''gfix.exe''. Znajdują się w ''%Program Files%\Firebird\Firebird_2_5\bin''.

##Uruchamiamy konsolę (naciskamy WIN + R, wpisujemy cmd, naciskamy ENTER),

##Uruchamiamy konsolę (naciskamy ''WIN + R'', wpisujemy ''cmd'', naciskamy ENTER),

##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.,

##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.,

##Wpisujemy ~~back_db_fb2.5~~.bat <nazwa_bazy_danych> (np. back_db_fb2.5.bat IS_PLACE) i naciskamy ENTER.

##Wpisujemy ''back_db_frs.bat <nazwa_bazy_danych>'' (np. ''back_db_fb2.5.bat IS_PLACE'') i naciskamy ENTER.

##Konsola zwraca informację o wykonanych operacjach.

#Migracja dla innego hasła niż masterkey - kopiujemy plik security2.fdb z katalogu firebird_2_1 do katalogu firebird_2_5.

#Migracja dla innego hasła niż masterkey - kopiujemy plik ''security2.fdb'' z katalogu ''firebird_2_1'' do katalogu ''firebird_2_5''.

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

#Dla programów: Kasa i KSZOB należy w pliku konfiguracyjnym XML dopisać w sekcji link parametr: charset=''WIN1250'', np:

Linia 561:

Linia 563:

</syntaxhighlight>

====Back_db ~~FB 2.5~~ listing====

=====Back_db listing=====

~~Zawartość pliku ''back_db_fb2.5~~.bat'':

=====back_db_frs.bat=====

: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 -~~shut single~~ -force 60 -user sysdba -password masterkey %1.GDB

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

</syntaxhighlight>

=====back_db_sec.bat=====

: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

gbak -~~REP~~ -user sysdba -~~pas~~ masterkey %1.GBK %1.GDB ~~-FIX_FSS_DATA WIN1250 -FIX_FSS_METADATA WIN1250~~

move %1.GDB $olddb$.ib

gfix -~~shut full~~ -force 0 -user sysdba -password masterkey %1.GDB

gbak -rep -page 8192 -user sysdba -password masterkey %1.GBK %1.GDB

gfix -~~online~~ -user sysdba -password masterkey %1.GDB

gfix -sh -force 60 -user sysdba -password masterkey %1.GDB

gfix -o -user sysdba -password masterkey %1.GDB

pause

</syntaxhighlight>

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

{| class="wikitable"

! style="font-weight:bold;" | Architektura

! style="font-weight:bold;" | Tryb pracy

! style="font-weight:bold;" | 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.

{| class="wikitable"

! style="font-weight:bold;" | Firebird

! style="font-weight:bold;" | 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:

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

#Zatrzymujemy serwer (np. wykonując polecenie ''instsvc stop'').

#Zmieniamy nazwę bazy danych (unikamy w ten sposób przypadkowego podłączenia do bazy).

#Przenosimy bazę do innego katalogu, w którym będzie wykonywana kopia i odtworzenie bazy.

#Uruchamiamy serwer (np. wykonując polecenie ''instsvc start'').

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

#Odtwarzamy bazę z kopii: ''gbak -user usr -pas psw -c -v -se service_mgr backupfile database1''

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

#Używamy przełącznika ''-g'' podczas tworzenia kopii, który wyłącza 'odśmiecanie' (''garbage collector'').

#Używamy przełącznika ''-se service_mgr'' zarówno przy tworzeniu kopii, jak i odtwarzaniu. Powoduje on wykonywanie polecenia w ramach procesu serwera.

#Używamy dysków SSD.

#Zablokowanie innych czynników, które mogłyby używać dyskowych operacji I/O.

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

[[Category:Baza danych]]

[[Category:Dokumentacja bazy danych]]

@@ Linia 146: / Linia 146: @@
 {{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).
-Należy również sprawdzić wersję jądra i biblioteki glibc (czasami nie ma możliwości upgradu np. dla 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:
@@ Linia 163: / Linia 162: @@
 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)
+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''.
-proponuje przełączyć się na tryb SuperClassic:
- za pomocą skryptu changeMultiConnectMode.sh i odpowiedzieć “thread”
 ===Bazy danych===
@@ Linia 412: / Linia 409: @@
 *''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 [mailto:serwis@groszek.pl serwis@groszke.pl] w celu wyjaśnienia powstałych problemów. Poniżej zapis odpowiadający błędowi z powyższego przykładu:
+*''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 [mailto:serwis@groszek.pl serwis@groszek.pl] w celu wyjaśnienia powstałych problemów. Poniżej zapis odpowiadający błędowi z powyższego przykładu:
 <syntaxhighlight lang="xml">
 <?xml version="1.0" encoding="windows-1250" ?>
@@ Linia 449: / Linia 446: @@
 * 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ą====
+#Wykonać porządkowanie bazy danych opisanym wyżej skryptem,
+#Sprawdzić zgodność i aktualność oprogramowania serwera bazy danych oraz klientów na poszczególnych stacjach roboczych - różnice ich wersji mogą powodować spowolnienia,
+#Dodać pliki *.ini programu do wykluczeń w oprogramowaniu antywirusowym.
 ===Archiwizacja===
@@ Linia 454: / Linia 456: @@
 *''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).
+*''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.
@@ Linia 541: / Linia 543: @@
 ====Kroki migracji====
-#Koniecznie przed migracją na FB 2.5 należy wykonać indeksowanie bazy używając nowego pliku bat (poniżej kod).
+#Koniecznie przed migracją na FB 2.5 należy wykonać indeksowanie bazy używając pliku: ''back_db_frs.bat'' (poniżej kod).
-##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.
+##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.
 ##Przeprowadzenie indeksowania na FB 2.5 zmienia ODS bazy – nie ma możliwości powrotu serwera do niższej wersji.
 #Back_db dla FB 2.5 (listing w sekcji poniżej), uruchomienie:
@@ Linia 548: / Linia 550: @@
 ##Do jednego katalogu przenosimy:
 ###Bazę danych,
-###Skrypt back_db_fb2.5.bat,
+###Skrypt ''back_db_frs.bat'',
-###Pliki fbclient.dll, gbak.exe, gfix.exe. Znajdują się w %Program Files%\Firebird\Firebird_2_5\bin.
+###Pliki ''fbclient.dll'', ''gbak.exe'', ''gfix.exe''. Znajdują się w ''%Program Files%\Firebird\Firebird_2_5\bin''.
-##Uruchamiamy konsolę (naciskamy WIN + R, wpisujemy cmd, naciskamy ENTER),
+##Uruchamiamy konsolę (naciskamy ''WIN + R'', wpisujemy ''cmd'', naciskamy ENTER),
-##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.,
+##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.,
-##Wpisujemy back_db_fb2.5.bat <nazwa_bazy_danych> (np. back_db_fb2.5.bat IS_PLACE) i naciskamy ENTER.
+##Wpisujemy ''back_db_frs.bat <nazwa_bazy_danych>'' (np. ''back_db_fb2.5.bat IS_PLACE'') i naciskamy ENTER.
 ##Konsola zwraca informację o wykonanych operacjach.
-#Migracja dla innego hasła niż masterkey - kopiujemy plik security2.fdb z katalogu firebird_2_1 do katalogu firebird_2_5.
+#Migracja dla innego hasła niż masterkey - kopiujemy plik ''security2.fdb'' z katalogu ''firebird_2_1'' do katalogu ''firebird_2_5''.
 #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.
 #Dla programów: Kasa i KSZOB należy w pliku konfiguracyjnym XML dopisać w sekcji link parametr: charset=''WIN1250'', np:
@@ Linia 561: / Linia 563: @@
 </syntaxhighlight>
-====Back_db FB 2.5 listing====
+=====Back_db listing=====
-Zawartość pliku ''back_db_fb2.5.bat'':
+=====back_db_frs.bat=====
+{{Uwaga}}
+:Uruchamiany na bazie jednorazowo przy migracji z FB 2.1 na FB 2.5
 <syntaxhighlight lang="dos">
+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 -shut single -force 60 -user sysdba -password masterkey %1.GDB
+gfix -sh -force 60 -user sysdba -password masterkey %1.GDB
-gfix -v -f -i -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
+</syntaxhighlight>
+=====back_db_sec.bat=====
+{{Uwaga}}
+:Uruchamiany na bazie, która jest w wersji FB 2.5.
+<syntaxhighlight lang="dos">
+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
+gfix -mend -i  -f -user sysdba -password masterkey %1.GDB
 gbak -B -i -user sysdba -pas masterkey %1.GDB %1.GBK
-gbak -REP -user sysdba -pas masterkey %1.GBK %1.GDB -FIX_FSS_DATA WIN1250 -FIX_FSS_METADATA WIN1250
+move %1.GDB  $olddb$.ib
-gfix -shut full -force 0 -user sysdba -password masterkey %1.GDB
+gbak -rep -page 8192 -user sysdba -password masterkey %1.GBK %1.GDB
-gfix -online -user sysdba -password masterkey %1.GDB
+gfix -sh -force 60 -user sysdba -password masterkey %1.GDB
+gfix -o -user sysdba -password masterkey %1.GDB
 pause
 </syntaxhighlight>
+===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=====
+{| class="wikitable"
+! style="font-weight:bold;" | Architektura
+! style="font-weight:bold;" | Tryb pracy
+! style="font-weight:bold;" | 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.
+{| class="wikitable"
+! style="font-weight:bold;" | Firebird
+! style="font-weight:bold;" | 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:
+#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.
+#Zatrzymujemy serwer (np. wykonując polecenie ''instsvc stop'').
+#Zmieniamy nazwę bazy danych (unikamy w ten sposób przypadkowego podłączenia do bazy).
+#Przenosimy bazę do innego katalogu, w którym będzie wykonywana kopia i odtworzenie bazy.
+#Uruchamiamy serwer (np. wykonując polecenie ''instsvc start'').
+#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:
+#Odtwarzamy bazę z kopii: ''gbak -user usr -pas psw -c -v -se service_mgr backupfile database1''
+#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:
+#Używamy przełącznika ''-g'' podczas tworzenia kopii, który wyłącza 'odśmiecanie' (''garbage collector'').
+#Używamy przełącznika ''-se service_mgr'' zarówno przy tworzeniu kopii, jak i odtwarzaniu. Powoduje on wykonywanie polecenia w ramach procesu serwera.
+#Używamy dysków SSD.
+#Zablokowanie innych czynników, które mogłyby używać dyskowych operacji I/O.
+#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.
 [[Category:Baza danych]]
 [[Category:Dokumentacja bazy danych]]