Viktor Kustov. Informix. Rukovodstvo administratora baz dannyh --------------------------------------------------------------- Email: visor@olma.co.ru ¡ mailto:visor@olma.co.ru ---------------------------------------------------------------
1. Teoreticheskie osnovy. *
1.1 Ponyatie SUBD servera. *
1.1.1 Osnovnye funkcii SUBD *
1.1.2 Tipovaya organizaciya sovremennoj SUBD *
1.2 Ponyatie arhitektury klient-server. *
2. Teoreticheskie osnovy SUBD servera Informix OnLine v.7.X *
2.1 SUBD server Informix. *
2.2 Arhitektura SUBD servera Informix OnLine v.7.X *
2.2.1 . Dinamicheskaya masshtabiruemaya arhitektura *
2.2.1.1 Potoki *
2.2.1.2 Virtual'nye processory *
2.2.1.3 Planirovanie potokov *
2.2.1.4 Razdelenie potokov mezhdu virtual'nymi processorami. *
2.2.1.5 |konomiya pamyati i drugih resursov *
2.2.2 Organizaciya razdelyaemoj pamyati *
2.2.3 Organizaciya operacij obmena s diskami *
2.2.3.1 Upravlenie diskovoj pamyat'yu *
2.2.3.2 Asinhronnyj vvod-vyvod *
2.2.3.3 Operezhayushchee chtenie *
2.2.4 Podderzhka fragmentacii tablic i indeksov *
2.2.5 Parallel'naya obrabotka zaprosov *
2.2.5.1 Na chem osnovana tehnologiya PDQ *
2.2.5.2 Iteratory *
2.2.5.3 Primery primeneniya parallelizma *
2.2.5.4 Balans mezhdu OLTP i DSS-prilozheniyami *
2.2.6 Optimizator vypolneniya zaprosov po stoimosti *
2.2.7 Sredstva obespecheniya nadezhnosti *
2.2.7.1 . Zerkalirovanie diskovyh oblastej *
2.2.7.2 Tirazhirovanie *
2.2.7.3 Bystroe vosstanovlenie pri vklyuchenii sistemy *
2.2.7.4 Arhivirovanie i vosstanovlenie dannyh *
2.2.8 Dinamicheskoe administrirovanie *
2.2.8.1 Interfejs monitoringa sistemy *
2.2.8.2 Utilita DB/Cockpit *
2.2.8.3 Utilita OnPerf *
2.2.8.4 Utilita parallel'noj zagruzki *
2.2.9 Raspredelennye vychisleniya *
2.2.9.1 Vzaimodejstvie klient-server *
2.2.9.2 Prozrachnost' raspolozheniya dannyh *
2.2.9.3 Raspredelennye bazy dannyh i protokol dvuhfazovoj fiksacii tranzakcij *
2.2.10 Podderzhka nacional'nyh yazykov *
2.2.11 Sredstva bezopasnosti klassa S2 *
2.3 Dopolnitel'nye komponenty kompanii Informix dlya vypolneniya specificheskih zadach. *
2.3.1 Informix-Enterprise Gateway 7.1 *
2.3.2 Tehnologiya i komponenty EDA/SQL *
2.3.2.1 EDA API/SQL *
2.3.2.2 EDA/Link *
2.3.2.3 EDA/SQL Server *
2.3.2.4 EDA/Data Drivers *
2.3.3 Vozmozhnosti Enterprise Gateway *
2.3.3.1 Prozrachnyj dostup dlya chteniya i zapisi *
2.3.3.2 Raspredelennye soedineniya *
2.3.3.3 Konfigurirovanie Enterprise Gateway *
2.3.3.4 Bezopasnost' *
2.3.4 Biblioteki sopryazheniya servera Informix-OnLine DS s menedzherami tranzakcij: Informix-TP/XA i Informix-TP/TOOLKIT *
2.4 Zaklyuchenie *
2.5 Literatura *
1. Teoreticheskie osnovy.
1.1 Ponyatie SUBD servera.
Tradicionnyh vozmozhnostej fajlovyh sistem okazyvaetsya nedostatochno dlya postroeniya dazhe prostyh informacionnyh sistem. Pri postroenii informacionnoj sistemy trebuetsya obespechit': podderzhanie logicheski soglasovannogo nabora dannyh; obespechenie yazyka manipulirovaniya dannymi; vosstanovlenie informacii posle raznogo roda sboev; real'no parallel'naya rabota neskol'kih pol'zovatelej. Dlya vypolneniya vseh etih zadach' vydelyaetsya gruppa programm, ob'edenennyh v edinyj programmnyj kompleks. |tot kompleks nosit nazvanie sistema upravleniya bazami dannyh (SUBD). Sformuliruem eti (i drugie) vazhnye funkcii otdel'no.
1.1.1 Osnovnye funkcii SUBD
K chislu funkcij SUBD prinyato otnosit' sleduyushchee:
1. Neposredstvennoe upravlenie dannymi vo vneshnej pamyati
|ta funkciya vklyuchaet obespechenie neobhodimyh struktur vneshnej pamyati kak dlya hraneniya neposredstvennyh dannyh, vhodyashchih v BD, tak i dlya sluzhebnyh celej, naprimer, dlya ubystreniya dostupa k dannym v nekotoryh sluchayah (obychno dlya etogo ispol'zuyutsya indeksy). V nekotoryh realizaciyah SUBD aktivno ispol'zuyutsya vozmozhnosti sushchestvuyushchih fajlovyh sistem, v drugih rabota proizvoditsya vplot' do urovnya ustrojstv vneshnej pamyati. No podcherknem, chto v razvityh SUBD pol'zovateli v lyubom sluchae ne obyazany znat', ispol'zuet li SUBD fajlovuyu sistemu, a esli ispol'zuet, to kak organizovany fajly. V chastnosti, SUBD podderzhivaet sobstvennuyu sistemu imenovaniya ob®ektov BD (eto ochen' vazhno, poskol'ku imena ob®ektov bazy dannyh sootvetstvuyut imenam ob®ektov predmetnoj oblasti).
Sushchestvuet mnozhestvo razlichnyh sposobov organizacii vneshnej pamyati baz dannyh. Kak i vse resheniya, prinimaemye pri organizacii baz dannyh, konkretnye metody organizacii vneshnej pamyati neobhodimo vybirat' v tesnoj svyazi so vsemi ostal'nymi resheniyami.
2. Upravlenie buferami operativnoj pamyati
SUBD obychno rabotayut s BD znachitel'nogo razmera; po krajnej mere etot razmer obychno sushchestvenno prevyshaet dostupnyj ob®em operativnoj pamyati. Ponyatno, esli pri obrashchenii k lyubomu elementu dannyh budet proizvodit'sya obmen s vneshnej pamyat'yu, to vsya sistema budet rabotat' so skorost'yu ustrojstva vneshnej pamyati. Edinstvennym zhe sposobom real'nogo uvelicheniya etoj skorosti yavlyaetsya buferizaciya dannyh v operativnoj pamyati. I dazhe esli operacionnaya sistema proizvodit obshchesistemnuyu buferizaciyu (kak v sluchae OS UNIX), etogo nedostatochno dlya celej SUBD, kotoraya raspolagaet gorazdo bol'shej informaciej o poleznosti buferizacii toj ili inoj chasti BD. Poetomu v razvityh SUBD podderzhivaetsya sobstvennyj nabor buferov operativnoj pamyati s sobstvennoj disciplinoj zameny buferov. Pri upravlenii buferami osnovnoj pamyati prihoditsya razrabatyvat' i primenyat' soglasovannye algoritmy buferizacii, zhurnalizacii i sinhronizacii. Zametim, chto sushchestvuet otdel'noe napravlenie SUBD, kotorye orientirovany na postoyannoe prisutstvie v operativnoj pamyati vsej BD. |to napravlenie osnovyvaetsya na predpolozhenii, chto v predvidimom budushchem ob®em operativnoj pamyati komp'yuterov smozhet byt' nastol'ko velik, chto pozvolit ne bespokoit'sya o buferizacii. Poka eti raboty nahodyatsya v stadii issledovanij.
3. Upravlenie tranzakciyami
Tranzakciya - eto posledovatel'nost' operacij nad BD, rassmatrivaemyh SUBD kak edinoe celoe. Libo tranzakciya uspeshno vypolnyaetsya, i SUBD fiksiruet (COMMIT) izmeneniya BD, proizvedennye eyu, vo vneshnej pamyati, libo ni odno iz etih izmenenij nikak ne otrazhaetsya v sostoyanii BD. Ponyatie tranzakcii neobhodimo dlya podderzhaniya logicheskoj celostnosti BD. Esli vspomnit' nash primer informacionnoj sistemy otdela kadrov s fajlami SOTRUDNIKI i OTDELY, to edinstvennym sposobom ne narushit' celostnost' BD pri vypolnenii operacii priema na rabotu novogo sotrudnika budet ob®edinenie elementarnyh operacij nad fajlami SOTRUDNIKI i OTDELY v odnu tranzakciyu. Takim obrazom, podderzhanie mehanizma tranzakcij - obyazatel'noe uslovie dazhe odnopol'zovatel'skih SUBD (esli, konechno, takaya sistema zasluzhivaet nazvaniya SUBD). No ponyatie tranzakcii gorazdo sushchestvennee vo mnogopol'zovatel'skih SUBD. To svojstvo, chto kazhdaya tranzakciya nachinaetsya pri celostnom sostoyanii BD i ostavlyaet eto sostoyanie celostnym posle svoego zaversheniya, delaet ochen' udobnym ispol'zovanie ponyatiya tranzakcii kak edinicy aktivnosti pol'zovatelya po otnosheniyu k BD. Pri sootvetstvuyushchem upravlenii parallel'no vypolnyayushchimisya tranzakciyami so storony SUBD kazhdyj pol'zovatel' mozhet v principe oshchushchat' sebya edinstvennym pol'zovatelem SUBD (na samom dele, eto neskol'ko idealizirovannoe predstavlenie, poskol'ku pol'zovateli mnogopol'zovatel'skih SUBD poroj mogut oshchutit' prisutstvie svoih kolleg).
S upravleniem tranzakciyami v mnogopol'zovatel'skoj SUBD svyazany vazhnye ponyatiya serializacii tranzakcij i serial'nogo plana vypolneniya smesi tranzakcij. Pod serializacij parallel'no vypolnyayushchihsya tranzakcij ponimaetsya takoj poryadok planirovaniya ih raboty, pri kotorom summarnyj effekt smesi tranzakcij ekvivlenten effektu ih nekotorogo posledovatel'nogo vypolneniya. Serial'nyj plan vypolneniya smesi tranzakcij - eto takoj sposob ih sovmestnogo vypolneniya, kotoryj privodit k serializacii tranzakcij. Ponyatno, chto esli udaetsya dobit'sya dejstvitel'no serial'nogo vypolneniya smesi tranzakcij, to dlya kazhdogo pol'zovatelya, po iniciative kotorogo obrazovana tranzakciya, prisutstvie drugih tranzakcij budet nezametno (esli ne schitat' nekotorogo zamedleniya raboty dlya kazhdogo pol'zovatelya po sravneniyu s odnopol'zovatel'skim rezhimom).
Sushchestvuet neskol'ko bazovyh algoritmov serializacii tranzakcij. V centralizovannyh SUBD naibolee rasprostraneny algoritmy, osnovannye na sinhronizacionnyh zahvatah ob®ektov BD. Pri ispol'zovanii lyubogo algoritma serializacii vozmozhny situacii konfliktov mezhdu dvumya ili bolee tranzakciyami po dostupu k ob®ektam BD. V etom sluchae dlya podderzhaniya serializacii neobhodimo vypolnit' otkat (likvidirovat' vse izmeneniya, proizvedennye v BD) odnoj ili bolee tranzakcij. |to odin iz sluchaev, kogda pol'zovatel' mnogopol'zovatel'skoj SUBD mozhet real'no (i dostatochno nepriyatno) oshchutit' prisutstvie v sisteme tranzakcij drugih pol'zovatelej.
4. ZHurnalizaciya
Odno iz osnovnyh trebovanij k SUBD - nadezhnoe hranenie dannyh vo vneshnej pamyati. Pod nadezhnost'yu hraneniya ponimaetsya to, chto SUBD dolzhna byt' v sostoyanii vosstanovit' poslednee soglasovannoe sostoyanie BD posle lyubogo apparatnogo ili programmnogo sboya. Obychno rassmatrivayutsya dva vozmozhnyh vida apparatnyh sboev: tak nazyvaemye myagkie sboi, kotorye mozhno traktovat' kak vnezapnuyu ostanovku raboty komp'yutera (naprimer, avarijnoe vyklyuchenie pitaniya), izhestkie sboi, harakterizuemye poterej informacii na nositelyah vneshnej pamyati. Primerami programmnyh sboev mogut byt' avarijnoe zavershenie raboty SUBD (iz-za oshibki v programme ili nekotorogo apparatnogo sboya) ili avarijnoe zavershenie pol'zovatel'skoj programmy, v rezul'tate chego nekotoraya tranzakciya ostaetsya nezavershennoj. Pervuyu situaciyu mozhno rassmatrivat' kak osobyj vid myagkogo apparatnogo sboya; pri vozniknovenii poslednej trebuetsya likvidirovat' posledstviya tol'ko odnoj tranzakcii.
No v lyubom sluchae dlya vosstanovleniya BD nuzhno raspolagat' nekotoroj dopolnitel'noj informaciej. Drugimi slovami, podderzhanie nadezhnogo hraneniya dannyh v BD trebuet izbytochnosti hraneniya dannyh, prichem ta ih chast', kotoraya ispol'zuetsya dlya vosstanovleniya, dolzhna hranit'sya osobo nadezhno. Naibolee rasprostranennyj metod podderzhaniya takoj izbytochnoj informacii - vedenie zhurnala izmenenij BD.
ZHurnal - eto osobaya chast' BD, nedostupnaya pol'zovatelyam SUBD i podderzhivaemaya osobo tshchatel'no (inogda podderzhivayutsya dve kopii zhurnala, raspolagaemye na raznyh fizicheskih diskah), v kotoruyu postupayut zapisi obo vseh izmeneniyah osnovnoj chasti BD. V raznyh SUBD izmeneniya BD zhurnalizuyutsya na raznyh urovnyah: inogda zapis' v zhurnale sootvetstvuet nekotoroj logicheskoj operacii izmeneniya BD (naprimer, operacii udaleniya stroki iz tablicy relyacionnoj BD), a poroj zapis' sootvetstvuet minimal'noj vnutrennej operacii modifikacii stranicy vneshnej pamyati. V nekotoryh sistemah odnovremenno ispol'zuyutsya oba podhoda.
Vo vseh sluchayah priderzhivayutsya strategii "uprezhdayushchej" zapisi v zhurnal (tak nazyvaemogo protokola Write Ahead Log - WAL). Grubo govorya, eta strategiya zaklyuchaetsya v tom, chto zapis' ob izmenenii lyubogo ob®ekta BD dolzhna popast' vo vneshnyuyu pamyat' zhurnala ran'she, chem izmenennyj ob®ekt popadet vo vneshnyuyu pamyat' osnovnoj chasti BD. Izvestno, esli v SUBD korrektno soblyudaetsya protokol WAL, to s pomoshch'yu zhurnala mozhno reshit' vse problemy vosstanovleniya BD posle lyubogo sboya.
Samaya prostaya situaciya vosstanovleniya - individual'nyj otkat tranzakcii. Strogo govorya, dlya etogo ne trebuetsya obshchesistemnyj zhurnal izmenenij BD. Dostatochno dlya kazhdoj tranzakcii podderzhivat' lokal'nyj zhurnal operacij modifikacii BD, vypolnennyh v etoj tranzakcii, i proizvodit' otkat tranzakcii vypolneniem obratnyh operacij, sleduya ot konca lokal'nogo zhurnala. V nekotoryh SUBD tak i delayut, no v bol'shinstve sistem lokal'nye zhurnaly ne podderzhivayut, a individual'nyj otkat tranzakcii vypolnyayut po obshchesistemnomu zhurnalu, dlya chego vse zapisi ot odnoj tranzakcii svyazyvayut obratnym spiskom (ot konca k nachalu).
Pri myagkom sboe vo vneshnej pamyati osnovnoj chasti BD mogut nahodit'sya ob®ekty, modificirovannye tranzakciyami, ne zakonchivshimisya k momentu sboya, i mogut otsutstvovat' ob®ekty, modificirovannye tranzakciyami, kotorye k momentu sboya uspeshno zavershilis' (po prichine ispol'zovaniya buferov operativnoj pamyati, soderzhimoe kotoryh pri myagkom sboe propadaet). Pri soblyudenii protokola WAL vo vneshnej pamyati zhurnala dolzhny garantirovanno nahodit'sya zapisi, otnosyashchiesya k operaciyam modifikacii oboih vidov ob®ektov. Cel'yu processa vosstanovleniya posle myagkogo sboya yavlyaetsya sostoyanie vneshnej pamyati osnovnoj chasti BD, kotoroe vozniklo by pri fiksacii vo vneshnej pamyati izmenenij vseh zavershivshihsya tranzakcij i kotoroe ne soderzhalo by nikakih sledov nezakonchennyh tranzakcij. CHtoby etogo dobit'sya, snachala proizvodyat otkat nezavershennyh tranzakcij (undo), a potom povtorno vosproizvodyat (redo) te operacii zavershennyh tranzakcij, rezul'taty kotoryh ne otobrazheny vo vneshnej pamyati. |tot process soderzhit mnogo tonkostej, svyazannyh s obshchej organizaciej upravleniya buferami i zhurnalom. Bolee podrobno my rassmotrim eto v sootvetstvuyushchej lekcii.
Dlya vosstanovleniya BD posle zhestkogo sboya ispol'zuyut zhurnal i arhivnuyu kopiyu BD. Grubo govorya, arhivnaya kopiya - eto polnaya kopiya BD k momentu nachala zapolneniya zhurnala (imeetsya mnogo variantov bolee gibkoj traktovki smysla arhivnoj kopii). Konechno, dlya normal'nogo vosstanovleniya BD posle zhestkogo sboya neobhodimo, chtoby zhurnal ne propal. Kak uzhe otmechalos', k sohrannosti zhurnala vo vneshnej pamyati v SUBD pred®yavlyayutsya osobo povyshennye trebovaniya. Togda vosstanovlenie BD sostoit v tom, chto ishodya iz arhivnoj kopii po zhurnalu vosproizvoditsya rabota vseh tranzakcij, kotorye zakonchilis' k momentu sboya. V principe mozhno dazhe vosproizvesti rabotu nezavershennyh tranzakcij i prodolzhit' ih rabotu posle konca vosstanovleniya. Odnako v real'nyh sistemah eto obychno ne delaetsya, poskol'ku process vosstanovleniya posle zhestkogo sboya yavlyaetsya dostatochno dlitel'nym.
5. YAzyki BD
Dlya raboty s bazami dannyh ispol'zuyutsya special'nye yazyki, v celom nazyvaemye yazykami baz dannyh. V rannih SUBD podderzhivalos' neskol'ko specializirovannyh po svoim funkciyam yazykov. CHashche vsego vydelyalis' dva - yazyk opredeleniya shemy BD (SDL - Schema Definition Language) i yazyk manipulirovaniya dannymi (DML - Data Manipulation Language). SDL sluzhil glavnym obrazom dlya opredeleniya logicheskoj struktury BD, t.e. toj struktury BD, kakoj ona predstavlyaetsya pol'zovatelyam. DML soderzhal nabor operatorov manipulirovaniya dannymi, t.e. operatorov, pozvolyayushchih zanosit' dannye v BD, udalyat', modificirovat' ili vybirat' sushchestvuyushchie dannye. My rassmotrim bolee podrobno yazyki rannih SUBD v sleduyushchej lekcii.
V sovremennyh SUBD obychno podderzhivaetsya edinyj integrirovannyj yazyk, soderzhashchij vse neobhodimye sredstva dlya raboty s BD, nachinaya ot ee sozdaniya i obespechivayushchij bazovyj pol'zovatel'skij interfejs s bazami dannyh. Standartnym yazykom naibolee rasprostranennyh v nastoyashchee vremya relyacionnyh SUBD yavlyaetsya yazyk SQL (Structured Query Language). V neskol'kih lekciyah etogo kursa yazyk SQL budet rassmatrivat'sya dostatochno podrobno, a poka my perechislim osnovnye funkcii relyacionnoj SUBD, podderzhivaemye na "yazykovom" urovne (t.e. funkcii, podderzhivaemye pri realizacii interfejsa SQL).
Prezhde vsego yazyk SQL sochetaet sredstva SDL i DML, t.e. pozvolyaet opredelyat' shemu relyacionnoj BD i manipulirovat' dannymi. Pri etom imenovanie ob®ektov BD (dlya relyacionnoj BD - imenovanie tablic i ih stolbcov) podderzhivaetsya na yazykovom urovne v tom smysle, chto kompilyator yazyka SQL proizvodit preobrazovanie imen ob®ektov v ih vnutrennie identifikatory na osnovanii special'no podderzhivaemyh sluzhebnyh tablic-katalogov. Vnutrennyaya chast' SUBD (yadro) voobshche ne rabotaet s imenami tablic i ih stolbcov.
YAzyk SQL soderzhit special'nye sredstva opredeleniya ogranichenij celostnosti BD. Opyat' zhe ogranicheniya celostnosti hranyatsya v special'nyh tablicah-katalogah, i obespechenie kontrolya celostnosti BD proizvoditsya na yazykovom urovne, t.e. pri kompilyacii operatorov modifikacii BD kompilyator SQL na osnovanii imeyushchihsya v BD ogranichenij celostnosti generiruet sootvetstvuyushchij programmnyj kod.
Special'nye operatory yazyka SQL pozvolyayut opredelyat' tak nazyvaemye predstavleniya BD, fakticheski yavlyayushchiesya hranimymi v BD zaprosami (rezul'tatom lyubogo zaprosa k relyacionnoj BD yavlyaetsya tablica) s imenovannymi stolbcami. Dlya pol'zovatelya predstavlenie yavlyaetsya takoj zhe tablicej, kak lyubaya bazovaya tablica, hranimaya v BD, no s pomoshch'yu predstavlenij mozhno ogranichit' ili naoborot rasshirit' vidimost' BD dlya konkretnogo pol'zovatelya. Podderzhanie predstavlenij proizvoditsya takzhe na yazykovom urovne.
Nakonec, avtorizaciya dostupa k ob®ektam BD proizvoditsya na osnove special'nogo nabora operatorov SQL. Ideya sostoit v tom, chto dlya vypolneniya operatorov SQL raznogo vida pol'zovatel' dolzhen obladat' razlichnymi polnomochiyami. Pol'zovatel', sozdavshij tablicu BD, obladaet polnym naborom polnomochij dlya raboty s etoj tablicej. V ih chislo vhodit polnomochie na peredachu vseh ili chasti polnomochij drugim pol'zovatelyam, vklyuchaya polnomochie na peredachu polnomochij. Polnomochiya pol'zovatelej opisyvayutsya v special'nyh tablicah-katalogah, kontrol' polnomochij podderzhivaetsya na yazykovom urovne.
1.1.2 Tipovaya organizaciya sovremennoj SUBD
Estestvenno, organizaciya tipichnoj SUBD i sostav ee komponentov sootvetstvuet rassmotrennomu nami naboru funkcij.
Logicheski v sovremennoj relyacionnoj SUBD mozhno vydelit' naibolee vnutrennyuyu chast' - yadro SUBD (chasto ego nazyvayut Data Base Engine), kompilyator yazyka BD (obychno SQL), podsistemu podderzhki vremeni vypolneniya, nabor utilit. V nekotoryh sistemah eti chasti vydelyayutsya yavno, v drugih - net, no logicheski takoe razdelenie mozhno provesti vo vseh SUBD.
YAdro SUBD otvechaet za upravlenie dannymi vo vneshnej pamyati, upravlenie buferami operativnoj pamyati, upravlenie tranzakciyami i zhurnalizaciyu. Sootvetstvenno mozhno vydelit' takie komponenty yadra (po krajnej mere, logicheski, hotya v nekotoryh sistemah eti komponenty vydelyayutsya yavno), kak menedzher dannyh, menedzher buferov, menedzher tranzakcij i menedzher zhurnala. Kak mozhno bylo ponyat' iz pervoj chasti etoj lekcii, funkcii etih komonentov vzaimosvyazany, i dlya obespecheniya korrektnoj raboty SUBD vse eti komponenty dolzhny vzaimodejstvovat' po tshchatel'no produmannym i proverennym protokolam. YAdro SUBD obladaet sobstvennym interfejsom, ne dostupnym pol'zovatelyam napryamuyu i ispol'zuemym v programmah, proizvodimyh kompilyatorom SQL (ili v podsisteme podderzhki vypolneniya takih programm), i utilitah BD. YAdro SUBD yavlyaetsya osnovnoj rezidentnoj chast'yu SUBD. Pri ispol'zovanii arhitektury "klient-server" yadro yavlyaetsya osnovnym sostavlyayushchim servernoj chasti sistemy.
Osnovnaya funkciya kompilyatora yazyka BD - kompilyaciya operatorov yazyka BD v nekotoruyu vypolnyaemuyu programmu.
Osnovnoj problemoj relyacionnyh SUBD yavlyaetsya to, chto yazyki etih sistem (a eto, kak pravilo, SQL) yavlyayutsya neprocedurnymi, t.e. v operatore takogo yazyka specificiruetsya nekotoroe dejstvie nad BD, no eta specifikaciya ne procedura, ona lish' opisyvaet v nekotoroj forme usloviya soversheniya zhelaemogo dejstviya (vspomnite primery iz pervoj lekcii). Poetomu kompilyator dolzhen reshit', kakim obrazom vypolnyat' operator yazyka, prezhde chem proizvesti programmu. Primenyayutsya dostatochno slozhnye metody optimizacii operatorov, kotorye my podrobno rassmotrim v sleduyushchih lekciyah. Rezul'tatom kompilyacii yavlyaetsya vypolnyaemaya programma, predstavlyaemaya v nekotoryh sistemah v mashinnyh kodah, no bolee chasto v vypolnyaemom vnutrennem mashinno-nezavisimom kode. V poslednem sluchae real'noe vypolnenie operatora proizvoditsya s privlecheniem podsistemy podderzhki vremeni vypolneniya, predstavlyayushchej soboj, po suti dela, interpretator etogo vnutrennego yazyka.
Nakonec, v otdel'nye utility BD obychno vydelyayut takie procedury, kotorye slishkom nakladno vypolnyat' s ispol'zovaniem yazyka BD, naprimer, zagruzka i razgruzka BD, sbor statistiki, global'naya proverka celostnosti BD i t.d. Utility programmiruyutsya s ispol'zovaniem interfejsa yadra SUBD, a inogda dazhe s proniknoveniem vnutr' yadra.
1.2 Ponyatie arhitektury klient-server.
V podavlyayushchem bol'shinstve sluchaev lokal'naya set' ispol'zuetsya dlya kollektivnogo dostupa k bazam dannyh.
Sushchestvuet dva podhoda k organizacii kollektivnogo dostupa dannym. Pervyj podhod zaklyuchaetsya v tom , chto fajly dannyh raspolagayut na diskah fajl servera i vse rabochie stancii poluchayut k nemu dostup. |tot podhod nosit nazvanie arhitektura "fajl-server". Esli fajly dannyh raspolozheny na servere ( v dannom sluchae server nazyvaetsya "fajl-server" ) , s nimi odnovremenno rabotayut neskol'ko programm , zapushchennyh na rabochih stanciyah. Pri etom programmy dolzhny sami sledit' za tem , chtoby izmenyaemye zapisi bazy dannyh blokirovalis' dlya zapisi i chteniya so storony drugih programm vo vremya izmenenij. Dannyj metod imeet sushchestvennyj nedostatok: fajl-server ne obespechivaet dostatochnuyu proizvoditel'nost' pri bol'shom kolichestve rabochih stancij.
Vtoroj podhod nosit nazvanie arhitektura "klient-server".
Opredeleniya:
Klient - Rabochaya stanciya dlya odnogo pol'zovatelya, obespechivayushchaya rezhim registracii i dr. neobhodimye na ego rabochem meste funkcii vychisleniya, kommunikaciyu, dostup k bazam dannyh i dr.
Server - odin ili neskol'ko mnogopol'zovatel'skih processorov s edinym polem pamyati, kotoryj v sootvetstvii s potrebnostyami pol'zovatelya obespechivaet im funkcii vychisleniya, kommunikacii i dostupa k bazam dannyh.
Obrabotka Klient - Server - sreda, v kotoroj obrabotka prilozhenij raspredelena mezhdu klientom i serverom. Neredko v obrabotke uchastvuyut mashiny raznyh tipov, prichem klient i server obshchayutsya mezhdu soboj s pomoshch'yu fiksirovannogo mnozhestva standartnyh protokolov obmena i procedur obrashcheniya k udalennym platformam.
SUBD s personal'nyh |VM ( takie, kak Clipper, DBase, FoxPro, Paradox, Clarion imeyut setevye versii, kotorye prosto sovmestno ispol'zuyut fajly baz dannyh teh zhe formatov dlya PK, osushchestvlyaya pri etom setevye blokirovki dlya razgranicheniya dostupa k tablicam i zapisyam. Pri etom vsya rabota osushchestvlyaetsya na PK. Server ispol'zuetsya prosto kak obshchij udalennyj disk bol'shoj emkosti. Takoj sposob raboty privodit k risku poteri dannyh pri apparatnyh sboyah.
Po sravneniyu s takimi sistemami sistemy , postroennye v arhitekture Klient - Server, imeyut sleduyushchie preimushchestva:
2. Teoreticheskie osnovy SUBD servera Informix OnLine v.7.X
2.1 SUBD server Informix.
Raboty nad sistemoj upravleniya bazami dannyh Informix byli nachaty v 1980 g. Soglasno nachal'nomu zamyslu programmnyj kompleks Informix rassmatrivalsya kak SUBD, special'no orientirovannaya dlya raboty v srede OS UNIX. Dlya organizacii hraneniya dannyh byl vybran relyacionnyj podhod. S teh por Informix stal odnoj iz osnovnyh SUBD, rabotayushchih v srede UNIX.
Sejchas produkty Informix uzhe ustanovleny prakticheski na vseh UNIX-komp'yuterah. Sredi vseh OEM firma vybrala shest' strategicheskih partnerov. |to: Sequent, HP, SUN, IBM, Siemens Nixdorf, NCR. Portirovanie produktov firmy na proizvodimye strategicheskimi partnerami platformy proizvoditsya v pervuyu ochered'. Prakticheski eto oznachaet, chto pri poyavlenii na rynke novoj platformy ili novoj versii operacionnoj sistemy dlya platformy uzhe imeetsya sootvetstvuyushchaya versiya produktov Informix.
Sredi ne UNIX platform Informix podderzhivaet NetWare, Windows, Windows NT i DOS.
Firma Informix ob®yavila i podderzhivaet programmu InSync. Programma ob®edinyaet nezavisimyh razrabotchikov programmnogo obespecheniya. V ramkah etoj programmy sozdany programmnye interfejsy dlya svyazi s SUBD drugih proizvoditelej, v chastnosti SUBD, funkcioniruyushchie na ne UNIX-platformah.
2.1.1 Opisanie produktov Informix
Produkty Informix soderzhat servery baz dannyh, sredstva razrabotki i otladki, kommunikacionnye sredstva. Harakternoj osobennost'yu Informix yavlyaetsya nalichie neskol'kih tipov serverov, podrobnee o nih budet skazano nizhe.
Nachinaya s versii 4.0 firma Informix postavlyaet server bazy dannyh OnLine, kotoryj podderzhivaet apparat raspredelennyh tranzakcij (tehnologiya OLTP - on-line transaction processing), chto pozvolyaet po-novomu podhodit' k sozdaniyu baz dannyh s ochen' bol'shim ob®emom hranimoj informacii.
Krome togo, v Informix-OnLine vklyuchen novyj tip dannyh - bitovye polya (BLOB - binary large objects). Bitovye polya mogut ispol'zovat'sya dlya mul'timedijnyh prilozhenij (hranenie izobrazhenij i zvuka).
2.1.2 Tipovye konfiguracii
V osnove sistem, razrabotannyh na osnove SUBD Informix, lezhit princip arhitektury "klient-server". Klient - eto pol'zovatel'skaya prikladnaya programma, obespechivayushchaya vzaimodejstvie (interfejs) bazy dannyh s pol'zovatelem. Vsyu rabotu, svyazannuyu s dostupom i modifikaciej bazy dannyh, vypolnyaet server bazy dannyh (BD-server).
Server bazy dannyh (database engine), on zhe yadro bazy dannyh - eto otdel'naya programma, vypolnyaemaya kak otdel'nyj process. Server peredaet vybrannuyu iz bazy informaciyu po kanalu klientu. Imenno server rabotaet s dannymi, zabotitsya ob ih razmeshchenii na diske. Tehnologiyu "klient-server" so storony servera obespechivayut moduli Informix-SE, Informix-Online ili Informix OnLine-Dynamic Server.
Informix-SE predstavlyaet soboj server bazy dannyh, prednaznachennyj dlya obespecheniya raboty v sistemah s malym ili srednim ob®emom informacii.
Hranenie dannyh v etom sluchae osushchestvlyaetsya v fajlovoj sisteme operacionnoj sistemy, chto znachitel'no uproshchaet razrabotku i ekspluataciyu prilozhenij.
Klienty i servery mogut nahodit'sya na odnom komp'yutere, libo na neskol'kih, svyazannyh mezhdu soboj set'yu. Podobnoe razdelenie funkcij daet vysokuyu proizvoditel'nost' i maksimal'nuyu gibkost'. Dlya obespecheniya otnoshenij svyazi tipa "klient-server" mezhdu razlichnymi komp'yuterami so storony servera primenyaetsya modul' Informix-NET.
Informix-OnLine - eto server vtorogo pokoleniya, obespechivayushchij tehnologiyu raspredelennyh tranzakcij (OLTP - on-line transaction processing). Tehnologiya raspredelennyh tranzakcij pozvolyaet vypolnyat' zaprosy v raspredelennoj baze dannyh, fizicheski nahodyashchihsya na razlichnyh komp'yuterah. Po sravneniyu s Informix-SE server Informix-OnLine imeet special'nyj tip dannyh - bitovye polya (BLOB - Binary Large Objects), simvol'nye stroki peremennoj dliny, buferizaciyu tranzakcij, zerkal'nyj disk, avtomaticheskoe vosstanovlenie posle sistemnyh sboev, bol'shuyu skorost' (v 2-4 raza).
Modul' Informix-Star yavlyaetsya sredstvom podderzhki raboty s raspredelennymi bazami dannyh. Posredstvom modulya InformixStar osushchestvlyaetsya operativnaya obrabotka tranzakcij.
Rabota servera Informix zaklyuchaetsya v zapuske special'noj programmy (SQLEXEC dlya Informix-SE i SQLTURBO dlya Informix-OnLine), kotoraya obespechivaet rabotu vseh SQL-operatorov. Dlya kazhdogo klienta zapuskaetsya process operacionnoj sistemy, ispol'zuyushchij etu programmu. V sluchae, esli klient prerval rabotu, no ne vyshel iz svoej zadachi, to ego process zanimaet resursy sistemy, snizhaya ee proizvoditel'nost'.
Odnim iz poslednih dostizhenij firmy stal vypusk novogo servera bazy dannyh OnLine Dynamic Server, kotoroj vhodit v sostav sistemy nachinaya s versii 6.0. |tot produkt osnovan na tak nazyvaemoj Dinamicheskoj Masshtabiruemoj Arhitekture (Dynamically Scalable Architecture - DSA), kotoraya special'no orientirovana na rabotu s mnogoprocessornymi sistemami. OnLine Dynamic Server obespechivaet povyshenie proizvoditel'nosti za schet gibkosti ispol'zovaniya resursov SUBD, ispol'zovanie mnogopotochnoj arhitektury. Fakticheski OnLine Dynamic Server beret na sebya mnogie svyazannye s raspredeleniem resursov funkcii operacionnoj sistemy. V rezul'tate umen'shaetsya nagruzka na operacionnuyu sistemy, chto v konechnom schete privodit k rostu proizvoditel'nosti.
Dlya obsluzhivaniya klientov zapuskayutsya "virtual'nye processory" - processy operacionnoj sistemy, kotorye ustanavlivayut svyaz' mezhdu klientom i yadrom Informix. Svyaz' ustanavlivaetsya s pomoshch'yu special'nyh "nitej" (thread), kotorye aktiviziruyutsya tol'ko esli klient aktiven i obrashchaetsya k serveru bazy dannyh. V sluchae, esli klient neaktiven, "nit'" mozhet obsluzhivat' drugih klientov.
CHislo virtual'nyh processorov opredelyaet administrator bazy dannyh, ishodya iz real'nyh resursov vychislitel'noj sistemy i seti klientov. Esli vychislitel'naya sistema yavlyaetsya mnogoprocessornoj, to raznye virtual'nye processory mogut obsluzhivat'sya raznymi real'nymi processorami.
V versii 6.0 setevye funkcii zalozheny v yadre SUBD. Poetomu dlya funkcionirovaniya v seti OnLine Dynamic Server moduli Informix-Net ili Informix-Star ne trebuyutsya.
2.2 Arhitektura SUBD servera Informix OnLine v.7.X
K SUBD, pretenduyushchim na rol' informacionnoj osnovy sovremennyh predpriyatij, pred®yavlyayutsya vse novye i bolee zhestkie trebovaniya. K chislu vazhnejshih mozhno otnesti sleduyushchie:
Dannyj razdel posvyashchen, glavnym obrazom, rassmotreniyu arhitekturnyh osobennostej i mehanizmov servera INFORMIX-OnLine DS, napravlennyh na udovletvorenie perechislennyh vyshe trebovanij. Privoditsya takzhe informaciya o sredstvah raspredelennyh vychislenij, bezopasnosti, podderzhki nacional'noj sredy.
2.2.1 . Dinamicheskaya masshtabiruemaya arhitektura
Arhitektura servera INFORMIX-OnLine DS poluchila nazvanie "dinamicheskaya masshtabiruemaya arhitektura" (DSA). Sut' ee zaklyuchaetsya v tom, chto odnovremenno vypolnyaetsya otnositel'no nebol'shoe chislo servernyh processov (virtual'nyh processorov), kotorye razdelyayut mezhdu soboj rabotu po obsluzhivaniyu mnozhestva klientov. Po sravneniyu s bolee rannimi modelyami servera INFORMIX, gde dlya kazhdogo klienta sozdavalsya individual'nyj servernyj process (ris. 1), novaya model' obladaet ryadom preimushchestv:
Dlya mnogoprocessornyh platform:
Ris. 1. Model' "odin klient - odin servernyj process".
Poka pol'zovatel' analiziruet rezul'taty ili gotovit ocherednoj zapros, servernyj process prostaivaet, zanimaya sistemnye resursy.
Arhitektura DSA polnost'yu ispol'zuet vozmozhnosti simmetrichnyh mnogoprocessornyh platform SMP (Symmetric Multiprocessing systems), i mozhet rabotat' na odnoprocessornyh platformah. V posleduyushchih versiyah predpolagaetsya rasshirit' arhitekturu servera, obespechiv podderzhku slabosvyazannyh sistem i sistem s massovym parallelizmom (MPP). Vse bazovye tehnologii DSA yavlyayutsya vstroennymi, oni vklyucheny v biblioteki servera, i ih primenenie ne zavisit ot osobennostej OS ili apparatnyh platform razlichnyh postavshchikov.
2.2.1.1 Potoki
Arhitekturu INFORMIX-OnLine DS nazyvayut takzhe mnogopotokovoj. Dlya kazhdogo klienta sozdaetsya tak nazyvaemyj potok, ili nit' (thread). Potok - eto podzadacha, vypolnyaemaya v ramkah odnogo iz servernyh processov.
V nekotoryh sluchayah dlya obsluzhivaniya odnogo klientskogo zaprosa sozdaetsya neskol'ko parallel'nyh potokov. Potoki sozdayutsya takzhe dlya vypolneniya vnutrennih zadach servera - vvoda-vyvoda, zhurnalizacii, administrirovaniya i dr. Takim obrazom, odnovremenno vypolnyaetsya mnozhestvo potokov, kotorye raspredelyayutsya mezhdu nalichnymi virtual'nymi processorami (ris. 2).
Ris.2. Mnogopotokovaya model'. Virtual'nye processory (VP) ne prostaivayut, esli imeyutsya gotovye k vypolneniyu pol'zovatel'skie ili sistemnye potoki.
INFORMIX-OnLine DS ne polagaetsya na mehanizmy potokov, imeyushchiesya v nekotoryh operacionnyh sistemah. On formiruet potoki, specifichnye dlya zadach obrabotki baz dannyh, optimal'nye v otnoshenii vydelyaemoj pod nih pamyati, metodov planirovaniya i chisla instrukcij, zatrachivaemyh na pereklyuchenie mezhdu potokami.
2.2.1.2 Virtual'nye processory
Virtual'nym processorom nazyvaetsya process servera baz dannyh. Virtual'nyj processor mozhno sravnit' s operacionnoj sistemoj. Potok po otnosheniyu k nemu vystupaet kak process, podobno tomu, kak sam virtual'nyj processor yavlyaetsya processom s tochki zreniya operacionnoj sistemy.
Virtual'nye processory (VP) yavlyayutsya specializirovannymi - oni podrazdelyayutsya na klassy v sootvetstvii s tipom potokov, dlya vypolneniya kotoryh oni prednaznacheny. Primery klassov VP:
CPU - Potoki obsluzhivaniya klientov, realizuyut optimizaciyu i logiku vypolneniya zaprosov. K etomu klassu otnosyatsya i nekotorye sistemnye potoki.
AIO - Operacii asinhronnogo obmena s diskom.
ADM - Administrativnye funkcii, naprimer, sistemnyj tajmer.
TLI - Kontrol' setevogo vzaimodejstviya posredstvom interfejsa TLI (Transport Layer Interface).
V otlichie ot operacionnoj sistemy, kotoraya dolzhna obespechivat' vypolnenie proizvol'nyh processov, klassy virtual'nyh processorov sproektirovany dlya naibolee optimal'nogo vypolneniya zadanij opredelennogo vida.
Nachal'noe chislo virtual'nyh processorov kazhdogo klassa, sozdavaemyh pri zapuske INFORMIX-OnLine DS, zadaetsya v konfiguracionnom fajle. Odnako, potrebnosti v kazhdom vide obrabotki ne vsegda predskazuemy. Instrumenty administrirovaniya pozvolyayut dinamicheski, ne ostanavlivaya server, zapustit' dopolnitel'nye virtual'nye processory. Naprimer, esli rastet ochered' potokov k virtual'nym CPU-processoram, to mozhno uvelichit' ih chislo. Tochno tak zhe, vozmozhno dobavlenie virtual'nyh processorov obmena s diskami, setevyh processorov vzaimodejstviya s klientami, sozdanie processora obmena s opticheskim diskom, esli on otsutstvoval v nachal'noj konfiguracii. Dinamicheski sokratit' mozhno tol'ko chislo virtual'nyh processorov klassa CPU.
Na nekotoryh mul'tiprocessornyh platformah, gde OnLine DS podderzhivaet rodstvo processorov (processor affinity), dopuskaetsya privyazka virtual'nyh CPU-processorov k opredelennym central'nym processoram komp'yutera. V rezul'tate proizvoditel'nost' virtual'nogo CPU-processora povyshaetsya, poskol'ku operacionnaya sistema rezhe proizvodit pereklyuchenie processov. Privyazka pozvolyaet takzhe izolirovat' rabotu s bazoj dannyh, vydelyaya dlya etoj celi opredelennye processory, v to vremya kak ostal'nye budut zanyaty drugimi zadachami.
2.2.1.3 Planirovanie potokov
Server osvedomlen o stepeni znachimosti razlichnyh potokov i v sootvetstvii s etim naznachaet dlya nih prioritety. Naprimer, potoki vvoda-vyvoda poluchayut prioritety sleduyushchim obrazom:
Takim obrazom, garantiruetsya, chto operacii zapisi v logicheskij zhurnal, ot kotoryh zavisit vosstanovlenie bazy dannyh v sluchae sboya, ne okazhutsya v ocheredi pozadi operacii vyvoda vo vremennyj rabochij fajl.
Sami virtual'nye processory vypolnyayutsya kak vysokoprioritetnye processy operacionnoj sistemy, kotorye ne preryvayutsya, poka ne pusty ocheredi gotovyh k vypolneniyu potokov.
Vypolnenie potoka ne otkladyvaetsya po istechenii zadannogo kvanta vremeni, kak eto proishodit s processami v operacionnoj sisteme. Potok otkladyvaetsya v dvuh sluchayah:
2.2.1.4 Razdelenie potokov mezhdu virtual'nymi processorami.
Dlya kazhdogo klassa podderzhivayutsya tri ocheredi potokov, kotorye razdelyayutsya vsemi virtual'nymi processorami dannogo klassa:
Esli vypolnyaemyj potok zavershaetsya, zasypaet ili otkladyvaetsya, to osvobodivshijsya virt