Ha lassú az adatbázis, akkor ezeket érdemes ellenőrizni

Ha lassú az adatbázis, akkor ezeket érdemes ellenőrizni

 

Tartalomjegyzék

 

Firebird telepítéssel kapcsolatos problémák. 1

32 bites vagy 64 bites Firebird szerver használata. 1

Firebird szerver telepítése Classic / SuperServer / SuperClassic módban. 1

Az ideiglenes adatok tárolási helyének beállítása. 2

Ha LINUX-ra telepítik a Firebird-szervert 3

Firebird beállításaival kapcsolatos problémák. 4

A Firebird szerver beállításai 4

Az adatbázis olvasási gyorsítótár mérete túl kicsi 5

Az adatbázis írás-gyorsítótárazása ki van kapcsolva. 6

Az adatbázis aktív tranzakciós naplója túl nagy. 7

Háttértár sebességével kapcsolatos problémák. 9

A lemez írási/olvasási sebessége. 9

A lemez-vezérlőn az írási gyorsítótár ki van kapcsolva. 10

A RAID vezérlő írási gyorsítótár beállítása. 10

A megfelelő RAID tömb használata. 10

Az adatbázis lapmérete és a lemez „allocation unit” mérete. 11

Hálózattal kapcsolatos problémák. 11

A hálózat sebessége. 11

Ha számítógépnév alapján kapcsolódnak a szerverhez. 11

A Firebird hálózati forgalmának magasabb prioritást beállítani (QOS) 12

Hálózati adatbázis-kapcsolat vagy terminál szerver közötti választás. 13

 

 

 

Firebird telepítéssel kapcsolatos problémák

 

32 bites vagy 64 bites Firebird szerver használata

Ha a szerver lehetővé teszi, akkor érdemes a 64 bites Firebirdöt telepíteni, mert a 64 bites Firebird egyértelműen nagyobb teljesítményre képes, aminek elsősorban a nagyobb adatbázisok esetben van jelentősége. A légyegesebb különbségek:

– 2 GB-nál több memóriát csak a 64 bites tud használni.

– az adatbázisonként használható olvasási cache csak a 64 bitesnél lehet 130 KB-nál több.

Firebird szerver telepítése Classic / SuperServer / SuperClassic módban

 

Az egyes telepítési üzemmódok belső felépítése és erőforrás-felhasználási profilja eltér, ezért a felhasználás körülményeitől – leginkább a csatlakoztatott adatbázisok és a csatlakozó kliensek számától – függ, hogy melyik üzemmód a legelőnyösebb. (A szerver telepítési módja nem befolyásolja az adattárolás szerkezetét, tehát a telepítési mód változtatása után is használható ugyan azon adatbázis). A legfontosabb különbségek:

 

Számunkra a működési sebesség szempontjából fontos beállítás a firebird.conf fájlban a GCPolicy = background, amelyet csak a SuperServer ismeri, ezért javasoljuk, hogy a Firebirdöt Superserver üzemmódba telepítsék.

 

 

  Classic SuperServer SuperClassic
 

Processzek

Minden kapcsolathoz külön process indul a szerveren.  

Minden kapcsolat egyetlen processzt használ

 

Memória

Minden kapcsolat saját gyorsítótárat használ Minden kapcsolat ugyan azt a gyorsítótárat használja Minden kapcsolat saját gyorsítótárat használ
Guardian Nem használható Használható Csak Linuxon használható

 

Az ideiglenes adatok tárolási helyének beállítása

Néhány lemezműveletet a Firebird nem az adatbázis fájlban, hanem egy külön TEMP mappában végez, úgy hogy a TEMP mappában létrehoz a nevükben „fb_” karakterekkel kezdődő fájlokat, amiket a használat után automatikusan töröl. Ilyen műveletek például az adatok rendezése vagy az ideiglenes táblák használata.

környezeti változók

Az adatbázist tároló háttértár tehermentesíthető – ezáltal a sebesség növelhető – ha a Firebird által használt ideiglenes mappát egy másik – szintén gyors –

háttértáron helyezzük el.

Annak ellenére, hogy csak ideiglenes adatok tárolási helyéről van szó, a helytelen beállítások leállíthatják az adatbázis szervert, ezáltal nem csak az adott felhasználót, hanem a szerverre csatlakozó összes program összes felhasználója számára elérhetetlenné válhat az adatbázis, ezért fontos figyelemmel lenni az alábbiakra:

  • Ha a megadott TEMP mappa nem érhető el (pl.: nem elérhető a megadott meghajtó, vagy a megadott mappa nincs létrehozva…), akkor a Firebird – a TEMP mappa első használatának kísérletekor – SQL hibát ad, és ezzel együtt leáll, a Firebird Szerver és a Guardian szolgáltatás is.

 

  • Ha a megadott meghajtó a művelet végrehajtása során betelik, akkor a művelet SQL hibát ad. Amíg a tárterület nem szabadul fel más felhasználók TEMP műveletei sem hajthatóak végre.

 

  • A megadott meghajtót az egész Firebird szerver használja, tehát a meghajtón annyi helynek kell lennie, ami elegendő az összes csatlakozó felhasználó összes adatbázis-kapcsolat számára, ami természetesen az adatbázisok teljes fájlméretének többszöröse is lehet.

 

  • Mivel a TEMP mappába egyes lekérdezések is tárolnak ideiglenes adatokat, ezért ennek a TEMP adatokat tároló háttértár sebessége is fontos.

 

A Firebird által használt TEMP mappa megadható a FIREBIRD_TMP környezeti változóban. Fontos, hogy:

  • A környezeti váltózó a rendszerváltozók között szerepeljen (tehát ne a felhasználó profiljában legyen). Ilyen változót a Rendszer tulajdonságai > Speciális rendszerbeállítások > Környezeti változók > Rendszerváltozók beállítási csoportba lehet felvenni.
  • A változó beállítása után újra kell indítani a Firebird szolgáltatást.

 

Ha LINUX-ra telepítik a Firebird-szervert

 

Linuxon Ext3 fájlrendszeren a Firebird sebessége lényegesen lassabb (az átlagos Windowsos teljesítmény felét tudja csak), viszont XFS fájlrendszeren jobb teljesítményt ad, mint Windowson.

http://www.slideshare.net/ibsurgeon/firebird-25-benchmark-by-tsutomu-hayashi-tomneko

 

Firebird beállításaival kapcsolatos problémák

A Firebird szerver beállításai

 

Az adatbázis szervert SuperServer módban kell telepíteni, mert egy fontos beállítás csak ebben a módban elérhető.

 

Az adatbázis-szerveren lévő firebird.conf fájlban át kell állítani az alábbi beállításokat. Figyelni kell rá, hogy a sor előtt a NE legyen # karakter, mert különben a beállítás hatástalan.

GCPolicy = background

Ebben az esetben az automatikus tábla-karbantartó utasítások egy külön szálon futnak és nem várakoztatják a tábla hozzáféréseket. Ez a beállítás csak SuperServer módban elérhető, a Classic-nál nem.

CpuAffinityMask = 255

Ekkor a Firebird az első 8 processzormagot használhatja. Ez a beállítás csak akkor érdekes, ha SuperServer-ként telepítettük a Firebirdöt.

ProcessPriorityLevel = 1

Ekkor a Firebird magas prioritással fut a számítógépen és hamarabb és több ideig használhatja a gép erőforrásait. Az alapértelmezett érték 0, ami a normál prioritásnak felel meg.

LockMemSize = 4194304

A Firebird belső adatzárolás-kezelője által használható memória mérete, bájtokban megadva. Alapból 1 MB, ha egy tranzakción belül sok adatmódosítás történik, akkor érdemes ezt az értéket növelni.

TempCacheLimit = 967108864

A Firebird néhány művelethez ideiglenes táblákat hoz létre, például az alábbiakhoz:

  • Ha a „Create Temporary Table” utasítással létrehozott táblába írunk / módosítunk
  • Olyan rendezésekhez (order by), amelyekhez nem tartozik index
  • Olyan tábla kapcsolatokhoz (join) amelyekhez nem tartozik index

Ezek csak ideiglenes adatok ezért sosem kerülnek be az adatbázis-fájlba, sőt legjobb, ha elférnének a memóriában és sosem kellene lemezre írni őket. A TempCacheLimit beállítás adja meg az e célra felhasználható maximális memória mérete, bájtokban. Alapértelmezett értéke 64 MB. Classic szerver esetén vigyázni kell vele, mert adatbázis-kapcsolatonként használ ennyi memóriát.

 

Ha nagyméretű táblákat kell a Firebirdnek TEMP táblákban kezelnie, akkor érdemes lehet a TempBlockSize beállítás értékét növelni (alapból 1 MB), mert ez határozza meg, hogy a TEMP területet mekkora egységekkel növelje. A nagyobb érték csökkenti a TEMP adatok belső töredezettségét, így hatékonyabb használatot eredményez.

RemoteAuxPort = 8100

A Firebird szerver „Event Notification Messages” TCP üzeneteit az itt megadott TCP portra küldi. Az alapértelmezett érték 0, ami azt jelenti, hogy véletlenszerűen kitalál egy portot, ami esetleg problémát okozhat a tűzfalnál. Próbáljunk meg beállítani egy meghatározott portszámot és ezt engedjük át a tűzfalon.

TcpRemoteBufferSize = 8192

A TCP protokoll adatforgalmát az itt megadott méretű csomagokba szervezi (alapértelmezett értéke: 8192, lehetséges értékei 1448 – 32767 között). Ha rendszerint sok adatot fetchelünk, megbízható hálózaton, akkor hasznos lehet nagyobb értéket megadni.

 

Az adatbázis olvasási gyorsítótár mérete túl kicsi

 

Az adatbázisból kiolvasott adatokat a Firebird gyorsítótárazza. Az olvasási gyorsítótár adatbázisonként kerül felhasználásra és adatbázisonként állítható a mérete. Ha az adott adatbázis-fájl az olvasási gyorsítótár méretét nem határozza meg (alapból ez a helyzet), akkor a firebird.conf fájl DefaultDbCachePages beállításában megadott gyorsítótárat foglalja le, ami 2048 adatbázis lap. Az alapértelmezett gyorsítótár használathoz tartozik még a firebird.conf fájl FileSystemCacheSize  és a FileSystemCacheThreshold beállításai is, amelyeknek csak akkor van jelentőségük, ha az adatbázishoz rendelt gyorsítótár lapok már elfogytak.

 

A gyorsítótár mérete adatbázisonként megadható az alábbi paranccsal:

GFIX.EXE -BUFFERS 5000 %ELES_FDB% -USER SYSDBA –PASSWORD masterkey

A buffers paraméternek megadott számú adatbázis-lapnak megfelelő memóriát foglal az adatbázisban, tehát ha az adatbázis lapmérete 4KB (mi ilyen adatbázisokat használunk) akkor az 5000 lap összes memóriaigénye: 5000 * 4KB = 20 MB lesz. SuperServer telepítés esetén minden felhasználó ugyan azt a gyorsítótárat használja, ez optimális a memória és a sebesség szempontjából is. Ahány adatbázishoz csatlakozunk a szerveren, mindegyik adatbázishoz készít a szerver egy saját gyorsítótárat, az adatbázisban meghatározott mérettel. Például, ha a fenti beállításokkal létrehozott két adatbázishoz csatlakozik 10 – 10 felhasználó, akkor – SuperServer telepítés esetén – összesen 2 * 20 MB = 40 MB memóriát foglal a gyorsítótár.

 

Nincs értelme nagyobbra állítani a gyorsítótár méretét, mint az adatbázisfájlban lévő összes lapok száma. Az adatbázis lapszámát megbecsülhetjük, ha az adatbázis fájlméretét osztjuk a lapmérettel, például egy 100 MB-os adatbázisnál: 100 MB / 4 KB = 25 000.

Az alábbi batch file az első paraméterben várja az adatbázis fájlt, a másodikban a gyorsítótár méretét megabájtokban (4096 bájtos lapméret esetén):

@SET /A CACHE_IN_MEGABYTES=%2 * 256

“c:\Program Files\Firebird\Firebird_2_5\bin\gfix.exe” -BUFFERS %CACHE_IN_MEGABYTES% %1 -USER SYSDBA -PASSWORD masterkey

Az adatbázisban lévő lapok száma pontosan lekérdezhető az alábbi paranccsal, ami sajnos táblánként írja ki a lapok számát, több egyéb adattal együtt:

GSTAT.EXE -d %ELES_FDB% -USER SYSDBA -PASSWORD masterkey > c:\proba.txt

A fenti parancs által készített listafájlból ( c:\proba.txt ) csak a lapok számát ( „Data pages” ) tartalmazó sorokat listázni lehet az alábbi DOS paranccsal:

findStr /C:”Data pages” c:\proba.txt > c:\proba2.txt

A fenti parancs által készített fájlból az Excel számára használható lista készíthető ezzel a PoweShell paranccsal:

powershell -Command “(gc c:\proba2.txt) -replace ‘    Data pages: ‘, ” | Out-File c:\proba3.txt”

A fenti parancs által készített fájlt (c:\proba3.txt) meg lehet nyitni az Excelben, a megnyitáskor elindul a „szövegbeolvasó varázsló” (az Excel 2003-ig: „adatok – szövegből oszlopok”) amelyben az első oldalon „tagolt” a másodikban a „határoló jelek” keretben az „Egyéb” mezőbe be kell írni a vessző karaktert.

Az adatbázis írás-gyorsítótárazása ki van kapcsolva

 

A Firebird az adatbázis-írási műveleteket alapértelmezés szerint azonnal végrehajtja, azért hogy bármilyen leállás a lehető legkevesebb adatvesztéssel járjon. Lehetőség van az adott adatbázis-fájlra engedélyezni az írási műveletek gyorsítótárazását ( aszinkron írásnak nevezi a Firebird), ekkor az írási műveletet csak a memóriában történnek meg, az adatok lemezre írása egy belső algoritmus által választott, későbbi időpontban történik majd. Ezzel a sok írási műveletet igénylő programrészek jelentősen – akár több tízszeresére – gyorsulhatnak.

 

Az adatok tényleges kiírása a háttértárra megtörténik:

  • legkésőbb az tranzakció véglegesítésekor (commit)
  • egy beállítható időérték leteltekor.

 

A gyorsítótár bekapcsolása az adatvesztés kockázatát nem növeli számottevően, mert az adatbázisban csak véglegesített (commit) tranzakciókat olvasunk vissza, emiatt nem fordul elő olyan eset, hogy a felhasználó már megtörténtnek látná az adatrögzítést, de azt valójában még nem tároltuk a lemezen.

 

Az írás-gyorsítótárazása az alábbi parancssori utasítással kapcsolható be a megadott adatbázison (aszinkron írást végez szinkron helyett):

GFIX.EXE –WRITE ASYNC %ELES_FDB% -USER SYSDBA –PASSWORD masterkey

Az írás-gyorsítótárazása az alábbi parancssori utasítással kapcsolható ki a megadott adatbázison (szinkron írást végez aszinkron helyett):

GFIX.EXE –WRITE SYNC %ELES_FDB% -USER SYSDBA –PASSWORD masterkey

Az írási műveletek ki- / bekapcsolt állapota az alábbi paranccsal kérdezhető le:

GSTAT.EXE –h %ELES_FDB%

A fenti parancs ( felhasználónév és jelszó nélkül ) megjeleníti az adatbázis „header page” adatait, amelyek között, ha az „Attributes” beállítás értékében szerepel a „force write”, akkor az írás gyorsítótárazás ki van kapcsolva, tehát az írási műveletek azonnal megtörténnek, míg ha a „force write” nem szerepel, akkor az írás gyorsítótárazás be van kapcsolva.

Az írási gyorsítótár a firebird.conf alábbi beállításai szerint működik (A Firebird.conf-ban szereplő leírás arra utal, hogy a commit utasítás mindenképp kiírja az adatokat a lemezre: „Number of unflushed writes which will accumulate before they are flushed, at the next transaction commit.”):

A gyorsítótárban lévő maximális lapok számát a firebird.conf fájl MaxUnflushedWrites beállításában lehet szabályozni (alapértelmezett értéke: 100). A beállításnak csak aszinkron írás esetén van hatása.

A gyorsítótárban legfeljebb a firebird.conf maxUnflushedWriteTime beállításban megadott számú másodpercig maradhatnak a lapok, az itt megadott idő letelte után kiíródnak a lemezre. (alapértelmezett értéke: 5). A beállításnak csak aszinkron írás esetén van hatása.

 

Az adatbázis aktív tranzakciós naplója túl nagy

 

Minden adatbázis művelet sebességét lassítja, ha az adatbázisban a rekordokról túl sok verzió – akár több százezer – szerepel. A rekordverziókat az alábbi paranccsal lehet lekérdezni, de mivel táblánként írja ki, ezért egyből fájlba készítem a listát:

gstat.exe %ELES_FDB% -r -user SYSDBA -PASSWORD masterkey > c:\proba.txt

a gstat.exe a Firebird BIN mappájában található, például itt:

“c:\Program Files\Firebird\Firebird_2_5\bin\”

Az %ELES_FDB% helyére az FDB fájl teljes elérési útját és nevét kell írni. Írok ide két utasítást, amelyek a fenti példafájlból (c:\proba.txt) kiemelik azokat a sorokat, amelyek táblái több rekordverziót tartalmaznak:

findstr /C:”total versions:” c:\proba.txt > c:\log2.txt

findstr /V /C:”total versions: 0″ c:\log2.txt > c:\log3.txt

Az elkészült listából az egyes táblák „Total versions” adata érdekes, itt egy példa, ami a RENDELTET tábla egy állapotát mutatja:

RENDELTET (186)

Primary pointer page: 878, Index root page: 879

Average record length: 232.56, total records: 17502

Average version length: 9.09, total versions: 511770, max versions: 129

Data pages: 5811, data page slots: 13600, average fill: 76%

 

Megoldás:

 

  • adatbázis mentés – visszatöltés

vagy

  • SWEEP futtatása, az alábbi paranccsal:

gfix.exe -user SYSDBA -password masterkey -sweep %ELES_FDB%

(a gfix.exe a Firebird BIN mappájában található, például itt:

“c:\Program Files\Firebird\Firebird_2_5\bin\”)

A SWEEP idejére az adatbázis nem elérhető a felhasználók számára.

Ha ez a probléma fennáll az adatbázisnál, akkor érdemes az automatikus sweep műveletet kikapcsolni, különben a Firebird esetleg a felhasználók számára alkalmatlan időpontban indítja el az adatbázis automatikus karbantartását ( sweep ) ami percekre megakaszthatja a munkát. A Firebird adatbázis automatikus karbantartását kikapcsolni ezzel az utasítással lehet:

gfix.exe %ELES_FDB% –h 0 -user SYSDBA -password masterkey

Természetesen a kikapcsolt karbantartás (sweep) mellett az adatbázis használata egyre lassabb lesz, tehát időnként futtatni kell egy sweepet vagy egy adatbázis mentést és visszatöltést.

 


Háttértár sebességével kapcsolatos problémák

 

A lemez írási/olvasási sebessége

 

Az adatbázis műveletekhez NEM a lemez szekvenciális írási/olvasási sebessége számít, hanem a random írási/olvasási sebessége. Ezt érdemes lemérni egy tesztprogrammal, például az ingyenesen használható CrystalDiskMarkkal, ami letölthető innen:

https://crystalmark.info/en/download/#CrystalDiskMark

 

Egy gyors szerver winchester Egy normál SSD
 Egy gyors szerver winchester  Egy normál SSD
Egy gyors SSD

(Kingston SKC400)

3 gyors SSD-ből álló RAID0 tömb

(Kingston SKC400)

 Egy gyors SSD  3 gyors SSD-ből álló RAID0 tömb
Két NVMe tárolóból álló RAID1 tömb
(Samsung NVMe 950 PRO)
Egy nagyon gyors NVMe tároló

(Intel NVMe 750)

 Két NVMe tárolóból álló RAID1 tömb  Egy nagyon gyors NVMe tároló

 

A tesztprogram adataiból nekünk a “4K” sorban szereplő adatok érdekesek, mert ugyan ekkora az adatbázis lapmérete ( a Firebird is 4 kilobájtos blokkokban írja az adatbázis-fájlt ).

Megoldás:

 

Az adatbázist át kell helyezni egy olyan háttértárolóra, amelynek a 4K random írási / olvasási sebessége több 10 MB / másodperc.

 

Samsung SSD 850 EVO

Samsung SSD 850 EVO

Samsung SSD 860 EVO M2

Samsung SSD 860 EVO M2

Samsung 970 Evo plus NvMe

Samsung 970 Evo plus NvMe

 

 

 

A lemez-vezérlőn az írási gyorsítótár ki van kapcsolva

 

A legtöbb esetben ez alapból be van kapcsolva a beépített lemezeken Windowsban, de ha külső (USB-n csatlakoztatott) lemezen tárolná az adatbázist, ott alapból ki van kapcsolva.   Ha az eszközvezérlőben az írási gyorsítótár ki van kapcsolva, az még SSD esetén, egyetlen felhasználónál is a többszörösére lassítja az adatbázis írási műveleteit. A gyorsítótárat bekapcsolni a Windowsban az eszközkezelőben meg kell keresni azt a lemezmeghajtót, amelyiken az adatbázist tároljuk, dupla klikk a lemez nevén, majd a házirendek fülön be kell kapcsolni az írási gyorsítótárazás engedélyezése az eszközön kapcsolót.

A RAID vezérlő írási gyorsítótár beállítása

 

Ha külön RAID vezérlőkártyát használ, akkor ellenőrizze, hogy az írási gyorsítótár beállítása „wright-back” (nem „write-through”). Azon RAID vezérlők, amelyek saját akkumulátort tartalmaznak (BBU = Backup Battery Unit), lehetséges, hogy nem engedélyezik a gyorsítótár  bekapcsolását, ha az akkumulátor állapota nem megfelelő, illetve, automatikusan kikapcsolják a gyorsítótárat ha problémát észlelnek az akkumulátorral.

 

A megfelelő RAID tömb használata

 

Akár egyedülálló lemezen (RAID tömb nélkül), akár RAID1 vagy RAID5 tömbben használja az adatbázis fájlokat tároló háttértárat, ennél nagyobb teljesítményhez juthat, ha áttér RAID10 konfigurációra. Ez a fenti kialakításokhoz képest több fizikai lemezt igényel, ezért jelentős költségekkel járhat.

Az adatbázis lapmérete és a lemez „allocation unit” mérete

 

A gyorsabb I/O műveletek eléréséhez az is fontos, hogy az adatbázis lapmérete (4 KB) megegyezzen az adatbázis-fájlt tároló partíció formázásakor megadott “allocation unit” méretével. Az alábbi parancssori utasítással meg lehet nézni, hogy mekkora a megadott partíció “allocation unit” mérete (a parancs futtatásához rendszergazdai jog kell):

fsutil fsinfo ntfsinfo c:

A formázáskor megadható „allocation unit” méretét a fenti parancs a „bytes per cluster” sorban írja ki.

Megoldás:

Olyan lemezpartíción kell elhelyezni az adatbázis-fájlt, amelynek „allocation unit” mérete 4K.

A partíció allocation unit mérete csak formázáskor állítható, ráadásul a Windows beépített lemezformázó eszköze nem mindig ajánlja fel az „allocation unit” beállítását.

 

 

Hálózattal kapcsolatos problémák

 

A hálózat sebessége

 

A Firebird szervernek egy kérés feldolgozási idejéhez hozzátartozik az adatok hálózati utaztatása is, ami a művelet összes-végrehajtási idejének 90%-át is adhatja.

 

Ha vezeték nélküli hálózaton kapcsolódnak, az különösen problémás, mert ott sokkal gyakoribb a kapcsolat megszakadása, amit az adatbázis-szerverek nem tolerálnak olyan jól, mint a webkiszolgálók.

 

Megoldás:

 

  • A szerver és a kliensek is vezetékes hálózatot használjanak
  • Lehetőleg gigabites hálózatot használjanak

 

Ha számítógépnév alapján kapcsolódnak a szerverhez

 

Ha az adatbázis-kapcsolat felépítésénél NEM IP címet, hanem számítógépnevet használunk és a szerveren több hálózati csatoló is szerepel ( pl.: LAN, WIFI, VPN, Virtuális hálózati adapterek… ) akkor előfordul, hogy a számítógépnév feloldására nem mindig a LAN hálózati csatoló IP címét kapjuk vissza, hanem egy másik csatolóét, amelyre esetleg más beállítások vonatkoznak ( pl.: más a TimeOut ideje, más tűzfal-szabályok vonatkoznak rá…) és ez változatos – nem állandóan, hanem látszólag véletlenszerűen jelentkező – problémákat okozhat (lassulást, működésképtelenséget ).

 

Megoldás:

Az adatbázis-kapcsolat megadásánál mindenhol IP cím szerepeljen

  • A szerver nevének és IP címének összerendelése az sam fájlban. A fájl helye a Windowsban: <windir>\System32\drivers\etc\lmhosts.sam. A fájl egy egyszerű szöveges fájl a kliens számítógépen (mindegyik kliensen módosítani kell), ahol egy új sor elejére kell írni a szerver IP címét, majd egy (vagy több) SPACE (vagy TAB) karakter után a szerver nevét, például:

192.168.0.4 SERVERXP

A Firebird hálózati forgalmának magasabb prioritást beállítani (QOS)

 

Az alábbi beállításnak csak akkor van értelme, ha:

  • a kliensek hálózatban csatlakoznak az adatbázis-kezelőhöz
  • az adatbázis szerver nem dedikált szerver, hanem az adatbázis kiszolgáláson felül más hálózati feladatokat is végez ( pl.: fájlszerver, webszerver…)

Az operációs rendszerbe épített QOS (Quality Of Services) használatához az adatbázis szerverhez vezető hálózati forgalmat kezelő routereknek és switcheknek támogatniuk kell a Differentiated Services Code Points (DSCP) technológiát. Ezzel a hálózat TCP protokolljának minden egyes csomagjához egy prioritási érték rendelhető (0-63 közötti szám). Ha a hálózati eszközben (switch, router) több csomag is várakozik, hogy hozzáférhessen a fizikai réteghez („ a vezetékhez”), akkor az eszköz azt a csomagot próbálja hamarabb küldeni, amelyiknél nagyobb a beállított száma.

Az adatbázis szerveren az alábbi beállításokat kell elvégeznie:

  1. Jelentkezzen be rendszergazdaként
  2. Írja be a parancssorba: MMC, majd nyomjon ENTER-t
  3. Az MMC konzol ablakában nyomja meg a CTRL+M billentyűket új beépülő modul hozzáadásához.
  4. Az „Add or Remote Snap-ins window”-ban válassza a „Group Policy Object Editor”-t az „Available snap-ins” listából, majd nyomja meg az Add
  5. A „Select Group Policy Object” ablakban csak nyomja meg a „Finish” gombot.
  6. Kattintson az „OK”-ra, az „Add or Remote Snap-ins” ablak bezárásához.
  7. Az MMC konzol bal oldalán nyissa ki a „Local Computer” > „Computer Configuration” > „Windows Settings” beállítást, majd kattintson a jobb egérgombbal a „Policy-based QoS”-re és válassza a Create new policy”-t a menüből.
  8. A „policy-based QOS” ablakban írjon be egy nevet a „policy name” mezőbe, állítsa be a DSCP értékét 63-ra, majd kattintson a „Next” gombra.

policy-based QOS

  1. A következő ablakban jelölje be a „Only applications with this executable name” rádiógombot
  2. Írja be annak az alkalmazásnak a nevét, amelyiknek hálózati forgalmának nagyobb prioritás szeretne adni – Superserver telepítésű Firebird szerver esetén ez: „fbserver.exe”, majd kattintson a „Next” gombra.

policy-based QOS fbserver

Hálózati adatbázis-kapcsolat vagy terminál szerver közötti választás

 

Több felhasználó csatlakozásának hagyományos módja a kliens-szerver architektúra, ahol a hálózatban dolgozó felhasználók kliens programjai csatlakoznak ugyan ahhoz az adatbázis-kiszolgálóhoz. Ekkor a kliens és a szerver között forgalmazott összes adat áthalad a hálózaton.

Ettől eltérően a terminál szerveres használat esetén lehetőség van arra, hogy a felhasználók egy terminál szerverre csatlakozzanak, amely helyben telepített adatbázis-kezelőt használ. Ekkor a felhasználók kliens számítógépeire egyáltalán nem szükséges telepíteni a Novitax programokat. A felhasználók a Windowsba épített „távoli asztali kapcsolat” nevű programmal csatlakoznak a kiszolgálóhoz, ahol minden felhasználónak külön bejelentkezési lehetősége van, amelyhez a Windows felhasználás szokásos elemei (asztal, dokumentumok…) tartoznak. A felhasználók a szerver által számukra előállított felhasználói felületének képét látják, amelyet saját egerükkel és billentyűzetükkel vezérelnek, épp úgy mintha a saját gépükön futó programot használnának.

 

Bizonyos esetekben a terminál szerveres működés gyorsabb használatot biztosít, mint ha a felhasználók saját gépére telepített Novitax programokkal csatlakoznának az adatbázishoz.