۲ مطلب با کلمه‌ی کلیدی «materialized view» ثبت شده است

مقدمه‌ای بر معماری Oracle Data Guard

خب میخوایم یه ذره راجع به DataGuard و انواع اون صحبت کنیم.

پرکاربردترین نوع Oracle Data Guard نوع Physical Standby هست. توی Physical Standby دیتابیس شما در وضعیت readonly قرار می‌گیره و تضمین میکنه که داده‌های شما از بین نمیره در صورتی که دیتابیس‌ها باهم sync باشند.

نحوه کپی اطلاعات برای sync کردن توسط Archive Redo Logsها هستش. در حقیقت وقتی Archive Redo Log File ها در سمت دیتابیس primary ساخته میشه به سمت سرور standby فرستاده میشه و با استفاده از standby Redo Log File ها بر روی سرور standby قرار می‌گیرند (apply می‌شوند)

همچنین شما می‌تونید از سرور physical standby بک‌آپ هم بگیرید.

به شکل زیر توجه کنید:

خب همانطور که گفتم physical standby به صورت readonly هستش، حالا اگر شما می‌خواهید تغییراتی در سرور standby داشته باشید باید این دیتابیس در وضعیت read/write قرار بگیره.

برای انجام اینکار باید سرور physical خود را به سرور logical تبدیل کنید. توی این حالت redo فایلها تبدیل به دستروات sql میشه و بعد بر روی سرور logical شما apply میشه.

کاربرد این حالت بیشتر روی سرورهای گزارش‌گیر هستش که شما می‌تونید indexهای متفاوت و یا materialized view های متفاوت تعریف کنید و یا برای تیم‌های دولوپ که فرضاً احتیاج به یسری بک‌آپ از سرور دارند می‌تونند از این سرور logical استفاده کنند و بک‌آپ‌ها رو روی این سرور import کنن و ازش استفاده کنند.

مثال

فرض کنید database primary شما در تهران است، می‌خواهیم ۲تا سایت داشته باشیم و به صورت ریموت از این ۲تا سایت استفاده کنیم که اگر زمانی مشکلی برای سرور تهران پیش اومد شما به physical standby که در تبریز هست سوییچ کنید بدون اینکه مشکلی توی سیستم به وجود بیاد همچنین می‌تونیم یک logical standby توی یک شهر دیگه فرضاً شیراز داشته باشیم و از این logical برای گزارش‌گیری استفاده کنیم و یا حتی از logical به عنوان یک سرور standby دیگه استفاده کنیم و روش سوییچ بزنیم.

قابلیت Far Sync - Road Map

این قابلیت در نسخه 12c معرفی شده که در این تکنولوژی دیگه instance اهمیتی نداره و پهنای باند شما هر چقدر باشه با استفاده از این تکنولوژی می‌تونید سرور stanby رو راه‌اندازی و مدیریت کنید.

در این قابلیت شما می‌تونید چندین دیتابیس stanby داشته باشید که سرور primary اونها رو سرویس میده.

در این حالت شما می‌تونید هم سرور Physiacl Standby داشته باشید و هم Logical Standby

معماری این حالت هم شبکه ۱ به n هست یعنی شما می‌تونید n تا سرور داشته باشید که از سمت primary به standby ها آرشیوها ارسال بشود.

همچنین در سرعت‌های پایین شبکه نیز این معماری قابل استفاده است.

به طور خلاصه:

  • پشتیبانی از چند دیتابیس standby
  • استفاده از Pgusical & Logical Standby
  • معماری شبکه یک به چند
  • پشتیبانی در سرعت‌های پایین شبکه
۰۲ خرداد ۹۴ ، ۱۱:۲۰ ۰ نظر
مهدی غفاری

قاعده CHECK

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

مثال:

CREATE TABLE T3(ID NUMBER, NAME VARCHAR2(20), PHONE VARCHAR2(20), CONSTRAINT HOOHOO CHECK(PHONE LIKE '0__________'));

در این جدول دیگر نمی‌توان در فیلد PHONE هر داده‌ای را وارد کرد و حتماً باید با فرمت صحیح داده را وارد کرد تا درج اطلاعات انجام بشه:

INSERT INTO T3 VALUES(1, 'MAHDI', '091212312');
*
ERROR at line 1:
ORA-02290: CHECK CONSTRAINT (MGHAFFARI.HOOHOO) violated'
INSERT INTO T3 VALUES(1, 'MAHDI', '09121231234');

نکته: قاعده CHECK بار پردازشی بسیار زیادی بر روی دیتابیس اعمال می‌کند.

ادامه مطلب...
۲۹ فروردين ۹۴ ، ۰۱:۱۵ ۰ نظر
مهدی غفاری