Ръководство за потребителя


Пул за връзки

DB2 Connect Enterprise Edition сървърите често осигуряват възможност за свързване към базата данни на хиляди едновременни заявки от клиенти. Установяването и прекъсването на свързванията към сървъра на базата данни може да е процес, за който са необходими много ресурси и неблагоприятно влияе върху производителността на сървъра на базата данни и DB2 Connect сървъра. Това е особено очевидно в web обкръжение, където всяко посещение на web страница може да изисква изграждането на ново свързване към сървъра на базата данни, изпълняване на запитване и прекратяване на свързването. За да се намали това натоварване, DB2 Connect Enterprise Edition използва пул за връзки, с който поддържа отворените връзки към базата данни в лесно достъпен пул.

Как работи пулът за връзките

Пулът за връзките е прозрачен за приложенията, които се свързват към хоста чрез DB2 Connect. Когато приложение заяви прекъсване на връзката към хоста, DB2 Connect прекъсва входящата връзка с приложението, но запазва в пул изходящата връзка към хоста. Когато ново приложение заяви свързване, DB2 Connect използва една от връзките в съществуващия пул. Използването на вече установена връзка намалява общото време за свързване, както и високото натоварване на процесора при свързване към хоста.

За да се използва пул за връзки, трябва да се приложи следния APAR върху DB2 за OS/390 версия 6.1:

     APAR PQ33473

DB2 Connect агентите може да са в едно от следните две състояния: свободно или активно. Агент е активен, когато изпълнява работа за приложение. След като приключи тази работа, агентът преминава в състояние свободно, като чака по-нататъшна работа от същото или друго приложение. Всички свободни агенти се пазят заедно в така наречения пул на свободни агенти. Можете да конфигурирате размера на този пул с помощта на конфигурационния параметър NUM_POOLAGENTS. Този параметър е равен на максималния брой свободни агенти, които искате да се поддържат от системата. Ако определите този параметър да е нула, това е равносилно на изключване на функцията за пул за връзки.

DB2 Connect не установява свързване към базата данни, преди да получи първата заявка от отдалечен клиент. Независимо от това ако искате, можете да попълните пула от свободните агенти, преди някой клиент да отправи заявка. Пулът може да се запълни при стартирането с помощта на конфигурационния параметър NUM_INITAGENTS. Този параметър определя колко свободни агенти трябва да се създадат при стартирането. Тези свободни агенти първоначално няма да имат свързвания към хост сървъра на базата данни.

Когато клиент заяви свързване към хоста, DB2 Connect ще опита да вземе агент сред тези в пула, които имат връзка към хост сървъра на базата данни. Ако не успее, ще се опита да намери достъпен агент в пула със свободни агенти. Ако пулът е празен, DB2 Connect ще създаде нов агент.

Можете да контролирате максималния брой агенти, които може да са едновременно активни, с помощта на конфигурационния параметър MAX_COORDAGENTS. Ако се надвиши този брой, новите свързвания няма да се изпълнят, а ще се върне грешка с код sqlcode SQL1226. (Този код означава, че е надвишен максималният брой на едновременните изходящи свързвания.)

DB2 регистърната променлива DB2CONNECT_IN_APP_PROCESS позволява на приложенията, които работят на същата машина, като DB2 Connect EE да накарат DB2 Connect да работи в рамките на процеса на приложенията, поведение по подразбиране, или приложението да трябва да се свързва към DB2 Connect EE сървър и след това свързването към хост да се изпълни в рамките на агент. За да може приложение да използва пул за връзки, свързването към хоста трябва да се направи вътре от агенти на DB2 Connect EE сървър и така DB2CONNECT_IN_APP_PROCESS трябва да се установи на NO.

DB2 Connect концентратор за връзки

Технологията на DB2 Connect концентратор на връзки позволява на DB2 Connect Enterprise Edition сървърите да осигурят поддръжка на хиляди потребители, които едновременно изпълняват бизнес транзакции, като драстично намалява ресурсите, необходими за S/390 хоста или AS/400 сървъра на базата данни. Изпълнява тази задача, като концентрира натоварването от всички приложения в много по-малък брой свързвания към S/390 хост или AS/400 сървър на базата данни. Въпреки че този начин може да изглежда подобен на функцията на пул за връзки, описан горе, на практика е много по-усъвършенстван подход за намаляване консумирането на ресурси за много голям обем OLTP (On-line Transaction Processing) приложения.

Пулът на връзките спестява разходите по установяване на свързване, когато връзката повече не е необходима за приложение, което е приключило. С други думи едно приложение трябва да се откачи, за да може друго да използва запазеното в пул свързване.

Концентраторът на връзките от друга страна, позволява на DB2 Connect да направи свързването достъпно за приложение, веднага след като друго приложение е приключило с транзакция и не е необходимо другото приложение да се откачи. По същество свързването към сървър на базата данни и асоциираните хост и DB2 Connect ресурси се използват от приложение, само докато има активна транзакция. Веднага, след като транзакцията приключи, свързването и асоциираните ресурси са достъпни за използване от всяко друго приложение, което трябва да изпълни транзакция.

Как се реализира концентратор на връзки

В предишните версии на DB2 Connect всяко активно приложение имаше Engine Dispatchable Unit (EDU), който управляваше свързването към базата данни, както и всички заявки от приложения. Тази EDU обикновено се разглежда като агент координатор. Всеки агент координатор проследяваше състоянието или контекста на приложението и EDU. Всяка EDU заема значително количество памет, когато броя на свързванията се увеличи, а заради превключването на контекста между агентите се получава допълнително натоварване.

В горната архитектура има директна взаимовръзка един-към-един между свързванията и всяка EDU. Обаче концентраторът на връзките позволява взаимовръзка много-към-един между свързванията и EDU. Това означава, че отношението между свързванията (X) спрямо EDU (Y) сега е X >= Y.

Концентраторът на свързванията разделя агента на две части - логически агент и работещ агент. Логическите агенти представляват приложение, но без препратка към определена EDU. Логическият агент съдържа цялата информация и контролира блоковете, необходими за приложението. Ако има n приложения, свързани към сървъра, ще има n логически агенти на сървъра. Работещите агенти са физически EDU, които изпълняват заявки на приложения, но не са прикрепени постоянно към дадено приложение. Работещите агенти се асоциират към логически агенти, за да изпълнят транзакции и при приключване на транзакцията прекъсват асоциацията и се връщат към достъпния пул.

Модул, известен като планировчик на логически агенти присвоява работещи агенти на логически агенти. Ограничението по отношение на броя на указателите за отворени файлове на определени компютърни платформи може да наложи наличието на повече от един екземпляр на планировчика, когато броя на логическите агенти го надвиши.

Активиране на концентратора

За да се използва концентратор на връзки, трябва да се приложи следния APAR върху DB2 за OS/390 версия 6.1:

      APAR PQ33473

Конфигурационния параметър MAX_LOGICAGENTS на мениджъра на базата данни определя максималния брой логически агенти. Можете да активирате функцията на концентратор, като зададете за стойността на MAX_LOGICAGENTS число, по-голямо от стойността по подразбиране. Стойността по подразбиране за MAX_LOGICAGENTS е равна на стойността на MAX_COORDAGENTS. Тъй като всяко приложение ще има един логически агент, MAX_LOGICAGENTS на практика контролира броя на приложенията, които могат да се свържат към потребителския модел на базата данни, а MAX_COORDAGENTS контролира броя на входящите свързвания, които може да са активни в даден момент. MAX_LOGICAGENTS може да е число в обхвата от MAX_COORDAGENTS до 64 000. Броят по подразбиране на логическите агенти е равен на MAX_COORDAGENTS.

Редица съществуващи конфигурационни параметри се използват за конфигуриране на агенти. Тази параметри са както следва:

MAXAGENTS
Максималният брой работещи агенти.

MAX_COORDAGENTS
Максималният брой на активни агенти координатори.

NUM_POOLAGENTS
Размер на пула за агенти. Пулът за агенти включва неактивните агенти и свободните агенти.

NUM_INITAGENTS
Първоначалният брой на работещите агенти в пула. Това ще са свободните агенти.

Поддръжка на XA транзакции

Архитектурата на концентратора за връзки позволява на DB2 Connect да осигури тясно свързана поддръжка на XA транзакции за DB2 за OS/390 и DB2 за AS/400. Концентраторът ще асоциира работещ агент с определена XA транзакция (единичен XID), както би направил за всяка друга транзакция. Обаче ако XA транзакцията приключи с xa_end() (край на разклонение), работещият агент няма да се освободи в общия пул. Вместо това работещият агент остава асоцииран с тази определена XA транзакция. Когато друго приложение се присъедини към същата XA транзакция, работещият агент ще се прикрепи към това приложение.

Всяко обръщение за край на транзакция ще върне агента в пула. Например, командите xa_prepare() само за четене, xa_rollback(), xa_recover(), xa_forget(), xa_commit() или някоя XA грешка, която причинява отхвърляне на последните промени, ще върне агента в обикновения пул. Самият Xa_end() приключва само разклонението на транзакцията и това не е достатъчно за прекратяване на асоциирането с XID.

Примери

  1. Да разгледаме обкръжение, в което са необходими 4000 или повече едновременни свързвания. Web сървър, който използва CGI приложения или офис система с много настолни потребители може да надвишат това изискване. В тези случаи ефективността обикновено налага DB2 Connect да работи като отделен шлюз; това означава, че базата данни и DB2 Connect системата са на отделни машини.

    DB2 Connect сървърът може да няма възможност да обслужва 4000 едновременно отворени свързвания към машината на базата данни. В повечето случаи броят на транзакциите, които се изпълняват в даден момент ще бъде значително по-малък от броя на едновременните свързвания. Тогава системният администратор може да увеличи максимално ефективността на системата, като настрои конфигурационните параметри на базата данни, както следва:

         MAX_LOGICAGENTS =  4,000
         MAX_AGENTS      =  1,000
         MAX_COORDAGENTS =  1,000
         NUM_POOLAGENTS  =  1,000
    

    Концентраторът ще поддържа отворени максимално 4000 едновременни сесии, независимо, че в даден момент шлюзът може да управлява само 1000 транзакции.

  2. В горния пример работещите агенти непрекъснато ще образуват и прекъсват асоциации към логически агенти. Онези агенти, които не са свободни, може да поддържат свързване към базата данни, но не участват в някоя определена транзакция, и следователно са достъпни за всеки логически агент (приложение), който заяви свързване.

    Случаят с XA транзакциите е някак си различен. За този пример можете да приемете, че се използва TP монитор с DB2 Connect шлюз и OS/390 или AS/400 база данни. Когато приложение заяви свързване, концентраторът или ще превключи неактивен агент, за да обслужи тази заявка, или ще създаде нов работещ агент. Нека да приемем, че приложението е изпратило заявка за XA транзакция. Създава се XID за тази транзакция и се асоциира работещият агент.

    Когато заявката на приложението се обслужи, се генерира xa_end() и се откача от работещия агент. Работещият агент остава асоцииран с идентификатора XID на транзакцията. Сега може да обслужва заявки само за транзакции с неговия асоцииран XID.

    В този момент друго приложение може да направи заявка за транзакция, която не е XA. Дори ако няма други достъпни работещи агенти, агентът, асоцииран с XID, няма да е достъпен за второто приложение. Той се разглежда като активен. За второто приложение ще се създаде нов работещ агент. Когато това второ приложение приключи своята транзакция, неговия работещ агент се освобождава в достъпния пул.

    Междувременно други приложения, които са заявили транзакцията, асоциирана с XID на първия агент, може да са се закачали и откачали от този агент, който е изпълнявал заделената XA транзакция за тях. Всяко приложение, което изпрати заявка за тази определена транзакция, ще се изпрати на този работещ агент, ако е свободен.

    Работещият агент няма да се освободи в основния пул, докато приложение не генерира обръщение за приключване на транзакция (не xa_end()). Например, приложение може да приключи транзакция с xa_commit(), като в този момент работещият агент прекъсва асоциацията си с XID и се връща в достъпния пул. На този етап всяко приложение, което е изпратило заявка, може да го използва за транзакция, която е или не XA.

Ограничения

Има редица важни ограничения по отношение използването на концентратор на шлюз. Разгледайте следващата информация в нейната цялост, преди да се опитате да използвате концентратор за връзки във вашата система.

Настройка на базата данни

Производителността на системата ще зависи от производителността на базата данни на хоста или AS/400 сървъра на базата данни.

Различните системи за управление на базата данни имат различни характеристики по отношение на производителността. Например, SQL оптимизаторите на различните системи може да се държат различно с едно и също приложение. Повече информация за производителността потърсете в документацията за вашия хост или AS/400 сървър на база данни.

При DB2 Universal Database за AS/400 може да имате възможност да повишите производителността, като използвате опциите при свързване защита при четене на незаписани промени (UR - uncomitted read) или без записване на промените (NC - no commit), за да избегнете записването в журналите.

Забележка:Когато използвате UR, данните извън журнала могат само да се четат, но не и да се обновяват и то само ако параметърът за създаване на блокове е установен на ALL.

В зависимост от сървъра на приложения и степента на заключване, която осигурява, използваното ниво на изолация за запитването или приложението може да има значителен ефект върху производителността.

Базата данни трябва да има съответното ниво за нормализация, ефективно използване на индекси и подходящо заделяне на пространството на базата данни. Освен това производителността може да се повлияе от типовете данни, които използвате, както е описано в следващите раздели.

Настройка на DB2 за OS/390

OS/390 V1R3 е минималното изискване за TCP/IP поддръжка. OS/390 V2R5 или следващи се препоръчват.

Помощното средство за разпределени данни (DDF - Distributed Data Facility) отговаря за свързването на разпределените приложения към DB2 за OS/390. DDF трябва да се настрои като сървър на приложения. За да направите това, можете да вмъкнете LU името на отдалечената система в таблицата SYSIBM.LUNAMES или да вмъкнете стойностите LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT и USERNAMES в таблицата SYSIBM.SYSLUNAME. След това обновете DDF до Boot Strap Data Set (BSDS). Например:

   DDF LOCATION=LOC1,LUNAME=LU1,PORT=8000,RESPORT=8001

За да постигнете най-добра производителност, трябва да използвате препоръчваните приоритети в DDF адресното пространство (малко по-малко или равно на DBM1, ако сте в режим COMPAT). Използвайте RACF кеширане на оторизациите във VLF и ако можете използвайте V5 кеширане на оторизации за пакети. За повечето случаи е достатъчна стойността CACHEPAC=32768.

Тъй като DDF ще се опита да се свърже към VTAM, VTAM трябва да е активен при стартирането на DDF. Отдолу е представена примерна дефиниция на VTAM APPL:

   SYD51TC* APPL  AUTH=(ACQ),                                  X
              PARSESS=YES,                                     X
              HAVAIL=YES,                                      X
              EAS=1600,                                        X
              APPC=YES,                                        X
              DSESLIM=1024,                                    X
              DMINWNL=512,                                     X
              DMINWNR=512,                                     X
              AUTOSES=1,                                       X
              SECACPT=ALREADYV,                                X
              SRBEXIT=YES,                                     X
              SYNCLVL=SYNCPT,                                  X
              MODETAB=DB2MODET,                                X
              VPACING=63                                       X

Можете да оптимизирате обработката на неактивна нишка в OS/390. Във V3 е разрешено да има до 10 000 едновременно свързани клиенти, а във V4 и V5 до 25 000. Във всички случаи обаче, максималният брой на едновременно активните клиенти е 1999. Всеки клиент работна станция може да остане свързан, когато не е активен; неговата нишка се поставя в неактивна верига при всяко записване на промените.

DSNZPARM параметрите CMTSTAT, CONDBAT и MAXDBAT влияят върху обработката на нишките. За да постигнете най-добра производителност, установете CMTSTAT на INACTIVE, настройте CONDBAT на максималния брой свързани DBAT, при който се осигурява добра производителност, а MAXDBAT на максималната приемлива стойност от активни DBAT.

За пълно представяне на свързването на DB2 за OS/390 в DRDA мрежа, включително конфигурирането на VTAM, се обърнете към Приложение за свързваемост.

Преобразуване на данни

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

Разгледайте следните платформи:

и следните типове числени данни:

Таблица 8 показва кога се изпълнява преобразуване.

Таблица 8. Преобразуване на данни

 


Intel


IEEE


S/370 & S/390


OS/400


Packed decimal data


Intel
IEEE
S/370/390
OS/400


Не
Не
Не
Не


Не
Не
Не
Не


Не
Не
Не
Не


Не
Не
Не
Не


Zoned decimal data


Intel
IEEE
S/370/390
OS/400


Не
Не
Да
Да


Не
Не
Да
Да


Да
Да
Не
Не


Да
Да
Не
Не


Integer data


Intel
IEEE
S/370/390
OS/400


Не
Да
Да
Да


Да
Не
Не
Не


Да
Не
Не
Не


Да
Не
Не
Не


Данни плаваща запетая


Intel
IEEE
S/370/390
OS/400


Не
Да
Да
Да


Да
Не
Да
Не


Да
Да
Не
Да


Да
Не
Да
Не

Натоварването на процесора при преобразуването на еднобайтови символни данни е като цяло по-малко, отколкото при преобразуването на числени данни (където е необходимо преобразуване на данните).

Натоварването при преобразуване на данни от тип DATE/TIME/TIMESTAMP е почти същото, както при еднобайтови CHAR. Най-голямо е натоварването при преобразуване на данни от тип FLOATING (плаваща запетая). При проектирането на приложението разработчикът може да пожелае да се възползва от тези факти, когато проектира приложение, базирано на DB2 Connect.

Ако таблица в база данни има колона, дефинирана като 'FOR BIT DATA', няма да изискват никакво преобразуване данните символи, които се прехвърлят между приложението и базата данни. Това може да се използва, когато архивирате данни на хоста или AS/400 сървъра на базата данни.

Типове символни данни

Символните данни могат да са с тип CHAR или VARCHAR. Кой тип данни е по-ефективен, зависи от типичната дължина на данните в полето:

Мрежови настройки

Най-добрият начин да се повиши общата производителност в обкръжение на разпределена база данни, е да се отстранят забавянията от мрежата. Обичайно е за мрежовите администратори, да обмислят как мрежата да стане по-ефективна, като събират колкото е възможно повече данни между прехвърлянията. Този подход не работи за приложения, като разпределени бази данни, защото генерира забавяния в мрежата. Крайният потребител не вижда ефективността на мрежата, а само забавянията.

Повечето мрежови устройства имат параметри за забавяне и повечето от тях имат стойности по подразбиране, които са много неподходящи за разпределени бази данни. За да се повиши производителността, трябва да намерите тези параметри и ако е възможно, да ги установите на нула. Освен това трябва да се уверите, че размерът на буфера на устройството е достатъчно голям, за да предотврати повторни прехвърляния поради загуба на данни. Например, UNIX системите обикновено приемат по подразбиране стойност от 32 за размер на опашката за прехвърляне и получаване. За да постигнете по-добри резултати, определете размерът на опашката да е 150. Съответния параметър при DLC настройките е Receive Depth, който също трябва да е 150.

Параметърът IOBUF има прекалено ниска стойност на повечето сайтове. Обикновено е 500, но опитът е показал, че стойността 3992 работи най-добре, ако премествате големи количества данни, особено за канални свързвания като ESCON или 3172.

При SNA свързвания трябва да определите параметъра Mode Profile на софтуера на всяка работна станция да е 63. Като цяло стойностите за стъпката при получаване в рамките на мрежата трябва да са установени на техните най-големи стойности, така че параметрите VPACING и PACING на оператора DB2 APPL и PU/LU за работната станция при превключен основен режим трябва също да се установят на 63. Така ще може прогресивно да се увеличава количеството на потоците съобщения, преди изпращача да трябва да чака за отговор.

При LAN система размерите на прозорците DLC или LLC предаване и получаване може да имат значителен ефект върху производителността. Стойността за изпращане трябва да е установена на седем или повече, а при повечето конфигурации стойност за получаване от четири или по-малко работи най-добре.

Ако използвате Ethernet, трябва да определите размера на TCP сегмента на 1500 байта. При token ring или FDDI мрежа тази стойност трябва да е 4400 байта, а ако използвате ESCON адаптер с TCP/IP, размерът на сегмента трябва винаги да е 4096.

Накрая за TCP/IP мрежи размерите на буфера за изпращане и получаване трябва да са определени на повече от 32768. Като цяло стойността от 65536 е най-добра.
Забележка:Установяването на свързване от шлюза към сървъра (изходящо свързване) е много по-скъпо от установяването на свързване от клиент към шлюз (входящо свързване). В среда, в която хиляди клиенти често се свързват и прекъсват връзката от сървъра чрез шлюза, се отделя значителна част от времето за обработка при установяване на изходящи свързвания. DB2 Connect осигурява пул за връзки през TCP/IP. Когато клиент заяви прекъсване на свързването към сървъра, шлюзът прекъсва входящата връзка с клиента, но запазва в пул изходящата връзка към сървъра. Когато нов клиент пристигне в шлюза, за да заяви свързване, шлюзът осигурява съществуваща връзка от пула, като така намалява общото време за свързване и спестява голямото натоварване на процесора върху сървъра.

Допълнителна информация за създаването на пул за връзки под DB2 потърсете в Ръководство за администриране.

Обобщение на методите за настройка на мрежовата производителност е представено в следващата таблица.
Какво да се търси Пример Настройка Забележки
Съзнателни забавяния Параметри за забавяне на мрежови устройства Установени на 0. Стойностите по подразбиране обикновено са по-високи.
Буфери IOBUF параметър Установен на 3992. Особено полезно при ESCON или друг канален адаптер.
RUSIZE Оптимален размер - 4096. Може да се получи най-добра производителност, ако се определи един и същи размер за RUSIZE и RQRIOBLK.
Стъпка VPACING, PACING и Mode Profiles трябва да се установят на 63. Използвайте адаптивна стъпка, където е приложимо
Настройки на адаптер Размер на опашка Предаване/Получаване Препоръчваната стойност е 150 По подразбиране обикновено е 32.
DLC прозорци в SNA Определете висок размер за предаване (>7). Определете нисък размер на прозорец за получаване (например 1), тествайте и увеличете последователно, за да намерите идеалната стойност. Всяко логическо устройство добавя забавяне. Опростете колкото се може повече мрежовата топология.
TCP настройки Размери на сегменти 1500 в Ethernet, 4400 в token ring и FDDI. ESCON адаптерите, използвани за TCP/IP трябва винаги да се установяват на 4096.
Размери на пространства за Изпращане/Получаване Трябва да е 64K и за двете. По подразбиране е само 8192 при Windows. Може да се установи в Windows регистъра.

Мрежов хардуер

Следните съображения се отнасят за хардуера:

Конкурентно използване на системните ресурси

Производителността може да се влоши, ако много задачи в системата се борят за системните ресурси. Разгледайте следните въпроси:

Отстраняване на проблеми, свързани с производителността

Ако потребители на DB2 Connect се сблъскват с дълги времена за отговор при големи запитвания от хост или AS/400 сървъри, следните области трябва да се проверят за възможна причина на проблема с производителността:

  1. При запитвания, които в резултат връщат големи блокове с данни от хоста или AS/400 сървъра (обикновено 32K данни или повече), се уверете, че конфигурационният параметър RQRIOBLK на мениджъра на базата данни е установен на 32767. Това може да се направи с помощта на процесора за обработка на команди (CLP), както е посочено:
       db2 update database manager configuration using RQRIOBLK 32767
    
  2. Ако се използва VTAM при свързването към хоста или AS/400 сървъра, погледнете под конфигурацията "превключен основен режим" за стойността на параметъра PACING. На DB2 Connect работна станция проверете комуникационната настройка на "LU 6.2 Mоde Profile" за дефиницията на режим IBMRDB. В тази дефиниция се уверете, че стойността за параметъра "Receive pacing window" е по-малка или равна на стойността PACING, дефинирана във VTAM. Разпространена стойност за "Receive pacing window" при DB2 Connect работна станция и "PACING" на VTAM е 8.
  3. Уверете се, че максималният размер на RU, определен в дефиницията на IBMRDB режим, е установен на подходяща стойност. Препоръчваме не по-малко от 4K при свързване с помощта на Token-ring хардуер. При свързвания с помощта на Ethernet хардуер отбележете максималния размер на Еthernet фрейм от 1536 байта, който може да е ограничаващ фактор.
  4. Консултирайте се с VTAM администратора във вашето обкръжение, за да се уверите, че VTAM използва "адаптивна стъпка" в LU-LU сесии с вашата DB2 Connect работна станция.


[ Начало на страницата | Предишна страница | Следваща страница ]