Oracle Database قدرتمند است، اما لایسنس، پشتیبان‌گیری، بازیابی از فاجعه و مدیریت کارایی آن تخصص می‌طلبد. خطرات لایسنس در محیط‌های مجازی، RMAN، Data Guard، وصله‌گذاری، AWR و مدل DBA برون‌سپاری‌شده را به زبان ساده توضیح می‌دهیم.
Oracle Database پشتوانه بسیاری از برنامه‌های حیاتی است، از بانکداری و تولید گرفته تا بخش دولتی و خرده‌فروشی. این پلتفرمی قدرتمند، بالغ و انعطاف‌پذیر است. اما این قدرت بهایی دارد: اگر لایسنس آن نادرست باشد، ریسک مالی جدی ایجاد می‌کند؛ اگر پشتیبان‌گیری آن نادرست باشد، هنگام حادثه غافلگیری‌های ناخوشایندی به بار می‌آورد؛ و اگر به‌خوبی پایش نشود، مشکلات کارایی فرایندهای کسب‌وکار را کند می‌کند.
در این مقاله چهار حوزه اصلی مدیریت پایگاه داده Oracle، یعنی لایسنس، پشتیبان‌گیری، کارایی و پشتیبانی را بررسی می‌کنیم و تفاوت استخدام یک DBA تمام‌وقت با استفاده از سرویس DBA برون‌سپاری‌شده را شرح می‌دهیم.
لایسنس Oracle: نادیده‌گرفته‌ترین ریسک
لایسنس در ظاهر موضوعی فنی نیست، اما مستقیماً بر تصمیم‌های زیرساختی اثر می‌گذارد. نصب Oracle از نظر فنی آسان است؛ محاسبه درست نیاز لایسنس تخصص می‌خواهد.
ویرایش‌ها و معیارها
به‌طور کلی، Oracle Database در قالب Standard Edition 2 و Enterprise Edition عرضه می‌شود. لایسنس می‌تواند بر اساس معیار پردازنده (Processor) یا Named User Plus باشد. Standard Edition 2 برای ظرفیت سروری که روی آن اجرا می‌شود محدودیت دارد. Enterprise Edition مجموعه امکانات گسترده‌تری ارائه می‌دهد و بسیاری از قابلیت‌های پیشرفته به‌صورت گزینه‌ها و بسته‌هایی با لایسنس جداگانه عرضه می‌شوند.
در مجازی‌سازی محتاط باشید
بزرگ‌ترین ریسک‌ها معمولاً در محیط‌های مجازی پدیدار می‌شوند. ممکن است Oracle برخی فناوری‌های مجازی‌سازی را به‌عنوان روش پارتیشن‌بندی‌ای که لایسنس را محدود می‌کند به رسمیت نشناسد. در این صورت، نه‌فقط پردازنده‌های ماشین مجازی‌ای که Oracle روی آن اجرا می‌شود، بلکه همه میزبان‌های فیزیکی‌ای که آن ماشین مجازی می‌تواند روی آن‌ها اجرا شود، ممکن است در محاسبه لایسنس لحاظ شوند. در یک کلاستر مجازی‌سازی بزرگ، این می‌تواند به نیاز لایسنسی بسیار بیشتر از حد انتظار بینجامد.
قواعد ممکن است بسته به قرارداد شما، فناوری مجازی‌سازی مورد استفاده و سیاست‌های جاری لایسنس متفاوت باشد. پیش از انتقال Oracle به محیط مجازی یا ساخت یک کلاستر جدید، اکیداً توصیه می‌کنیم از یک مشاور متخصص لایسنس مشورت بگیرید. نقش ما به‌عنوان تیم فنی این است که به شما کمک کنیم بارهای کاری Oracle را طوری جانمایی کنید که از نظر لایسنس قابل تفکیک باشند و گزینه‌های معماری را با هم مقایسه کنیم.
قابلیت‌ها و لایسنس‌ها
برخی ابزارها به‌صورت پیش‌فرض نصب می‌شوند اما استفاده از آن‌ها لایسنس جداگانه می‌خواهد. برای مثال، برخی ابزارهای تشخیصی که در تحلیل کارایی زیاد استفاده می‌شوند، در Enterprise Edition به لایسنس بسته اضافی نیاز دارند. استفاده ناآگاهانه از این قابلیت‌ها می‌تواند در ممیزی لایسنس مشکل‌ساز شود. یک DBA خوب می‌داند کدام قابلیت تحت کدام لایسنس قابل استفاده است و محیط را بر همین اساس پیکربندی می‌کند.
پشتیبان‌گیری: راهبرد درست با RMAN
RMAN (Recovery Manager)، ابزار پشتیبان‌گیری داخلی Oracle، روش استاندارد برای تهیه نسخه‌های پشتیبان سازگار و قابل بازیابی است. کپی کردن فایل‌های پایگاه داده در سطح سیستم‌عامل در حالی که پایگاه داده باز است، روش قابل اعتمادی نیست.
یک راهبرد سالم RMAN معمولاً شامل این موارد است:
- حالت ARCHIVELOG: نگهداری redo logهای بایگانی‌شده، بازیابی به یک نقطه زمانی مشخص را ممکن می‌کند. این حالت تقریباً همیشه برای پایگاه‌های داده عملیاتی ضروری است.
- پشتیبان کامل و افزایشی: یک پشتیبان level 0 هفتگی و پشتیبان‌های افزایشی level 1 روزانه، مدل شروع رایجی است.
- پشتیبان archive log: در طول روز به‌دفعات تهیه می‌شود تا بازه از دست رفتن داده کوچک‌تر شود.
- پشتیبان control file و parameter file: قابلیت autobackup برای control file باید فعال باشد.
- سیاست نگهداری: تعیین می‌کند تا چه زمانی به عقب می‌توانید بازگردید و نسخه‌های پشتیبان قدیمی را مرتب پاک‌سازی می‌کند.
یک نسخه از پشتیبان‌های RMAN باید به خارج از سرور، و ترجیحاً به فضای ذخیره‌سازی تغییرناپذیر، منتقل شود. باج‌افزار یا یک فرمان اشتباه می‌تواند نسخه‌های پشتیبان روی سرور را هم از بین ببرد.
در نهایت، نسخه‌های پشتیبان باید اعتبارسنجی شوند و به‌طور منظم در یک محیط جداگانه بازیابی شوند. فرمان‌های اعتبارسنجی RMAN مفیدند اما جایگزین آزمون بازیابی واقعی نمی‌شوند.
بازیابی از فاجعه: Data Guard
بازیابی یک پایگاه داده بزرگ از نسخه پشتیبان ممکن است ساعت‌ها طول بکشد. وقتی سیستم‌های حیاتی به زمان توقف کوتاه‌تری نیاز دارند، Oracle Data Guard وارد عمل می‌شود. Data Guard تغییرات را به‌طور پیوسته از پایگاه داده اصلی به یک پایگاه داده standby ارسال می‌کند. اگر پایگاه داده اصلی دچار مشکل شود، standby به‌سرعت قابل راه‌اندازی است.
- Physical standby: نسخه‌ای در سطح بلاک از پایگاه داده اصلی و پرکاربردترین مدل.
- حالت‌های حفاظت: توازن‌های متفاوتی میان کارایی و عدم از دست رفتن داده. انتخاب باید با توجه به فاصله و تأخیر شبکه میان دو سایت انجام شود.
- Switchover و failover: هر دو باید به‌طور منظم آزمایش شوند.
Data Guard همراه با Enterprise Edition در دسترس است و برخی کاربردهای پیشرفته، مانند باز نگه داشتن standby برای گزارش‌گیری، ممکن است به لایسنس اضافی نیاز داشته باشند. برای محیط‌های Standard Edition 2 می‌توان رویکردهای جایگزینی را بر پایه ارسال archive logها به‌صورت دستی یا با ابزارهای شخص ثالث در نظر گرفت. قرار دادن standby در یک دیتاسنتر دیگر، پایه یک برنامه بازیابی از فاجعه است.
مدیریت وصله‌ها
Oracle در فواصل منظم برای آسیب‌پذیری‌های امنیتی و باگ‌ها وصله منتشر می‌کند. به تعویق انداختن طولانی وصله‌ها ریسک امنیتی را افزایش می‌دهد؛ اعمال بی‌برنامه آن‌ها می‌تواند برنامه‌ها را از کار بیندازد. یک فرایند متوازن وصله‌گذاری شامل این مراحل است:
- ارزیابی ارتباط وصله‌های منتشرشده با محیط شما.
- اعمال آن‌ها ابتدا در محیط آزمایشی و اعتبارسنجی با تیم برنامه.
- برنامه‌ریزی یک پنجره نگهداری در محیط عملیاتی و آماده‌سازی مراحل بازگشت.
- در محیط‌های Data Guard، وصله‌گذاری standby در ابتدا برای کاهش زمان توقف.
- پیگیری نسخه‌هایی که به پایان دوره پشتیبانی می‌رسند و برنامه‌ریزی ارتقا.
مدیریت کارایی
شکایت‌های مربوط به کارایی معمولاً با جمله «سیستم کند است» مطرح می‌شوند. علت ممکن است پایگاه داده، برنامه، ذخیره‌سازی یا شبکه باشد. تشخیص درست نیازمند اندازه‌گیری است.
- گزارش‌های AWR و ASH: در Enterprise Edition و با لایسنس بسته تشخیصی مربوط، با جزئیات نشان می‌دهند پایگاه داده در یک بازه مشخص مشغول چه کاری بوده است. اگر لایسنس شما آن‌ها را پوشش نمی‌دهد، می‌توان از جایگزین‌هایی مانند Statspack استفاده کرد.
- Wait eventها: نشان می‌دهند پایگاه داده زمان خود را کجا صرف می‌کند. خواندن از دیسک، قفل‌شدگی و انتظارهای شبکه هر یک راه‌حل متفاوتی دارند.
- بهینه‌سازی SQL: بیشتر کندی‌ها معمولاً از تعداد انگشت‌شماری کوئری ناشی می‌شود. رفع یک ایندکس جاافتاده یا یک execution plan ضعیف بسیار ارزان‌تر از افزودن سخت‌افزار است.
- حافظه و ذخیره‌سازی: تنظیمات SGA و PGA و تأخیر ذخیره‌سازی باید به‌طور منظم پایش شوند.
هدف کار روی کارایی این است که پیش از افزایش بودجه سخت‌افزار، مطمئن شوید منابع موجود به‌خوبی استفاده می‌شوند. در محیط‌های Oracle که لایسنس آن‌ها بر اساس هسته است، این مستقیماً به صرفه‌جویی در هزینه منجر می‌شود.
پایش و بررسی‌های پیشگیرانه
در یک محیط Oracle که به‌خوبی مدیریت می‌شود، بیشتر مشکلات پیش از آنکه کاربران متوجه شوند شناسایی می‌شوند. موارد کلیدی برای پایش عبارت‌اند از:
- میزان استفاده از فضای tablespace و archive log
- وضعیت موفقیت کارهای پشتیبان‌گیری
- تأخیر همگام‌سازی Data Guard
- خطاهای موجود در alert log
- نشست‌های طولانی‌مدت و قفل‌ها
- حساب‌های کاربری، دسترسی‌ها و سیاست‌های رمز عبور
امنیت و مدیریت دسترسی
پایگاه‌های داده هدف واقعی مهاجمان هستند. شکاف‌های امنیتی رایج در محیط‌های Oracle به‌ندرت پیچیده‌اند: حساب‌هایی با رمز عبور پیش‌فرض تغییرنیافته، کاربران برنامه با دسترسی‌های بیش از حد، یا پورت‌های listener که به روی کل شبکه باز هستند. تدابیر پایه عبارت‌اند از:
- قفل کردن حساب‌های پیش‌فرض بلااستفاده و اعمال سیاست رمز عبور قوی
- اعطای فقط دسترسی‌های مورد نیاز به کاربران برنامه
- محدود کردن پورت‌های پایگاه داده به سرورهای برنامه با فایروال
- فعال کردن ممیزی برای عملیات حیاتی و بازبینی منظم آن
- رمزگذاری نسخه‌های پشتیبان و داده‌های حساس، با بررسی پیشاپیش الزامات لایسنس قابلیت‌های رمزگذاری
DBA داخلی یا DBA برون‌سپاری‌شده؟
یافتن و نگه داشتن یک DBA باتجربه و تمام‌وقت Oracle دشوار است. وابستگی به یک نفر به‌خودی‌خود ریسک است: مرخصی، بیماری یا استعفا می‌تواند به از دست رفتن دانش حیاتی منجر شود. مدل DBA برون‌سپاری‌شده به این مسائل به شکل دیگری پاسخ می‌دهد:
| موضوع | DBA داخلی | سرویس DBA برون‌سپاری‌شده |
|---|---|---|
| گستره تخصص | محدود به تجربه یک نفر | تیمی با تجربه در سناریوهای متعدد |
| تداوم | ریسک در زمان مرخصی و ترک کار | تیم جایگزین، فرایندهای مستند |
| هزینه | حقوق تمام‌وقت و آموزش | سرویس متناسب با نیاز شما |
| پشتیبانی خارج از ساعت کاری | ایجاد برنامه کشیک دشوار است | بر اساس سطح سرویس تعریف می‌شود |
| شناخت کسب‌وکار | بسیار بالا | به‌مرور شکل می‌گیرد و با مستندسازی پشتیبانی می‌شود |
برای بسیاری از سازمان‌ها کارآمدترین مدل ترکیبی است: یک تیم داخلی که برنامه را به‌خوبی می‌شناسد، به‌همراه پشتیبانی DBA برون‌سپاری‌شده برای نگهداری روزمره، پشتیبان‌گیری، پایش و موارد اضطراری.
پرسش‌های متداول
آیا اجرای Oracle در فضای ابری هزینه لایسنس مرا افزایش می‌دهد؟
این به زیرساخت مورد استفاده و شرایط قرارداد لایسنس شما بستگی دارد. در برخی محیط‌ها با معماری درست می‌توان هزینه‌ها را کنترل کرد؛ در برخی دیگر ممکن است افزایش غیرمنتظره‌ای رخ دهد. پیش از تصمیم به مهاجرت، از یک مشاور لایسنس مشورت بگیرید.
آیا پشتیبان ماشین مجازی به‌جای RMAN کافی است؟
پشتیبان ماشین مجازی برای بازیابی کل سرور مفید است اما به‌عنوان تنها لایه حفاظت Oracle توصیه نمی‌شود. RMAN قابلیت‌های ویژه پایگاه داده مانند بازیابی به نقطه زمانی و اعتبارسنجی در سطح بلاک را ارائه می‌دهد. استفاده هم‌زمان از هر دو سالم‌ترین رویکرد است.
آیا هر محیطی به Data Guard نیاز دارد؟
خیر. این به میزان زمان توقفی بستگی دارد که سیستم می‌تواند تحمل کند. جایی که چند ساعت توقف قابل قبول است، نسخه‌های پشتیبان RMAN که به‌خوبی آزموده شده‌اند ممکن است کافی باشند.
قیمت سرویس DBA برون‌سپاری‌شده چگونه تعیین می‌شود؟
بر اساس تعداد، حجم و میزان حیاتی بودن پایگاه‌های داده و ساعات پشتیبانی مورد انتظار تعیین می‌شود. در CloudRUX، برای سرویس‌های پایگاه داده بنا به درخواست پیش‌فاکتور ارائه می‌شود.
سرویس‌های پایگاه داده Oracle در CloudRUX
هر کسی می‌تواند سروری برای اجرای Oracle به شما اجاره دهد؛ ارزش واقعی در این است که بدانید نسخه‌های پشتیبان آزموده می‌شوند، وصله‌ها طبق برنامه اعمال می‌شوند و وقتی مشکلی پیش می‌آید، مهندسی هست که سیستم شما را می‌شناسد. CloudRUX سرویس‌های پایش، پشتیبان‌گیری، کارایی و بازیابی از فاجعه را برای Oracle و دیگر پلتفرم‌های پایگاه داده با مهندسانی که به فارسی و ترکی صحبت می‌کنند ارائه می‌دهد و داده‌های شما در ترکیه باقی می‌ماند. برای جزئیات صفحه راهکارهای پایگاه داده ما را ببینید، یا برای ارزیابی محیط خود با ما تماس بگیرید.