در معماری موتور پایگاه داده اوراکل (Oracle Database Engine)، تغییرات داده‌ای پیش از اعمال قطعی در دیسک، در بافرهای حافظه موقت (Redo Log Buffer) ثبت شده و به کمک پروسه پس‌زمینه LGWR (Log Writer) در فایل‌های آنلاین ردو لاگ (Online Redo Logs) نوشته می‌شوند. به صورت استاندارد، اوراکل زمانی اقدام به تغییر فایل ردو لاگ و ایجاد رویداد لاگ‌سوئیچ (Log Switch) می‌کند که فایل لاگ فعال جاری به طور کامل پر شده باشد.
اما در بسیاری از محیط‌های عملیاتی و حیاتی سازمانی—به‌ویژه بسترهایی که دارای استراتژی Disaster Recovery مبتنی بر Oracle Data Guard هستند—تکیه بر پر شدن طبیعی ردولاگ‌ها می‌تواند ریسک‌های جدی به همراه داشته باشد. در ساعات کم‌ترافیک (Off-Peak Hours)، پر شدن یک ردولاگ بزرگ ممکن است چندین ساعت طول بکشد؛ این یعنی داده‌های آرشیو نشده و ارسال‌نشده به سایت پشتیبان ممکن است با خطرات جدی مواجه شوند.
برای پاسخ به این نیاز و زمان‌بندی دقیق چرخه لاگ‌سوئیچ، اوراکل پارامتر راهبردی ARCHIVE_LAG_TARGET را تعبیه کرده است.
مفهوم پارامتر ARCHIVE_LAG_TARGET چیست؟
پارامتر ARCHIVE_LAG_TARGET یک پارامتر سیستمی و دینامیک در سطح نمونه (Instance) است که به اوراکل دستور می‌دهد:
«محتوای تغییرات نباید بیشتر از مدت زمان تعیین‌شده در لاگ‌فایل جاری باقی بماند.»
اگر طی این بازه زمانی مشخص، به دلیل حجم کم تراکنش‌ها لاگ‌سوئیچ به شکل نرمال رخ ندهد، خود دیتابیس به صورت خودکار یک لاگ‌سوئیچ اجباری را تریگر کرده و لاگ فعلی را جهت تولید Archive Log می‌بندد.
- واحد اندازه‌گیری: ثانیه (Seconds)
- مقدار پیش‌فرض:
0(غیرفعال) - دامنه تغییرات: از
0تا7200ثانیه (حداکثر ۲ ساعت)
مزایا و اهداف پیاده‌سازی
تنظیم اصولی و هوشمندانه این پارامتر مزایای متعدد و کلیدی برای مدیران پایگاه داده (DBAs) و پایداری سیستم دارد:
۱. تضمین و کاهش چشمگیر شاخص RPO (Recovery Point Objective)
بزرگ‌ترین مزیت این ویژگی، کاهش خطر از دست رفتن داده‌ها (Data Loss) است. در پیکربندی‌های Data Guard به‌ویژه در حالت‌های غیر همگام (Asynchronous Redo Transport / Maximum Performance)، تا زمانی که لاگ تغییرات به سایت Standby منتقل و اعمال نشود، ریسک از دست رفتن تراکنش‌ها در صورت خرابی سخت‌افزاری سایت اصلی وجود دارد. با فورس کردن لاگ‌سوئیچ در فواصل زمانی مشخص (مثلاً هر ۱۵ یا ۳۰ دقیقه)، تضمین می‌کنید که حداکثر دیتای در معرض خطر دقیقاً محدود به همان سقف زمانی است.
۲. توزیع بار یکنواخت در آرشیو و پشتیبان‌گیری (Backup Distribution)
در نبود این پارامتر، ممکن است در طول روز فواصل تولید Archive Log نامنظم باشد. در ساعات خلوت لاگی تولید نشود و ناگهان با افزایش بار تعداد زیادی لاگ حجیم ایجاد شود. ARCHIVE_LAG_TARGET باعث جریان پیوسته و یکنواخت ایجاد Archive Logها شده و عملیات پشتیبان‌گیری افزایشی (Incremental Backup) توسط RMAN را هموارتر می‌کند.
۳. مانیتورینگ سلامت Data Guard و فرآیند Redo Apply
وقتی لاگ‌ها با فواصل زمانی مشخص ارسال شوند، بررسی شاخص Apply Lag و Transport Lag در دیتابیس استندبای قابل پیش‌بینی‌تر خواهد بود. این مسئله باعث می‌شود خطاهای شبکه یا قطعی مسیر ردولاگ در فواصل طولانی و مخفی باقی نماند و ابزارهایی نظیر Data Guard Broker و Enterprise Manager هشدارهای بهنگام صادر کنند.
۴. جلوگیری از انباشتگی ردولاگ‌ها در یک زمان
در سناریوهای بازگردانی (Crash Recovery) یا عملیات failover، خواندن و اعمال فایل‌های ردو در قالب قطعات کوچک‌تر و زمان‌بندی‌شده، زمان مورد نیاز برای Recovery را کوتاه‌تر و قابل مدیریت‌تر می‌کند.
نحوه پیکربندی عملیاتی
این پارامتر به صورت Dynamic طراحی شده و تغییر آن در محیط‌های Production نیازی به ری‌استارت دیتابیس ندارد:
۱. بررسی وضعیت فعلی
SHOW PARAMETER ARCHIVE_LAG_TARGET;
یا از طریق دیتا دیکشنری:
SELECT name, value
FROM v$parameter
WHERE name = 'archive_lag_target';
۲. اعمال تنظیمات جدید
برای مثال، جهت فورس کردن لاگ‌سوئیچ حداکثر هر ۱۵ دقیقه (۹۰۰ ثانیه):
ALTER SYSTEM SET ARCHIVE_LAG_TARGET = 900 SCOPE=BOTH;
برای سیستم‌هایی با حساسیت کمتر یا نیاز به فواصل ۳۰ دقیقه‌ای:
ALTER SYSTEM SET ARCHIVE_LAG_TARGET = 1800 SCOPE=BOTH;
۳. غیرفعال‌سازی (بازگشت به پیش‌فرض)
ALTER SYSTEM SET ARCHIVE_LAG_TARGET = 0 SCOPE=BOTH;
نکات فنی و Best Practices اوراکل
-
توجه به سقف پایین (Lower Threshold):
- طبق مستندات و بهترین تجارب اوراکل، قرار دادن مقادیر کمتر از ۹۰۰ ثانیه (۱۵ دقیقه) عموماً توصیه نمی‌شود مگر با دلایل خاص بیزینسی.
- مقادیر خیلی کم (مثلاً ۶۰ یا ۱۲۰ ثانیه) باعث تولید فایل‌های لاگ بسیار کوچک، افزایش سربار I/O، درگیر شدن مداوم پروسه‌های
ARCnو پر شدن سریع دیسک Fast Recovery Area (FRA) می‌شود.
-
هوشمندی اوراکل در زمان بیکاری (Idle Database):
- اگر پایگاه داده کاملاً غیرفعال باشد و هیچ تغییر یا بلاک تراکنشی (Dirty Buffer / Redo Generation) در سیستم رخ نداده باشد، اوراکل به صورت بیهوده لاگ‌سوئیچ نمی‌کند؛ سوئیچ فقط در صورتی انجام می‌شود که تراکنشی طی بازه گذشته ثبت شده باشد.
-
سازگاری با RAC (Real Application Clusters):
- در محیط‌های کلاستر RAC، این پارامتر باید روی تمام اینستنس‌ها اعمال شود تا جریان لاگ‌سوئیچ در همه گره‌ها هماهنگ و منظم باشد:
ALTER SYSTEM SET ARCHIVE_LAG_TARGET = 900 SCOPE=BOTH SID='*';
پارامتر ARCHIVE_LAG_TARGET یکی از ابزارهای بسیار موثر برای معماران دیتابیس و DBAs است تا استراتژی Zero Data Loss یا حداقل‌سازی RPO را پیاده‌سازی کنند. این پارامتر تضمین می‌کند که فرآیند انتقال و آرشیو تغییرات به صورت یکنواخت و قابل پیش‌بینی انجام شود، بدون اینکه نیازی به نوشتن اسکریپت‌های دستی در سطح سیستم‌عامل (نظیر Cronjobهای زمان‌بندی‌شده با دستور ALTER SYSTEM SWITCH LOGFILE) باشد.