Այս կարճ գրառմամբ ես կցանկանայի ցրել մեկ թյուրիմացություն՝ կապված Oracle Exadata-ով աշխատող AWR տվյալների բազաների վերլուծության հետ: Գրեթե 10 տարի ես անընդհատ բախվում եմ հարցի հետ. ո՞րն է Exadata Software-ի ներդրումը արտադրողականության մեջ: Կամ օգտագործելով նոր ստեղծած բառերը. որքանո՞վ է «փորձագիտական» տվյալ տվյալների բազայի աշխատանքը:
Հաճախ այս ճիշտ հարցին, իմ կարծիքով, սխալ են պատասխանում՝ հղում կատարելով AWR վիճակագրությանը: Այն ներկայացնում է համակարգի սպասման մեթոդը, որը արձագանքման ժամանակը վերաբերվում է որպես պրոցեսորների (DB CPUs) գործառնական ժամանակի և տարբեր դասերի սպասման ժամանակի գումար:
Exadata-ի գալուստով AWR-ի վիճակագրությունում հայտնվեցին Exadata Software-ի շահագործման հետ կապված կոնկրետ համակարգի ակնկալիքներ: Որպես կանոն, նման սպասումների անվանումները սկսվում են «բջջ» բառով (Exadata Storage սերվերը կոչվում է բջիջ), որոնցից ամենատարածվածը սպասումներն են՝ «բջիջների խելացի աղյուսակի սկանավորում», «բջջային բազմաբլոկ» ինքնաբացատրվող անուններով։ ֆիզիկական ընթերցում» և «բջջային մեկ բլոկի ֆիզիկական ընթերցում»:
Շատ դեպքերում նման Exadata սպասումների մասնաբաժինը պատասխանի ընդհանուր ժամանակում փոքր է, և, հետևաբար, դրանք նույնիսկ չեն մտնում Top10 Առաջնային իրադարձությունները ըստ ընդհանուր սպասման ժամանակի բաժնում (այս դեպքում դուք պետք է որոնեք դրանք «Առաջին պլանում սպասեք»: Իրադարձություններ բաժինը): Մեծ դժվարությամբ մեր հաճախորդներից գտանք ամենօրյա AWR-ի օրինակ, որում Exadata-ի ակնկալիքները ներառված էին Top10 բաժնում և ընդհանուր առմամբ կազմում էին մոտ 5%:
իրադարձություն
Սպասում է
Սպասման ընդհանուր ժամանակը (վրկ)
Միջին սպասել
%DB ժամանակ
Սպասեք դաս
DB պրոցեսոր
115.2K
70.4
SQL*Net ավելի շատ տվյալներ dblink-ից
670,196
5471.5
8.16ms
3.3
Ցանց
բջջային մեկ բլոկի ֆիզիկական ընթերցում
5,661,452
3827.6
676.07 ԱՄՆ դոլար
2.3
Օգտատիրոջ մուտք/ելք
Համաժամացրեք ASM-ի վերաբալանսը
4,350,012
3481.3
800.30 ԱՄՆ դոլար
2.1
այլ
բջջային բազմաբլոկային ֆիզիկական ընթերցում
759,885
2252
2.96ms
1.4
Օգտատիրոջ մուտք/ելք
ուղիղ ուղի կարդալ
374,368
1811.3
4.84ms
1.1
Օգտատիրոջ մուտք/ելք
SQL*Net հաղորդագրություն dblink-ից
7,983
1725
216.08ms
1.1
Ցանց
բջջային խելացի սեղանի սկանավորում
1,007,520
1260.7
1.25ms
0.8
Օգտատիրոջ մուտք/ելք
ուղիղ ճանապարհի ընթերցման ջերմաստիճանը
520,211
808.4
1.55ms
0.5
Օգտատիրոջ մուտք/ելք
enq: TM - վիճաբանություն
652
795.8
1220.55ms
0.5
դիմում
Նման AWR վիճակագրությունից հաճախ արվում են հետևյալ եզրակացությունները.
1. Exadata magic-ի ներդրումը տվյալների բազայի աշխատանքի մեջ մեծ չէ. այն չի գերազանցում 5%-ը, և տվյալների բազան վատ է «էկզադատացվում»:
2. Եթե նման տվյալների բազան Exadata-ից տեղափոխվի դասական «սերվեր + զանգված» ճարտարապետության, ապա կատարողականը շատ չի փոխվի։ Քանի որ նույնիսկ եթե պարզվի, որ այս զանգվածը երեք անգամ ավելի դանդաղ է, քան Exadata պահեստավորման համակարգը (ինչը դժվար թե հնարավոր լինի ժամանակակից All Flash զանգվածների համար), ապա 5% -ը երեքով բազմապատկելով մենք ստանում ենք I/O սպասման մասնաբաժնի աճ մինչև 15%: - տվյալների բազան, անշուշտ, գոյատևելու է սա:
Այս երկու եզրակացությունները ճշգրիտ չեն, ավելին, դրանք խեղաթյուրում են Exadata Software-ի հիմքում ընկած գաղափարի ըմբռնումը: Exadata-ն ոչ միայն ապահովում է արագ մուտք/ելք, այլ սկզբունքորեն այլ կերպ է աշխատում՝ համեմատած դասական սերվերի + զանգվածի ճարտարապետության հետ: Եթե տվյալների բազայի գործողությունը իսկապես «էդադապտացված է», ապա SQL տրամաբանությունը փոխանցվում է պահեստավորման համակարգին: Պահպանման սերվերները մի շարք հատուկ մեխանիզմների շնորհիվ (առաջին հերթին Exadata Storage Indexes, բայց ոչ միայն) իրենք են գտնում անհրաժեշտ տվյալները և ուղարկում DB-ն սերվերներին: Նրանք դա անում են բավականին արդյունավետ, ուստի սովորական Exadata սպասումների մասնաբաժինը պատասխանի ընդհանուր ժամանակում փոքր է:
Ինչպե՞ս կփոխվի այս մասնաբաժինը Exadata-ից դուրս: Ինչպե՞ս դա կազդի տվյալների բազայի աշխատանքի վրա որպես ամբողջություն: Թեստավորումը լավագույնս կպատասխանի այս հարցերին: Օրինակ, Exadata-ից դուրս «բջջային սեղանի խելացի սկանավորման» սպասելը կարող է վերածվել այնպիսի ծանր սեղանի ամբողջական սկանավորման, որ I/O-ն խլում է պատասխանի ողջ ժամանակը, և կատարումը կտրուկ վատանում է: Այդ իսկ պատճառով սխալ է AWR-ն վերլուծելիս Exadata-ի ակնկալիքների ընդհանուր տոկոսը դիտարկել որպես դրա մոգության ներդրում կատարման մեջ, և առավել եւս օգտագործել այս տոկոսը՝ Exadata-ից դուրս կատարողականությունը կանխատեսելու համար: Հասկանալու համար, թե որքանով է «ճշգրիտ» տվյալների բազայի աշխատանքը, պետք է ուսումնասիրել «Instance Activity Stats» բաժնի AWR վիճակագրությունը (կան բազմաթիվ վիճակագրություններ ինքնաբացատրվող անուններով) և համեմատել դրանք միմյանց հետ:
Եվ հասկանալու համար, թե ինչպես կզգա Exadata-ից դուրս տվյալների բազան, ավելի լավ է տվյալների բազայի կլոնավորումը կատարել թիրախային ճարտարապետության կրկնօրինակից և վերլուծել այս կլոնի աշխատանքը ծանրաբեռնվածության տակ: Exadata-ի սեփականատերերը, որպես կանոն, ունեն այս հնարավորությունը։
Հեղինակ: Ալեքսեյ Ստրուչենկո, Jet Infosystems տվյալների բազայի բաժնի ղեկավար
Source: www.habr.com