بروزرسانی کامل MV به صورت non-atomic

نویسنده مطلب: Vahid Yousefzadeh 2 Comments

در صورتی که در زمان بروزرسانی mvها، نیازی به در دسترس بودن اطلاعات وجود ندارد، می توان در هنگام بروزرسانی کامل mv، از دستور truncate به جای delete استفاده کرد.

این تغییر سبب می شود تا هیچ فردی در زمان بروز رسانی mv، به اطلاعات آن دسترسی نداشته باشد پس این روش که اصطلاحا non-atomic هم نامیده می شود، خطراتی از قبیل لغو شدن بروزرسانی در حین درج اطلاعات را به همراه دارد که به همین دلیل استفاده کمتری نسبت به شیوه معمول دارد هر چند با استفاده از truncate به جای delete، سرعت بروزرسانی کامل(complete) بسیار افزایش خواهد یافت و کاهش حجم آرشیولاگ ایجاد شده دیتابیس هم از دیگر ثمرات آن می باشد.

(بیشتر…)

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

نویسنده مطلب: Vahid Yousefzadeh 7 Comments

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

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

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

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

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

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

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

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

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

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

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

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

(بیشتر…)

Full Database Caching

نویسنده مطلب: Vahid Yousefzadeh 1 Comment

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

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

(بیشتر…)

Full Transportable Export/Import

نویسنده مطلب: Vahid Yousefzadeh 1 Comment

قبلا در مطلبی نحوه ارتقا به اوراکل 12c از طریق ویژگی Transportable Tablespace را توضیح دادیم همانطور که در ان مطلب اشاره شد، ارتقا از طریق Transportable Tablespace زمانی روش مناسبی خواهد بود که اطلاعات کاربران در tablespaceهای غیرسیستمی موجود باشند.

در صورتی که حم قابل توجهی از اطلاعات کاربران در درون tablespaceهای سیستمی قرار موجود باشند، شاید به صرفه باشد این اطلاعات را به طور مستقیم به بانک جدید منتقل کنیم(بدون انتقال به user tablespaceها) برای این کار می توانیم از ویژگی Full Transportable Export/Import استفاده کنیم.

فرق اصلی این روش با روش قبلی(Transportable Tablespace) در استفاده از عبارت full=y transportable=always در هنگام تهیه دامپ می باشد که سبب خواهد شد تا اطلاعات کاربری موجود در tablespaceهای سیستمی از طریق EXPDP، همراه اطلاعات متادیتا در دامپ ذخیره شوند.

(بیشتر…)