Ha a rendszerünk teljesítményén szeretnénk javítani, miközben egyre kevesebb a cégnél az informatikai szakember, és egyre kisebb a költségvetés, akkor mindenképp be kell szereznünk néhány olyan terméket, amelyek leegyszerűsítik és automatizálják a karbantartási funkciókat. Az adatbázis-adminisztrátornak szüksége van olyan eszközökre, melyek órákról percekre vagy egy percen belülire csökkentik a karbantartási időt és a karbantartási feladatokat úgy tudják ellátni, hogy közben a felhasználók a munkájuk elvégzéséhez szükséges adatokhoz folyamatosan hozzáférnek. Néhány adatbázis-kezelő rendszer rendelkezik ilyen beépített eszközökkel. Az eszközök használatával az adatbázis elérhető marad, azaz a felhasználók olvasni és írni is tudják az adatokat, és az adatbázis-adminisztrátor is el tudja végezni a karbantartási feladatait. Az adatbázis integritása nem sérül a karbantartó programok használata során. Ha az adatbázis-kezelő rendszernek nincs ilyen eszköze, akkor vásárolhatunk más cégtől is ilyen terméket.

A következő feladatokhoz van a legnagyobb szükség olyan segédprogramokra, amelyek nem szakítják meg az adatbázis működését:

Vegyünk egy példát. Ha az adatbázis-adminisztrátor az adatbázist úgy akarja újraszervezni, hogy közben az adatbázis elérhető maradjon, illetve csak nagyon minimális mértékben ne legyen elérhető az adatbázis, akkor az nem megoldás, hogy leállítjuk az adatbázist, újraszervezzük, majd újraindítjuk. Helyette inkább hozzunk létre egy adatmásolatot, és szervezzük át a másolatot. Ekkor az olvasási és az írási hozzáférés az eredeti adatokon folytatódhat, majd amikor a másolat újraszervezése készen van, az újraszervező folyamat az adatbázisnaplókat használja, hogy az eredeti adatokon végzett módosításokat a másolaton alkalmazza. Amikor a másolat utolérte az eredetit, akkor a vezérlést áthelyezzük az új, másolati adatbázisba, azaz a másolatból lesz az eredeti, az eredetit pedig törölni lehet.

Ne felejtsük el, hogy a legtöbb adatbázis-karbantartó művelet hat az elérhetőségre. Az adatok biztonsági másolatai, az adatok helyreállítása, integritássértéseket ellenőrző adatellenőrzés, adatbázis-statisztika készítése, az új adatok betöltése az adatbázisba mind kedvezőtlenül hat az elérhetőségre. Amikor az adatbázist online állapotban, működés közben tartjuk karban, nagy hasznát vehetjük azoknak az eszközöknek, amelyek a legújabb tárolási eszközökkel együtt dolgozva a leállás minimalizálására és kiküszöbölésére szolgálnak. Néhány tárolási egység gyors pillanatfelvételt tud készíteni az állományokról. Ha az adatbázist karbantartó műveletek élnek e technika adta lehetőségekkel, a leállást percekről vagy órákról másodpercekre le lehet csökkenteni.

A legtöbb adatbázis-karbantartás hatással van az elérhetőségre. A legnagyobb veszélyt az elérhetőségre nézve az adatbázis-változások jelentik. Az elérhetőségre való hatás függ a változás típusától és attól, hogy az adatbáziskezelő-rendszer hogyan valósítja meg a változást. Ha olyan egyszerű változásra van szükség, amelyhez az ALTER utasítást lehet használni, mint például bizonyos adatbázis konfigurációs paraméterek változtatása, akkor az, bár hatással van az elérhetőségre, mégis kisebb probléma, mert ezt a változtatást gyorsan végre lehet hajtani. Az adatbázis-objektumokon történő változásoknak, mint például egy táblabeli oszlop definíciójának a változtatása, nagyobb hatásuk van az elérhetőségre. Ha az adatbázis-objektum szerkezeti definícióját változtatjuk, akkor azt legtöbbször csak úgy lehet megtenni, hogy közben az adatbázis-objektumot a felhasználók nem érhetik el. Minél összetettebb a változás típusa, annál nagyobb a hatása az elérhetőségre. Bizonyos változások objektumok eldobását és adatok törlését igénylik. Nyilvánvaló, hogy egy ilyen változás leállást okoz. Minél hosszabb ideig tart a változás végrehajtása, annál nagyobb leállás lesz. A nagy sebességű LOAD (betöltő) és UNLOAD (kimentő) segédprogramok csökkenthetik a leállás időtartamát. A változás automatizálása tovább növelheti az elérhetőséget.

Ha az adatbázis-adminisztrátori eljárások egy részét automatizáljuk, az növelheti a teljes adatbázis elérhetőségét. Egy megfelelően létrehozott, automatizált folyamat ritkábban hibásodik meg, mint a manuálisan megvalósított utasítások halmaza. Az ember hibát követ el, így minél összetettebb a feladat, annál hasznosabb az automatizálás.

Az adatbázis-változások végrehajtása összetett feladat. Így jogosan feltételezhetjük, hogy a változások automatizálása javíthatja az elérhetőséget. Ha automatizált adatbázis-adminisztrátori eszközöket használunk, csökken az emberi hiba lehetősége. Sokkal több időbe telik az adatbázis-adminisztrátornak, hogy manuálisan írjon szkripteket a változásokhoz, mint egy változáskezelő eszköznek ahhoz, hogy generálja azokat. Ráadásul nem valószínű, hogy az eszköz hibát követ el. Tehát az adatbázis-változások automatizálásával kevesebb idő szükséges azok végrehajtásához, mint ahhoz, hogy az adatbázis-adminisztrátor a kívánt változásokat elemezze, hogy a változás végrehajtására a szkripteket fejlesszen, és, hogy az adatbázis-változásához a szkripteket futtassa. Természetesen a változások elemzése automatizált eszköz segítségével sem maradhat el, de az eszköz ebben a feladatrészben is nagy segítséget nyújthat.

Az automatizálásnak az adatbázis mentésénél és helyreállításánál vehetjük még nagy hasznát. Egy cégnél előre számítani kell arra, hogy a rendszer valamilyen hiba miatt leáll, vagy valamilyen katasztrófa történik. Ezekre az eseményekre fel kell készülni, vagyis az adatbázist megfelelő módon archiválni kell. A cél, hogy a hiba vagy katasztrófa bekövetkezte után a cég minél hamarabb helyreállítsa az adatait. A biztonsági mentéshez és helyreállításhoz való proaktív megközelítés segít abban, hogy a hiba vagy katasztrófa után a rendszer adatvesztés nélküli minimális leállással tudjon működni. Míg egy nem végiggondolt mentési-, helyreállítási stratégia esetén a cégünk esetleg soha nem tud talpra állni. A legtöbb adatbázisrendszer és alkalmazás minimálisan járul hozzá az automatizált biztonsági mentéshez és helyreállításhoz, illetve nem biztosítanak olyan funkciókat, melyek a proaktív helyreállítási tervezést támogatnák. Az adatbázis-adminisztrátornak olyan eszközökre van szüksége, melyek lehetővé teszik a gyakori mentéseket úgy, hogy azok közben az online rendszerre minimális hatást gyakoroljanak. A mentési és helyreállítási szoftver egy másik fontos követelménye, hogy nagyon gyorsan tudja helyreállítani az adatokat, mégpedig olyan sorrendben, ahogy azt az üzleti alkalmazások kritikussága meghatározza. Ha szükséges, az adatbázis-adminisztrátornak helyre kell tudnia állítani minden adatbázis-objektumot a rendelkezésére álló biztonsági mentések és adatbázisnaplók segítségével. Ez az adatbázis-kezelő rendszer, az alkalmazás, és a környezet ismeretét követeli meg, illetve megfelelően dokumentált mentési-, helyreállítási stratégiát igényel. Elérhetőek olyan eszközök, amelyek probléma esetén a helyreállítás automatizálását segítik azáltal, hogy a helyzetet elemzik és olyan helyreállítási szkripteket készítenek, amelyekkel a rendszer rövid időn alatt helyreállítható.

Ha az adatbázis-kezelő rendszerünket úgy tervezték, hogy ki tudja használni a klaszteres megoldásokat vagy a párhuzamos adatfeldolgozást, akkor törekedjünk rá, hogy cégünk adatbázisainál is ki tudjuk használni ezeket a technológiákat. Már az adatbázis tervezésénél is gondoljunk arra, hogy ha nem is azonnal, de később be lehessen vezeti ezeket a megoldásokat. Az adatbázis-kezelő rendszerek általában képes a legújabb hardverbeli és operációs rendszerbeli képességeket is kihasználni, csak a cégünk pénztárcáján múlik, hogy valóban ki tudjuk-e őket használni.

A legtöbb adatbázis-kezelő rendszernek sok olyan eszköze van, amely az elérhetőséget támogatja. Két legalapvetőbb példa ezek közül: a segédprogramok és az adatbázis rendszerparaméterei. Segédprogramok futtatása, valamint az adatbázis rendszerparamétereinek a megváltoztatása régen olyan feladatok voltak, amelyek a legtöbb esetben leállást igényeltek. Általában ahhoz, hogy a segédprogramot futtatni lehessen, a karbantartott adatbázis-objektumokat az adatbázis-kezelő rendszerről le kellett kapcsolni. Ha rendszerparaméter változtatására volt szükség, akkor az egész adatbázis-kezelő rendszert le kellett állítani, és az újraindítással történt meg a változás. A legtöbb adatbázis-kezelő rendszer az újabb verziókban már olyan technikát biztosít, amellyel a rendszerparamétereket úgy lehet megváltoztatni, hogy közben az adatbázis-kezelő rendszert nem kell leállítani.

Ha az adatbázis-kezelő rendszernek új verziója kerül a piacra, akkor az adatbázis-adminisztrátornak érdemes felülvizsgálni, hogy a régi, leállást igényelő karbantartó műveletek helyett az új verzióba kerültek-e be olyan új megoldások, amelyek ugyanazt a feladatot már leállás nélkül is meg tudják oldani. Ha igen, akkor érdemes ezeket az új megoldásokat kihasználva újratervezni ezeket a karbantartási műveleteket.

A klaszter összekapcsolt szerverek csoportja, amelynek a segítségével növelhetjük a szerverek megbízhatóságát. Emlékezzünk vissza a klaszterezés definíciójára, amely Az adatbázis-környezet létrehozása című fejezetben is szerepelt: A klaszterezés több független számítógép összekapcsolása, melyeknek az együtt végzett munkája a felhasználó számára úgy tűnik, mintha egy önálló, magas elérhetőségű rendszer használnánk. Tekintsük meg a 11-1-es ábrát.

11-1. ábra – Klaszter

Többféleképp meg lehet valósítani a szerverek klaszterezését. Lehetőség lehet például, hogy a számítógépeknek csak a tároló eszközeiket osztjuk meg. Egy másik lehetőség, hogy egy szoftver segítségével a munkaterhelést szétosztjuk a számítógépek között. És természetesen még ezeken kívül is léteznek más megvalósítások a klaszterezésre.

A klaszterezés egyik nagy előnye, hogy ha a növekvő üzleti igények miatt az áteresztőképességet növelni szeretnénk, akkor új szervereket vagy csomópontokat kapcsolhatunk a klaszterhez mégpedig úgy, hogy közben az adatbázis-környezetünk elérhető marad.

A klaszterezésnek a másik nagy előnye a megbízhatóság. A klasztert meg lehet úgy valósítani, hogy ha az összekapcsolt szerverek közül az egyik meghibásodik, akkor annak a feladatát a többi szerver át tudja venni. Ezáltal csökken a leállás esélye, ami fokozza az elérhetőséget. A klaszterben minden szerver kapcsolatban van a többi szerverrel, így amikor a klaszternek egy csomóponttal megszűnik a kapcsolata, a klaszter felismeri ezt a hibát és elindít egy olyan folyamatot, ami a hiba kiküszöbölésére szolgál.

A szerverhiba kezelését tekintve a klasztereket többféleképp lehet megvalósítani. Például, az egyik megoldás, hogy ha egy szerver meghibásodik, akkor ennek a csomópontnak a feladataihoz kapcsolódó összes folyamatot egyetlen másik szerver veszi át. Egy másik lehetőség, hogy a klaszternek van egy olyan szervere, amelyik általában nem dolgozik. Amikor a hiba megtörténik, a tétlen csomópont veszi át a meghibásodott szerver feladatait. Harmadik megoldás lehet, hogy a meghibásodott szerver feladatát a klaszter a többi csomópont között szétosztja. Az, hogy melyik csomópont mennyi feladatot kap, azon múlik, hogy melyiknek mekkora az áteresztőképessége.

A klaszterezés növeli az elérhetőséget, mert a meghibásodott csomópontokat leállás nélkül el lehet távolítani a klaszterből és amikor a szerver újra működőképes lesz, újra csatlakoztathatjuk a klaszterhez.

A rengeteg előny ellenére sok IT cég nem használja ki a klaszter megoldást, aminek az oka elsősorban a költségekben keresendő. A klaszterhez több gép szükséges, és alapvetően igaz, hogy egy gép még mindig olcsóbb, mint több gép, főleg kezdetben. Másik ok lehet, hogy az alkalmazásokat a klaszter megvalósításnak megfelelően valószínűleg módosítani kell, hogy a szerverhiba kezelése lehetővé váljon. Ez a változtatás is költségekkel jár.

A legtöbb operációs rendszer támogat bizonyos fokú klaszterezést. Az adatbázis szempontjából az adatbázis-kezelő rendszer szoftverét úgy kell beállítani, hogy ha tudja, akkor kihasználhassa az operációs rendszerbeli klaszter-támogatást.

A klaszterezés amiatt is hasznos, hogy a rutin karbantartások hatását elfedjük vele. Ha egy szervert karbantartás miatt a rendszerről le kell kapcsolni, az általa végzett munkát áttehetjük egy másik szerverre. Például, ha szükséges memóriát hozzáadni egy szerver alaplapjához, azt a szervert le kell állítani. Ha a leállított szerver egy klaszterben vesz részt, a munkaterhelését a klaszter egy másik csomópontjára lehet átirányítani. A memóriabővítés után pedig a szervert visszahelyezzük a klaszterbe, hogy újra ellássa ott a feladatát. Így a karbantartás nem igényel leállást.