وظایف پایه یک راهبر پایگاه داده اوراکل- آرتاراد

وظایف پایه یک راهبر پایگاه داده اوراکل

چک لیست DBA

نقش یک مدیر پایگاه داده اوراکل (Oracle DBA) می‌تواند بسیار پیچیده باشد. یک اوراکل DBA نه تنها باید به مدیریت کاربران و مدیریت فضای Tablespaceها و جداول و Viewها و Indexها بپردازد بلکه نیاز به بررسی Objectهای داخلی پایگاه داده از قبیل Triggerها و Procedureها و Functionها و بسته‌های همراه آن‎ها نیز دارد.
علاوه بر این بررسی روند جاری تغییر و تحولات پایگاه داده نیز از اهمیت خاصی برخوردار است.

به عنوان شرح وظایف روزانه انبوهی از فعالیت های روزمره باید صورت پذیرند.
با وجود گذشت چندین سال از وجود ابزارهای خودکار مدیریت و نگهداشت پایگاه داده که حتی برخی از آنان نیز در خود اوراکل نیز وجود دارند و برخی دیگر نیز از طریق تولید کنندگان جانبی عرضه شده‌اند هنوز در این بازار بسیار نوپا ابزار جامعی در این خصوص معرفی نشده است و در این شرایط است که یک DBA نیاز مبرم به تهیه یک لیست مشروح از وظایف حوزه فعالیت خویش را به شدت احساس خواهد نمود.
در خصوص لیست مذکور به بحث خواهیم پرداخت و قطعا فعالیت های ضروری دیگری نیز وجود خواهند داشت که در این بحث نیامده و هر DBA شخصاْ باید لیستی مطابق با نیازهای حوزه عملیاتی خویش را تهیه نماید.

پشتیبان‌گیری و بازگردانی
یک DBA قطعا اقدام به تهیه پشتیبان می‌نماید ولی از صحت و وضعیت خوانایی Tape پشتیبان خود اطمینان دارد؟ در خصوص چرخه فرآیند Tape و اطمینان کامل از صحت عملکرد آن در مواقع مورد نیاز وضعیت چگونه است؟
همچنین Control fileها را فراموش نکنید. زمانی که Instance را Shutdown می‌نمایید و پس از اجرای BACKUP CONTROL FILES TO TRACE فایل Trace را یافته و قبل از انجام پشتیبان در Tape نسبت به تغییرنام و انتقال آن اقدام نمایید.
همچنین در خصوص پشتیبان‌گیری از init.ora و دیگر فایل‌های اساسی پایگاه داده نظیر listener.ora و login.sql باید توجه لازم شود.

Shutdown/Restart
با این فرض که به صورت دوره‌ای اقدام به Shutdown و Restart پایگاه داده شود، این عمل موجب پاکسازی مسیر Trace file و ایجاد یک Error log جدید می‌شود.
پس از Restart یک Instance دقت کنید که یک Data cache خالی خواهید داشت، لذا می‌توانید برخی Packageها و Procedureها را در حافظه Pin نمایید در این صورت Package headerها در حافظه Cache سیستم بارگذاری خواهند شد. با این حال شاید نیاز به اجرای برخی Procedureها قبل از Package bodyها باشد، به این منظور تمامی Packageها را تنها با مقدار Null تنها جهت فعال نمودن آن‌ها برای اجرا پس از Startup سیستم و Pin نمودن آن‌ها در حافظه اجرا کنید.

مدیریت Tablespace
اطلاعات اصلی روی Tablespaceها به وسیله جداول سیستمی DBA_TABLESPACES، DBA_DATA_FILES و V$FATAFILE نگهداری می‌شود.
برای بررسی وضعیت Tablespace در سیستم درخواست DBA_FREE_SPACE اجرا شود.
درصد میزان باقیمانده هر Tablespace بررسی شود.
میزان فضای باقیمانده از هر Tablespace با درخواست DBA_EXTENTS بررسی شود.
بررسی سطرهای زنجیره‌ای داده‌ها و اثر مربوطه در بازه انتخاب داده‌ها. دستور ANALYZE TABLE نام جدول LIST CHAINED ROWS، دیتا را به جدول CHAINED_ROWS اضافه می‌نماید ولی قبل از انجام این کار توجه داشته باشید که ابتدا UTLCHAIN.SQL اجرا شود.
هنگامی که یک سطر زنجیره‌ای پیدا شد، باید نسبت به حذف و ورود مجدد سطر با کمک یک جدول موقت اقدام شود. در زمان طراحی و راه‌اندازی پایگاه داده، توجه شود که Tablespace و Rollback segmentها تنها شامل یک نوع از جداول باشند.

Redo Logs
کنترل و مدیریت Redo logها بسیار آسان است ولی نباید به فراموشی سپرده شود.
با درخواست V$LOGFILE و V$LOG وضعیت جاری و Online بودن تمام Logها و گروه‌ها بررسی شوند.

Rollback Segments
جمله معروفی از Kevin Loney “فرزند ناخلف خانواده” در این مورد وجود دارد. مدیریت Rollback Segmentها مبحثی است که باید دریک مقاله جداگانه به آن پرداخته شود.
به یاد داشته باشید که یک Instance برای ایجاد Rollback به تعداد مورد نیاز بر اساس پارامترهای init.ora و TRANSACTIONS تقسیم بر TRANSACTIONS_PER_ROLLBACK_SEGMENT اقدام خواهد نمود.
در بهترین شرایط هر پایگاه داده باید یک یا تعدادی بیشتر Tablespace تنها برای Rollback segmentها داشته باشد، رشد و انتشار بیش از اندازه در این Tablespaceها موجب ایجاد فضای بلااستفاده غیر طبیعی می‌شود.
DBA به منظور Offline یا Online و یا تغییر در ذخیره‌ساز نیاز به استفاده از دستور ALTER ROLLBACK SEGMENT دارد.
جدول سیستمی DBA_ROLLBACK_SEGS سگمنت‌های Rollback را به Tablespace که در آن وجود دارد مرتبط می‌سازد.

مدیریت Table
بررسی و صحت سنجی سریع از اینکه تمام Indexها برای هر جدولی که به آن‌ها نیاز دارد در محل مناسب خود قرار دارد و کاملاْ در وضعیت مناسبی قرار دارند، فرآیند مفیدی است.
بازسازی تمامی Indexها برای جداولی که پیش‌بینی می‌شود ساختار “btree” آن‌ها به “skewed” به همراه تعداد زیادی جدول اضافه و حذف تبدیل شود، پیشنهاد می‌گردد. جدول SYS.DBA_INDEXES شامل اطلاعاتی در خصوص هر جدول و Indexها از قبیل حجم و میزان رشد و غیره است. درصورت نیاز میزان بیشتری به منظور رشد در آینده می‌توان اختصاص دهید.

آمار و اطلاعات بهینه‌سازی
با فرض اینکه شما از روش بهینه‌سازی هزینه محور استفاده می‌کنید، بر روی جداولی که دارای رشد قابل ملاحظه‌ای هستند دستور ANALYZE TABLE COMPUTE STATISTICS را اجرا کنید. این اعمال لازم و ملزوم یکدیگرند لذا تا زمانی که شما آمار قابل اطمینانی در دست نداشته باشید شناختی از جداول پرکاربرد نخواهیم داشت، در این شرایط دانش کافی از کاربری تجاری سامانه اطلاعات مناسبی در اختیار شما قرار خواهد داد.
در جداول بزرگ پایگاه داده، بار پردازشی COMPUTE STATISTICS مقداری بالا خواهد بود، که شامل بررسی کامل جدول است و انتظار می‌رود به میزان ساخت یک Index کامل به طول انجامد و همچنین به مقدار بالایی از فضای بخش Temporary نیاز دارد (حداقل به میزان ستون‌های جدول)
به این منظور بار پردازشی بین جداولی که با COMPUTE تحلیل شده است و جداولی که با ESTIMATE به طور متناسب تقسیم می‌شود. به طور پیش فرض ESTIMATE تنها ۱۰۶۴ سطر ابتدایی را خواهد خواند که شاید گویای داده‌های شما باشد یا خیر البته امکان تعریف حجم آزمایشی نیز وجود دارد.

صحت منطقی
مناطق متعددی جهت بررسی وجود دارد که در برخی سایت‌ها توسط مستندات DBA به بررسی این نقاط پرداخته می‌شود نظیر ارتباطات والد-فرزندی موجود، گزارش گیری از هر درخواست بدون Header، البته این فعالیت از وظایف DBA نیست ولی چه فردی می‌تواند انجام دهد؟
این فعالیت می‌تواند به وسیله Triggerهای تعریف شده در سامانه انجام شود.

صحت Objectهای پایگاه داده
گزارش مختصر روی نام تمام Packageها و Procedureها و Functionها، در شرایطی که یک یا دو Object توسط شخصی تغییر یافته و یا جهت Re-Compilation انتخاب شده‌اند.
جدول SYS.DBA_SOURCE به منظور نگهداری Objectهای داخلی پایگاه داده مانند Packageها و Package bodyها و Procedureها و غیره توسط مالک Schema مدیریت می‌شود.

امنیت Role و کاربر
یک بررسی مختصر بر اطلاعات کاربران در SYS.DBA_USERS برای اطمینان از صحت Tablespaceهای پیش‌فرض و موقتی (از Tablespace سیستم به عنوان Tablespace پیش‌فرض هیچ کاربری استفاده نشود) دسترسی‌های هر کاربر در جدول DBA_SYS_PRIVS ذخیره شده است.
اگر از Role یا پروفایلی استفاده می‌شود، در SYS.DBA_ROLES و DBA_ROLE_PRIVS و DBA_PROFILES می‌توانید آنها را بیابید.
در صورتی که امنیت خاصی در سطح جدول یا ستون‌ها تعریف شده است نیاز به بررسی DBA_COL_PRIVS، DBA_COL_PRIVS_MADE، DBA_COL_PRIVS_RECD وجود دارد.
توجه داشته باشید که به راحتی می‌توانید سهم یک کاربر از Tablespace را به منظور جلوگیری از ایجاد Object برابر صفر قرار دهید.

برنامه‌ریزی ظرفیت
این مورد در مستندات استاندارد سایت ثبت شده است و با بررسی این مستندات می‌توان به میزان حداکثر فضای Tablespace و غیره پی‌برد.
شاید در بلند مدت به دست آوردن حجم کلی جداول اصلی به تشکیل یک الگوی نرخ افزایش این قبیل جداول کمک کند. برخی DBAها به منظور بررسی برای برنامه‌ریزی ظرفیت، این نتایج را در DBA Schema قرار می‌دهند.
فراموش نکنید که این آمار و ارقام تا لحظه اجرای آخرین ANALYZE TABLE COMPUTE STATISTICS به‌روز می‌باشد.
جنبه دیگر برنامه‌ریزی ظرفیت تنها از جانب میزان مورد نیاز جداول نیست بلکه برای Rollback segmentها و Temporary segmentها که نیاز به افزایش ظرفیت مانند پایگاه داده دارند نیز استفاده می‌شود.
دیتافایل‌های اضافی نیز ممکن است برای Rollback segmentها و Temporary segmentها جدید نیاز باشد.
برخی DBAها سیاست اضافه نمودن تعداد Redo log file groupsها بر اساس تعداد کاربران Online دارند.

آخرین اقدامات
همیشه مواردی برای انجام وجود دارد.
مانند بررسی وضعیت تمام Tablespaceها و Rollback segmentها که در وضعیت Online باشند.
و اینکه SQL*Net listener در حال فعالیت باشد.
بنابراین یک مستند مختصر در خصوص بررسی این موارد می‌تواند بسیار راهگشا باشد.

جمع‌بندی
همانطور که در ابتدا اشاره شد، این موارد می‌تواند تنها به عنوان یکسری آیتم‌های مختصر چک لیست باشد و هر DBA باید لیست متناسب بر اساس تجربه خود را تهیه نماید.
این موارد تنها به این دلیل ذکر شده است که شخصاْ بیشترین کاربرد را داشته و به نظر می‌تواند برای دیگران نیز مفید باشد.