Большинс­тво ор­га­низа­ций ис­пользу­ет при­ложе­ния для уп­равле­ния биз­нес-про­цес­са­ми и действи­ями, а эти при­ложе­ния обыч­но хра­нят дан­ные в ба­зе дан­ных (БД). Ор­га­низа­ции все бо­лее за­висят от при­ложе­ний и дан­ных, ко­торые они хра­нят. В та­кой си­ту­ации БД яв­ля­ют­ся кри­тичес­ки важ­ным ком­по­нен­том биз­не­са в об­ласти ин­фраструк­ту­ры ин­форма­ци­он­ных тех­но­логий.
На те­кущем эта­пе раз­ви­тия ин­форма­ци­он­ные сис­те­мы по­мога­ют соз­да­вать и рас­простра­нять ин­форма­цию че­рез при­ложе­ния, обес­пе­чива­ющие ком­па­ни­ям дос­туп к дан­ным и сис­те­мам ком­му­ника­ций, свя­зыва­ющим раз­вет­влен­ное пред­при­ятие по все­му ми­ру. Ин­форма­ци­он­ные сис­те­мы жиз­ненно не­об­хо­димы и яв­ля­ют­ся ис­точни­ками кон­ку­рен­тно­го пре­иму­щес­тва.

Про­фес­сор Уни­вер­си­тета Вос­точной Ка­роли­ны Вен­кат Гу­дива­да (США) с кол­ле­гами в пе­ри­оди­чес­ком из­да­нии «От­кры­тые сис­те­мы. СУБД» пи­шет, что ре­ляци­он­ные СУБД вы­дер­жа­ли про­вер­ку вре­менем с точ­ки зре­ния воз­можнос­ти об­слу­жива­ния при­ложе­ний опе­ратив­ной об­ра­бот­ки тран­закций (OnLine Transaction Processing — OLTP). В чис­ло стан­дар­тных фун­кций та­ких СУБД вхо­дят SQL, уп­равле­ние тран­закци­ями, ав­то­риза­ция и кон­троль дос­ту­па, ре­зер­вное ко­пиро­вание и вос­ста­нов­ле­ние. Преж­де все­го под­держи­ва­ют­ся при­ложе­ния, ко­торым нуж­ны сох­ра­нение це­лос­тнос­ти, а­утен­ти­фика­ция и де­тали­зиро­ван­ный кон­троль дос­ту­па, а так­же дек­ла­ратив­ные язы­ки зап­ро­сов и тран­закции.
Ре­ляци­он­ные СУБД хо­рошо ра­бота­ют с фик­си­рован­ной схе­мой и сох­ра­ня­ют це­лост­ность дан­ных за счет ог­ра­ниче­ний и триг­ге­ров, вы­пол­няя тран­закции в пол­ном со­от­ветс­твии с прин­ци­пами ACID. Хра­нимые про­цеду­ры по­мога­ют ми­ними­зиро­вать пе­ренос дан­ных, осу­щест­вляя рас­че­ты внут­ри са­мой БД.

Движ­ки хра­нения в этих СУБД обыч­но оп­ти­мизи­рова­ны для пос­троч­ной об­ра­бот­ки — для из­ме­нения единс­твен­но­го зна­чения в стро­ке нуж­но по­лучить ее всю це­ликом. Та­кая мо­дель хра­нения под­хо­дит для OLTP-при­ложе­ний, но слож­ность вы­чис­ле­ния аг­ре­гатов по стол­бцам таб­ли­цы с рос­том объема дан­ных уве­личи­ва­ет­ся.
В нас­то­ящее вре­мя су­щес­тву­ет бо­лее 100 ком­мерчес­ких и от­кры­тых ре­ляци­он­ных СУБД, сре­ди ко­торых на­ибо­лее по­пуляр­ны Oracle Database, Microsoft SQL Server, MySQL, PostgreSQL и IBM DB2.
Oracle Database — это объек­тно-ре­ляци­он­ная СУБД. В нас­то­ящее вре­мя она яв­ля­ет­ся ли­диру­ющей плат­формой для пос­тро­ения вы­соко­наг­ру­жен­ных рас­пре­делен­ных кор­по­ратив­ных хра­нилищ дан­ных и ана­лити­чес­ких сис­тем. От про­из­во­дительнос­ти Oracle Database мо­гут за­висеть мно­гие важ­ные биз­нес-про­цес­сы, по­это­му она нуж­да­ет­ся в по­сто­ян­ном мо­нито­рин­ге.
Microsoft SQL Server — это плат­форма, на ко­торой пос­тро­ено ог­ромное ко­личес­тво ре­шений, вклю­чая как пер­со­нальные БД на компьюте­рах пользо­вате­лей, так и круп­ные кор­по­ратив­ные сис­те­мы и при­ложе­ния лю­бых мас­шта­бов. Microsoft SQL Server пред­став­ля­ет со­бой ком­плексное ре­шение для уп­равле­ния БД, а так­же со­дер­жит об­ширный на­бор средств для биз­нес-ана­лити­ки. Дан­ный сер­вер яв­ля­ет­ся од­ной из са­мых рас­простра­нен­ных СУБД в ми­ре. Про­из­во­дительность, на­деж­ность, бе­зопас­ность и мас­шта­биру­емость поз­во­ля­ют ис­пользо­вать его прак­ти­чес­ки во всех биз­нес-кри­тич­ных сис­те­мах, где есть пот­ребность в хра­нении и об­ра­бот­ке дан­ных.
Се­год­ня биз­нес дик­ту­ет все бо­лее вы­сокие тре­бова­ния к кор­по­ратив­ным сис­те­мам, так как от них за­висит эф­фектив­ность ра­боты всей ком­па­нии в це­лом. Не­допус­ти­мы да­же ма­лейшие от­кло­нения и сбои. Но чем слож­нее сис­те­ма, тем труд­нее оп­ре­делить при­чину не­дос­та­точ­ной про­из­во­дительнос­ти. Да­же ес­ли сис­те­ма ра­бота­ет ста­бильно и вы­пол­ня­ет­ся сог­ла­шение об уров­не пре­дос­тавле­ния сер­ви­са (Service Level Agreement — SLA), она все рав­но нуж­да­ет­ся в уп­режда­ющем мо­нито­рин­ге. Его ре­зульта­ты по­могут сок­ра­тить или пол­ностью ис­клю­чить прос­тои и свя­зан­ные с ним фи­нан­со­вые по­тери ком­па­нии. Эти дан­ные мож­но ис­пользо­вать и при мас­шта­биро­вании для на­ибо­лее эф­фектив­но­го ис­пользо­вания IT-бюд­же­та на за­куп­ку и мо­дер­ни­зацию ап­па­рат­ных средств. Ка­чес­твен­ный мо­нито­ринг поз­во­ля­ет вы­яв­лять не только уз­кие мес­та в сис­те­ме, но и тен­денции из­ме­нения про­из­во­дительнос­ти, а так­же найти но­вые пу­ти уве­личе­ния про­из­во­дительнос­ти на ра­бота­ющей сис­те­ме.
Ес­ли с БД ра­бота­ет нес­колько че­ловек, то не­из­менно воз­ни­ка­ет проб­ле­ма сов­мес­тно­го ис­пользо­вания дан­ных. Прос­тейшим при­мером этой проб­ле­мы яв­ля­ет­ся од­новре­мен­ная по­пыт­ка из­ме­нения од­ной и той же ин­форма­ции нес­кольки­ми пользо­вате­лями. Сис­те­ма уп­равле­ния ба­зами дан­ных дол­жна ре­шать, из­ме­нения ка­кого пользо­вате­ля дол­жны быть вы­пол­не­ны.
Та­ким об­ра­зом, воз­ни­ка­ет не­об­хо­димость пос­то­ян­но сле­дить за сос­то­яни­ем и ра­ботос­по­соб­ностью сер­ве­ра. Эту ра­боту вы­пол­ня­ет ад­ми­нис­тра­тор БД.