……….آموزش، مشاوره و پشتیبانی……….
مجوز select any table، علاوه بر امکان مشاهده اطلاعات جداول، قابلیتهای اضافه ای را هم به کاربران خواهد داد نظیر:
select * from .. for update;
مجوز جدیدی در اوراکل 12c ارائه شد که read any table نام دارد و می توان از آن به عنوان جایگزینی برای select any table استفاده کرد این مجوز، صرفا امکان مشاهده اطلاعات را به کاربران خواهد داد و قابلیتهای اضافه مربوط به مجوز select any table را ندارد.
(بیشتر…)یکی از قابلیتهای جدیدی که در اوراکل 12c ارائه شد، FAR SYNC DATA GUARD می باشد که شباهت هایی هم به cascade standby دارد.
با کمک این ویژگی، می توان از ماشین(یا سرور) سومی که نقش واسط را بین سرور primary و data guard ایفا می کند، استفاده کرد بطوری که redoها از سرور primary به این سرور ارسال شده و سپس از آنجا به سمت دیتاگارد هدایت شوند.
(بیشتر…)در اوراکل 12c می توان همراه با اجرای دستورات DMLای بر روی رکوردهای یک جدول، دستورات DDLای زیر را به صورت انلاین بر روی جدول یا ابجکتهای مرتبط با آن، انجام داد:
ALTER INDEX UNUSABLE
SET COLUMN UNUSED
DROP INDEX
DROP CONSTRAINT
(بیشتر…)پارامتر enable_ddl_logging که از اوراکل 12c اضافه شد قابلیت لاگ گیری از دستورات DDLای را در فایلی مجزا ارائه می دهد دستورات DDLای از قبیل:
CREATE|ALTER|DROP|TRUNCATE TABLE
DROP USER
CREATE|ALTER|DROP PACKAGE|FUNCTION|VIEW|SYNONYM|SEQUENCE
(بیشتر…)فرض کنید نقش مدیریت مجموعه “نگهداشت دیتابیس” را در سازمانی برعهده دارید که در آن سازمان، دیتابیسهای متعددی با حجم بارکاری بسیار پایین وجود دارند با توجه به بارکاری کم این دیتابیسها، اگر به ازای هر دیتابیس از سرور و یا ماشین مجزایی استفاده کنید، با چالشهای احتمالی زیادی روبه رو خواهید شد چالشهایی از قبیل:
1.ممکن است نیاز شود تعداد dbaها را افزایش دهید.
2.با توجه به حجم پایین بارکاری دیتابیسها، احتمالا از همه منابع سرور استفاده نخواهد شد و در صورت عدم استفاده از virtualization، ممکن است منابع زیادی به هدر برود.
3.در صورتی که سیاست سازمان به راه اندازی دیتاگارد باشد، باید برای هرکدام از دیتابیسها، دیتاگارد جداگانه ای راه اندازی شود که در این صورت، نگهداری سرورها و دیتاگاردها نیاز به هزینه بالایی خواهد داشت.
4.برای گرفتن بکاپ روزانه از دیتابیسها، باید مستقلا از همه آنها بکاپ گرفت که این کار برای تعداد بالای دیتابیس می تواند پرهزینه باشد.
با این فرض که نسخه اوراکل استفاده شده در این سازمان برابر با 11g است، دو راهکار جایگزین دیگر هم برای نگهداری این دیتابیسها وجود دارد که در ادامه چالشهای هر کدام از آنها را مورد بررسی قرار خواهیم داد.
راهکار اول: تجمیع همه دیتابیسها در قالب یک دیتابیس و ایجاد اسکیمای مجزا برای هر دیتابیس. تعدادی از معایب و چالشهای این راهکار را در ادامه می بینید:
1.با اهدای مجوز و یا نقش سطح بالا یه یک کاربر، آن کاربر می تواند دیتای همه اسکیماها و یا به عبارتی دیگر همه سامانه ها را ببینید و یا تغییر دهد.
2.در صورتی که کاربری منابع زیادی را از سیستم بگیرد، روی سامانه های دیگر هم اثر منفی خواهد گذاشت.
3.این ساختار بسیار مستعد اختلاط می باشد و اگر روزی تصمیم به جدا کردن سامانه ای را گرفته اید، روشهای زمانبری را برای جدا کردن آن سامان در پیش خواهید داشت.
راهکار دوم: استفاده از چند instance و قرار دادن چند دیتابیس به صورت مجزا از هم در یک سرور. چالشهای این راهکار بسیار بدیهی است و مدیریت دیتابیسها در این محیط می تواند برای dba ایجاد چالش کند.
حال در اوراکل 12c، ویژگی جدیدی ارائه شد که نه تنها مشکلات مذکور را مرتفع می کند بلکه قابلیتهای جدیدی را هم به همراه دارد این ویژگی (pluggable database(PDB نام دارد.
در نسخه های قبل از 12c، این قابلیت وجود داشت تا سگمنتهای خاصی که به کررات مورد استفاده قرار می گیرند را برای ماندن بیشتر در حافظه، انتخاب کنیم این کار در صورت انتخاب درست، می توانست سبب بهتر شدن کلی کارایی شود.
حال در نسخه 12c این قابلیت به وجود امد تا این اتفاق در سطح کل بانک اطلاعاتی قابل انجام باشد(البته در صورت امکان).
(بیشتر…)قبلا در مطلبی نحوه ارتقا به اوراکل 12c از طریق ویژگی Transportable Tablespace را توضیح دادیم همانطور که در ان مطلب اشاره شد، ارتقا از طریق Transportable Tablespace زمانی روش مناسبی خواهد بود که اطلاعات کاربران در tablespaceهای غیرسیستمی موجود باشند.
در صورتی که حم قابل توجهی از اطلاعات کاربران در درون tablespaceهای سیستمی قرار موجود باشند، شاید به صرفه باشد این اطلاعات را به طور مستقیم به بانک جدید منتقل کنیم(بدون انتقال به user tablespaceها) برای این کار می توانیم از ویژگی Full Transportable Export/Import استفاده کنیم.
فرق اصلی این روش با روش قبلی(Transportable Tablespace) در استفاده از عبارت full=y transportable=always در هنگام تهیه دامپ می باشد که سبب خواهد شد تا اطلاعات کاربری موجود در tablespaceهای سیستمی از طریق EXPDP، همراه اطلاعات متادیتا در دامپ ذخیره شوند.