د دې لنډ پوسټ سره زه غواړم د AWR ډیټابیسونو تحلیل پورې اړوند یو غلط فهم له مینځه یوسم چې په Oracle Exadata کې روان دي. د نږدې 10 کلونو لپاره ، زه په دوامداره توګه د دې پوښتنې سره مخ شوی یم: په تولید کې د Exadata سافټویر ونډه څه ده؟ یا د نوي جوړ شوي ټکي په کارولو سره: د یو ځانګړي ډیټابیس کار څنګه "کارپوه" دی؟
ډیری وختونه دا سمه پوښتنه، زما په نظر، د AWR احصایې په حواله په غلط ډول ځواب شوي. دا د سیسټم انتظار طریقه وړاندې کوي، کوم چې د غبرګون وخت د پروسیسرونو عملیاتي وخت (DB CPUs) او د مختلفو ټولګیو انتظار وخت په توګه چلند کوي.
د Exadata په راتګ سره، د Exadata سافټویر عملیاتو پورې اړوند ځانګړي سیسټم تمې د AWR احصایو کې څرګندې شوې. د یوې قاعدې په توګه، د داسې انتظارونو نومونه د "سیل" کلمې سره پیل کیږي (د Exadata ذخیره کولو سرور د سیل په نوم یادیږي)، چې تر ټولو عام یې د ځان توضیحي نومونو "د سیل سمارټ میز سکین"، "د سیل ملټي بلاک" سره انتظار کوي. فزیکي لوستل" او "د حجرې واحد بلاک فزیکي لوستل".
په ډیری حاالتو کې، د ځواب په ټول وخت کې د ورته Exadata د انتظار برخه لږه ده، او له همدې امله دوی حتی د ټول انتظار وخت برخې لخوا په غوره 10 مخکینۍ پیښو کې نه راځي (په دې حالت کې، تاسو اړتیا لرئ چې په مخکینۍ انتظار کې یې وګورئ. د پیښو برخه). په لوی مشکل سره، موږ د خپلو پیرودونکو څخه د ورځني AWR یوه بیلګه وموندله، په کوم کې چې د Exadata توقعات په Top10 برخه کې شامل شوي او په ټولیز ډول شاوخوا 5٪ ته رسیدلي:
دکمپاینونو
انتظار کوي
د انتظار ټول وخت (ثانوي)
اوسط انتظار
د DB وخت
ټولګي ته انتظار وکړئ
د DB CPU
115.2K
70.4
SQL* د dblink څخه نور معلومات
670,196
5471.5
8.16ms
3.3
شبکه
د حجرې واحد بلاک فزیکي لوستل
5,661,452
3827.6
676.07us
2.3
کارن I/O
د ASM بیا توازن همغږي کړئ
4,350,012
3481.3
800.30us
2.1
نور
د سیل ملټي بلاک فزیکي لوستل
759,885
2252
2.96ms
1.4
کارن I/O
مستقیم لار لوستل
374,368
1811.3
4.84ms
1.1
کارن I/O
SQL*نیټ پیغام د dblink څخه
7,983
1725
216.08ms
1.1
شبکه
د ګرځنده سمارټ میز سکین
1,007,520
1260.7
1.25ms
0.8
کارن I/O
مستقیمه لاره د حرارت درجه لوستل
520,211
808.4
1.55ms
0.5
کارن I/O
enq: TM - شخړه
652
795.8
1220.55ms
0.5
کاریال
لاندې پایلې اکثرا د دې ډول AWR احصایو څخه اخیستل کیږي:
1. د ډیټابیس فعالیت کې د Exadata جادو ونډه ډیره نه ده - دا له 5٪ څخه ډیر نه وي، او ډیټابیس په کمزوري توګه "ایکساداتیز" کوي.
2. که دا ډول ډیټابیس د Exadata څخه کلاسیک "سرور + سري" جوړښت ته لیږدول کیږي، نو فعالیت به ډیر بدلون ونلري. ځکه چې حتی که دا سرې د Exadata ذخیره کولو سیسټم په پرتله درې چنده ورو وي (کوم چې د عصري ټول فلش صفونو لپاره په سختۍ سره امکان لري)، نو بیا د 5٪ په دریو سره ضرب کول موږ د I/O برخه 15٪ ته انتظار کوو. - ډیټابیس به یقینا دا ژوندي پاتې شي!
دا دواړه پایلې ناسمې دي، سربیره پردې، دوی د Exadata سافټویر تر شا د مفکورې پوهه تحریفوي. Exadata یوازې ګړندی I/O نه چمتو کوي ، دا د کلاسیک سرور + سري جوړښت په پرتله په بنسټیز ډول کار کوي. که چیرې د ډیټابیس عملیات واقعیا "تعدیل شوي" وي، نو د SQL منطق د ذخیره کولو سیسټم ته لیږدول کیږي. د ذخیره کولو سرورونه، د یو شمیر ځانګړو میکانیزمونو څخه مننه (په ابتدايي توګه د Exadata ذخیره کولو شاخصونه، مګر نه یوازې)، اړین معلومات پخپله ومومئ او DB سرورونو ته واستوي. دوی دا په خورا اغیزمنه توګه ترسره کوي، نو د عمومي Exadata ونډه په ټول ځواب وخت کې انتظار کوي لږ دی.
دا ونډه به د Exadata څخه بهر څنګه بدلون ومومي؟ دا به څنګه په ټوله کې د ډیټابیس فعالیت اغیزه وکړي؟ ازموینه به دې پوښتنو ته غوره ځواب ووایی. د مثال په توګه، د Exadata څخه بهر د "سیل سمارټ میز سکین" انتظار کول کولی شي دومره درانه جدول بشپړ سکین ته واړوي چې I/O د غبرګون ټول وخت نیسي او فعالیت په ډراماتیک ډول خرابیږي. له همدې امله دا غلط دی ، کله چې د AWR تحلیل کول ، د Exadata توقعاتو ټوله سلنه په فعالیت کې د دې جادو ونډې په توګه په پام کې ونیسئ ، او حتی نور هم د Exadata څخه بهر د فعالیت وړاندوینې لپاره دا سلنه وکاروئ. د دې لپاره چې پوه شئ چې د ډیټابیس کار څومره "دقت" دی، تاسو اړتیا لرئ د "انسټانس فعالیت احصایې" برخې د AWR احصایې مطالعه کړئ (د ځان توضیحي نومونو سره ډیری احصایې شتون لري) او د یو بل سره پرتله کړئ.
او د دې پوهیدو لپاره چې د Exadata بهر ډیټابیس به څنګه احساس وکړي ، دا غوره ده چې د هدف جوړښت کې د بیک اپ څخه ډیټابیس کلون جوړ کړئ او د بار لاندې د دې کلون فعالیت تحلیل کړئ. د Exadata مالکین، د یوې قاعدې په توګه، دا فرصت لري.
لیکونکی: الیکسي سټروچینکو، د جیټ انفوسیستم ډیټابیس څانګې مشر
سرچینه: www.habr.com