آموزش ۵۰۰+ سوال و جواب مصاحبه DBA اوراکل ۲۰۲۶ - آخرین آپدیت

پوشش دقیق حوزه‌های آزمون

این مخزن تست‌های عملی به طور سیستماتیک سازماندهی شده تا با توزیع دقیق سناریوهای معماری پیشرفته و مشکلات عیب‌یابی که در مصاحبه‌های فنی Oracle DBA سازمانی ظاهر می‌شوند، مطابقت داشته باشد.

• معماری دیتابیس (۲۰٪): ساختارهای ذخیره‌سازی، چیدمان منطقی و فیزیکی، مدیریت Tablespaces و Datafiles، مکانیسم‌های Online Redo Logs، اندازه‌گیری Undo Tablespace و امنیت Database Link.

• بهینه‌سازی عملکرد (۱۸٪): رمزگشایی گزارش‌های AWR، شناسایی Top Timed Events، تحلیل ماتریس‌های Load Profile، ارزیابی درصد کارایی Instance و رفع Wait Events در سطح سیستم.

• امنیت دیتابیس (۱۲٪): مدیریت کاربران سازمانی، مجوزهای دقیق (Fine-grained)، تخصیص نقش‌های پیچیده، استراتژی‌های مدیریت امن رمز عبور و ردیابی جامع AUDIT دیتابیس.

• پشتیبان‌گیری و بازیابی (۱۵٪): معماری RMAN، استراتژی‌های عمیق بک‌آپ، ابزارهای سریع Data Pump (EXPDP و IMPDP)، بازیابی در لحظه (Point-in-time recovery) و کلونینگ فیزیکی/منطقی دیتابیس.

• PL/SQL و اتوماسیون (۱۰٪): عیب‌یابی رویه‌های PL/SQL، بهینه‌سازی پکیج‌ها، جریان اجرای Triggerهای دیتابیس و زمان‌بندی کارهای سازمانی از طریق پکیج DBMS_SCHEDULER.

• مانیتورینگ و عیب‌یابی دیتابیس (۱۰٪): بررسی Alert Logها، تحلیل Trace Fileها، ردیابی Session Waitها، رفع Deadlockها و Lockهای پیچیده، و شناسایی ریشه‌ای هنگ‌های ناگهانی دیتابیس.

• انبار داده و Multitenant (۵٪): مفاهیم Data Warehousing، مدیریت معماری Multitenant، نگهداری Container Databases (CDBs) و جداسازی Pluggable Databases (PDBs).

• نصب، پیکربندی و ارتقاء (۱۰٪): پیش‌نیازهای نصب دیتابیس، پیکربندی پارامترها، ارتقاء نسخه‌های اصلی، اجرای روال‌های Patching و مهاجرت دیتابیس بین پلتفرم‌های مختلف.

درباره این دوره

موفقیت در مصاحبه‌های سطح عملیاتی Oracle DBA یا مدیر ارشد دیتابیس، فراتر از حفظ کردن دستورات پایه SQL یا تعاریف استاندارد داده‌ها است. محیط‌های دیتابیس سازمانی مدرن نیازمند مدیرانی هستند که بتوانند تحت فشار زیاد تفکر انتقادی داشته باشند؛ خواه این به معنای رفع یک هنگ غیرمنتظره در ساعات اوج تراکنش‌ها باشد، یا اصلاح یک بلوک فاسد در هنگام Restore با RMAN، و یا تحلیل یک گزارش مبهم AWR برای یافتن علت افت ناگهانی کارایی Instance. من این بانک سوالات هدفمند را به عنوان ابزاری جامع طراحی کرده‌ام تا شکاف بین دانش عملیاتی عمومی و سناریوهای دقیق و چالش‌برانگیزی که مصاحبه‌کنندگان ارشد فنی می‌پرسند را پر کند.

با ۵۵۰ سوال اصیل و با دقت آماده شده، این دوره بسیار فراتر از تعاریف ساده واژگان است. من لاگ‌های Trace پیچیده را کالبدشکافی می‌کنم، هشدارهای شکست در محیط عملیاتی را شبیه‌سازی می‌کنم، خطاهای کلونینگ دیتابیس را بررسی می‌کنم و طرح‌های اجرای غیربهینه (Suboptimal Execution Plans) را ارزیابی می‌کنم. هر سوال با یک تحلیل فنی دقیق همراه است که دقیقاً توضیح می‌دهد چرا استراتژی مدیریتی صحیح کار می‌کند و چرا پارامترها یا دستورات جایگزین شکست می‌خورند یا پایداری سیستم را به خطر می‌اندازند. چه هدف شما ارتقاء به نقش Senior DBA باشد، چه آماده شدن برای یک دور سخت تحلیل‌گر زیرساخت، یا صرفاً تثبیت تخصص خود در Multitenancy و Performance Tuning برای یک مصاحبه ترفیع، این بانک سوالات جامع، تست‌های عملی مورد نیاز شما را فراهم می‌کند تا با اعتماد به نفس کامل در اولین تلاش از مراحل فنی عبور کنید.

پیش‌نمایش نمونه سوالات

برای درک عمق تحلیلی و ساختار توضیحات ارائه شده در این مجموعه، این سه نمونه سوال فنی را بررسی کنید.

سوال ۱: تحلیل عملکرد و تفسیر Wait Eventهای AWR

در یک دوره تراکنش فعال، یک دیتابیس Oracle 19c دچار افت شدید نرخ پردازش (Throughput) می‌شود. DBA یک گزارش AWR تهیه می‌کند و متوجه می‌شود که 'db file sequential read' در صدر لیست Top Timed Events قرار دارد و ۶۵٪ از کل زمان دیتابیس را به خود اختصاص داده است، اما میانگین زمان انتظار برای هر درخواست تنها ۲ میلی‌ثانیه است. مدیر دیتابیس باید چه نتیجه‌ای از این معیارهای عملکرد بگیرد؟

• الف) آرایه‌های ذخیره‌سازی فیزیکی زیرین دچار گلوگاه‌های شدید سخت‌افزاری I/O و چرخه‌های خواندن کند هستند.

• ب) Instance دیتابیس در حال اجرای خوانش‌های تک-بلوکی بیش از حد است که احتمالاً ناشی از دستورات SQL بهینه‌نشده است که به طور نامناسب از Index Lookup استفاده می‌کنند.

• ج) اندازه Buffer Cache دیتابیس بسیار کوچک است و پردازش‌های پس‌زمینه را مجبور می‌کند بلوک‌های تصادفی را به طور مداوم به دیسک بنویسند.

• د) یک وضعیت Deadlock بحرانی در System Tablespace ایجاد شده و پردازش پس‌زمینه DBWR را کاملاً متوقف کرده است.

• ه) Log Buffer دیتابیس پر شده و مانع از تخلیه ورودی‌های تراکنش توسط LGWR به فایل‌های Redo Log فعال می‌شود.

• و) Undo Tablespace به حداکثر مرز تخصیص خود رسیده و کوئری‌های فعال را مجبور می‌کند سگمنت‌های Undo موقت را در حافظه ایجاد کنند.

پاسخ صحیح و توضیحات:

• پاسخ صحیح: ب

• چرا صحیح است: رویداد انتظار 'db file sequential read' نشان‌دهنده یک خوانش فیزیکی تک-بلوکی به داخل Buffer Cache است که معمولاً نشان‌دهنده عملیات Index Lookup است. میانگین زمان انتظار ۲ میلی‌ثانیه فوق‌العاده سریع است و ثابت می‌کند که زیرسیستم ذخیره‌سازی به طور کامل عمل می‌کند. بنابراین، اگر این رویداد بر کل زمان دیتابیس غالب است، گلوگاه سخت‌افزار کند نیست، بلکه حجم خوانش‌هاست. احتمالاً اپلیکیشن در حال اجرای کوئری‌های بهینه‌نشده‌ای است که مکرراً روی ایندکس‌ها حلقه می‌زنند یا Range Scanهای ایندکس را در حالی انجام می‌دهند که Full Table Scan بهینه‌تر می‌بود.

• چرا گزینه‌های دیگر نادرست هستند:

  • گزینه الف نادرست است: گلوگاه سخت‌افزاری I/O به صورت افزایش میانگین زمان انتظار (معمولاً بیش از ۱۵-۲۰ میلی‌ثانیه) ظاهر می‌شود، نه ۲ میلی‌ثانیه سالم.

  • گزینه ج نادرست است: کش‌های کوچک منجر به خوانش‌های فیزیکی بالا می‌شوند، اما 'db file sequential read' به طور خاص خوانش‌های تک-بلوکی را جدا می‌کند که معمولاً به طراحی کوئری اپلیکیشن باز می‌گردد نه صرفاً اندازه کش.

  • گزینه د نادرست است: Deadlockها بلافاصله خطای ORA-00060 را به نشست (Session) ارسال می‌کنند و به صورت رویدادهای 'db file sequential read' با تاخیر کم ظاهر نمی‌شوند.

  • گزینه ه نادرست است: مشکلات Log Buffer به صورت رویدادهای 'log buffer space' یا 'log file sync' ظاهر می‌شوند، نه رویدادهای خواندن فایل داده.

  • گزینه و نادرست است: اتمام فضای Undo Tablespace باعث شکست در تخصیص فضا (مانند ORA-01650) می‌شود و توسعه تراکنش‌ها را مسدود می‌کند، نه اینکه جریان‌های عظیم خوانش تک-بلوکی ایجاد کند.

سوال ۲: پشتیبان‌گیری و بازیابی پیشرفته از طریق پیکربندی کانال RMAN

یک مدیر قصد دارد با استفاده از RMAN Active Database Cloning از طریق یک لینک شبکه امن، یک کپی کامل از دیتابیس تهیه کند. عملیات shortly پس از شروع با یک خطای Timeout غیرقابل بازیابی شکست می‌خورد. بررسی‌ها نشان می‌دهد که پهنای باند شبکه مقصد کافی است، اما یک کانال واحد RMAN توسط دیتافایل‌های حجیم اشباع شده است. DBA چگونه می‌تواند این گلوگاه انتقال داده را به طور موثر در معماری اسکریپت‌نویسی RMAN حل کند؟

• الف) پارامتر SECTION SIZE را در بلوک دستور DUPLICATE پیاده‌سازی کند تا انتقال فایل‌های بزرگ را به صورت موازی در چندین کانال تخصیص یافته توزیع کند.

• ب) سیستم منبع را قبل از شروع فرآیند بک‌آپ به یک Container Database (CDB) مستقل تبدیل کند تا استریمینگ چندرشته‌ای اجباری شود.

• ج) پارامتر مقداردهی اولیه LOG_BUFFER را در Instance کمکی افزایش دهد تا بلوک‌های ورودی فضای کش بیشتری داشته باشند.

• د) تمام Primary Keyهای جداول بزرگ را در دیتابیس منبع حذف کند تا حجم فیزیکی داده‌های منتقل شده از طریق لینک شبکه کاهش یابد.

• ه) روال Duplicate RMAN را با استفاده از پارامتر NOFILENAMECHECK اجرا کند تا بررسی‌های استاندارد همگام‌سازی Control File در هنگام استریمینگ شبکه دور زده شود.

• و) بلافاصله قبل از شروع فرآیند کپی، یک Checkpoint کلی سیستم را از طریق دستور ALTER SYSTEM CHECKPOINT اجبار کند تا بافرهای حافظه تخلیه شوند.

پاسخ صحیح و توضیحات:

• پاسخ صحیح: الف

• چرا صحیح است: هنگام مواجهه با دیتافایل‌های بسیار بزرگ در Active Duplication، یک کانال واحد به راحتی می‌تواند تبدیل به گلوگاه شود زیرا به طور سنتی هر فایل در هر لحظه به یک کانال اختصاص می‌یابد. با استفاده از عبارت SECTION SIZE (مثلاً SECTION SIZE 50G)، RMAN یک دیتافایل غول‌پیکر را به بخش‌های منطقی کوچک‌تر و قابل مدیریت تقسیم می‌کند. سپس این بخش‌ها را به طور همزمان بین تمام کانال‌های موازی موجود توزیع می‌کند، از ظرفیت شبکه به طور موثرتر استفاده می‌کند و از Timeoutهای تک-کاناله جلوگیری می‌کند.

• چرا گزینه‌های دیگر نادرست هستند:

  • گزینه ب نادرست است: تبدیل دیتابیس به CDB ساختار معماری را تغییر می‌دهد اما الگوریتم‌های پایه تخصیص دیتافایل RMAN را به طور خودکار تغییر نمی‌دهد.

  • گزینه ج نادرست است: تغییر LOG_BUFFER به عملکرد نوشتن Redo در تراکنش‌های سنگین کمک می‌کند اما رفتار کانال بک‌آپ فیزیکی یا گلوگاه‌های سریال‌سازی شبکه را حل نمی‌کند.

  • گزینه د نادرست است: حذف محدودیت‌های ساختاری مانند Primary Keyها خطرناک است، یکپارچگی داده‌ها را تخریب می‌کند و اندازه تخصیص فیزیکی دیتافایل را به طور قابل توجهی کاهش نمی‌دهد.

  • گزینه ه نادرست است: گزینه NOFILENAMECHECK صرفاً مانع از شکست RMAN در صورت مطابقت مسیرهای مقصد با منبع می‌شود و هیچ تاثیری بر موازی‌سازی استریم شبکه یا عملکرد ندارد.

  • گزینه و نادرست است: اجبار Checkpoint هدرهای دیتافایل را روی دیسک بروز می‌کند، اما نحوه بسته‌بندی یا موازی‌سازی بلوک‌ها توسط RMAN در لوله‌های شبکه را تغییر نمی‌دهد.

سوال ۳: جداسازی کانتینر و تنظیمات Local Undo در محیط‌های Multitenant

یک محیط دیتابیس Multitenant اوراکل 19c با سه Pluggable Database (PDB) پیکربندی شده است. یک توسعه‌دهنده تازه‌کار یک تراکنش دسته‌ای (Batch) بهینه نشده را در PDB_PROD_01 اجرا می‌کند که تمام فضای Undo موجود را مصرف کرده و باعث شکست تراکنش محلی می‌شود. با این حال، تراکنش‌های سنگین همزمان در PDB_PROD_02 بدون هیچ اختلالی به کار خود ادامه می‌دهند. کدام پیکربندی معماری این جداسازی شکست را توجیه می‌کند؟

• الف) دیتابیس Container (CDB) صراحتاً در سطح Root Container با دستور ALTER SYSTEM SET UNDO_MANAGEMENT = MANUAL پیکربندی شده است.

• ب) حالت Local Undo در دیتابیس فعال است (local undo on)، که به هر دیتابیس قابل اتصال مستقل، یک Undo Tablespace اختصاصی می‌دهد.

• ج) Root Container به طور خودکار یک Undo Tablespace واحد را به اشتراک می‌گذارد اما اولویت PDBها را بر اساس ترتیب الفبایی نام‌گذاری تعیین می‌کند.

• د) Resource Manager را به گونه‌ای پیکربندی کرده که هر نشستی را که از حد مجاز تخصیص Undo در ۶۰ ثانیه فراتر رود، قطع کند.

• ه) سیستم‌عامل زیرین به طور پویا PDB_PROD_02 را هرگاه شکست تخصیص حافظه رخ دهد به ذخیره‌ساز مجازی Flash مپ می‌کند.

• و) کانتینر PDB_PROD_01 عمداً در حالت READ ONLY باز شده است که بلوک‌های حافظه داخلی آن را به طور خودکار جدا می‌کند.

پاسخ صحیح و توضیحات:

• پاسخ صحیح: ب

• چرا صحیح است: از نسخه 12c Release 2 به بعد و در نسخه‌های 19c/21c، اوراکل به طور پیش‌فرض از "Local Undo Mode" استفاده می‌کند. در این پیکربندی، هر Pluggable Database (PDB) Undo Tablespace داخلی و مستقل خود را مدیریت می‌کند. اگر یک کوئری بهینه نشده یا یک عملیات دسته‌ای بزرگ در یک PDB تمام فضا را مصرف کند، شکست کاملاً محدود به آن کانتینر خاص می‌شود. سایر دیتابیس‌های قابل اتصال دست‌نخورده باقی مانده و به آرامی اجرا می‌شوند.

• چرا گزینه‌های دیگر نادرست هستند:

  • گزینه الف نادرست است: قرار دادن مدیریت Undo روی حالت دستی، مدیریت خودکار را کاملاً غیرفعال کرده و سیستم را به سگمنت‌های Rollback قدیمی باز می‌گرداند که عملیات مدرن Multitenant را مختل می‌کند.

  • گزینه ج نادرست است: دیتابیس‌های اوراکل هرگز منابع حیاتی سیستم مانند بلوک‌های Undo را بر اساس ترتیب الفبایی نام اشیاء تخصیص نمی‌دهند.

  • گزینه د نادرست است: در حالی که Resource Manager مصرف CPU و I/O را کنترل می‌کند، اما نمی‌تواند یک Undo Tablespace مشترک را از اتمام فضا در صورتی که حالت Shared Undo فعال باشد، محافظت کند.

  • گزینه ه نادرست است: سیستم‌عامل‌ها نمی‌توانند ساختارهای فیزیکی دیسک را به طور پویا فراهم کنند یا کانتینرهای خاص را در حین یک خطای تراکنش فعال به لایه‌های Flash مجزا هدایت کنند.

  • گزینه و نادرست است: اگر کانتینر در حالت READ ONLY باز می‌شد، توسعه‌دهنده بلافاصله خطای محدودیت نوشتن را دریافت می‌کرد و اصلاً نمی‌توانست تراکنشی اجرا کند که فضای Undo را مصرف نماید.

چه انتظاراتی داشته باشید

• به تست‌های سوالات مصاحبه خوش آمدید تا شما را برای ارزیابی سوالات مصاحبه DBA اوراکل آماده کنیم

• می‌توانید آزمون‌ها را هر چند بار که بخواهید تکرار کنید

• این یک بانک سوالات اصیل و بسیار گسترده است

• در صورت داشتن سوال، از پشتیبانی مدرسان بهره‌مند می‌شوید

• هر سوال دارای یک توضیح دقیق است

• سازگار با موبایل از طریق اپلیکیشن Udemy

امیدواریم تا الان متقاعد شده باشید! سوالات بسیار بیشتری در داخل دوره وجود دارد.