غیرفعال سازی logging بهنگام impdp

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

برای بهبود سرعت برگرداندن اطلاعات dumpfile، می توان از پارامتر logging به هنگام اجرای دستور impdp استفاده کرد و با تنظیم این پارامتر(که از اوراکل 12c ارائه شد) به مقدار DISABLE_ARCHIVE_LOGGING:Y، مانع از ایجاد آرشیولاگ در زمان impdp شد:

 impdp directory=usef dumpfile=c.dmp schemas=usef  TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y

Import: Release 12.1.0.2.0 – Production on Tue Jul 5 15:02:28 2016

. . imported “USEF”.”COM_LOC”                      533.490 MB    226333 rows

در صورت استفاده از data guard در چنین محیطی، اطلاعات import شده به سمت data guard منتقل نخواهند شد و با رجوع به این جدول در محیط data guard، با خطای زیر مواجه خواهیم شد:

select count(*) from usef.com_loc

ORA-01578: ORACLE data block corrupted (file # 6, block # 555)

ORA-01110: data file 6: ‘/u02/oradata/usef2/datafile/users.258.916411623’

ORA-26040: Data block was loaded using the NOLOGGING option

البته اگر دیتابیس در حالت force logging قرار داشته باشد، امکان استفاده از چنین ویژگی ای وجود ندارد(معمولا قبل از راه اندازی data guard، اوراکل تاکید دارد تا این گزینه فعال شود).

 این ویژگی در سطح ایندکس هم قابل استفاده می باشد:

TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y:INDEX

ویژگی های جدید اوراکل در نسخه 12c

نویسنده مطلب: Vahid Yousefzadeh Leave a comment

بانک اطلاعاتی اوراکل با هر نسخه جدیدی که ارائه می کند معمولا بسیاری از باگهای ایجاد شده در نسخه های قبلی را برطرف کرده و علاوه بر آن، ویژگی های جدیدی را هم عرضه می کند.

به همین منوال، اوراکل در نسخه 12c، بیش از 500 ویژگی جدید را ارائه کرده است که در این مقاله قصد داریم بعضی از این ویژگی ها را مورد بررسی قرار دهیم.

(بیشتر…)

بازیابی دیتافایل بانک اصلی از استندبای

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

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

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

این کار در نسخه 12c، تنها با استفاده از یک دستور در محیط RMAN، قابل انجام می باشد:

(بیشتر…)

RESOURCE ROLE و UNLIMITED TABLESPACE

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

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

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

(بیشتر…)

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

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

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

(بیشتر…)

READ ANY TABLE

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

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

select * from .. for update;

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

(بیشتر…)

MATERIALIZED VIEW

نویسنده مطلب: Vahid Yousefzadeh Leave a comment

همانطور که می دانید ویو(view) ذخیره پرس و جو در بانک اطلاعاتی به یک اسم خاص می باشد که عمده  کاربرد آن در امنیت و استقلال منظقی داده ها می باشد ویوها هیچ فضایی را برای ذخیره داده مصرف نمی کنند و با هر بار اجرا، پرس وجو را هم اجرا می کنند. همانند ویو، شی دیگری نیز وجود دارد که شامل یک پروس و جو می باشد که برخلاف ویو، خروجی پرس و جو را هم در جایی ذخیره می کند و در مواقع ضروری می توان آن را بروز کرد این شی Materialized View نام دارد.

(بیشتر…)

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

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

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

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

(بیشتر…)

Full Database Caching

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

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

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

(بیشتر…)