یکی از چالش‌برانگیزترین و بحرانی‌ترین سناریوها برای یک مدیر پایگاه داده (Oracle DBA)، مواجهه با خطاهای داخلی اوراکل موسوم به ORA-00600 در مرحلهٔ باز شدن (OPEN) پایگاه داده است. این شرایط زمانی پیچیده‌تر می‌شود که پایگاه داده در محیط تست، توسعه یا بدون داشتن بکاپ و آرشیولاگ معتبر قرار داشته باشد و امکان بازیابی استاندارد (Media Recovery) میسر نباشد.
در این مقاله، به بررسی ریشه‌ای علت بروز هم‌زمان خطاهای ORA-00600 [4137] و ORA-00600 [4193] پرداخته و یک متدولوژی عملیاتی برای دور زدن ریکاوری ناقص، باز کردن دیتابیس و بازسازی کامل فضای Undo ارائه می‌دهیم.
هشدار بسیار مهم: احتمال Data Loss و محدودیت‌های این روش
روشی که در این سناریو استفاده شد، یک راهکار اضطراری (Emergency / Bypass) برای نجات دیتابیس و باز کردن آن در شرایط بحرانی است؛ مخصوصاً وقتی هیچ بکاپ یا آرشیولاگی در دسترس نیست و دیتابیس در مرحله OPEN به‌دلیل خرابی Undo کرش می‌کند.
چرا احتمال Data Loss وجود دارد؟
در حالت طبیعی، اوراکل هنگام Crash Recovery باید:
- تغییرات Commit شده را با Redo تثبیت کند (Roll Forward)
- و تراکنش‌های Commit نشده را با Undo برگرداند (Rollback)
اما در این سناریو:
- Undo Tablespace دچار خرابی شده بود و rollback برخی تراکنش‌ها ممکن نبود.
- با استفاده از تنظیمات اضطراری (مانند
undo_management=MANUALوevent 10513) عملاً بخشی از فرآیند Transaction Recovery/Rollback دور زده شد تا دیتابیس بتواندOPENشود.
۱. تحلیل و کالبدشکافی رخداد (Root Cause Analysis)
علائم و لاگ‌های خطا
هنگام تلاش برای باز کردن دیتابیس، در فایل alert.log یا Trace لاگ‌های پروسس SMON خطاهای زیر ثبت می‌شوند:
Errors in file /u01/app/oracle/diag/rdbms/.../MKCFSTESTDB_smon_32888.trc:
ORA-00600: internal error code, arguments: [4137], [1], [23], [], [], []
ORA-00600: internal error code, arguments: [4193], [], [], []
ORA-00604: error occurred at recursive SQL level 1
ORA-00607: Internal error occurred during recovery action
چرا این اتفاق می‌افتد؟
- مکانیزم Crash Recovery: هنگامی که دیتابیس به‌صورت غیرعادی خاموش می‌شود یا سرور کرش می‌کند، اوراکل در زمان استارت، تراکنش‌های اعمال‌نشده (Uncommitted) را از طریق پروسس SMON شناسایی کرده و برای بازگرداندن وضعیت به حالت پایدار، عملیات Rollback را آغاز می‌کند.
- خطای
ORA-00600 [4137]: این خطا بیانگر عدم امکان خواندن یا یافتن بلاک‌های متناظر با یک تراکنش در سگمنت Undo است (مثلاً تراکنش شماره(1, 23)). - خطای
ORA-00600 [4193]: این خطا نشان‌دهندهٔ عدم تطابق ساختاری (Sequence/Block Header Mismatch) میان رکوردهای Redo و هدر بلاک‌های Undo است. - پیامد: اوراکل به دلایل ایمنی داده‌ها و جلوگیری از تخریب بیشتر بلاک‌ها، فوراً دیتابیس را به وضعیت
SHUTDOWN ABORTهدایت می‌کند و اجازهٔOPENشدن دیتابیس داده نمی‌شود.
۲. استراتژی حل مسئله (Bypass & Rebuild Strategy)
اگر بکاپ RMAN موجود باشد، اولین و استانداردترین گزینه RESTORE / RECOVER DATAFILE است. اما در محیط‌های آزمایشی یا شرایطی که هیچ بکاپی وجود ندارد، رویکرد عملیاتی شامل ۳ فاز اصلی خواهد بود:
- غیرفعال‌سازی موقت ریکاوری SMON و قرار دادن سیستم مدیریت Undo در حالت دستی (
MANUAL). - باز کردن دیتابیس (
OPEN) و ایجاد یک Undo Tablespace کاملاً جدید و سالم. - سوییچ دائمی به Undo جدید، حذف پارامترهای اضطراری و بازگرداندن سیستم به حالت نرمال (
AUTO).
۳. مراحل گام‌به‌گام عملیاتی (Step-by-Step Implementation)
گام ۰: تهیه نسخه پشتیبان سرد در سطح سیستم‌عامل (Cold Backup)
قبل از هر تغییری، برای جلوگیری از ریسک از دست رفتن داده‌ها در سطح دیسک، تمام فایل‌های اوراکل را در یک مسیر امن کپی کنید.
گام ۱: ساخت PFILE و پیکربندی پارامترهای اضطراری
ابتدا با SYSDBA لاگین کرده و دیتابیس را در حالت MOUNT بالا بیاورید تا از روی SPFILE یک فایل متنی PFILE بسازید
sqlplus / as sysdba
SQL> startup mount;
SQL> create pfile='/tmp/initMKCFSTESTDB.ora' from spfile;
SQL> shutdown abort;
سپس فایل /tmp/initMKCFSTESTDB.ora را با ویرایشگر باز کنید و مقادیر زیر را در آن اصلاح یا اضافه نمایید:
*.undo_management='MANUAL'
*.event="10513 trace name context forever, level 2"
# ۳. آفلاین کردن سگمنت‌های معیوب (در صورت نیاز)
*._offline_rollback_segments=(_SYSSMU1$, _SYSSMU2$, _SYSSMU3$, _SYSSMU4$, _SYSSMU5$, _SYSSMU6$, _SYSSMU7$, _SYSSMU8$, _SYSSMU9$, _SYSSMU10$)
گام ۲: باز کردن دیتابیس و ایجاد Undo Tablespace جدید
اکنون دیتابیس را با استفاده از PFILE سفارشی باز کنید:
SQL> startup pfile='/tmp/initMKCFSTESTDB.ora';
بلافاصله یک Undo Tablespace کاملاً جدید بسازید:
SQL> create undo tablespace UNDOTBS2
datafile '/u01/app/oradata/MKCFSTESTDB/undotbs02.dbf' size 4G
autoextend on next 256M maxsize unlimited;
کته مهم: اگر در این مرحله دستور ALTER SYSTEM SET UNDO_TABLESPACE=UNDOTBS2; را اجرا کنید، با خطای زیر مواجه می‌شوید:
ORA-30014: operation only supported in Automatic Undo Management mode
این خطا کاملاً طبیعی است زیرا دیتابیس در حالت MANUAL باز شده است؛ بنابراین سوییچ باید از طریق فایل پارامتر صورت گیرد.
گام ۳: بازگرداندن سیستم به حالت اتوماتیک (AUTO) و پایدارسازی
دیتابیس را خاموش کنید:
SQL> shutdown immediate;
-- در صورت عدم پاسخگویی سریع: shutdown abort;
فایل /tmp/initMKCFSTESTDB.ora را مجدداً باز کرده و پارامترها را به شکل نرمال تنظیم کنید:
undo_managementرا بهAUTOبرگردانید.- مقدار
undo_tablespaceرا برابرUNDOTBS2قرار دهید. - تمام خطوط مربوط به
event 10513و پارامترهای مخفی (_offline...) را حذف یا کامنت (#) کنید.
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS2'
# event="10513 trace name context forever, level 2"
# _offline_rollback_segments=...
سپس دیتابیس را با PFILE بالا آورده و SPFILE رسمی را بازسازی نمایید:
SQL> startup pfile='/tmp/initMKCFSTESTDB.ora';
SQL> create spfile from pfile='/tmp/initMKCFSTESTDB.ora';
گام ۴: راه‌اندازی استاندارد و حذف Undo Tablespace خراب
دیتابیس را خاموش کرده و به‌صورت استاندارد بالا بیاورید تا مطمئن شوید SPFILE جدید فعال است:
SQL> shutdown immediate;
SQL> startup;
صحت تنظیمات و فعال بودن تیبل‌اسپیس جدید را بررسی کنید:
SQL> show parameter undo;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_tablespace string UNDOTBS2
وضعیت سگمنت‌های قدیمی را بررسی کرده و سپس تیبل‌اسپیس خراب قبلی را به‌همراه دیتافایل مربوطه حذف کنید:
SQL> select tablespace_name, status, count(*)
from dba_rollback_segs
group by tablespace_name, status;
SQL> drop tablespace UNDOTBS1 including contents and datafiles;
۴. جمع‌بندی و نکات کلیدی (Best Practices)
- علت استفاده از Event 10513: این Event داخلی به هستهٔ اوراکل اعلام می‌کند که فرآیند Transaction Recovery توسط SMON را معلق نگه دارد تا امکان دسترسی به داده‌ها و رفع خرابی فراهم شود.
- عدم باقی ماندن پارامترهای موقت: همیشه پس از رفع بحران، رویدادها (
Events) و پارامترهای مخفی (Underline Parameters) را از SPFILE پاک کنید تا رفتار اوراکل استاندارد و پیش‌بینی‌پذیر باقی بماند. - وضعیت داده‌های تراکنش‌های ناتمام: با دور زدن Undo خراب، تراکنش‌هایی که در زمان کرش
COMMITنشده بودند، به حالت Half-Baked یا ناتمام در جداول باقی می‌مانند. توصیه می‌شود پس از بالا آمدن سیستم، یک بررسی منطقی (Data Integrity Check) روی جداول عملیاتی انجام گیرد.