Firebird Collation hiba megoldása (UNICODE_CI) lépésről lépésre

Több ügyfelünk jelezte, hogy a Debian alapú Linux disztribúciók esetén szükség lenne a konkrét megoldási lépésekre. Kollégáink elvégezték a tesztet. Az alábbi módon egy debian-6.0.6-i386-netinst.iso (200MB)-ból telepített, csak alapcsomagokkal rendelkező x86-os számítógépen működésre bírható a Firebird 2.5:

  1. /etc/init.d/firebird stop
  2. Firebird 2.5 source beszerzése és kicsomagolása (későbbiekben source)
  3. apt-get install libncurses5-dev
  4. apt-get install g++
  5. cd source/extern/icu/source
  6. ./configure
  7. make
  8. make install
  9. cd source
  10. ./configure –enable-superserver
  11. make
  12. make install (abban ENTER-rel a szolgáltatás indítása)

A make install intelligensen a régi helyére “teszi” az új bináris állományt, azaz /etc/init.d/firebird restart az általunk fordított verziót kezeli.

Megfürödtünk a Firebird tóban – megúsztuk szárazon

Szeretek adatbázisokról vitatkozni. Szeretek olyanokkal vitatkozni, akik olvasták az “Adatbázis-rendszerek tervezése” könyvet. Valahol a szakma ott kezdődik.

 

Az Ügyfél

Egyik nagy ügyfelünk (a kép nem véletlenül került ide) részére fejlesztett szoftver nagy mennyiségű adatot kezel, precízen, pontosan. 1.45 millió vevőből tud(t)unk gyorsan válogatni. Valami azonban most egy kicsit belassult. Bármilyen terhelés mellett 4.5 mp volt a válaszidő. És egy rendes programozó érzi, ha valami nincs rendjén. A vevőtörzset átszippantottuk és egy teljesen szűz operációs rendszeren is 4.5 mp-re jött ki a lekérdezés. Minden index rendben volt. És a problémát pont ez okozta….

horstfuchs_firebird

 

Az index néha probléma?

Igen. Az index tartalmazott 9.000 valós, nem NULL értéket, ami 1.45 millió vevőre vonatkozóan pont megfelelő eloszlást jelentett (index stat), emiatt a lekérdezésekben a rendszer használta. De nem kellett volna, mert az eredmény csak ennek az indexnek a használata lett. A 9.000 vevő kiszűrése után 1.44 millió vevőn FULL-SCAN-t (!!!) végzett. Fogta a “rekordokat” és merevlemez hozzáférést is indukált. Nem keveset. Van megoldás?

 

Megoldás?

Az indexet eltávolítva a probléma megoldódott. Volna. De ez nem egy index volt, hanem egy foreign key (idegen kulcs) által létrehozott belső index. Nem törölhető. Az index használata PLAN kézzel való megadásával befolyásolható. De nem szeretnék az adatbázis szerver helyett gondolkodni (pedig talán menne, lásd: Adatbázis-rendszerek tervezése). Akkor valahogy el kellene érni, hogy az indexet a rendszer NE használja. Eltelt pár óra, majd még pár… és megszületett a megoldás. Nem írom le a megoldást, de büszke vagyok rá. 

A megoldás pedig beépítésre került az SQLManager-be, minden lekérdezés bizonyos mezőket kihagy az indexből. Automatikusan. A végeredmény egy állandóan 65-70 ms (!!!) alatt lefutó lekérdezés és egy nagyon alacsony terhelés. Örülünk Vincent?

Firebird Collation hiba megoldása (UNICODE_CI)

Egyre több ügyfelünk telepíti a Symbol Ügyvitelt Linux kiszolgálóra és sokan a bulváros OpenSUSE helyett valami “rendeset” választanak, például Gentoo-t vagy Debian-t (vagy ubuntu-t, ami szintén egy Debian). A Linuxok érzékenyek a csomagokra, Debian és barátai végképp.

Általában a libICU (nemzetközi kódkiosztásért felelős csomag) szokott a probléma lenni, amit egy rendszergazda meg tud oldani, de hogyan is? A hiba akkor jelentkezik, amikor a CREATE TABLE lefut(na), a szöveges mezőknél UNICODE_CI collation-t megadva. A Debian nem ismeri az UNICODE_CI-t a hibaüzenet szerint.

6115_debian_splash

Megoldás A

fbintl.conf fájlban a libicu bejegyzéshez hozzá kell írni a gépre telepített libicu verziószámot. Ez “manapság” 49 körül járhat.

Megoldás B

firebird csomagot scratch-ből kell fordítani és a Linux ./configure futtatásakor meg kell adni a –with-system-icu kapcsolót.

Desktop bűvös bája

Nagyon trendi laptop/notebook kombinációval fejleszteni, de cégünk már rég kinőtte azt a méretet, amikor a fejlesztő mozog, ügyfelekhez jár, bemutat, előadást tart. Fejlesztői gépeink szokásos cseréje most kicsit nagyobb változást hoz(ott).

Bármennyire is erős egy notebook, bármennyire fel van tuningolva SSD meghajtókkal, amitől csendes lesz és gyors… az asztali számítógépek teljesítményét nem éri el. Ár/érték arányban biztosan nem. Asztali, desktop számítógépek mellett raktuk le a voksunkat. HP Pro, Intel Core I5/I7 processzorral szerelve, benne végtelen mennyiségű (500GB sok mindenre elég) tárhely. Mindez kiegészítve persze a céges fájlszerverrel optimális fejlesztésre. De van még egy jobb ötletünk…

ssd

A cég vezetése kitalálta, hogy legyen dedikált fejlesztői szerver. Kollégák távoli asztallal (RDP) be tudnak lépni a számítógépeikre, sőt ha azok ki vannak kapcsolva, akkor WakeOnLan-nal fel tudják előtte ébreszteni azokat. De milyen jó lenne egy dedikált szerver! És valóban… Jövőbeni törekvésünk az, hogy egy olyan nagy teljesítményű, könnyen bővíthető (skálázható, például virtuális gépekre  épülő, felhős) számítógépet állítsunk be, amelyen minden fejlesztői tevékenység elvégezhető. Legyen szó webes vagy WinForms fejlesztésről.

Minden fejlesztő ide lépne be, állandóan futna. Minden, a fejlesztéshez szükséges komponens megtalálható lenne rajta. Nem kellene gépenként verziókövetés, biztonsági mentés, stb.

Ez az álom a terveink szerint hamar valóra fog válni.