Не позволявайте на потоците да ви заблуждават

Понякога конвенционалната мъдрост не е толкова конвенционална или често срещана. Като пример, администраторите на база данни могат да вярват, че пулът STREAMS е запазен стриктно за процеси на потоци. Това не е така, тъй като други помощни програми на Oracle, като Data Pump и GoldenGate, използват този пул. Разбира се изборът за използване на динамично управление автоматично ще разпредели необходимата памет при поискване, но тази памет трябва да идва отнякъде. Oracle ще „открадне“ това, от което се нуждае от буферния кеш, и няма да бъде заменен веднага. Нека разгледаме пример, доказващ това, като използваме Data Pump.

„Жертвата“ ще бъде база данни на Oracle 12.1.0.2, конфигурирана с streams_pool_size, зададен на 0 (тъй като Streams не е конфигуриран, очакването е, че пулът няма да се използва) и конфигурирано автоматично управление на споделена памет (параметрите sga_target и sga_max_size са зададени на различни от нула стойности):

SQL> --SQL> -- Пулът от потоци НЕ е само заSQL> -- StreamsSQL> --SQL> -- Data pump и GoldenGate и двете използватSQL> -- itSQL> --SQL> -- Не се задава размер за streamsSQL> -- пулът може да причини проблеми, когато еSQL> -- първо използванSQL> --SQL> --SQL> -- Разглеждане на параметрите на базата данниSQL> -- проверете sga parametersSQL> -- за sizingSQL> --SQL> показване на параметър sgaNAME TYPE VALUE ------------------------------------ -------- --- ------------------------------lock_sga boolean FALSEpre_page_sga boolean TRUEsga_max_size голямо цяло число 600Msga_target голямо цяло число 600Munified_audit_sga_queue_size цяло число 1048576

При проверка на изгледа V$SGA_DYNAMIC_COMPONENTS за компоненти с ненулеви текущи размери се връщат следните резултати:

SQL> SQL> формат на колона компонент a29SQL> задаване размер на линия 300 numwidth 12SQL> SQL> изберете компонент, current_size, min_size, max_size, user_specified_size user_spec_sz, 2 oper_count, last_oper_type, last_oper_time, last_oper_time, last_oper_mode, last_com dynamic_name от където_последен_oper_com> 0;COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE---------------------------- -------- ---- ------------ ------------ ------------ ---------- -- ------------- --------- --------- ------------------ общ басейн 176160768 146800640 176160768 0 6 ОТЛОЖЕНО РАЗВИВАНЕ 15-ОКТ-19 4194304голям басейн 8388608 8388608 125829120 0 1 ОТЛОЖЕНО СВИВАНЕ 15-ОКТ-19 41943041 java басейн 44943404 ST 44943404 44943404 4194304 Кеш на буфера по подразбиране 411041792 301989888 419430400 0 8 СВИВАНЕ ОТЛОЖЕНО 15-OCT-19 4194304Споделен IO пул 20971520 0 2CT1520 0 2CT11527 0 2CT11520 0 2011520 0 2011527 0 2011527 0 2015 01 2015 0 2015 0 2015 0 2015 0 2015 0 20 10 19 

 Проверка дали streams_pool_size е настроен на 0:
 
SQL> SQL> --SQL> -- Проверете, че пулът от потоци е настроен наSQL> -- 0SQL> --SQL> показване на параметър streamsNAME TYPE VALUE---------------- -------------------- ----------- -------------------- -----------streams_pool_size голямо цяло число 0SQL> 
 

 Експортирането на Data Pump се изпълнява и след това компонентите на динамичната памет се проверяват за размер:
 
SQL> SQL> --SQL> -- Стартирайте taskSQL за експортиране на помпа на данни> -- и вижте какво се случва с streamsSQL> -- pool sizeSQL> --SQL> !expdp parfile=expdp_test.parSQL> SQL> колона формат на компонент a29SQL> задаване на размер на линията 300 numwidth 12SQL> SQL> изберете компонент, текущ_размер, минимален_размер, максимален_размер, потребителски_специфичен_размер user_spec_sz, 2 oper_count, last_oper_type, last_oper_mode, last_oper_time, last_oper_time, last_oper_time, granule_size current_size_COM> granule_size_Size_COM OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE---------------------------- ------------ ---- -------- ------------ ------------ ------------ ------ ------- --------- --------- ------------споделен басейн 197132288 146800640 197132288 0 11 РАСТЕНЕ НЕЗАБАВНО 15 ОКТ- 19 4194304голям басейн 8388608 8388608 125829120 0 1 СВИВАНЕ ОТЛОЖЕНО 15-OCT-19 4194304java pool 4194304 4194304 4194304 0 0 STATIC 4194304streams pool 8388608 0 8388608 0 2 GROW IMMEDIATE 15-OCT-19 4194304DEFAULT buffer cache 381681664 301989888 419430400 0 15 SHRINK IMMEDIATE 15-OCT-19 4194304Shared IO Pool 20971520 0 20971520 0 1 НАРАСТВАНЕ НЕЗАБАВНО 15-OCT-19 Избрани са 41943046 реда.SQL> 
 

 Забележете, че размерът на кеша на буфера ПО ПОДРАЗБИРАНЕ беше намален до 381681664 от първоначална настройка от 411041792, отчасти за да помогне за „финансирането“ на пула от потоци. Тествайки тази идея, streams_pool_size е настроен на 8M (стойността, която Oracle я задава динамично) и, за да направят тестовете възможно най-равни, базата данни се изключва и стартира:
 
SQL> SQL> --SQL> -- Задаване на streams_pool_size на currentSQL> -- valueSQL> --SQL> -- Изключване и стартиране на базата данниSQL> --SQL> променете системния набор streams_pool_size=8M scope=spfile; System Alreter.sql> SQL> SUTLDOWN IMPATINEDATABASE Затворен.Датабаза Discounted.Oracle ENSTAND SUTWENT.SQL> Стартиране на инстанция на STARTUPORACLE. предварително> 

 Параметрите на динамичната памет, проверени за начални стойности:
 
SQL> SQL> --SQL> -- Проверете динамичното оразмеряване на компонентите SGA SQL> --SQL> формат на компонента на колоната a29SQL> задайте размер на реда 300 numwidth 12SQL> SQL> изберете компонент, текущ_размер, мин. размер, максимален размер, указан за потребителя_размер, потребителски2 спецификации_sz oper_count, last_oper_type, last_oper_mode, last_oper_time, granule_size 3 от v$sga_dynamic_components 4, където current_size> 0;COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_TYP LAST_OPER_TYP LAST_OPER_TYP LAST_LE-SIZE --------- ------------ ------------ ------------ ----- ------- ------------------ ------------- --------- --------- ------------споделен басейн 155189248 146800640 155189248 0 2 РАСТЕНЕ НЕЗАБАВНО 15-ОКТ-19 4194304голям басейн 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 4 4 4 43 190 4 4 43 190 4 0 0 Статичен 4194304Streams Pool 8388608 8388608 8388608 8388608 0 Static 4194304Default Buffer Cache 327155712 327155712 335544320 0 2 Свиване /rm /u01/app/oracle/admin/orcl/dpdump/scott.*
 

 Стартирайте отново заданието Data Pump с коригираните настройки на пула памет:
 
SQL> SQL> --SQL> -- Стартирайте taskSQL за експортиране на помпа на данни> -- и вижте какво се случва с streamsSQL> -- pool sizeSQL> --SQL> !expdp parfile=expdp_test.parSQL> SQL> колона формат на компонент a29SQL> задаване на размер на линията 300 numwidth 12SQL> SQL> изберете компонент, текущ_размер, минимален_размер, максимален_размер, потребителски_специфичен_размер user_spec_sz, 2 oper_count, last_oper_type, last_oper_mode, last_oper_time, last_oper_time, last_oper_time, granule_size current_size_COM> granule_size_Size_COM OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE---------------------------- ------------ ---- -------- ------------ ------------ ------------ ------ ------- --------- --------- ------------споделен басейн 197132288 146800640 197132288 0 12 РАСТЕНЕ НЕЗАБАВНО 15 ОКТ- 19 4194304голям басейн 8388608 8388608 125829120 0 1 СВИВАНЕ ОТЛОЖЕНО 15-OCT-19 4194304java pool 4194304 4194304 4194304 0 0 STATIC 4194304streams pool 8388608 8388608 8388608 8388608 0 STATIC 4194304DEFAULT buffer cache 381681664 264241152 381681664 0 14 GROW DEFERRED 15-OCT-19 4194304Shared IO Pool 20971520 0 20971520 0 1 GROW IMMEDIATE 15-OCT- Избрани са 19 41943046 реда.SQL> 
 

 Забележете, че буферният кеш по подразбиране е увеличен, а не намален, както в предишния пример. Никаква памет не беше „открадната“ от буферния кеш, така че производителността не пострада от динамичното преместване на ресурси. Възможен проблем със задаване на streams_pool_size на 0 може да бъде влошаване на производителността в момента, в който пулът от потоци е разпределен, тъй като буферният кеш претърпя свиване в същото време, когато пулът от потоци нараства. Това може да бъде особено забележимо в системи, където натоварването на потребителя е доста голямо като начало.
 

 Както бе споменато по-рано, GoldenGate също използва пула от потоци и поради тежката активност по записване в момента на стартиране на процеса на извличане, може да покаже евентуално тревожно влошаване на обслужването, което продължава, докато процесът на извличане завърши своите стартиращи дейности. [Други процеси, създадени от GoldenGate, допринасят за забавянето, като например синхронизиране на глобален регистрационен файл за изтриване на ангажираните данни в регистрационните файлове за повторно изпълнение.] Една система пострада толкова тежко, когато процесът на извличане беше стартиран, че влизанията в операционната система не бяха в състояние да завършат в предоставените време, което кара софтуера за наблюдение на трети страни да докладва, че базите данни, работещи на този сървър, вече не са налични. Задаването на streams_pool_size на стойност, различна от нула, допринесе значително за подобряването на общата производителност при стартиране на процесите на извличане.
 

 Общото знание може да бъде нож с две остриета; за всеки случай, в който общото знание е вярно, може да има един или повече случаи, в които не е така. Единственото истинско решение е да се тества такава „мъдрост“, за да се провери нейната точност. Далеч по-добре е да се въздейства на система за тестване, разработка или „пясъчница“ с такива изследвания, отколкото да приемаме такова „знание“ като „Евангелие“ само за да открием, че предположенията, на които се основава тази „мъдрост“, са погрешни. Да знаеш е по-добре, отколкото да гадаеш; малко време, прекарано в разследване, може да извлече огромни ползи, когато дойде време за внедряване на нов процес, включващ Oracle.
 
# # #
 

 Вижте статии от Дейвид Фицярел