Az adatbázis adatait tartalmazó állományok helye meghatározó hatással lehet a teljesítményre. Egy adatbázis esetén nagyon sok input/output művelet van. Az adatbázis-adminisztrátornak mindent meg kell tennie, hogy a fizikai lemez írásának és olvasásának a költségét minimalizálja. Ehhez ismernie kell, hogy az adatbázis-kezelő rendszer az egyes adatelemeket hogyan éri el, és az adatokat a fizikai lemezeszközön úgy kell elhelyeznie, hogy a teljesítmény optimális legyen.
Először is az indexeket és az adatokat tartalmazó állományokat különítsük el, ha lehet. Az adatbázis-lekérdezésekhez gyakran a tábla és a táblához tartozó index adatainak elérésére is szükség lehet. Ha mindkettő ugyanazon a lemezen van, akkor az valószínűleg negatív hatással van a teljesítményre. A lemezről történő adatkinyeréshez az író-olvasó fej mozog a lemezfelületen, hogy az adatot tároló fizikai blokkokat a lemezről kiolvassa. Ha egy művelet ugyanarról a lemezeszközön levő állományokból kéri az adatot, lappangás történik: annak a folyamatnak, amely az egyik állományból olvasna, várnia kell, amíg a másik állományból az olvasás történik. Ha az adatbázis-kezelő rendszer az indexeket és az adatokat ugyanarra a lemezre teszi, az indexeket és az adatokat nem tudja az adatbázis-kezelő rendszer párhuzamosan olvasni.
Másik szabály az állományelhelyezéshez, hogy az alkalmazások adatkéréseit elemezzük, és válasszuk külön azon táblák állományait, amelyeket gyakran együtt kérnek le. Az ok ugyanaz, mint az indexek és adatok esetén.
Az utolsó állományelhelyezési elvet akkor használhatjuk, ha egy tábla több állományba van tárolva, azaz particionált táblák esetén. Ekkor az egyes állományokat helyezzük különböző lemezeszközre, hogy támogassuk és optimalizáljuk a párhuzamos adatbázis-műveleteket. Ha az adatbázis-kezelő rendszer egy lekérdezést részekre törhet, hogy párhuzamosan futtassa, akkor a particionált táblák több állományának a különböző lemezeszközökön való elhelyezése minimalizálja a lemez-lappangást.
Ha a tranzakciónaplót az aktuális adatoktól elkülönítve helyezzük el, akkor az adatbázisnaplót az adatbázis-kezelő rendszer úgy tudja írni, hogy közben az adatbázis adatainak a lemezre írására és a lemezről olvasására nem kell várnia. Ha ugyanazon a lemezmeghajtón lévő két állományba ugyanabban az időpontban ír az adatbázis-kezelő rendszer, az a teljesítményre negatív hatással van. Ez a teljesítménycsökkenés írás esetén sokkal nagyobb, mint ha az adatokat olvasnánk. Ha az adatbázisnaplót elkülönítjük, akkor minimalizáljuk a párhuzamos írást ugyanarra a lemezre. Hiszen tudjuk, hogy minden adatbázis-módosítás a tranzakciónaplóba is bekerül.
Az adatbázisnapló elkülönítése a mentésnél is hasznos. Az adatbázisnaplót minden naplóváltáskor menteni kell, amely sokkal többször fordul elő, mint a teljes adatbázis mentése. Ha a tranzakciónaplót elkülönítjük az adatoktól, akkor a napló mentése kevésbé fogja a rendszer teljesítményét hátrányosan befolyásolni.
Az adat elhelyezés célja az elérés optimalizálása. Ezt általában az adatbázis-adminisztrátor azzal teszi meg, hogy a fizikai eszközön csökkenti a versengést. Egy kliens/szerver környezetben ez a cél kibővül az alkalmazás-teljesítmény optimalizálásával, mégpedig úgy, hogy az adatbázis-adminisztrátor igyekszik a hálózati átviteli költségeket csökkenteni. Ehhez az adatnak azon az adatbázisszerveren kell lennie, ahol a legvalószínűbb vagy a leggyakoribb, hogy használják. Azaz az adatot igyekszik az adat használójához a legközelebb elhelyezni.
Az elosztott adatokról az Elosztott adatbázisok című fejezetben olvashatunk még.
A legtöbb adatbázis-kezelő rendszer esetén meg lehet határozni az adatlap méretét. Az adatlapról bővebben az Adat- és tároláskezelés című fejezetben olvashattunk.
Van olyan adatbázis-kezelő rendszer, amely teljesen korlátozza az adatlap méretét, azonban a legtöbb adatbázis-kezelő rendszer esetén az adatlap méretét az adatbázis-adminisztrátor választhatja meg. Az adatlap méretére azonban a lemezen használt állományrendszer, az operációs rendszer, és az adatbázis-kezelő rendszer is korlátokat határoz meg. Az adatbázis-adminisztrátornak a legjobb adatlapméret kiszámítását a sorok méretére, az adatlaponkénti sorok számára, és az adatlapon megkövetelt szabad hely mennyiségére alapozhatja.
A megfelelő adatlapméret kiválasztása fontos feladat, mert az adatbázis-adminisztrátornak ez az egyik eszköze arra, hogy az adatbázis input/output műveleteinek a teljesítményét optimalizálja.
Nagyméretű adatrekord akkor fordulhat elő, ha egy táblában olyan adattípusokat tárolunk, mint szövegek, képek, vagy más bináris nagyméretű objektumok. Ha más típusú rekordoknál is előfordul az, hogy az adatrekord nagyobb, mint az adatlap, akkor az adatbázis-adminisztrátor a telepítésnél nem jól választotta meg az adatlap méretét. Ez pedig teljesítményproblémákhoz vezethet.
A relációs technológiával és az SQL utasításokkal könnyű az adatmódosítás. Egy INSERT, UPDATE vagy DELETE utasítás a megfelelő WHERE utasításrésszel, és az adatbázis-kezelő rendszer elvégzi az aktuális navigációt és módosítást. Ahhoz, hogy ez az absztrakciós szint biztosíva legyen, az adatbázis-kezelő rendszer a háttérben nagyon sokat dolgozik. Többek között meg kell valósítania a fizikai adatbázisban az adatok módosítását, azaz adatot kell elhelyezni, módosítani vagy törölni a lemezen, amely esetleg adatmozgatással is jár. Elméletileg ez mindenkinek jó. A programozói interfész egyszerű, a relációs adatbázis-kezelő rendszer elvégzi a munka nagy részét: az adatok aktuális helyének manipulálását. Azonban a dolgok sajnos nem ennyire egyszerűek. Az adatbázis-kezelő rendszer fizikai adatkezelésének a módja teljesítményproblémákat okozhat.
Minden adatbázis-adminisztrátor találkozott már olyan szituációval, ahol egy olyan lekérdezés vagy alkalmazás, amelynek eddig a teljesítményével nem volt gond, a termelési rendszerben lelassul egy idő után. Ennek a lelassulásnak sok lehetséges oka lehet, például megnőtt a tranzakciók száma, vagy kiterjedt az adatmennyiség. A teljesítményproblémát az adatbázis szétszórtsága is okozhatja. Az adatbázis szétszórtsága akkor áll elő, amikor egy adatbázis logikai vagy fizikai tárolási allokációi sok különálló tárterületet tartalmaznak, amelyek túl kicsik, fizikailag nem folytonosak vagy nagyon távol vannak egymástól. Tekintsük át a leggyakoribb okokat:
Töredezettség: sok a szétszórt, kis méretű tárolási terület. Ez elpazarolt helyet eredményez, amely a teljesítményt csökkenti. Mégpedig azért, mert ugyanazt az adatmennyiséget egy töredezett tárolási területről sokkal több input/output művelet segítségével lehet kinyerni, mint egy nem töredezett területről.
Sorláncolás és sormigráció: akkor történik, ha a módosított adat nem fér el arra a helyre, amelyen eredetileg volt, és az adatbázis-kezelő rendszernek új helyet kell találnia a frissített sornak. A sorláncolással az adatbázis-kezelő rendszer a módosított adatsor egy részét a táblatéren belül mozgatja egy olyan helyre, ahol elég szabad hely létezik. A sormigráció esetén az adatbázis-kezelő rendszer a teljes sort máshova mozgatja a táblatéren belül. Az adatbázis-kezelő rendszer mindkét esetben mutatókat használ, amely a sor maradék részére vagy a teljes sorra mutat. A sorláncolás és a sormigráció esetén is egy sor olvasásához több input/output művelet szükséges. A teljesítmény sérül a többszörös input/output művelet miatt.
Állománykiterjesztések: a kiterjesztés egy újabb állomány, amely az eredeti állományhoz van kötve és csak az eredeti állománnyal együtt lehet használni. Ha egy táblatér által használt állomány kifut a helyből, egy állománykiterjesztést kap. Az állománykiterjesztések nem folyamatosan tárolódnak az eredeti állománnyal. Ha vannak állománykiterjesztések, az adatkéréseknek az adatot állománykiterjesztésről állománykiterjesztésre nyomon kell követniük és ez szükségtelen túlterhelés jelent. Az újraszervezés megszüntetheti a problémát.
Az adatbázis-kezelő rendszertől függően még sok oka lehet a szétszórtságnak. Például ha több tábla van egy táblatérben és az egyik táblát eldobjuk, akkor a tárterület visszaszerzéséhez lehetséges, hogy a táblateret újra kell szervezni.
A szervezetlen adatstruktúrák javítására az adatbázis-adminisztrátor adatbázis vagy táblatér újraszervező segédprogramot (REORG) futtathat, hogy kikényszerítse az adatbázis-kezelő rendszertől az adatbázis-objektum újra strukturálását. Így az adatbázis-adminisztrátor megszüntethet pár teljesítményproblémákat okozó okot, mint a töredezettség, vagy a sorláncolás. Az újraszervezés elsődleges előnye, hogy az újraszervezés után az adatbázis-funkciók gyorsabbak és hatékonyabbak lesznek, mivel az adatok a lemezen optimálisabb módon lesznek elhelyezve. Az újraszervezés maximalizálja az adatbázisok elérhetőségét és megbízhatóságát.
A táblatereket és indexeket is lehet újraszervezni. Az adatbázis-kezelő rendszertől függ, hogy az adatbázis-adminisztrátor hogyan futtatja a REORG-ot. Néhány adatbázis-kezelő rendszernek van beépített újraszervező segédprogramja. Más adatbázis-kezelő rendszerek nem rendelkeznek ilyennel, ekkor másik szállítótól lehet venni egyet.
Az adatbázis-adminisztrátor manuálisan is újraszervezheti az adatbázist, mégpedig úgy, hogy a teljes adatbázist újraépíti. Ez egy nagyon bonyolult feladat, sok, bonyolultan összekapcsolt lépést kell hozzá végrehajtani. Ha az újraszervezéshez érhető el segédprogram, a folyamat leegyszerűsödik. Néha csak egyetlen egyszerű parancs szükséges hozzá.
A hagyományos újraszervezéshez az adatbázist le kell állítani. Néhány REORG segédprogram online adatbázis mellett is végrehajtja az újraszervezést. Az ilyen újraszervezés adatmásolat készítéssel megy végbe. Az online REORG segédprogram újraszervezi a másolatot, miközben az eredeti adatok elérhetőek maradnak. Ha a másolt adatok újraszerveződtek, az online REORG az adatbázisnaplót használja, hogy a másolaton is végbemenjenek az adatváltozások, amelyek a folyamat alatt történtek. Ha a másolat felfrissült, a REORG áthelyezi a vezérlést az eredeti táblatérről a másoltra. Egy online újraszervezéshez tárterület szükséges. Az online újraszervezést érdemes olyan időszakban elvégezni, amikor az eredeti adatbázisban kevés tranzakció történik. Ellenkező esetben az újraszervezett adatbázisban a változások átvezetése nagyon sok időt emészt fel.
A rendszerkatalógus segíthet annak a meghatározásában, hogy mikor kell egy adatbázis-objektumot újraszervezni. Az adatbázis-kezelő rendszerek általában rendelkeznek egy olyan eszközzel, amely végigolvassa az adatbázis-tartalmat és az egyes adatbázis-objektumokról statisztikai információkat ment el. Adatbázis-kezelő rendszertől függően ez a statisztikai információ vagy a rendszerkatalógusban vagy egy speciális adatlapon az adatbázis-objektumon belül tárolódik.
Néha nehéz nyomon követni a szétszórtság más okait. Néhány adatbázis-kezelő rendszer statisztikát gyűjt a töredezettségről, a sorláncolásról, a sormigrációról, az eldobott objektumokhoz dedikált helyekről, amelyek segíthetnek felfedezni a rendezetlenség okait.
A táblatér nem az egyetlen adatbázis-objektum, amelyet újra lehet szervezni. Az indexeknél is előnyös (sőt szükséges - ha az indexelt tábla változása ezt igényli) lehet az újraszervezés. Ahogy a táblába új adat kerül, vagy a tábla módosul, az indexnek is módosulnia kell. Az ilyen változások okozhatják azt, hogy az index szétszórttá válik.
Ha lehetséges, az adatbázis-adminisztrátornak automatizálni kell az újraszervezést. Az automatizálási eszköz lekérdezheti az adatbázis-statisztikát és elindíthatja az újraszervezést azoknál az objektumoknál, amelyek a statisztika szerint elérnek egy küszöbértéket.
Az újraszervezés költséges lehet, mert leállással és az erőforrások terhelésével jár. Nehéz meghatározni, hogy az újraszervezés mikor javít a teljesítményen. A bölcs adatbázis-adminisztrátor megtervezi és ütemezi az újraszervezéseket, hogy feloldja a szétszórtsági problémákat az adatbázisban.