تعاریف پایه Oracle GoldenGate

گلدن گیت ۲ نوع معماری کلی داره:classic captureدر این سناریو گلدن گیت وابسته به ورژن باینری خودش بر روی پلتفرم مورد نظر هستش و گلدن گیت باید کنار هر دیتابیس در سرور مبدا و مقصد نصب بشودintegrate captureدر این معماری گلدن گیت بر روی یک سرور در کنار یک دیتابیس نصب میشه و با agentهایی دیتابیس‌ها باید logهای خودشون رو به این سرور ارسال کنند و capture (بازکردن لاگها) در سرور گلدن گیت انجام میشه. مثلاً شما می‌تونید گلدن گیت رو بر روی یک سرور لینوکسی نصب و راه‌اندازی کنید و ریپلیکیشن بین دیتابیسهای سرورهای ویندوزی راه‌اندازی کنید.integrate capture downstreamاگر سرور گلدن گیت با یکی از دیتابیس‌ها یکی باشه بهش integrate capture میگن ولی اگه کلاً سرور گلدن گیت جدا از سرورهای دیتابیس باشه بهش integrate capture downstream میگننکته: یادمون باشه مبنای سناریوی integrate کلاً انجام عملیات logminer هستشتوپولوژی‌هایی که GG می‌تونه برای ما ساپورت بکنه به صورت کلی شکل زیر هستش راجع به هر توپولوژی من یک توضیح مختصری میدم:انواع سناریو ریپلیکیشن پایگاه دادهUNIDIRECTIONAL or HOT Standbyمعماری ۱ طرفه گلدن‌گیتکابرد دیتاگارد رو در نظر بگیرید این توپولوژی همانند دیتاگارد اوراکل‌ه، در حقیقت این کانفیگ یک ریپلیکیشن یکطرفه است که در گلدن گیت به این مدل ریپلیکیشن (ریپلیکیشن یکطرفه) UNIDIRECTIONAL میگنشما با این توپولوژی می‌تونید با گلدن‌گیت standbyهای متفاوتی ایجاد کنید و درکل standbyای که با گلدن‌گیت راه‌اندازی بشه HOT Standby گفته میشه چون standby ما به طور کامل OPEN هستش و نیازی نیست موقع سوییچ (برای در دسترس گرفتن standby) از حالت open readonly خارجش بکنیم و open اش کنیم.از این سناریو می‌تونیم برای کار با نرم‌افزارهای ریپورت‌گیری استفاده بکنیمBI-DIRECTIONAL or Live Standbyمعماری ۲ طرفه گلدن‌گیتیعنی دیتابیس‌های ما به صورت Active در Active هستند. به این مدل Live Standby هم میگن تو این حالت هر دو دیتابیس با هم SYNC هستنداز این حالت به عنوان سایت DR دوطرفه هم می‌تونیم استفاده بکنیم یعنی با راه‌اندازی این سناریو تغییرات هر دو سایت دیتابیس رو همیشه یک طرف داریم و اگه یکی از دیتابیسها از دسترس خارج بشه اطلاعات هر ۲ سایت رو باز در دسترس داریم پس علاوه بر اینکه ریپلیکیشن ۲ طرفه راه‌اندازی کردیم و مشکلاتمون رو رفع کردیم از داده‌هامون هم محافظت کردیم.Peer-to-Peer or Ring Databaseدر زیرساخت شبکه ما می‌تونیم توپلوژی‌های ring راه‌اندازی کنیم در این معماری نیز می‌تونیم ring دیتابیسی برقرار کنیم.شاید بد نباشه بدونید اولین شبکه‌ای که تو ایران راه افتاد شبکه نیروی هوایی بوده که بر مبنای solutionهای IBM Mainframe توسط نیروی‌های آمریکایی برای سیستم Logistics بوده (سیستم انبار قطعات جت‌ها) مثلاً اگه تو پایگاه هوایی نوژه همدان یه قطعه‌ی جت‌ای کم میومد و تو شبکه داخلی دنبال قطعه میگشتن سیستم تو تمام اطلاعات شهرهای دیگه میگشت مشهد، بوشهر و ... استعلام قطعه رو میگرفت البته به صورت رینگ دیتابیسی که همه‌ی پایگاه‌داده‌ها با هم SYNC بودند.هم اکنون انجام اینکار با گلدن‌گیت به سادگی ممکنه و نیازی به solutionهای گران قیمت IBM نیست.Broadcast or Data Distributionتو این توپولوژی ما میخوایم یک broadcat دیتابیسی راه‌اندازی کنیم تا داده رو بین دیتابیسهای مختلف توزیع کنیم. در حقیقت ما یک دیتابیس master داریم و نیاز داریم که داده رو بین چند دیتابیس slave توزیع کنیم چون هرکی نیاز داره دیتای خودشو داشته باشهدر این توپولوژی ما broadcat یکطرفه داریم البته می‌تونیم broadcast دوطرفه هم داشته باشیم ولی معمولاً کارایی بالایی از لحاظ بیزنسی ندارهIntegration/Consolidation or Data Warehouse/Mart/Storeفرض کنید ما دیتابیسهای مختلفی از vendorهای مختلف داریم مثلاً داریم از MySQL, DB2, SQL Server در اپلیکیشنهای مختلف استفاده می‌کنیم حالا نیاز داریم دیتای این دیتابیسها رو باهم تجمیع بکنیم و در یک دیتابیس دیگه ذخیره بکنیم تا انباره‌داده ای رو شکل بدیم تو این سناریو خیلی مهمه که این دیتابیسها از دسترس خارج نشوند و به صورت لحظه‌ای دیتا و تغییرات اونها در انباره‌داده ما تجمیع بشه خب ما با گلدن‌گیت به راحتی می‌تونیم اینکار ور انجام بدیم. همچنین می‌تونیم به صورت برگشتی هم اینکار رو انجام بدیم یعنی از انباره‌داده مون دیتا رو به دیتابیس‌های مختلف انتقال بدیم.مثال عملی این موضوع Bank of America هستش که برای ارتباط سیستم ATMهاش با سیستم Core Bank از گلدن‌گیت استفاده میکنه به این صورت که هر تراکنشی که در atm میخوره باید از طریق core انجام بشه فضراً فکر کنید در core سند خورده که حساب شما دستور ویژه داره خب موقع استعلام حسابتون از طریق atm فقط داده شما با گلدن‌گیت به atm برمیگرده و اطلاعات حسابتون خونده میشهتو این سناریو شما باید broadcat و integration رو باهم راه‌اندازی کنید چون همیشه این ارتباط یکطرفه نیست و فرضاً در آخر که رکورد شما آپدیت میشه پ شما پول از atm دریافت می‌کنید باید اطلاعات با core هم sync بشهCASCADING or Scalabilityاینجا cascade یا همون عملیاتهای آبشاری مثل revoke کردن دسترسی‌ها از دسترسی‌های SYSTEM و OBJECT به این صورت که وقتی شما grant system privilege به کاربری با grant admin بدید اگه کاربر ما با کاربر دیگه‌ای این grant رو بده دیگه با revoke privilege از کاربر اول از کاربر دوم دسترسی گرفته نمیشه ولی در object privilege ها با دادن دسترسی با grant admin به کاربر حتی اگه کاربر مذکور دسترسی رو به کاربر دیگه‌ای بده ما اگه از کاربر اولمون که خودمون بهش grant دادیم دسترسی رو revoke کنیم دترسی تمام کاربرهایی که کاربر مذکور به کاربرهای دیگه هم با grant admin خودش داده گرفته میشه که بهش cascade revoke‌ میگنیا مثل cascade standby در معماری دیتاگارد این همون standby ای هستش که روی standby دیگه‌ای راه‌اندازی میشهپایگاه‌داده‌های آبشاریاین معماری یک مشکل اساسی داره physical ما میتونه به صورت passive or active با دیتابیس اصلی sync باشه ولی همیشه cascade standby ما(تا 11g) به اندازه یک لاگ عقب‌تر هستش و هیچوقت نمی‌تونیم به صورت آنلاین cascade رو داشته باشیم (تو 12c این مشکل برطرف شده و cascade standby ما هم میتونه همیشه با آخرین تغییرات آنلاین باشه)یکی دیگه از توپولوژی‌های بسیار کاربردی گلدن‌گیت همین موضوع هستش ما می‌تونیم دیتابیسهای cascade داشته باشیم مثلا دیتا رو بفرستیم روی یک دیتابیس دیگه و از اون دیتابیس دوباره دیتا رو به یک دیتابیس دیگه به صورت آنلاین(realtime) منتقل کنیم فرضاً در ساده‌ترین شکل ما می‌تونیم یک HOT Standby راه‌اندازی کنیم و دوباره بر روی Standby امون یک HOT Standby دیگه بدون محدودیت راه‌اندازی کنیماز این قابلیت گلدن‌گیت برای ساخت Data Martها هم می‌توان استفاده کرد مثلا ما نیاز به ساخت یک DWH کوچیک برای بخشهای مالی و اداری و انبار در استانهای مختلف داریم پس با گلدن‌گیت به راحتی می‌تونیم از DWH مارتهای گوناگون در محل‌های فیزیکی مختلف بسازیممنبعhttps://docs.oracle.com/goldengate/1212/gg-winux/GWUAD/wu_about_gg.htm