Skip navigation

Кога базите данни предизвикват проблеми в мрежата

Networkworld България - брой 6, 2002 г. / Съдържание
706 прочитания, 0

Релационните СУБД могат да изядат жива вашата мрежа, но ако спазвате няколко основни правила, можете да държите пираните далеч от нея Когато разработчиците завършат създаването на ново приложение, те организират парти, а мрежовите администратори, подобно на Пепеляшка, нямат възможност да отидат. В повечето случаи екипът, поддържащ мрежата, не е имал думата при избора на системата за управление на бази данни (СУБД), не е получил от разработчиците точни отговори на въпросите, свързани с изискванията за мрежовия трафик, и няма възможност да покаже на ръководството на организацията какъв ефект има дадено приложение върху мрежовите ресурси. Въпреки всичко изброено именно този екип е отговорен за надеждността, свързаността и достъпността на приложенията. Един от най-честите проблеми на мрежовия администратор е мудното изпълнение на заявките. Всъщност поведението и бързодействието на релационната СУБД зависи от множество фактори – от сървъри и мрежова среда, от настройваеми параметри, от начина, по който са проектирани приложенията, и от това колко интензивно се използват. Освен това повечето СУБД работят върху различни ОС и машини. Множествата от фактори и платформи са доста сложни и взаимосвързани и ориентацията сред тях определено изисква високо ниво на компетентност и практически опит. Затова тук се съсредоточаваме върху въпроса в какви ситуации потребителите на 4 популярни СУБД (Oracle 9i, Sybase Adaptive Server Enterprise (ASE) 12.5, Microsoft SQL Server 2000 и IBM DB2 Universal Database 7.2) могат да имат проблеми, свързани с производителността на мрежата. От гледна точка на комуникациите нежелателните ситуации в поведението на базата данни са няколко: СУБД софтуерът монополизира процесора на сървъра; Употребява много време, за да получи достъп до диска или паметта; Претоварва мрежовите карти на сървъра; Генерира мрежов трафик значително повече от колкото е редно. Започнете с правилната конфигурация Мрежовите специалисти трябва да следят как администраторът на базата данни конфигурира софтуера, особено когато става дума за първоначалното ползване на ново приложение. В много случаи когато се следват точно ръководствата, предоставяни от доставчиците, лесно може да създаде сървър, претоварващ мрежовите ресурси. И четирите продукта обаче дават възможност за контрол на границите, в които може да се ползва процесорно време, памет, дисково пространство и даже мрежови адаптери. Настройките са свързани с модификация на параметрите за брой и характеристики на сървърните процеси. Сървърът за бази данни на Oracle ползва параметрите, зададени от администраторът, за да създаде и изпълнява множество процеси за получаване и разпределяне на SQL заявки. Софтуерът включва един или повече разпределителни модула, които да следят за SQL*Net заявки от клиентите на базата данни. Обикновено всеки такъв модул транспортира SQL*Net трафик за около 10 потребители. Ако настройките са такива, че се включват недостатъчно разпределителни модули, постъпващите заявки чакат на опашка, докато им дойде ред да бъдат обработени. От друга срана, ако трафикът на транзакциите е висок и системата включи прекалено много разпределители, може да се получи претоварване на паметта или да се монополизира процесорът на сървъра. Възможностите за управление на сървърните процеси при MS SQL Server са аналогични. ASE и DB2 са в известен смисъл по-ограничени що се отнася до консумацията на CPU и памет, но и при тези продукти не е изключено процесорът и паметта да бъдат пренатоварени, ако администраторът не настрои базата данни правилно. Използвайте средствата за мониторинг При инсталация върху Windows NT Server или върху Windows 2000 Server, Oracle и MS SQL Server добавят компоненти за наблюдение на производителността към вградените в средства Microsoft Management Console. С тяхна помощ може да се получи доста подробна картина за поведението на сървъра за бази данни. Ако програмата за наблюдение на производителността дава индикации, че базата данни консумира прекалено много процесорно време, това не значи, че веднага трябва да замените сървъра с по-бърз или да добавите още процесори. Администраторът може да настрои системата, като редуцира максималния брой на едновременно изпълняваните от клиентски машини процеси. След това проверете производителността на клиентските станции и новите стойности за параметрите, отразяващи натовареността на процесора, на мрежовия адаптер, честотата на обръщенията към диска и т.н. Ако не забележите подобрения, продължавайте с настройките. Може да се окаже, че SQL заявките, включени в приложението са прекалено сложни. И в четирите СУБД, които разглеждаме, са вградени интелигентни SQL компилатори, които интерпретират и оптимизират получаваните заявки, обаче преобразуването на някои текстови (SQL) команди в поредица от действия за извличане на записи и обновяване на базата данни, в някои случаи може да затрудни и най-добре написания компилатор. По подобен начин анализирайте и използването на сървърната памет и проверете дали тя се ползва ефективно. За да осигурят по-добро бързодействие, 4-те популярни СУБД съхраняват в оперативната памет копия на данните, които клиентите извличат или съхраняват на диска. Така се избягва относително бавният достъп до физическите носители на информацията. Добавянето на оперативна памет може да подобри значително производителността на сървъра, но и настройката на swap (paging) файла може да има значителен ефект. За да си обясните защо е така, можете да си представите базата данни като изключително обемиста папка, която има 2 копия на диска – едното съхранява данните като редове и колони, а в другото (в paging файла) те са представени чрез байтове. Когато клиентът обнови даден ред, сървърът трябва да запише данните на диска два пъти – по веднъж за всеки от тези формати. Мрежовият трафик Ако вашите средства за наблюдение на производителността констатират прекалена натовареност на мрежовия адаптер или съответните анализатори на протоколи установят прекомерно използване на мрежата, това може да означава, че приложението не е добре проектирано, че има тясно място в мрежата или че са налице други проблеми. За предаване на SQL команди до сървъра за бази данни SQL Server и ASE ползват протокола TDS (Tabular Data Stream), a Oracle разчита на своя TNS (Transparent Network Substrate). Повечето средства за анализ на протоколи декодират TDS и TNS, а някои осигуряват и поддръжка за SQL транспортния протокол на DB2. Интересното е, че ако се заемете с анализ на трафика, ще установите, че SQL заявките за всички разглеждани тук СУБД са доста различни. Пакетите, съдържащи SQL, се отличават от останалия мрежов трафик. Силно натоварване на мрежата може да се получи когато клиентската част на приложението извлича голямо количество записи, прилагайки към тях селекционни критерии и филтриране. Например, ако от клиентската машина програма на Visual Basic генерира SQL заявка за извличане на повече от няколко реда от базата данни, се получава значителен трафик. T-1 или по-бавна WAN се превръща в тясно място за такова приложение. Понякога проблемът с натоварването на мрежата не може да се реши само с добавяне на честотен канал. Настройката на самото приложение и програмното му усъвършенстване от гледна точка на по-пестеливото използване на мрежата е по-добрият подход. Администраторите на мрежата и на базата данни могат да направят някои настройки, но с това няма да разтоварят мрежата в степен, в която това могат да постигнат приложните програмисти. Разумното ползване на средствата за наблюдение на производителността на сървъра и на анализаторите за протоколи е едновременно изкуство и наука. За да осигурите безпроблемната работа на вашата корпоративна мрежа, трябва да овладеете това изкуство и да работите в тясно сътрудничество с администраторите на базата данни и с разработчиците на приложенията. Решения на проблеми, свързани с производителността

Проблем Възможни решения
Недостиг на процесорни ресурси Настройте системата за управление на БД Анализирайте сложността на SQL заявките Сменете сървъра с по-бърз.
Недостиг на памет на сървъра Настройте системата за управление на БД Добавете памет Настройте размера на paging файловете.
Претоварване на сървърния харддиск Разпределете БД файловете в няколко диска Анализирайте сложността на SQL заявките
Претоварване на мрежовия адаптер и мрежовия трафик Оптимизирайте приложенията Настройте системата за управление на БД Добавете честотен канал
(07.12.2002)

КОМЕНТАРИ

Трябва да сте регистриран потребител, за да коментирате статията
"Кога базите данни предизвикват проблеми в мрежата "



    

© Ай Си Ти Медиа ЕООД 1997 - 2012 съгласно общи условия за ползване