اگر در دنیای مدیریت پایگاه دادههای اوراکل فعالیت کرده باشی، حتماً نام AWR Report یا همان Automatic Workload Repository به گوشت خورده است.
این گزارش یکی از قدرتمندترین ابزارهای تحلیل عملکرد (Performance Tuning) در Oracle Database است.
در حقیقت AWR مانند یک «جعبه سیاه» عمل میکند که در پسزمینه، تمام اتفاقات مهم را ثبت میکند؛ از SQLهای سنگین گرفته تا انتظارها (Wait Events)، مصرف CPU، آمار I/O، حافظه و رفتار Sessionها.
وقتی یک سیستم کند میشود، اولین جایی که باید سراغش بروی AWR Report است.
اگر خواندن و تحلیل این گزارش را بلد باشی، در اکثر مواقع میتوانی طی چند دقیقه دلیل کندی را پیدا کنی.
در این مقاله آموزش اوراکل در بخش آموزش بهینه سازی کوئری SQL Tuning ، یک بررسی کاملاً عملی، کاربردی و سئو شده از AWR و نحوه تحلیل آن میدهم — دقیقاً همان چیزی که یک DBA برای تکرار نکردن اشتباهات Performance نیاز دارد.
اگر با پایگاه داده Oracle کار کرده باشی، حتماً تجربه کردی که گاهی ایندکسهای ساختهشده روی جدولها، ناگهان اثر خودشان را از دست میدهند. پیشنهاد می کنم این مقاله زیر رو حتما مطالعه کنی.
در این مقاله شما می خوانید
Automatic Workload Repository یک مخزن خودکار برای ذخیرهسازی آمار عملکردی دیتابیس است.
این مخزن بهصورت پیشفرض هر ۶۰ دقیقه یک Snapshot از وضعیت کلی دیتابیس میگیرد و اطلاعات زیر را ذخیره میکند:
- آمار SQL (Elapsed, CPU, IO, Parse, Buffer Gets)
- آمار Sessionها
- آمار حافظه (SGA و PGA)
- آمار I/O و ASM
- Wait Eventها
- بَکگراند پروسسها
- وضعیت Cacheها
- Lockها و Latchها
- آمار شبکه و Cluster در RAC
AWR فقط در Oracle Enterprise Edition و با لایسنس Diagnostic Pack در دسترس است.
از مسیر زیر در SQL*Plus:
@$ORACLE_HOME/rdbms/admin/awrrpt.sql
ورودیها:
- فرمت: Text یا HTML
- شماره Snapshot شروع
- شماره Snapshot پایان
Oracle گزارش را تولید میکند و در سرور ذخیره میشود.
این بخش مهمترین بخش مقاله است؛ چراکه یاد میگیری دقیقاً چه چیزهایی را نگاه کنی و چطور تحلیل کنی.
۱. Summary
بخش Summary یک نمای کلی ارائه میدهد:
- DB Time
- DB CPU
- Elapsed Time
- Active Sessions
- Parse statistics
- IO Profile
تحلیل کاربردی:
اگر DB Time بهطور محسوسی از DB CPU بیشتر باشد، مشکل معمولاً Wait Event است (نه CPU).
مثال:
DB Time = 20000
DB CPU = 4000
این یعنی:
۸۰٪ زمان دیتابیس در انتظار I/O یا Lock یا Latch بوده است.
۲. Top 5 Timed Events
یکی از مهمترین بخشهای AWR که باید مثل کف دست بشناسید.
مثال واقعی:
- db file sequential read
- db file scattered read
- log file sync
- enq: TX – row lock contention
- latch: shared pool
تحلیل:
- db file sequential read: دسترسی Index در حالت I/O بالا
- scattered read: Full Table Scan زیاد
- log file sync: Commitهای زیاد یا مشکل Redo
- row lock contention: تراکنشها همدیگر را بلوکه کردهاند
- latch: shared pool: Hard Parse یا Shared Pool کم
۳. Load Profile
آمارهایی مانند:
- Commits per second
- Executions per second
- Logical Reads per second
- Physical Reads
- Redo Generated
تحلیل:
اگر Logical Read خیلی زیاد باشد، احتمالاً SQLهای بدون Index فشار ایجاد کردهاند.
۴. Instance Efficiency Percentages
این بخش عملکرد Cacheها را نشان میدهد.
شاخصهای مهم:
- Buffer Cache Hit %
- Library Cache Hit %
- Soft Parse %
- Parse CPU to Parse Elapsed %
تحلیل:
Soft Parse پایین → برنامه Bind Variable ندارد → Hard Parse زیاد → Shared Pool سردرگم.
Buffer Cache Hit پایین → SGA کم یا SQL بد.
۵. Top SQL
مهمترین بخش از نظر Performance Tuning همین است.
Oracle SQLها را بر اساس معیارهای مختلف رتبهبندی میکند:
- از نظر Elapsed Time
- از نظر CPU
- از نظر Buffer Gets
- از نظر Physical Reads
- از نظر Executions
- از نظر Cluster Wait
- از نظر I/O Wait
مثال یک SQL سنگین:
SQL ID: 3a6p8bw93ah4p
Elapsed: 4500s
Buffer Gets: 12M
Disk Reads: 800k
Executions: 6
جمعبندی تحلیل:
- اجرای کم + زمان زیاد = Query سنگین و اشتباه
- Buffer Gets بالا = عملیات منطقی زیاد
- Disk Reads بالا = I/O سنگین
راهکار ممکن:
- Index درست
- Rewriting Query
- CBO Statistics
۶. بخش I/O Statistics
سرعت خواندن/نوشتن دیسک را نمایش میدهد.
مثال:
Physical Read Latency = 18 ms
Write Latency = 22 ms
تحلیل:
Latency بالاتر از ۱۵ میلیثانیه → مشکل I/O یا زیرساخت storage.
۷. Advisory Sections
Oracle پیشنهادهای هوشمند tuning میدهد:
-_buffer cache advisory
-pga advisory
-sga target advisory
-shared pool advisory
مثال:
اگر نشان دهد با ۳۰٪ افزایش buffer cache میزان I/O نصف میشود → افزایش SGA شدیداً پیشنهاد میشود.
۸. ASH Report Summary
نمای زندهتر از فعالیت Sessionها.
با این بخش میتوان تشخیص داد:
- کدام Session قفل ایجاد کرده
- کدام User یا برنامه بار اصلی system را دارد
- کدام SQL باعث spike شده
مشکل: سیستم ناگهان کند شده.
نشانهها:
- CPU پایین
- I/O بالا
- Event: db file scattered read
- Full Scan زیاد
- log file sync بالا
تحلیل سریع:
- SQLهای Full Scan شناسایی شد
- Indexهای مهم ساخته یا اصلاح شد
- Shared Pool افزایش یافت
- Commitهای برنامه کاهش یافت (Batch Commit)
- Disk Group بررسی شد
نتیجه: بار سیستم ۵۰٪ کاهش پیدا کرد و اجراها ۳ برابر سریعتر شدند.
- همیشه از Summary شروع کن.
- اگر DB CPU پایین اما DB Time بالا باشد → مشکل Wait Event است.
- Scattered Read = Full Table Scan زیاد.
- Sequential Read = Index Access با I/O بالا.
- log file sync بالا = Commit زیاد یا مشکلات IO Redo.
- latch: shared pool = Soft Parse کم.
- Top SQL همیشه ۸۰٪ مشکل را نشان میدهد.
- Load Profile را جدی بگیر: spikes نشانه تغییرات برنامه است.
سوالات متداول درباره AWR Report در اوراکل
AWR Report مانند یک «نقشه راه کامل» از عملکرد دیتابیس عمل میکند.
این گزارش دقیقاً نشان میدهد که دیتابیس در بازه زمانی موردنظر چه چیزی را تجربه کرده است:
کدام SQL سنگین بوده، چه Eventهایی بیشترین تأخیر را ایجاد کردهاند، آیا مشکل از CPU است یا I/O یا Memory، و حتی آیا برنامهنویسها اشتباه Query نوشتهاند یا خیر.
با تحلیل سه بخش کلیدی (Top Timed Events، Top SQL و Load Profile) معمولاً میتوان ریشه ۹۰٪ کندیها را در کمتر از چند دقیقه پیدا کرد.
اگر زمان کمی داری و فقط میخواهی سریع علت کندی را بفهمی، این چهار بخش از همه مهمترند:
- Top 5 Timed Events (علت اصلی معطلی سیستم)
- Top SQL (مشکلسازترین کوئریها)
- Instance Efficiency (عملکرد حافظه و Cacheها)
- I/O Statistics (مشکلات دیسک و ASM)
اینها معمولاً همان بخشهایی هستند که DBAهای حرفهای در ۹۰٪ موارد با نگاه به آنها مشکل را تشخیص میدهند.
برای تشخیص I/O باید به مواردی مثل db file sequential read، scattered read، physical read latency و میزان Disk Reads در Top SQL نگاه کرد.
اگر latency دیسک بالا باشد یا تعداد Physical Reads غیرعادی زیاد باشد، مشکل از I/O یا Storage است.
اگر Buffer Gets بالا باشد اما Physical Reads کم، معمولاً مشکل از SQL است و Queryها نیاز به Index یا بهینهسازی دارند.
به زبان ساده:
- I/O بالا + Latency زیاد → مشکل Storage
- Buffer Gets بالا + Full Scan → مشکل طراحی SQL
یک روش عملی و سریع وجود دارد که DBAهای باتجربه استفاده میکنند:
۱. Summary را نگاه کن تا بفهمی CPU یا I/O مشکلساز است.
۲. برو سراغ Top Timed Events تا بفهمی سیستم کجا معطل میشود.
۳. بخش Top SQL را باز کن و مشکلسازترین کوئریها را شناسایی کن.
۴. بخش Memory Advisory و I/O Advisory را ببین تا بفهمی آیا با افزایش SGA یا تغییر اندازه Buffer Cache میتوان مشکل را حل کرد یا نه.
این روش حدوداً ۳ تا ۵ دقیقه زمان میگیرد اما در ۸۰٪ مواقع نتیجه میدهد.
جمعبندی
AWR Report یکی از قویترین ابزارهای عیبیابی اوراکل است.
اگر بتوانی فقط سه چیز را درست بخوانی، ۹۰٪ مشکلات performance را پیدا میکنی:
- Top Timed Events
- Top SQL
- Advisory بخش حافظه و I/O
تحلیل درست AWR یعنی فهمیدن علت کندی، نه صرفاً مشاهدهٔ علائم.
📥 اگر سوالی داری در مورد AWR Report در Oracle داری، در بخش کامنتها بپرس.
سؤالی درباره این مقاله داری؟
اگر نکتهای در این مقاله برات مبهم بود یا خواستی بیشتر بدونی، همین حالا برام بنویس تا دقیق و صمیمی پاسخت رو بدم — مثل یه گفتوگوی واقعی 💬
برو به صفحه پرسش و پاسخ
دیدگاهتان را بنویسید