RESOURCE ROLE و UNLIMITED TABLESPACE

در اوراکل 11g، با اهدای نقش resource به یک کاربر، همزمان مجوز unlimited tablespace هم به آن کاربر داده خواهد شد و کاربر قادر خواهد بود حتی در system tablespace هم اطلاعاتی را ذخیره کند.

در نسخه 12c، مجوز unlimited tablespace از role resource گرفته شده است.

(بیشتر…)

ویژگی Data Redaction در اوراکل 12c

در صورتی که بخواهیم قسمتی از اطلاعات یک جدول، برای تعدادی از کاربران مخفی و یا غیرواقعی نمایش داده شود، می توانیم از ویژگی data redaction که از اوراکل 12c ارائه شد، استفاده کنیم به این صورت که ابتدا کاربر پرس و جویی را اجرا کرده و منتظر دریافت خروجی خواهد بود، بر روی داده درخواستی کاربر، عملیات redact انجام شده و در نهایت کاربر مورد نظر، داده را بر اساس آن فرمتی که از قبل تعریف کرده ایم، خواهد دید.

(بیشتر…)

READ ANY TABLE

مجوز select any table، علاوه بر امکان مشاهده اطلاعات جداول، قابلیتهای اضافه ای را هم به کاربران خواهد داد نظیر:

select * from .. for update;

مجوز جدیدی در اوراکل 12c ارائه شد که read any table نام دارد و می توان از آن به عنوان جایگزینی برای select any table استفاده کرد این مجوز، صرفا امکان مشاهده اطلاعات را به کاربران خواهد داد و قابلیتهای اضافه مربوط به مجوز select any table را ندارد.

(بیشتر…)

FAR SYNC DATA GUARD

یکی از قابلیتهای جدیدی که در اوراکل 12c ارائه شد، FAR SYNC DATA GUARD می باشد که شباهت هایی هم به cascade standby دارد.

با کمک این ویژگی، می توان از ماشین(یا سرور) سومی که نقش واسط را بین سرور primary و data guard ایفا می کند، استفاده کرد بطوری که redoها از سرور primary به این سرور ارسال شده و سپس از آنجا به سمت دیتاگارد هدایت شوند.

(بیشتر…)

قابلیت PLUGGABLE DATABASE در اوراکل 12cR1

فرض کنید نقش مدیریت مجموعه “نگهداشت دیتابیس” را در سازمانی برعهده دارید که در آن سازمان، دیتابیسهای متعددی با حجم بارکاری بسیار پایین وجود دارند با توجه به بارکاری کم این دیتابیسها، اگر به ازای هر دیتابیس از سرور و یا ماشین مجزایی استفاده کنید، با چالشهای احتمالی زیادی روبه رو خواهید شد چالشهایی از قبیل:

1.ممکن است نیاز شود تعداد dbaها را افزایش دهید.

2.با توجه به حجم پایین بارکاری دیتابیسها، احتمالا از همه منابع سرور استفاده نخواهد شد و در صورت عدم استفاده از virtualization، ممکن است منابع زیادی به هدر برود.

3.در صورتی که سیاست سازمان به راه اندازی دیتاگارد باشد، باید برای هرکدام از دیتابیسها، دیتاگارد جداگانه ای راه اندازی شود که در این صورت، نگهداری سرورها و دیتاگاردها نیاز به هزینه بالایی خواهد داشت.

4.برای گرفتن بکاپ روزانه از دیتابیسها، باید مستقلا از همه آنها بکاپ گرفت که این کار برای تعداد بالای دیتابیس می تواند پرهزینه باشد.

با این فرض که نسخه اوراکل استفاده شده در این سازمان برابر با 11g است، دو راهکار جایگزین دیگر هم برای نگهداری این دیتابیسها وجود دارد که در ادامه چالشهای هر کدام از آنها را مورد بررسی قرار خواهیم داد.

راهکار اول: تجمیع همه دیتابیسها در قالب یک دیتابیس و ایجاد اسکیمای مجزا برای هر دیتابیس. تعدادی از معایب و چالشهای این راهکار را در ادامه می بینید:

1.با اهدای مجوز و یا نقش سطح بالا یه یک کاربر، آن کاربر می تواند دیتای همه اسکیماها و یا به عبارتی دیگر همه سامانه ها را ببینید و یا تغییر دهد.

2.در صورتی که کاربری منابع زیادی را از سیستم بگیرد، روی سامانه های دیگر هم اثر منفی خواهد گذاشت.

3.این ساختار بسیار مستعد اختلاط می باشد و اگر روزی تصمیم به جدا کردن سامانه ای را گرفته اید، روشهای زمانبری را برای جدا کردن آن سامان در پیش خواهید داشت.

راهکار دوم: استفاده از چند instance و قرار دادن چند دیتابیس به صورت مجزا از هم در یک سرور. چالشهای این راهکار بسیار بدیهی است و مدیریت دیتابیسها در این محیط می تواند برای dba ایجاد چالش کند.

حال در اوراکل 12c، ویژگی جدیدی ارائه شد که نه تنها مشکلات مذکور را مرتفع می کند بلکه قابلیتهای جدیدی را هم به همراه دارد این ویژگی (pluggable database(PDB نام دارد.

(بیشتر…)

Full Database Caching

در نسخه های قبل از 12c، این قابلیت وجود داشت تا سگمنتهای خاصی که به کررات مورد استفاده قرار می گیرند را برای ماندن بیشتر در حافظه، انتخاب کنیم این کار در صورت انتخاب درست، می توانست سبب بهتر شدن کلی کارایی شود.

حال در نسخه 12c این قابلیت به وجود امد تا این اتفاق در سطح کل بانک اطلاعاتی قابل انجام باشد(البته در صورت امکان).

(بیشتر…)

cascaded standby

در صورتی که قصد داشته باشیم برای یک بانک اطلاعاتی چند استندبای داشته باشیم ولی از طرفی با محدودیتهایی همانند شبکه روبرو باشیم، می توانیم از ویژگی cascaded standby استفاده کنیم یعنی از استندبای موجود یک استندبای جدید ایجاد کنیم به طوری که استندبای جدید هیچ ارتباط مستقیمی با بانک اصلی نداشته باشد و همه اطلاعات از استندبای اول به آن منتقل می شود. برای انجام این کار، می توانیم از active duplicate استندبای اول بهره مند شویم.

(بیشتر…)