Database performance сайжруулах

Rdn · November 11, 2021, 12:43pm

Hi
oracle single node database руу нэг агшинд 50-200 session тогтмол хандалттай байгаа. хааяа том query ажилахаар бусад session доо нөлөөлөөд бааз тэр чигтээ удаашираад байх юм.
sql tuning хийгээд хэсэг сайжираад хэд хоноод дахиад л давтагдаад болдоггүй.
db -г хувилах ч юмуу өөр ямар нэг шийдэл хэрэг болоод…

rac -р энэ асуудалыг шийдэж чадах болуу
эсвэл өөр архитектийн гоё шийдэл санал болгооч мастеруудаа

db oracle 12c EE
cpu 18 core
data 300G
sga_max_size 79616M
sga_target 79616M
pga_aggregate_limit 25724M
pga_aggregate_target 12862M

os oracle linux 7 memory 128G

цаашид session count 100-300 болох хандлагатай байгаа юм.

bayaraa · November 11, 2021, 3:48pm

Hi

Bgaa medeellees harahad 300gb hemjeetei geheer dajgvi tom baaz bh shig bn. Her udaan tsuglasan data ve? Sql tunning hiigeed udahgvi dahiad udaad bn geheer optimizer.n ajillagaa tm amarhan hotsrogdood bmaargvi yumdaa.

Sql tunning hiihdee yaj hj bgaa ve? Index nemeed bnuu?
Ter tom query.niihee sql execution planiig yvuulah bolomjtoi yu query.tei n tsug?

Sql.ee zasaad bolchihmoor yum shig sanagdaad bn.

Vneheer uur shiidel haij bgaa bol dr db vvsgeed ter tom query ajluuldag connectionoo shine baazruugaa zaachihsan n dr sanagdaj bn.
RAC bolloo gd aihtar saijraad bhgvi l bh. Tsaashid session tasraltgvi nemegdeh bol RAC bolgooroi.
Deerh nemelt medeellvvdiig yvuulchihval arai todorhoi medeelel ugch boloh bh.

Aan tm PGA target.aa limittei n ijil bolgochihooroi. SGA PGA haritsaa n arai zorvvtei bn.

Amjilt

ulambayar · November 12, 2021, 4:51am

Oracle-д хуварилсан RAM 100GB байгаа тохиолдолд active session 50-200 байгаа бол хандалт хангалттай бага байна гэж үзэхээр байна. Баазыг restart хийсний дараа үйл ажиллагаа мэдэгдэхүйц сайжирч байна уу гэдгийг хараарай. Хэрэв энэ тохиолдолд өөрчлөлт гарч байвал Memory хуваарилалт дээр ажиллах хэрэгтэй. Өөрчлөлт мэдрэгдэхгүй бол Script талд ажиллах нь. Мөн мониторинг сервертэй бол CPU болон RAM ийн гарфик гаргаад хараарай. Боломжтой бол 24 цагийн AWR хавсаргаарай. administration талын асуудал биш л бол RAC тай болсон ч чанарын ялгаа гарахгүй шүү.

Rdn · November 12, 2021, 6:04am

db restart хийсний дараа хэвийн байгаа сайжирсан эсвэл удааширсан гэсэн юм бараг мэдэгдэхгүй хэвэндээ байгаан.
ер нь query талдаа асуудал байгаан болуу гээд нилээн үзлээ.

жишээ нь a,b query байлаа
a query 300 000 row дататай ажиллана. буцаах row нь 80 000
b query 30 сая row дататай ажиллана. буцаах row нь 300 000

a query 5 мин ажиллаж байсан. sql tuning хийж сайжруулаад 2-3 sec ажилладаг болсон.
b query хэр их хэмжээний дата ухахаас шалтгаалаад 3sec-10 минут хүртэл ажилладаг. жишээ нь 1 өдрийн дата ухвал 3-4 sec жилээр хайвал table full scan хийгээд 10 мин болоод байгаа гэсэн үг.

b -тэй ойролцоо query 20 орчим байгаа. Энэ query ээс зэрэг юмуу эсвэл full scan хийх үед а query 5минут орчим ажиллах эсвэл бүр үр дүн буцаахгүй тохиолдол гараад байгаан. db тэр чигээрээ удаашраад байгаа гэж ойлгож болно.

иимэрхүү л юм болоод байгаан хө

сүүлийн 24 цагын AWR

Rdn · November 12, 2021, 7:55am

Жишээ нь энэ plan гаргаж байгаа query энгийн үедээ 1 сек болоод db ачаалах үед 50 сек орчим болоод байгаан

Plan hash value: 2051067756

| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |

| 0 | SELECT STATEMENT | | 9278 | 3588K| | 16733 (1)| 00:00:01 |
| 1 | SORT GROUP BY | | 9278 | 3588K| 14M| 16733 (1)| 00:00:01 |
|* 2 | HASH JOIN | | 37747 | 14M| | 15106 (1)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | SYS_C0023051 | 8 | 184 | | 2 (0)| 00:00:01 |
|* 4 | HASH JOIN | | 168K| 59M| | 15103 (1)| 00:00:01 |
|* 5 | TABLE ACCESS FULL | COD_CATMST | 2173 | 197K| | 14 (0)| 00:00:01 |
|* 6 | HASH JOIN RIGHT OUTER | | 97838 | 26M| | 15089 (1)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID BATCHED| STK_SKUDDTBL | 29037 | 1162K| | 7862 (1)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | SYS_C0034886 | 31631 | | | 180 (0)| 00:00:01 |
|* 9 | HASH JOIN RIGHT OUTER | | 96943 | 22M| | 7227 (1)| 00:00:01 |
|* 10 | TABLE ACCESS FULL | INV_INVCDSKUTBL | 17812 | 487K| | 2740 (1)| 00:00:01 |
|* 11 | HASH JOIN | | 96524 | 19M| 10M| 4486 (1)| 00:00:01 |
|* 12 | HASH JOIN | | 96524 | 9426K| | 1004 (1)| 00:00:01 |
|* 13 | MAT_VIEW ACCESS FULL | MVIEW_CTRCD | 1673 | 95361 | | 8 (0)| 00:00:01 |
|* 14 | MAT_VIEW ACCESS FULL | MVIEW_SKUJUM2 | 96524 | 4053K| | 996 (1)| 00:00:01 |
| 15 | MAT_VIEW ACCESS FULL | MVIEW_SKUCD2 | 248K| 26M| | 1521 (1)| 00:00:01 |

өөрийн чинь хэлсэнээр уншихдаа standby баазаас бичихдээ primary db тэй ажиллах шийдэл судлаад үзье
эхний ээлжинд db logic тал руугаа нилээн анхаарсын. Үр дүн гарч байгаа боловч гэнэт л ачаалаад эхлээд байхаар шийдэл сонирхсон юмаа.

ulambayar · November 12, 2021, 8:28am

дээрх SS хараад мэдэгдэх юм алга. Тоад-с харж байгаагүй юм байна. Top event дээр байгаа мэдээллээс харахад full access их хийдэг бололтой. Магадгүй Disk унших, бичих хурд бага байж магадгүй юм. Учир нь “db file sequential read” өндөр байна гэдэг нь buffer cache дээр ачаалал их өгч байгаа гэсэн үг. Tuning сайн хийх хэрэгтэй юм байнадаа.

bayaraa · November 12, 2021, 8:52am

За ямар ч байсан удаан ажиллаж байгаа хэд хэдэн шалтгаан байж болохоор байна.

Mat view болон таблерүүгээ.rvvgee full access хийж байна.
Hashjoin хийгээд байна. /шууд resource их ашиглах шалтаг/

Табле болон MVIEW-рүүгээ Full access хийгээд тэгээд Hash join ашиглаж байгаа нь ачааллыг нэмэгдүүлэх нь аргагүйдээ.

SQL-ээ л сайн сайжруулах хэрэгтэй дээ. MVIEW дээрээ index үүсгэж үзэх юм уу?
ер нь ямархуу филтерүүд ашиглаж байгаа вэ?
Заавал full access хийх шаардлагатай юу?
Хэрэв тийм бол parallel option ашиглаад үзвэл яадаг бол? мэдээж сөрөг талтай шүү.

Кодчилол тал дээрээ хугацаанаас хамаараад ялгаатай query ажилладаг байдлаар шийдчихэж болохоор байж магадгүй харагдаж байна шүү. Зүгээр санал болгож байна. Бодитоор харж мэдрэхгүй байгаа болохоор ийм л мэдээлэл байнадаа.

Rdn · November 12, 2021, 12:40pm

filter үүдийн хувьд ихэнхдээ 5-10 орчим парамтерээр хийдэг.
mview_ctrcd 1500 row 320K хэмжээтэй
mview_skucd2 250000 row 70M хэмжээтэй
mview_skujum2 580000 row 40M хэмжээтэй

mview дээр болхоор index үүсгэсэн ч гэсэн олон параметрээр хайдаг болхоор full scan хийгээд хийгдээд, бас full access хийж байгаа ч table үүд нь жижиг болхоор удаасан гэж дүгнэхгүй байгаа.
хэдэн сая мөртэй table үүд join хийгдгийн хажууд асар жижигдээ орно биз дээ :))

Хамгийн гол нь энгийн үедээ 1 sec ажиллаад db ачааллахаар удаан болоод байгаан query дээ биш өөр шалтгаан байнуу гээд. /тохиргоо ч юмуу/

удааширсан үед нь яаж шалгаж шалтгааныг л олох болох вэ?

баярлалаа

bayaraa · November 13, 2021, 5:08am

Дээрх планаас харахад 3 MVIEW-ийн хоорондох HASHJOIN-с эхлээд л ачаалал үүсч эхэлсэн байна. тэгээд дээр COD_CATMST табле-тэй бас HASHJOIN хийгээд л алаад байх шиг байнадаа.
Group хийж байгаа хэсгийг бүүр гадна биш тухайн табле эсвэл MVIEW дээр хийж болохгүй юу? хэхэ. QUERY-гээ PM-р явуулаач. Сонирхолтой санагдчихлаа.