Materialized View

به صورت مرسوم در پایگاه‌داده‌های حجیم جست‌وجوها مدت زمان زیادی به طول می‌انجامند و شامل تعداد زیادی Join, SUM و غیره می‌باشند. از این رو بهینه کردن مدت زمان و هزینه این جست‌وجوها یکی از دغدغه‌های راهبران این پایگاه‌داده‌ها می‌باشد. یکی از راه‌کارهای بهینه‌سازی این هزینه‌ها استفاده از Materialized View و یا به اختصار MV است. MV یک رونوشت از محدوده‌ای از داده‌ها در یک نقطه زمانی است که Segment آن از نوع جدول می‌باشد. منبعی که MV از روی آن ایجاد می‌شود محدود به یک جدول نبوده و داده‌ها می‌توانند از منبع‌های مختلفی گردآوری شوند.

در رابطه با MV دو عامل زیر از اهمیت ویژه‌ای برخوردار هستند.

1.Materialized View Creation Query

2.Refresh Materialized View

1-1            Materialized View Creation Query

جست‌وجوی ایجاد MV بر اساس تغییرات ایجاد شده در طول زمان بر روی منبع، می‌تواند ناکارآمد شود. از این رو بهینه‌سازی این جست‌وجو یکی از موارد مهم در نگهداری MV می‌باشد. اوراکل برای مدیریت این عامل سازوکار بهینه‌سازی خودکار این جست‌وجو را ارائه می‌دهد. بررسی هزینه جست‌وجوی بازنویسی شده و پیشین بر عهده Oracle CBO[1] می‌باشد. مدیریت این ویژگی از طریق پارامتر query_rewrite_enabled در سطح پایگاه‌داده و یا بند[2] [ENABLE | DISABLE] QUERY REWRITE] در سطح MV قابل مدیریت است. پارامتر فوق سه مقدار زیر را می‌پذیرد.

1. TRUE   : در صورتی که هزینه جست‌وجوی بازنویسی شده کمتر از جست‌وجوی پیشین است بازنویسی انجام گردد.
2. FALSE  : هیچ جست‌وجویی بازنویسی نگردد.
3. FORCE : همه جست‌وجوها بازنویسی شوند.

1-2            Refresh Materialized View

از آن جا که MV رونوشتی از محدوده‌ای از داده‌ها در یک نقطه زمانی است پس از تغییر در محدوده داده‌های منبع، وضعیت MV غیر معتبر می‌شود. از این رو بروز رسانی داده‌های MV نیز موضوع مهمی است. بر اساس نیازها و شرایط محیطی و تجاری بروز رسانی داده‌های MV می‌تواند در لحظه تغییر در داده‌های منبع و یا با تاخیر انجام شود. برای این منظور بند ON [COMMIT | DEMAND ] در زمان ایجاد MV استفاده می‌شود. در صورتی که بروز رسانی داده‌های MV با تاخیر نسبت به تغییرات منبع تنظیم گردد، این بروزرسانی از طریق بسته DBMS_MVIEW.REFRESH انجام می‌شود. همچنین نحوه بروز رسانی داده‌ها نیز می‌تواند حالت‌های مختلفی داشته باشد.

1. Complete : در این حالت جست‌وجوی ایجاد MV مجدد اجرا می‌شود. در برخی موارد ممکن است زمان ساخت MV به چندین ساعت برسد. در چنین شرایطی اگر حجم تغییرات اندک باشد، استفاده از این راه‌کار به‌صرفه نمی‌باشد.
2. FAST       : در این حالت یک جدول دیگر حاوی تغییرات برای MV ایجاد می‌شود و تغییرات داده‌های منبع در آن ذخیره می‌شود. در زمان بروز رسانی صرفاً تغییرات از این جدول خوانده و بر روی MV اعمال می‌گردد.
3. FORCE     : در این حالت ابتدا به صورت FAST اقدام به بروز رسانی می‌شود. در صورتی که مشکلی در پیاده‌سازی این روش رخ دهد، از راه‌کار Complete استفاده می‌شود.
4. NEVER     : در این حالت بروز رسانی بر روی MV انجام نمی‌شود.

 

---

[1] Cost Based Optimizer

[2] Clause