ESC را فشار دهید تا بسته شود

زمیوس آموزش، یادگیری و سرگرمی

چگونه یک SQL کند را در Oracle به موشک تبدیل کنیم؟

چگونه یک SQL کند را در Oracle به موشک تبدیل کنیم

اگر با پایگاه داده Oracle کار کرده باشی، حتماً با این صحنه مواجه شدی:
یه کوئری ساده می‌نویسی، ولی اجراش از باز شدن درب قطارهای بین‌شهری هم بیشتر طول می‌کشه! 😅

اینجاست که مفهوم SQL Tuning وارد بازی میشه.
تو این مقاله آموزش اوراکل در بخش آموزش بهینه سازی کوئری، دقیقاً یاد می‌گیری که چطور یک SQL کند رو به یک کوئری سریع و بهینه تبدیل کنی – اونم با روش‌هایی که قابل اجرا، قابل درک، و تست‌شده در پروژه‌های واقعی هستن.

آیا می‌خواهید بدانید که در اوراکل با امکانات پیشرفته دستورات PVOT و UNPIVOT بیشتر آشنا بشید، پیشنهاد می شود نوشته زیر را مطالعه کنید:

در این مقاله شما می خوانید

🧩 بخش اول: چطور بفهمیم کجای کار میلنگه؟

اولین قدم برای رفع کندی، پیدا کردن کوئری‌هایی‌ست که بار زیادی به سیستم وارد می‌کنن.

🔍 بررسی SQLهای پرهزینه با v$sql:

				
					SELECT sql_id, elapsed_time, executions, sql_text  
FROM v$sql  
WHERE elapsed_time/executions > ۱۰۰۰۰۰۰  
ORDER BY elapsed_time DESC;

این کوئری ساده، تمام پرس‌وجوهایی که به‌طور متوسط بیش از ۱ ثانیه زمان اجرا دارند رو نشون می‌ده.

📊 تحلیل Plan اجرا با DBMS_XPLAN.DISPLAY_CURSOR:

				
					SELECT * FROM table(DBMS_XPLAN.DISPLAY_CURSOR
('your_sql_id', NULL, 'ALLSTATS LAST'));

چرا مهمه؟
چون این خروجی بهت نشون می‌ده:

  • آیا کوئری داره Full Table Scan می‌زنه؟
  • آیا ایندکسی استفاده شده یا نه؟
  • کدوم مرحله‌ها بیشتر زمان یا I/O مصرف می‌کنن؟

🚧 بخش دوم: بهینه‌سازی مثل یک حرفه‌ای

✅ ۱. ایندکس‌گذاری هدفمند

بذار یه مثال بزنم:
فرض کن داریم با جدول orders کار می‌کنیم که ۱۰ میلیون رکورد داره.

کوئری زیر خیلی کند اجرا میشه:

				
					SELECT * FROM orders WHERE status = 'SHIPPED';

راه‌حل؟
ایندکس روی ستون status:

				
					CREATE INDEX idx_orders_status ON orders(status);

و بلافاصله اجرای کوئری مثل برق سریع می‌شه ⚡

✅ ۲. بازنویسی کوئری‌های ناکارآمد

گاهی ساختار کوئری خودش عامل کُندی‌ست.

مثال:

				
					SELECT * FROM customers WHERE customer_id IN 
(SELECT customer_id FROM orders WHERE status = 'PENDING');

این ساختار IN بعضی وقت‌ها باعث ایجاد Subqueryهای پرهزینه می‌شه.

بازنویسی به شکل Join:

				
					SELECT DISTINCT c.*  
FROM customers c  
JOIN orders o ON c.customer_id = o.customer_id  
WHERE o.status = 'PENDING';

✅ ۳. استفاده هوشمندانه از Hintها

بعضی وقت‌ها Optimizer خودش مسیر اشتباهی می‌ره. با Hint می‌تونی هدایتش کنی:

				
					SELECT /*+ INDEX(orders idx_orders_status) */ *  
FROM orders  
WHERE status = 'SHIPPED';

✅ ۴. پارالل‌سازی برای داده‌های حجیم

گزارش‌های سنگین داری؟
از قابلیت Parallel Execution استفاده کن:

				
					SELECT /*+ parallel(o, 4) */ *  
FROM orders o  
WHERE created_date >= SYSDATE - 30;

✅ ۵. کمتر بگیر، سریع‌تر بگیر

همیشه همه‌ی داده‌ها رو لازم نداری. پس از این روش‌ها استفاده کن:

				
					SELECT * FROM orders WHERE status = 'CANCELLED' 
FETCH FIRST 100 ROWS ONLY;

🧪 بخش سوم: ابزارهای تشخیص کندی در Oracle

🧾 ۱. AWR Report:

برای اینکه ببینی توی یه بازه زمانی چه SQLهایی سنگین بودن:

				
					@$ORACLE_HOME/rdbms/admin/awrrpt.sql

این کوئری ساده، تمام پرس‌وجوهایی که به‌طور متوسط بیش از ۱ ثانیه زمان اجرا دارند رو نشون می‌ده.

🧠 ۲. SQL Monitoring

برای بررسی زنده اجرای کوئری (نیاز به Oracle Tuning Pack داره).

🔬 ۳. ASH Report

جزئیات فعالیت Sessionها در یک لحظه خاص.

روال ترتیب بهینه سازی کوئری از کند تا پرسرعت در چند گام

گام توضیح
۱ شناسایی کوئری‌های کند با AWR یا نمای v$sql
۲ تحلیل Execution Plan با DBMS_XPLAN
۳ بهینه‌سازی: ایندکس‌گذاری، بازنویسی Query، استفاده از Hint
۴ تست مجدد و بررسی تغییر در Plan و زمان اجرا
۵ مستندسازی، مانیتورینگ مستمر، و حذف تغییرات اضافی

سوالات متداول درباره بهینه سازی کوئری در Oracle

دلایل زیادی برای کندی کوئری در Oracle وجود داره، ولی رایج‌ترین‌هاش ایناست:

  • نداشتن ایندکس روی ستون‌های کلیدی
  • Full Table Scan به‌جای استفاده از Index
  • زیرپرس‌وجوهای غیر بهینه (مثل IN (SELECT...))
  • فیلترهای ناکارآمد یا بدون شرط
  • Cardinality اشتباه در Execution Plan

با بررسی Execution Plan می‌تونی دقیق بفهمی کجاها بیشترین هزینه مصرف می‌شه.

برای افزایش سرعت SQL در Oracle، این روش‌ها از پایه‌ای تا پیشرفته توصیه می‌شن:

  • استفاده از Index روی ستون‌های WHERE و JOIN

  • بازنویسی کوئری با استفاده از JOIN به‌جای IN

  • محدود کردن تعداد رکوردها با FETCH FIRST N ROWS

  • استفاده از Hintها برای هدایت Optimizer

  • استفاده از Parallel Execution برای کوئری‌های حجیم

همیشه بعد از تغییرات، Execution Plan رو دوباره چک کن.

AWR (Automatic Workload Repository) یکی از قوی‌ترین ابزارهای اوراکله که با اجرای یک اسکریپت ساده (awrrpt.sql) بهت نشون می‌ده توی چه بازه زمانی‌ای، چه SQLهایی بیشترین بار رو روی سیستم گذاشتن.تو می‌تونی با مقایسه‌ی این گزارش‌ها قبل و بعد از بهینه‌سازی، اثر واقعی تغییراتت رو ببینی.

خیلی راحت! از ویژگی Index Monitoring استفاده کن:

ALTER INDEX your_index_name MONITORING USAGE;

بعد از مدتی اجرا، این دستور رو بزن:

SELECT * FROM v$object_usage WHERE index_name = ‘YOUR_INDEX_NAME’;

بهت می‌گه آیا ایندکس توی این مدت واقعاً استفاده شده یا نه.
اگر استفاده نشده، می‌تونی با خیال راحت حذفش کنی و منابع رو آزاد کنی.

📦 جمع‌بندی

یه کوئری کند، می‌تونه کل سیستم رو قفل کنه. ولی با ابزار درست و دانش مناسب، به راحتی می‌شه اون کوئری رو به موشکی تبدیل کرد که تو کمترین زمان، دقیق‌ترین داده‌ها رو برگردونه.

📥 اگر سوالی داری در مورد SQL Tuning در Oracle داری، در بخش کامنت‌ها بپرس.

سؤالی درباره این مقاله داری؟

اگر نکته‌ای در این مقاله برات مبهم بود یا خواستی بیشتر بدونی، همین حالا برام بنویس تا دقیق و صمیمی پاسخت رو بدم — مثل یه گفت‌وگوی واقعی 💬

برو به صفحه پرسش و پاسخ

میثم راد

من یه برنامه نویسم که حسابی با دیتابیس اوراکل رفیقم! از اونایی ام که تا چیزی رو کامل نفهمم،ول کن نیستم، یادگرفتن برام مثل بازیه، و نوشتن اینجا کمک می کنه تا چیزایی که یاد گرفتم رو با بقیه به شریک بشم، با هم پیشرفت کنیم.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *