از نیاز تا آینده Oracle GoldenGate

سناریوبه عنوان DBA یک بانک که در ایران و اروپا دفتر دارد مشغول کار هستید. بانک شما ۲ تا دیتابیس اوراکل 12C مجزا بر روی دو container مجزا در دفاتر اصلی خود دارد. شما نیاز دارید که برخی از جداول را از اسکیمای IR به اسکیمای EURO ببرید برای رسیدن به این هدف می‌توانید Oracle GoldenGate for Oracle 12c را امتحان کنید.شما برای امتحان حتماً دارید از یه محیط توسعه و آزمایشی استفاده می‌کنید (جدا از نگرانی‌های محیط عملیاتی) که این محیط آزمایشی میتونه روی یه PC هم باشه ولی یادمون باشه در محیط عملیاتی دیتابیس EURO و IR از هم جدا هستند.اوراکل گلدن‌گیت 12cدسته‌بندیDB = دیتابیسEDW = انباره‌داده سازمانی (Enterprise Data Warehouse)ETL = فرآیند Extract, Transform, LoadHW = سخت‌افزار رایانه‌ای (Intel 32-bit, Intel 64-bit, SPARC و خیلی محصولات دیگه)ODS = محل ذخیره گزارشهای عملیاتی بر روی EDWOLTP = دیتابیس تراکنشیOS = سیستم‌عامل (ویندوز، لینوکس و خیلی محصولات دیگه)اوراکل گلدن‌گیت یکی از محصولاتیه که تاثیرات خیلی کمی موقع کپچر اطلاعات(capture)، مسیریابی(routing)، تفییر اطلاعات(transformation) و انجام تراکنشهای مختلف در پایگاه‌داده‌های مختلف داره تقریباً زمانی نزدیک به زمان بی‌درنگاوراکل گلدن‌گیت تبادل و تغییر داده‌ها رو در سطح پایگاه‌داده‌های مختلف و سیستم‌عاملهای مختلف به صورت بی‌درنگ انجام می‌دهد همچنین یکپارچگی تراکنشها رو با زمان تاخیر خیلی کم نزدیک به بی‌درنگ انجام می‌دهد.همچنین قابلیت پیاده‌سازی سولوشنهای high availability و zero down time برای انواع upgrades یا migrations و live reporting و operational business intelligence و transactional data integration را به ما می‌دهد.بخش‌های مهم برای یادگیریمعماری گلدن‌گیت سناریوی گلدن‌گیت به صورت یکطرفه و سناریوی گلدن‌گیت به صورت دو طرفه با دستورات DDL و DMLپارامترهایی که به صورت روتین به اونها احتیاج داریمابزارها و روشهای نگهداری از گلدن‌گیتنکات مهمیکی از مسائل مهمی که معمولا در GG هستش نگهداری یا Maintense اون سخت تر از نصب و راه‌اندازی‌اش هستشدر حقیقت مشکلاتی که موقع کار با این ابزار می‌خوریم و trace انها و شناخت مشکلات و حل اونها معمولا یکم DBA ها رو بیشتر اذیت میکنه اما خوبیش اینه که این به صورت یک مهارت هستش و اگه ما به اون skill برسیم که بفهمیم از کدوم نقطه باید شروع بکنیم و تا کدوم نقطه باید برای رفع خطا بریم و کجاها رو باید سر بزنیم و چه نوع لاگهایی رو بخونیم کارمون بسیار راحتتر میشه و دیگه سختی قبل رو ندارهاگه هدف شما این باشه که از GG در شبکه داخلی خودتون استفاده بکنید به مراتب کار راحتتر هستش چون بخش بزرگی از مشکلات GG به خاطر مشکلات شبکه‌ای هستش و زیرساخت شبکه‌ای درکل بسیار حائز اهمیت هستشویژگی‌های کلیدی اوراکل گلدن‌گیتاوراکل گلدن‌گیت:به عنوان یه middleware برای طراحی و کار در یک محیط hetrogeneous با سیستم‌های مدیریتی پایگاه‌داده رابطه‌ای(RDBMS) مختلفتنها انتقال دیتاهای commit شده در سیستم‌های مختلف که به تاخیر و لایه دوم معروف هستش. در پایگاه داده اوراکل بین داده‌های commit شده نوشته شده در دیسک و commit نشده تفاوت‌هایی است که در redo log‌ اتفاق می‌افتد.گلدن‌گیت میتونه داده‌ها رو براساس پروتکل TCP/IP در شبکه منتقل کنه و نیازی به Oracle Net ندارهبا سیستم منحصر به فرد خودش برای نگهداری و یکپارچگی داده‌ها کار میکنه و از مفاهیم چند منظوره مثل معماری پایگاه‌داده اوراکل استفاده نمی‌کند.می‌تواند به سرعت داده‌ها رو به یک پایگاه‌داده آماده به کار منتقل کند که این خود می‌تواند از فاجعه جلوگیری کندبا استفاده از CSN تراکنشها رو شناسایی می‌کند(Commit Sequnce Number) که بیس آن SCN پایگاه‌داده اوراکل است نیاز به گلدن‌گیتزمانی سازمانها دنبال پیاده‌سازی سیستم‌هایی بودن که به وسیله‌ی اون سیستم بیان فرآیندهای اداری‌اشون رو اتوماتیک انجام بدن (اتوماسیون، 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ها استفاده میشهنکات مهمایجاد فلگ روی آپدیتها خیلی کاربردی نیستش اونجاهایی که ما fact داریم خوبه می‌تونیم فلگ بذاریم که هر مرحله بفهمیم تا کجا دیتا رو آوردیم (timestamp یا sequnce یا id آخرین رکورد درج شده رو می‌تونیم ذخیره کنیم) ولی روی dim زیاد کاربردی برای ما نداره و نمی‌تونیم به راحتی اینکار رو انجام بدیمدر dimها نیز SCD ها به همین شکل عمل میکنن و با typeها گوناگون و انواع اقسام در type 2 به همین شکل است یعنی اصل موضوع تغییرات روی اطلاعات پایه است و تغییرات روی اطلاعات تراکنشی اصلاً معنی ای نداره چون یک تراکنش که مثلاً پارسال خورده خیلی به ندرت آپدیت میشه (مثلاً حتی اگه در اتوماسیون ما نامه‌ای رو به اشتباه زده باشیم قاعدتاً دیگه نباید به اون نامه دست بزنیم و اگه نیاز به ویرایش باشه باید یه نامه جدید بخوره)factهای ما که از جنس log هستن معمولاً هیچوقت نباید آپدیت بشونددر سیستم‌های بانکی هر تراکنشی که میخوره یک سند مالی هستش و با توجه به دستور بانک مرکزی هیچ تراکنشی نباید آپدیت بشه و اگه بخواد سندی آپدیت بشه باید یک سند جدید بخوره و سند قبلی به هیچ عنوان نباید آپدیت بشونددر تمام اصلاحیات سندهای مالی باید فلگهای انقضای سند قبلی با time مربوطه باشه وگرنه اگه سندی برای سال ۹۰ در سال ۹۵ رکوردش آپدیت بشه چون سندهای سال ۹۰ از قبل حسابگری شدن و تراز مالی خوردن باعث اخلال در سیستم حسابداری معین و تفضیلی و جز میشههر 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‌ هستند (دیتاگارد، گلدن گیت و ...)COLD = یعنی توی یکسری بازه‌های مشخص(مثلا هرماه) ما بک‌آپ گیری‌های لازم(از دیتابیس و فایلهای فیزیکی) رو به صورت دستی و مطمئن انجام می‌دیم و می‌بریم روی سایتهای DR اعمال کنیمWARM = زمان انتقال دیتای COLD رو کمتر می‌کنیم و معمولاً به صورت ریموت بک‌آپ‌ها رو منتقل و ریستور می‌کنیمبرای استارتژی HOT ما نیاز داریم دیتابیسها رو لحظه‌ای باهم SYNC نگه داریم یکی از بهترین راه‌حل‌های اوراکل اینجا اوراکل دیتاگارد هستش اما اگه بنا به دلایلی (مثلاً‌ بیزنس بانکی که شب‌ها بچ‌ها کار می‌کنند و سندها جا به جا می‌شوند ما کلی دیتای TEMP از جنس Uncomited ایجاد میشه که در نهایت میخواد یک فیلد رو آپدیت کنه) خب اینجا اگه ما گارد physical داشته باشیم همیشه دیتابیسها باهم SYNC هستند پس باعث میشه TEMPهای من در standby هم ساخته بشه و کلی network, cpu, ram, disk مصرف شده و در نهایت این داده TEMP میخواد پاک بشه پس از standby هم پاک میشهاینجا پیشنهاد من اینه که ریپلیکیشن یکطرفه با گلدن گیت راه‌اندازی بشه و هیچکدوم از این مشکلات رو به خاطر معماری‌اش ایجاد نمیکنه در گلدن گیت میشه فقط نتیجه به سمت دیتابیس مقصد بره تا اینهمه پهنای باند و محاسبه دوباره در DR ما اتفاق نیوفتهپس برای DR Site گلدن گیت یکی از راه‌حل‌های بسیار خوب ما می‌تونه باشههمسان‌سازی پایگاه‌داده دو طرف فعال (Active-to-Active) یکی دیگه از نیازهای دیگه‌ای که گلدن گیت برای ما رفع میکنه ریپلیکیشن ۱ طرفه و ۲ طرف فعال هستشگلدن گیت به طور کامل 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توزیع داده برای سیستمهای OLTPتوزیع داده یکی از کارهای اصلی گلدن گیت هستشمثلا ما توی وزارت بهداشت کلی دیتا به صورت تجمیعی داریم و می‌خوایم اطلاعات مراکز سلامت استانهای مختلف رو بهشون به صورت تفکیک شده بدیم خیلی راحت می‌تونیم این توزیع دیتا رو با گلدن گیت انجام بدیم یا اصلاً‌برعکس این موضوع ما می‌خوایم اطلاعات تمام مراکز سلامت رو در دیتابیس وزارت بهداشت تجمیع کنیم تا ریپورتهای تجمیعی بگیریم خب ما می‌تونیم از گلدن گیت برای این موضوع استفاده کنیم تا به صورت آنلاین اینکار رو انجام بدیم