ابزار AWR در دیتابیس اوراکل یکی از مهمترین ابزارها برای بررسی عملکرد و عیبیابی (Troubleshooting) است. به صورت پیشفرض، اوراکل هر دقیقه یک Snapshot از وضعیت دیتابیس تهیه کرده و آنها را برای روز نگهداری میکند.
برای مشاهده تنظیمات فعلی AWR (شامل Interval و Retention)، میتوانید از ویوی DBA_HIST_WR_CONTROL استفاده کنید.
این کوئری ساده، مقادیر فعلی را به شما نشان میدهد:
SELECT
dbid,
snap_interval,
retention
FROM
dba_hist_wr_control;
خروجی دستور بالا:
DBID SNAP_INTERVAL RETENTION
---------- ---------------------------------------- ---------------------
482250778 +00000 01:00:00.0 +00008 00:00:00.0
همانطور که مشخص است بصورت پیش فرض هر یک ساعت یکبار اجرا می شود و تا 8 روز داده ها را نگاه می دارد.
کد زیر تنظیمات را به گونهای تغییر میدهد که اسنپشاتها هر ده دقیقه گرفته شده و برای ۳۰ روز ( دقیقه) نگهداری شوند:
exec dbms_workload_repository.modify_snapshot_settings(retention => 43200, interval => 10);
اگر دوباره select اول را اجرا کنیم، نتیجه به این تغییر پیدا کرده است:
DBID SNAP_INTERVAL RETENTION
---------- ---------------------------------------- ---------------------
482250778 +00000 00:10:00.0 +00030 00:00:00.0
اما چرا باید چنین تغییری ایجاد کنیم؟ چه مزایا و خطراتی دارد و بهترین روش استفاده از آن چیست؟
دلایل کاهش زمان اسنپشاتها به ۱۰ دقیقه
۱. گم شدن مشکلات گذرا (Transient Issues): در بازه یک ساعته، اگر یک مشکل کارایی شدیدی رخ دهد که تنها ۵ یا ۱۰ دقیقه طول بکشد، دادههای مربوط به آن در میان دادههای عادی ۵۰ دقیقه دیگر “رقیق” یا میانگینگیری میشوند. در نتیجه، در گزارش AWR یک ساعته، مشکل به وضوح دیده نمیشود.
۲. تست بار (Load Testing): هنگام اجرای تستهای استرس یا بارگذاری روی سیستم، نیاز به مانیتورینگ دقیق و لحظهبهلحظه رفتار دیتابیس است.
۳. سیستمهای با نوسان بالا: در دیتابیسهایی که حجم تراکنشها در عرض چند دقیقه به شدت بالا میرود و سپس افت میکند، اسنپشاتهای کوتاهتر دید بهتری به DBA میدهند.
مزایای این روش
- دقت و رزولوشن بالا: میتوانید زمان دقیق شروع و پایان یک Bottleneck (گلوگاه) را پیدا کنید.
- تحلیل دقیقتر رویدادهای انتظار (Wait Events): پیدا کردن کوئریها یا سشنهایی که در یک بازه کوتاه باعث افت شدید منابع شدهاند.
معایب و مشکلات احتمالی (هزینههای این تغییر)
۱. رشد شدید حجم فضای SYSAUX:
با تنظیمات پیشفرض (هر ده دقیقه)، در یک ماه تعداد زیادی اسنپشات تولید میشود.
با تنظیمات شما (هر ده دقیقه)، در یک ساعت 5 اسنپشات، در یک روز 120 و در ۳۰ روز (مدت زمان Retention شما) 3600 اسنپشات تولید میشود! این حجم عظیم داده میتواند فضای Tablespace مربوط به SYSAUX را به سرعت پر کند.
۲. بار اضافه (Overhead) روی دیتابیس: فرآیند گرفتن اسنپشات (توسط پراسس MMON) نیازمند مصرف CPU و I/O است. اجرای این فرآیند هر ۱۰ دقیقه یکبار، روی سیستمهای بسیار شلوغ میتواند خود باعث ایجاد بار اضافه شود.
۳. تولید گزارشهای AWR گیجکننده: مقایسه گزارشهای ۱۰ دقیقهای گاهی به دلیل کوتاه بودن بازه زمانی، اطلاعات مفیدی از روند کلی (Trend) به شما نمیدهد.
استراتژی استفاده مقطعی (Zoom-in Strategy)
بهترین روش برای استفاده از اسنپشاتهای ۱۰ دقیقهای، استفاده موقت است. یعنی زمانی که میدانید مشکلی در سیستم وجود دارد اما در گزارشهای ۱ ساعته دیده نمیشود، مانند یک ذرهبین روی دیتابیس زوم میکنید:
- تنظیم اسنپشات روی دقیقه.
- منتظر ماندن برای رخ دادن مشکل یا اجرای تست بار.
- استخراج گزارشهای AWR برای آن بازههای ۱۰ دقیقهایِ حیاتی.
- بازگرداندن تنظیمات به حالت نرمال (مثلاً ۱ ساعت):
EXEC dbms_workload_repository.modify_snapshot_settings(
retention => 11520,
interval => 60
);
پیشنهادات و Best Practiceها
۱. کاهش Retention در صورت کاهش Interval:
اگر واقعا مجبورید اسنپشاتها را روی ۱۰ دقیقه نگه دارید، نگهداری آنها برای ۳۰ روز توجیهی ندارد و فضای زیادی اشغال میکند. بهتر است اگر interval=10 است، retention را روی ۲ تا ۳ روز تنظیم کنید.
۲. استفاده از ASH (Active Session History) به جای تغییر AWR:
در بسیاری از مواقع نیازی به تغییر AWR نیست. ابزار ASH اطلاعات سشنهای فعال را هر ۱ ثانیه در حافظه و هر ۱۰ ثانیه روی دیسک ذخیره میکند. برای بررسی مشکلات زیر یک ساعت، تولید یک ASH Report (از طریق awrrpti.sql یا ashrpt.sql) بسیار منطقیتر، سبکتر و دقیقتر از تغییر بازه زمانی AWR است.
۳. مانیتور کردن مستمر SYSAUX:
اگر این اسکریپت را اجرا کردید، حتما به صورت روزانه میزان رشد SYSAUX را مانیتور کنید تا با خطای کمبود فضا (Space Exhaustion) مواجه نشوید.
کد شما از نظر سینتکس کاملا درست است، اما از نظر معماری، ترکیب interval=10 به همراه retention=43200 (یک ماه) یک تنظیم بسیار سنگین (Heavy-weight) محسوب میشود. پیشنهاد میشود از این روش تنها برای بازههای کوتاه عیبیابی استفاده کنید و سپس تنظیمات را به حالت استاندارد (۱ ساعته یا نیم ساعته ) برگردانید.
روش جایگزین : ایجاد اسنپشات به صورت دستی (Manual Snapshot)
این روش بهترین گزینه برای تحلیل یک عملیات خاص و برنامهریزی شده است (مثلاً اجرای یک Batch Job سنگین، یک Data Migration، یا یک Index Rebuild).
- قبل از شروع عملیات، یک اسنپشات دستی ایجاد کنید.
- بلافاصله پس از پایان عملیات، اسنپشات دوم را ایجاد کنید.
این کار یک بازه زمانی دقیق و ایزوله برای تحلیل ایجاد میکند. شما میتوانید گزارش AWR را دقیقاً بین این دو اسنپشات دستی تولید کنید تا فقط و فقط تأثیر همان عملیات خاص را ببینید.
دستور ایجاد اسنپشات دستی:
EXEC dbms_workload_repository.create_snapshot();
با این دستور پیش و پس از انجام کار می توانیم که زمان انجام کار را تحلیل کنیم.
همانطور که می بینید، در دیتابیس تستی زیر که مدت کمی از روشن شدن آن می گذرد، snapshot ها از یک ساعت به ده دقیقه کاهش پیدا کردند و دو snapshot با شماره های 20 و 21 توسط خودم با دستور بالا اضافه شده است:
Enter value for num_days: 3
Listing the last 3 days of Completed Snapshots
Instance DB Name Snap Id Snap Started Snap Level
------------ ------------ ---------- ------------------ ----------
vahiddb VAHIDDB 8 26 Apr 2026 04:43 1
9 26 Apr 2026 06:00 1
10 26 Apr 2026 07:00 1
11 26 Apr 2026 08:00 1
12 26 Apr 2026 09:00 1
13 26 Apr 2026 10:00 1
14 26 Apr 2026 11:00 1
15 26 Apr 2026 12:00 1
16 26 Apr 2026 13:00 1
17 26 Apr 2026 14:00 1
18 26 Apr 2026 15:00 1
19 26 Apr 2026 16:00 1
20 28 Apr 2026 05:17 1
21 28 Apr 2026 05:19 1
22 28 Apr 2026 05:20 1
23 28 Apr 2026 05:30 1
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: