به عنوان DBA یک بانک که در ایران و اروپا دفتر دارد مشغول کار هستید. بانک شما ۲ تا دیتابیس اوراکل 12C مجزا بر روی دو container مجزا در دفاتر اصلی خود دارد. شما نیاز دارید که برخی از جداول را از اسکیمای IR به اسکیمای EURO ببرید برای رسیدن به این هدف می‌توانید Oracle GoldenGate for Oracle 12c را امتحان کنید.
شما برای امتحان حتماً دارید از یه محیط توسعه و آزمایشی استفاده می‌کنید (جدا از نگرانی‌های محیط عملیاتی) که این محیط آزمایشی میتونه روی یه PC هم باشه ولی یادمون باشه در محیط عملیاتی دیتابیس EURO و IR از هم جدا هستند.
اوراکل گلدن‌گیت یکی از محصولاتیه که تاثیرات خیلی کمی موقع کپچر اطلاعات(capture)، مسیریابی(routing)، تفییر اطلاعات(transformation) و انجام تراکنشهای مختلف در پایگاه‌داده‌های مختلف داره تقریباً زمانی نزدیک به زمان بی‌درنگ
اوراکل گلدن‌گیت تبادل و تغییر داده‌ها رو در سطح پایگاه‌داده‌های مختلف و سیستم‌عاملهای مختلف به صورت بی‌درنگ انجام می‌دهد همچنین یکپارچگی تراکنشها رو با زمان تاخیر خیلی کم نزدیک به بی‌درنگ انجام می‌دهد.
همچنین قابلیت پیاده‌سازی سولوشنهای high availability و zero down time برای انواع upgrades یا migrations و live reporting و operational business intelligence و transactional data integration را به ما می‌دهد.
یکی از مسائل مهمی که معمولا در GG هستش نگهداری یا Maintense اون سخت تر از نصب و راه‌اندازی‌اش هستش
در حقیقت مشکلاتی که موقع کار با این ابزار می‌خوریم و trace انها و شناخت مشکلات و حل اونها معمولا یکم DBA ها رو بیشتر اذیت میکنه اما خوبیش اینه که این به صورت یک مهارت هستش و اگه ما به اون skill برسیم که بفهمیم از کدوم نقطه باید شروع بکنیم و تا کدوم نقطه باید برای رفع خطا بریم و کجاها رو باید سر بزنیم و چه نوع لاگهایی رو بخونیم کارمون بسیار راحتتر میشه و دیگه سختی قبل رو نداره
اگه هدف شما این باشه که از GG در شبکه داخلی خودتون استفاده بکنید به مراتب کار راحتتر هستش چون بخش بزرگی از مشکلات GG به خاطر مشکلات شبکه‌ای هستش و زیرساخت شبکه‌ای درکل بسیار حائز اهمیت هستش
زمانی سازمانها دنبال پیاده‌سازی سیستم‌هایی بودن که به وسیله‌ی اون سیستم بیان فرآیندهای اداری‌اشون رو اتوماتیک انجام بدن (اتوماسیون، BPMS، ERP، CRM) هدف همه‌ی این نرم‌افزارها اتوماتیک کردن یکسری از فرآیندهای سازمان به صورت تجمیعی هستش
اتوماتیک کردن این فرآیندها در یک سیستم و بستر نرم‌افزاری و قاعدتا این هدف ما رو به تجمیع اطلاعات میرسونه
نیازی که در آینده برای سازمانها به وجود اومد این بود که میخواستن در آینده این اطلاعات رو در باقی پایگاه‌داده‌ها توزیع بکنن (Distributed Data) فرضاً وزرات کشور به عنوان یک سازمان حکومتی داره دیتای تمام کشور رو به صورت تجمیع نگهداری میکنه حالا برای پاسخ به یک نیازی یکی از سازمانها نیاز به اطلاعاتی داره که در پایگاه‌داده‌های وزارت کشور قرار گرفته یا استانداری هر استان نیاز به اطلاعات بروز از این دیتابیس دارند.
یا برعکسش رو فکر کنید ما یکسری سامانه در هر استان داریم که وزارت کشور به عنوان یک سازمان حکومتی باید اطلاعات این سامانه‌ها رو داشته باشه و به صورت تجمیعی اونها رو نگهداری و دسته‌بندی کنه
پس نیازی به وجود اومده که ما دیتا رو توی دیتابیسهای مختلف توزیع کنیم حالا این توزیع میتونه به عنوان broadcat باشه یا به صورت integreaty باشه و بخوایم دیتای ما تجمیع بشه در کل به هر شکل این نیاز به وجود اومده
یکی از راهکارهایی که برای رفع این نیاز انجام میدن به این صورته که هر ۲ ساعت یکبار یا هر شبانه روز یکبار یا در طول روز ۳ یا ۴ بار ما اطلاعات رو بین دیتابیسها به صورت batch فایل یا با ابزارهای ETL توزیع دیتا رو انجام بدیم و دیتا رو جا به جا بکنیم
حالا نیاز ما هی داره پر رنگتر میشه مثلا ما میخوایم سامانه‌ای بنویسیم که احتیاج به تغییرات آنلاین دیتا در دیتابیس مرکزی وزارت کشور هستش
خب وقتی ما میخوایم تغییرات رو به صورت آنلاین داشته باشیم نمی‌تونیم از ابزار یا راهکاری استفاده بکنیم که هر ۲ ساعت یکبار اینکار رو انجام بده
مثلا یکی از سامانه‌های من این هستش که می‌خوام براساس رفتار یکی از استانها مرزی SMS ای رو برای ضینفعان اون در وزارت کشور بفرستم پس اینجا نیازه من دیتا رو به صورت آنلاین در اختیار داشته باشم
تمام این نیازها در کنار هم قرار گرفت و یک نیاز دیگه به اونها اضافه شد اینکه تمام vendorهای دیتابیس من در سازمانها یکی نیست و از vendorهای مختلفی هستند (Oracle, Microsoft, DB2, ...) ولی من نیاز دارم دیتا رو بین همه‌ی اینها همش به بازی و گردش دربیارم پس این نیاز هم به نیازهای دیگه‌ی من اضافه شد
هر کدوم از این نیازها متناسب با زمان خودش توسط vendorهای مختلف تکنولوژی نظیر مایکروسافت و آی‌بی‌ام و اوراکل راهکارهایی رو براش ارائه دادند
ما به تمام این راهکارها اصطلاحاً می‌گیم (CDC (Change Data Capture یعنی ما میایم تغییرات دیتا رو میایم جا به جا میکنیم
یه موقع تغییرات ما ۰ تا ۱۰۰ دیتا هستش که در حقیقت Initial Load ما اتفاق می‌افته
یه موقع تغییرات روزانه ۱۰ هزار رکورد هستش که ما فقط میخوایم ۱۰ هزار تا رو جا به جا کنیم
ساده‌ترین راه برای اینکار نوشتن اسکریپت SQL ای با mines هستش(آخرین وضعیت رو با وضعیت فعلی mines می‌زنیم و می‌فهمیم چه رکوردهایی تغییر کرده) که همین الان هم مرسوم هستش و در بسیار از DWها استفاده میشه
هر vendor دیتابیسی معمولاً یک ابزار CDC معرفی میکنه و یا به صورت دستی برنامه‌نویسان CDC رو می‌نویسند (مثلا یک batch بنویسیم که با mines تغییرات رو پیدا کنه و insert کنه در دیتابیس مورد نظر)
مایکروسافت هم در ابزار SSIS امکان انجام دادن CDC رو مهیا میکنه یا تو خود دیتابیس Oracle ما فانکشنهای داخلی PL/SQL ای برای CDC داریم و می‌تونیم فرآیندهامون رو تعریف کنیم
خب CDC نیازهای ما رو در بازه‌های زمانی مختلف برطرف میکرد ولی ما نیاز داشتیم به صورت لحظه‌ای تغییرات دیتا رو داشته باشیم مثلاً همون موقعی که تو سیستم مالی سندی درج شد در سیستم دیگه‌ای اون سند رو داشته باشم
پس نیاز به این بود که در Distrubuted دیتای ما دیتای تغییرات رو به سرعت داشته باشیم و آخرین وضعیت دیتا همیشه در اختیارم باشه
اینجا Online CDC رو مطرح کردند که تغییرات و کپچرها به صورت آنلاین اتفاق بیوفته به این صورت که ابزار یا اسکریپت CDC ما به صورت لحظه‌ای ارا می‌شد و تغییرات رو پس از شناسایی به دیتابیس distrubuted منتقل کنه
مثلا اگه ما بخوایم یک Replication در سطح دیتابیس با CDC راه اندازی کنیم چه اتفاقی می‌افته؟
تو replication قرار بر این نیست که هر لحظه که یک رکورد دیتا تغییر کنه کل دیتا به سمت دیتابیس مقصد بره و اونجا تغییرات دوباره استخراج بشه و بیاد سمت دیتابیس مبدا
ما وقتی replication داریم اولاً هر ۲ دیتابیس ما آنلاین هستن و قابلیت read و write دارند ثانیاً ما باید یک مکانیزم یا ابزاری داشته باشیم که فقط تغییرات رو به صورت آنلاین از هر ۲ طرف بیاره و جا به جا بکنه از این سناریوی replication میشه برای سایتهای DR به صورت Hot Standby استفاده کرد و شما هر وقت اراده بکنید می‌تونید روی دیتابیس DR عملیات انجام دهید
اولین ابزار و راه‌حل سناریوی replication شرکت اوراکل Advanced Replication بود که تا نسخه ۹ اکثراً با این کار میکردند. بعداً با توجه به مکانیزم سخت این سناریو و Overheadهایی که میذاشت و Maintenanceهای سختش اوراکل مکانیزم Streams رو معرفی کرد که ادمینها با این تولز راحتتر بودن و درکل عملکرد بهتری داشت حالا یک مسئله‌ای ایجاد شده که تمام دیتابیسهای سازمان از vendor اوراکل نبود که ما با streams بتونیم همه‌ی نیازها رو برطرف کنیم گاهاً مجبور می‌شدیم از چند ابزار برای جا به جایی دیتا بین vendorهای مختلف استفاده کنیم پس نیاز این بود که ما بین vendorهای مختلف مثلاً MySQL, Sybase, DB2, SQL Server, ... یک replication راه‌اندازی کنیم.
ابزارهایی که اوراکل تا الان برای replication معرفی کرده بود نمی‌تونستن بین ۲ وندور مختلف دیتابیس قرار بگیرن و حتماً باید ۲ طرف اوراکلی می‌بودند. اگه هم ما یک سناریوی رینگ بیس راه‌اندازی میکردیم همه‌ی دیتابیسها باید اوراکل می‌بودند.
بعد از اینکه اوراکل دید نیازی به گونه‌ای شده که باید راه‌حل جامع‌تری پیاده‌سازی بشه دست به تولید ابزار GoldenGate زد
Oracle GoldenGate تمام اون قابلیتهای قبلی که نیاز ما بوده رو داره و امکان پیاده‌سازی بین دیتابیسهای ناهمگون از vendorهای مختلف دیتابیسی رو داره با کلی فیچر جدید و performance بالاتر از باقی ابزارها
ما در Oracle GoldenGate می‌تونیم بالاترین سطح تغییرات رو داشته باشیم و قابلیت کار به صورت passive رو نیز داره یعنی زمانبندی برای انجام هر کدوم از وظایفش تعیین کنیم
- بهترین ابزار ETL آنلاین اوراکل GG هستش در راهکارهای کنونی در دنیا داشتن یک انباره داده که به صورت passive نباشه به شدت مورد نیاز هستش چون دیتابیس انباری که شبانه یا روزانه مثلا ۲ بار آپدیت میشه دیتابیس خیلی کارایی برای ما نمیتونه باشه پس ما نیاز به realtime datawarehouse داریم که به صورت لحظه‌ای ساختار OLAP با ساختاری OLTP ما SYNC باشه یا با زمانی خیلی اندک
گلدن گیت این امکان رو به سادگی به شما میده شما می‌تونید با ابزارهای ETL دیگه بیاین و سناریوی ETL اتون رو طراحی کنید و از گلدن گیت به عنوان زیرساخت کار استفاده کنید و اون رو مدیریت بکنید یا اگه با PL/SQL اسکریپتهای ETLاتون رو نوشتید با ترکیب گلدن گیت می‌تونید یک سناریوی آنلاین داشته باشید
حالا به نظرتون realtime datawarehouse دقیقاً چه کاربردهایی داره و کجاها واقعاً به درد میخوره؟
توی تحلیل‌های از جنس خطا شناسی شما هر چقدر دیتاتون به لحظه باشه خیلی سریعتر می‌تونید تصمیم‌سازی کنید مثلا در BI موقع تحلیل دیتاها و پیدا کردن علت معلول‌ها و آینده‌نگری شما وقتی می‌تونید از نتیجه این گزارش استفاده کنید که به لحظه تحلیل اون رو انجام داده باشید و بعد از چند ماه یا با اختلاف زمانی با این خطا برخورد نکنید (مثلاً یک پولشویی یا اختلاسی یا ...)
وقتی میخوایم خطا شناسی کنیم و fraudها رو پیدا کنیم باید سراغ Operational Intelligence بریم مثلاً وقتی یک عمل انجام شده در لحظه با عملهای دیگه ترکیب بشه احتمال وقوع یک fraudای رو بالا میبره پس اگه همون موقع بتونیم جلوی عمل رو بگیریم باعث win ما میشه
اینجا دیگه ما با passive datawarehouse نمی‌تونیم fraud رو شناسایی کنیم و باید با تعریف گراف‌هایی در OI که هر گراف مثلاً ۱۰ گام داره و اگه تا گام ۸ کسی پیش بره یعنی fraud ما در حال تکمیله دیگه نباید بذاریم به گام بعدی انتقال پیدا کنه
ابزار GoldenGate یکی از بهترین‌ها برای پیاده‌سازی OI در سطح vendorهای مختلف دیتابیسی هستش
ابزارهای مشابه با Oracle GoldenGate هم زیاده مثلاً یک درایوری هستش که روی SSIS هم سوار میشه به اسم attunity که اینم مثل گلدن گیت میتونه براتون Online CDC رو پیاده‌سازی کنه
https://www.attunity.com/content/microsoft-connectors-attunity/
https://www.microsoft.com/en-us/download/details.aspx?id=52950
اما بهتره تو سازمانی که اکثر دیتابیسهاش اوراکل هستش از گلدن گیت استفاده بکنیم البته گلدن گیت محدودیتی نداره و می‌تونید از گلدن گیت برای ریپلیکیشن بین DB2 و SQL Serevr استفاده بکنید و یا بین ۲ دیتابیس SQL Server و درکل هیچ مسئله‌ای نداره
شعار اوراکل برای گلدن گیت ابزار platform less هستش یعنی هیچ وابستگی به هیچ سیستم‌عامل و دیتابیسی وجود نداره گلدن گیت نسبت به تمام ورژنها و سیستم‌عاملها transparent هستش
پس ابزاری که به هیچ سیستم‌عامل و پلتفرمی وابسته نیست و امکان راه‌اندازی انواع سناریوهای ریپلیکیشن رو با بهترین سرعت و کارایی بین وندورها و ورژن‌های مختلف دیتابیس با سیستم‌عاملهای مختلف داره بسیار برای ادمین در دیتاسنتر میتونه مفید و ضروری باشه
حالا گلدن گیت فقط به درد ریپلیکیشن نمیخوره شما می‌تونید از گلدن گیت به هر شکلی که نیازتونه استفاده کنید در حقیقت بیشتر شبیه به یک فریمورک هستش که شما می‌تونید از اون به هر شکلی در سازمان برای رفع نیازهای متفاوت استفاده کنید
ما تصمیم گرفتیم دیتاسنترمون رو جا به جا کنیم یا قراره ورژن دیتابیسها عوض بشه و آپگریدی صورت بگیره مثلاً از ورژن 11.2.0.3.0 قراره بریم به دیتابیس 12.2.0.1.0 (یا میخوایم وندور دیتابیسهامون رو عوض کنیم) الان هم حجم دیتابیسهای دیتاسنتر زیاده و کارکرد اپلیکیشنها هم بالاست کلی هم پلن توجیهی برای آپگرید دیتابیسها داریم ولی نمی‌تونیم قطعی داشته باشیم (Zero Downtime) خب پس از یک طرف مجبوریم آپگرید کنیم و از طرفی نمی‌تونیم Downtime براش بدیم
حالا باید سراغ راه‌حل‌های migrate و upgrade به صورت Zero Downtime بریم
یکی از راه‌حل‌ها استفاده از GoldenGate هستش به این صورت سایت جدید رو بالا میاریم ریپلیکیشن یکطرفه بین ۲ سایت ایجاد میکنیم و تو یه مقطع زمانی که پیک کاری خیلی پایینه یه downtime چند ثانیه‌ای میگیریم و tnsها رو جا به جا میکنیم و اتصال به دیتابیس جدید انجام میشه دیتابیس جدید هم تا آخرین لحظه با دیتابیس قبلی sync بوده، پس بدون هیچ downtime ای ما این کار رو انجام دادیم
یکی دیگه از راه‌حل‌های اوراکل برای اینکار راه‌اندازی سایت DR (اکتیو دیتا گارد) به صورت logical standby هستش چون به صورت logical شما دارید از معماری streaming استفاده می‌کنید ولی توی physical standby شما دارید از معماری recovery استفاده می‌کنید
سناریوی recovery یعنی چی: وقتی شما یه RMAN رو میاین restore می‌کنید برای اینکه به اون نقطه زمانی خاص مدنظرتون برسید میاد لاگ‌ها و incremental backupها رو به صورت توالی ریکاور کردن physical standby هم با این سناریو برای شما سایت DR رو راه‌اندازی میکنه یعنی redo entry ها رو که تو ۳ حالت میتونن باشن (توی RAM یا توی Online Redo Log یا توی Archive Redo Log) رو برمیداره میاره و روی سایت DR ریکاور میکنه درکل برای همین هستش که سرعت خوبی داره و شما هر تغییر توی ساختار primary اتون میدید همیشه توی standbyاتون هست
توی logical این اتفاق نمی‌افته یعنی میگه redo entry رو بگیر و با logminer بیا این redoها رو به sql statment تبدیل کن و روی سایت standby اعمال کن دقیقاً مثل کسی میمونه که دوباره داره sql statementهای شما رو توی دیتابیس دیگه‌ای به همون شکل میزنه این راهکار streaming اوراکل هستش که میاد دستورات رو apply میکنه
توی این حالت نیازی نیست تمام دیتابیس sync باشه شما می‌تونید فقط چند schema رو sync نگه دارید و یا schemaهای مختلف در سمت standby داشته باشید و schemaها رو map کنید
یکی از کاربردها اینه که می‌تونیم فقط یک schema مثلا دولوپ رو sync نگه داریم
یکی دیگه از کاربردهای logical standby اینه که شما schemaهای اپلیکیشنتون رو میارید و sync نگه می‌دارید اما نسخه دیتابیس سایت standby آپگرید شده باشه و اینجوری migration رو انجام بدید
یکی دیگه از نیازهایی که می‌تونیم با گلدن گیت اون رو برطرف کنیم این هستش که مثلاً مدیر شما ازتون هرماه ریپورت ماهانه میخواد و شما تو اوج کاری هستید و اگه بخواین ریپورتها رو ایجاد بکنید باعث بالا رفتن مصرف CPU می‌شید چون قراره کلی دیتا رو با همدیگه محاسبه و تفکیک بندی کنید.
یا مثلاً اصلا ماهیت structure data جواب این ریپورتها رو نمیده و ما باید از دیزاین OLAP استفاده کنیم تا trends reportهای سریعتری بگیریم البته می‌تونیم با تریگر تو مدت کار اپلیکیشن یک schem dwh مجازی در دل OLTPامون ایجاد کنیم (VDWH)
لزوماً DWH ما نباید جدا باشه و ماهیت DWH برمیگرده به OLAP ساختار یعنی ما ساختاری بچینیم که برای select مناسب باشه، ایندکسها مناسب select باشه(index هرچقدر برای select خوبه موقع update, insert, delete عملکردش رو از بین میبره و سرعتتون رو کند میکنه - چون عملاً وقتی یک جدول آپدیت میشه باید جدول ایندکسها هم داده‌هاش آپدیت بشوند) پس ساختار OLAP به صورت Denormalization هستش
ما وقتی سرور OLAP رو جدا میکنیم که ببینیم ریپورتهای ما مصرف بالایی از CPU و RAM سروردارن و به خاطر این مصرف بالا اپلیکیشن OLTP ما به مشکل کندی بر خورده خب اگه فقط کندی ما تو سطح منابع CPU, RAM, Disk باشه با راه‌اندازی اکتیو دیتاگارد ما سرور امون رو جدا میکنیم و ریپورتهامون رو روی standby میندازیم و از نظر سرور از OLTP جدا می‌شیم ولی مسئله اینه که باز ساختار این ۲ دیتابیس کاملاً یکی هستش(در سناریوی physical) و اگه ما ایندکسی روی سرور standby نیاز داشته باشیم برای ریپوتمون باید در primary امون این ایندکس رو ایجاد کنیم پس در کل دست ما برای ایجاد تغییرات در دیتابیس standby بسته است چون همه تغییرات از سمت primary خونده و اعمال میشه
حالا اگه ما از سناریوی logical استفاده کنیم می‌تونیم تغییرات دلخواهمون رو روی سرور standby بدیم چون می‌تونیم توی حالت read/writr دیتابیس رو بالا بیاریم
یه ابزار دیگه هم که تو این ضمینه خیلی دست ما رو باز میذاره، سرعت فوق‌العاده‌ای داره و بهمون کمک میکنه اوراکل گلدن گیت هستش ما می‌تونیم یه سرور دیگه با یه structure data دیگه آماده کنیم ریپلیکیشن یکطرفه راه‌اندازی کنیم و روی این دیتابیس به طور کامل کنترل داشته باشیم تا ساختار اون رو به شکل OLAP در بیاریم
فکر کنید اتفاقی افتاده و دیتاسنتر استان تهران به مدت یک هفته قطع شده خب فکر کنید وزارت کشور که فقط به استان تهران نباید سرویس بده باید به کل کشور سرویس بده حالا تهران برقش قطع شده ولی اصفهان باید سرویس بگیره تو این مواقع به عنوان یک DBA تو دیتاسنتر و زیرساختمون باید به فکر disaster recovery site باشم که از نظر محل فیزیکی با سایت اصلی دیتاسنترش مجزاست . خب پس هر وقت سایت تهران از دسترس خارج شد ما از سایت اصفهان یا کرمان سرویس‌دهی رو انجام می‌دیم.
سایتهای DR به ۳ دسته تقسیم می‌شوند:
برای استارتژی HOT ما نیاز داریم دیتابیسها رو لحظه‌ای باهم SYNC نگه داریم یکی از بهترین راه‌حل‌های اوراکل اینجا اوراکل دیتاگارد هستش اما اگه بنا به دلایلی (مثلاً بیزنس بانکی که شب‌ها بچ‌ها کار می‌کنند و سندها جا به جا می‌شوند ما کلی دیتای TEMP از جنس Uncomited ایجاد میشه که در نهایت میخواد یک فیلد رو آپدیت کنه) خب اینجا اگه ما گارد physical داشته باشیم همیشه دیتابیسها باهم SYNC هستند پس باعث میشه TEMPهای من در standby هم ساخته بشه و کلی network, cpu, ram, disk مصرف شده و در نهایت این داده TEMP میخواد پاک بشه پس از standby هم پاک میشه
اینجا پیشنهاد من اینه که ریپلیکیشن یکطرفه با گلدن گیت راه‌اندازی بشه و هیچکدوم از این مشکلات رو به خاطر معماری‌اش ایجاد نمیکنه در گلدن گیت میشه فقط نتیجه به سمت دیتابیس مقصد بره تا اینهمه پهنای باند و محاسبه دوباره در DR ما اتفاق نیوفته
پس برای DR Site گلدن گیت یکی از راه‌حل‌های بسیار خوب ما میتونه باشه
یکی دیگه از نیازهای دیگه‌ای که گلدن گیت برای ما رفع میکنه ریپلیکیشن ۱ طرفه و ۲ طرف فعال هستش
گلدن گیت به طور کامل HandleCollisions رو انجام میده، یادمون باشه مکانیزم lock در دیتابیس باعث میشه همیشه دیتابیسconsistent باشه و تا وضعیت ولید بودن دیتا بهم نخوره ولی تو این لایه چون چندتا دیتابیس جلوی هم قرار می‌گیرن باید به صورت Master/Slave بیاد و برخورد کنه
وضعیت Master/Slave رو ما خودمون می‌تونیم انجام بدیم مثلاً به صورت فیزیکی بیایم بگیم یکی Master ه و یکی Slave و اگه یه اتفاق همزمان تو ۲ دیتابیس باهم رخداد اولویت با Master باشه یا به صورت زمانی مشخص کنیم مثلا اونی که سریعتر رخداد
با اکتیو اکتیو بودن دیتابیسها ما می‌تونیم در دسترس‌پذیری مداوم دیتابیسمون رو بین مناطق جغرافیایی مختلف تضمین کنیم
مثلاً‌در یک اتوماسیون اداری ما ۴۰۰ تا کاربر در ستاد تهران ۷۰۰ تا کاربر در عسلویه و ۳۰۰ تا کاربر در اصفهان داریم نوع اپلیکیشن هم کلاینت/سروری هستش خب ما بگیم دیتابیسمون تهران باشه و باقی کلاینتها از طریق شبکه به تهران وصل بشن و دیتا رو بخونن با فرض اینکه یه پنهای باند قوی mpls ای هم داریم پیاده‌سازی میکنیم بعد از پیاده‌سازی می‌بینیم کاربرها خیلی کند هستن اونم به دلیل ماهیت درایور این اپلکیشنهاست که میگن یه پکیج باید به طور کامل بیاد بعد پکیج بعدی رو بفرسته و حتی اگه ما بهترین پهنای باند رو هم داشته باشیم زمان اتلافی بالایی برای ریدن پکیجها داریم
خب پس بیایم یک دیتابیس برای هر سازمان بذاریم تا به صورت لوکال همه بتونن از اپلیکیشن استفاده کنن
چون هر جایی که اپلیکیشن و دیتابیس تو یه شبکه باشن و بهم نزدیک باشن کاربرها خیلی سرعت خوبی دارند و جایی که اپلیکیشن و دیتابیس نزدیک هم نباشن و کاربرها بخوان ریموتی کار کنن کندی رو مشاهده میکنن
حالا عمق فاجعه اینجا میشه که بستر ارتباطی ما به هر دلیلی مشکل دار بشه و قطعی ایجاد بشه تو این حالت تمام کاربرهایی که به صورت ریموتی با دیتابیس کار میکردند حتی دیگه تو اداره خودشون هم نمی‌تونن نامه‌نگاری کنن
بهترین راهکار برای این مواقع راه‌اندازی ۲ دیتابیس هستش یکی مثلا تهران یکی تو مرکز هر استان و اینها رو باهم ریپلیکیشن اکتیو اکتیو کنیم اینجوری هرکی تو هر استانی هست با دیتابیس خودش در سازمان استان خودشون کار میکنن و تا موقعی که شبکه برقرار باشه همه نامه‌های هم رو می‌بینند و میتونن باهم نامه نگاری کنن
فرضاً هم اگه شبکه قطع بشه ارتباط هر استان با استانهای دیگه قطع شده و میتونن تو استان و سازمان خودشون همچنان نامه‌نگاری داشته باشن یا اگه نیاز به ریپورت گیری از دیتای قدیمی باشه میتونن اینکار رو انجام بدن
گلدن گیت یه خوبی دیگه هم داره اونم اینکه بعد از اینکه این دیتابیسها از مدار رینگشون خارج شدند مثلا به خاطر مشکل شبکه‌ای دوباره بعد از برقراری شبکه بدون راه‌اندازی مجدد میتونه دیتابیسها رو به حالت سینک باهمدیگه برسونه
یکی از عملکردهای دیگه که می‌تونیم با گلدن گیت بهش برسیم realtime dwh هستش گفتم که می‌تونیم به صورت آنلاین تغییرات رو کپچر بکنیم و فقط change ها رو به سمت انباره‌داده ببریم و انباره‌داده رو به صورت لحظه‌ای بدون نیاز به ETL شبانه و BATCH بروزرسانی بکنیم اینجوری تغییرات به صورت لحظه‌ای در STAGE IO هستش و اونجا دیگه می‌تونیم تصمیم بگیریم مثلاً با نوشتن یک تریگر CUBE ما بروزرسانی بشه
حجم: 245 کیلوبایت
توضیحات: Best Practices for Real-Time Data Warehousing
توزیع داده یکی از کارهای اصلی گلدن گیت هستش
مثلا ما توی وزارت بهداشت کلی دیتا به صورت تجمیعی داریم و میخوایم اطلاعات مراکز سلامت استانهای مختلف رو بهشون به صورت تفکیک شده بدیم خیلی راحت می‌تونیم این توزیع دیتا رو با گلدن گیت انجام بدیم یا اصلاً‌برعکس این موضوع ما میخوایم اطلاعات تمام مراکز سلامت رو در دیتابیس وزارت بهداشت تجمیع کنیم تا ریپورتهای تجمیعی بگیریم خب ما می‌تونیم از گلدن گیت برای این موضوع استفاده کنیم تا به صورت آنلاین اینکار رو انجام بدیم
