https://virgool.io/feed/@mghaffari94 fa 2026-06-19 20:57:23 https://files.virgool.io/upload/users/10024/avatar/avatar.png?height=120&width=120 https://virgool.io/@mghaffari94 https://virgool.io/@mghaffari94/%D9%86%DA%AF%D8%A7%D9%87%DB%8C-%D8%A8%D8%B1-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-oracle-goldengate-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-pxokfxts75ps بعد از اینکه با معماری اوراکل خوب آشنا شدید و شناخت این موضوع که اوراکل گلدن‌گیت کجای سازمان ما میتونه باشه و چه راه‌کارهایی رو میتونه به ما ارائه بده به معماری خود گلدن‌گیت می‌رسیم. در کل همین اول کار بهتره بدونید گلدن‌گیت عملاً از یکسری سرویس تشکیل شده یعنی اینکه اگه فکر می‌کنید اپلیکیشن گرافیکی هستش و دیتابیسی پشتش قرار می‌گیره نه این اتفاق در گلدن‌گیت صورت نمی‌گیره.گلدن‌گیت در اصل یکسری سرویسه اینکه من تو پست‌های قبلی همش تاکید می‌کردم ما CDC داریم این سرویس‌ها هستن که اینکار رو انجام میدن و تغییرات رو میفهمن و تو شبکه جا به جا میکنن و در نهایت اعمال می‌کنن یا باز همین سرویسها هستن که منتظر تغییرات می‌مونن و به محض دریافت اونها رو اعمال میکنن و خودشون رو SYNC نگه میدارن درکل ما با یکسری سرویس سر و کار داریم و تمام فعالیت‌های ما هم روی همین سرویسهاست حالا این سرویسها هر کدوم برای خودشون آرگومانهایی دارند که ما Config Fileهای موجود آرگومانهای مختلفی رو براشون در نظر می‌گیریم و در نهایت این کانفیگ‌ها هستن که شما با اونها بسیار کار دارید.سناریوهای قابل پیاده‌سازی در گلدن‌گیتاوراکل گلدن‌گیتDB: database EDW: Enterprise Data Warehouse ETL: Extract, Transform, and Load HW: Hardware (Intel 32-bit, Intel 64-bit, SPARC, and so on) ODS: Operational Data Store OLTP: Online Transaction Processing OS: operating system (Linux, Windows, and so on)نکته: به نظرتون چرا گلدن‌گیت سراغ online redo logها میره؟ سرویس‌های گلدن‌گیت عملاً دنبال تغییرات دیتا هستن حالا در اوراکل این تغییرات در online redo log fileها عملاً نگهداری می‌شوند و فقط تغییرات در این فایلها هستند در دیتابیسهای دیگه هم گلدن‌گیت به دنیال فایلهای log و مکانیزم‌های تغییر دیتا میگرده و از اونها که برای هر دیتابیسی مختلف و منحصر به فرد هستش استفاده میکنهExtractExtractهمونطور که در شکل می‌بینید ما یک Source و یک Target داریم حالا سورس ما میتونه اوراکلی باشه یا غیر اوراکلی به همین ترتیب Target ما هم میتونه اوراکلی باشه و یا غیر اوراکلی پس گلدن‌گیت نسبت به نوع دیتابیس Transparent هستش و وابستگی به نوع دیتابیس ندارهاولین کاری که میخوایم گلدن‌گیت برامون انجام بده اینه که یکسری تغییرات رو capture بکنه همونطور که گفتم گلدن‌گیت سرویس بیس هستش یعنی برمبنای یکسری سرویس عملیات‌هاش رو انجام میدهپس اول از همه ما به یک سرویسی نیاز داریم که بیاد تغییرات دیتا رو capture بکنه به این سرویس Capture می‌گیم که از جنس Extract هستش یعنی میخواد عملیات Extract و Capture رو برای ما انجام بدهسرویس‌های ما در گلدن‌گیت به ۲ دسته کلی تقسیم می‌شوند:Extract = لاگ‌ها رو از دیتابیس استخراج میکنه و عملیات capture رو انجام میدهReplicat = لاگ‌ها رو بر روی دیتابیس مقصد apply میکنهیعنی یا دارند یکسری لاگ‌ها رو استخراج می‌کنند یا دارند یکسری لاگ‌ها رو اعمال می‌کنندشاید یه موضوعی ذهنتون رو درگیر کنه اونم اینکه تو شکل بالا نوشته Committed transactions خب این یعنی گلدن‌گیت فقط تراکنشهای commit شده رو Extract میکنه پس اگه ما یک تراکنشی داشته باشیم که هنوز commit اش نکردیم و معلوم نیست شاید rollback اش کنیم نیازی نیست اون رو به دیتابیس مقصد انتقال بدیم ما فقط نیاز داریم چیزی کپچر بشه که commit شده و وضعیتش stable هستشسرویس capture ما در اوراکل از روی online redo log fileها میاد تراکنشهای commit شده رو پیدا میکنه و از اینجا استخراج دستورات commit شده رو انجام میده حالا فکر کنید یک gap ای ایجاد بشه و اوراکل نتونه از روی online redo log fileها استخراجش رو انجام بده و نیاز اطلاعات مثلا 2 ساعت قبل رو داشته باشه که توی online redo log file ها نیست (خود gg بعد از هر عملیات مپچر scn مربوطه که extract کرده رو نگهداری میکنه پس وقتی میره سراغ online redo log fileها میدونه دقیقاً از کدوم scn دیتا رو باید استخراج کنه در صورتی که online redo log file ما اون scn رو نداره و خیلی وقته از روش گذشته و سوییچ رو انجام داده) اینجا پروسه کپچر سراغ archive log fileها میره و از روی آرشیوها برای حذف gap به خوندن میکنهنکته: گلدن‌گیت به صورت اجباری شما رو مجبوری نمیکنه که دیتابیستون رو روی حالت آرشیو ببرید و بدون حالت آرشیو هم به درستی کار میکنه و دیتابیسها رو SYNC نگه میداره ولی اگه gap ای وسط کار بیوفته تمام مسئولیتش با خودتون هستش و گلدن‌گیت نمیتونه براتون gap رو بدون آرشیوها handle بکنهنکته: هر زمانی سرویس capture ببینه نمیتونه آخرین SCN اش رو در Online Redo Log Fileها پیدا کنه و در صورتی که Archive Redo Log Fileها هم موجود نباشه سرویس capture به حالت abbended در میاد و تو این حالت شما باید وارد کار بشید و به صورت دستی براش تکلیف مشخص کنید مثلاً بگید gap رو بیخیال بشه و از scn فعلی دوباهر شروع به کار کردن بکنپس گلدن‌گیت بدون آرشیو لاگ هم کار میکنه ولی شما رو تو خطر بزرگی قرار میده پس همیشه سعی میکنیم دیتابیس مبدا رو روی آرشیو لاگ بذاریم تا خودش بتونه gap رو هم handle بکنهخب حالا ما شروع به capture تغییرات با پراسس Extract کردیم خب نتیجه این capture بی زبون ما باید یه جایی ذخیره بشه چون سرویس ما یه ورودی گرفته و دستورات commit شده رو از redo ها کشیده بیرون حالا باید یه جایی نتیجه کارش رو که convert این دیتاها به فرمت universal هستش رو ذخیره کنه این خروجی در گلدن‌گیت یکسری فایل به اسم Trail هستندTrailTrailاین Trail File ها در حقیقت همون تغییراتی هستند که سرویس Extract ما Capture و Convert کرده داخل یکسری فایلهای سیتسم‌عاملی در مسیری مشخص گلدن‌گیت پشت سرهم و با timestamp خروجی سرویس Extarct رو در Trail ها مینویسه حالا اگه این فایلها پر بشن میره یه فایل Trail جدید میسازه و اونجا ادامه کار رو جلو میبره (شما می‌تونید یک اندازه ثابت به Trail ها بدید)اینکه گلدن‌گیت داره خروجی کار Extract رو بیرون دیتابیس قرار میده خودش یک مزیته مثلاً شما در نظر بگیرید ما در حال کار با دیتابیس مبدا هستیم و دیتابیسمون همنی لحظه کرش کنه این وسط هم دیتای ما به سمت دیتابیس مقصد به خاطر مشکل شبکه‌ای نرفته اینجاست که می‌بینید اوراکل خیلی هوشمندانه عمل کرده چون با استفاده از همین Trail‌فایلها بعد برطرف شدن مشکلات میتونه دیتا رو تا آخرین نقطه‌ای که در Trail فایل‌ها هستش بخونه و اعمال بکنه پس ما data lost پایینی رو با استفاده از گلدن‌گیت تجربه می‌کنیمنکته: چون گلدن‌گیت هیچ background process ای رو سمت دیتابیس اعمال نمیکنه پس باعث کرش دیتابیس نمیشه و کرش دیتابیس هم ارتباطی به سرویسهای سیستم‌عاملی گلدن‌گیت ندارند نکته: میشه RMAN رو جوری تنظیم کرد که بعد از خوندن گلدن‌گیت آرشیو لاگ‌ها رو پاک کنهخب این Trail Fileهای ما یکسری فایل سیستمی هستند که از بلاک‌های سیستم‌عامل ما تشکیل شده‌اند درون اون هم به سرعت شروع به نوشتن میکنه توی این Trail فایلها تغییرات دیتابیس مبدا که با سرویس Extract کپچر شده‌اند و به صورت یک فرمت عمومی تبدیل شده‌اند قرار می‌گیرهPumpPumpخب وقتی Trail File سمت سرور مبدا ساخته بشه بهش Extrail میگیم یا همون Extract Trilتو یه معماری ما می‌تونیم بگیم که Extrail ها سمت مبدا ساخته نشه و سمت مقصد ما ساخته بشه (با دادن آدرس شبکه‌ای در مسیر trail file)تو این حالا ما میگیم RmTril یا Remote Tril ساخته شده تو این حالت اگه شبکه ما قطع بشه capture ما به مشکل میخوره و خروجی نمیتونه ذخیره کنه و اگه تو این قطعی شبکه یهو مبدا ما هم کرش بکنه دیگه ما دیتا رو نداریمبرای اینکه این مشکل رو نداشته باشیم از همین معماری Extrail استفاده می‌کنیم و یک سرویس pump (از جنس Extract) بالا میاریموظیفه این سرویس pump کردن trailها به سمت مسیر شبکه‌ای که ما بهش دادیم هستشدر نهایت بعد از انتقال trailها در شبکه trilهای ما با سرویس pump در سمت مقصد ساخته می‌شوندنکته: این Pump ما هیچ ارتباطی با فیچر  Data Pump دیتابیس اوراکل ندارهRouteRouteدر این عملیات Route که به وسیله‌ی Pump انجام میشه دیتای ما فشرده و رمزنگاری میشه و میتونه هزاران تراکنش رو بدون محدودیت فاصله به شرط داشتن یک شبکه‌ی stable در ثانیه منتقل بکنه همچنین این Trailهایی که ما با سرویس Pump در سمت مقصد ساختیم به RmTrail معروف هستن ReplicatReplicatاین سرویس به Delivery هم شهرت داره و جنسش از کامپوننتهای Replicat گلدن‌گیت هستشکار این سرویس اینه که RmTrail رو بخونه و روی مقصد اعمالش کنه این سرویس همیشه کارش همینه و فقط applie داده رو انجام میده و کار دیگه‌ای انجام نمیده ولی کامپوننت Extract ما یا میتونه هم Capture بکنه و هم Pumpاین کامپوننت در سمت سرور مقصد نصب و کانفیگ میشه و وقتی شروع به خوندن RmTrailهامون میکنه اونها رو به شکل SQLهای Native بر روی دیتابیس مقصد اعمال میکنهگلدن‌گیت سناریوی Replicat Classic که درباره‌اش صحبت کردیم رو به صورت Native در تمام پلتفرم‌هایی که پشتیبانی میکنه انجا میده پس سرعت بالایی در اینکار دارهبا این حال اگه پلتفرم دیتابیس مقصد شما یکی از ورژن‌های دیتابیس اوراکل باشه به صورت اختیاری می‌تونید عملیات apply رو به صورت direct بر روی دیسک انجام بدید و از SQL apply استفاده نکنیدنکته: تنهار سرویس اختیاری ما در این سناریو Pump هستش یعنی می‌تونیم با ایجاد کردن مستقیم RmTrail ها در سمت مقصد کارمون رو جلو ببریم پس اگه مسیر Trail ها رو در مبدا بهصورت لوکالی بدیم باعث این میشیم که به صورت اجباری سرویس Pump رو پیاده‌سازی کنیم.نکته: Trail فایلها درسته با استفاده از بلاک‌های سیستم‌عامل ساخته می‌شوند و از اوراکل بلاک‌ها برای ساختشون استفاده نمیشه ولی با این حال تنها کسی که میتونه این فایلهای باینری رو بخونه گلدن‌گیت هستشاین کلیت فرآیند انجام مکانیزم گلدن‌گیت در سناریوی UNDIRECTIONAL هستشنکته: ما تا الان باهم به این قاعده رسیدیم که هر سرویسی که خروجیش Trail فایل بشه از جنس Extract هستش و هر سرویسی که خروجیش باعث یک تغییری در دیتابیس بشه از جنس replicat هستش، اگه ببینیم Extract ما بخه یک دیتابیسی وصل شده و داره مستقیم توی یه مسیر شبکه‌ای فایلها رو میکنه پس میفهمیم که تو این سناریو سرویس Pump نداریم و RmTrail فایل‌ها توسط سرویس Capture ایجاد میشوند و اگه کانفیگ سرویس Extract ای رو باز کردیم و فهمیدیم سرویس به دیتابیسی وصل نمیشه و فقط آدرس یک مسیر شبکه‌ای رو داره این سرویس Pump ما هستش، پیدا کردن سرویس Replicat هم که پیدا کردنش خیلی راحته چون حتماً باید به یک دیتابیسی وصل بشه و حتماً هم درونش یک maping ای وجود داره و چیزی رو capture یا pump نمیکنه درک این موضوع خیلی مهم و حساس هستش چون شاید درست الان مشکلی تو درک اینها نداشته باشید ولی بعداً که سناریوهای پیچیده‌تری پیاده‌سازی کنیم و به مشکل بخوریم اینکه بدونیم کدوم سرویس به مشکل خورده خیلی مهمهنکته: بهتره از یک استاندارد نامگذاری برای نامگذاری سرویسها استفاده بکنید مثلاً Extract اول(capture) ما اسمش همیشه با E شروع بشه یا pump ما اسم سرویسش همیشه با P شروع بشه یا اسم سرویس Replicat ما همیشه با R شروع بشه حالا اگه وارد سازمانی شدید که نامگذاری‌هاش اینجوری نبود باید براساس قاعده بالا بفهمید که کدوم سرویس از جنس Replicat هستش و کدوم سرویس از جنس Extract Mahdi Ghaffari Mahdi Ghaffari Sun, 03 Jun 2018 23:30:24 +0430 https://virgool.io/@mghaffari94/%D9%86%DA%AF%D8%A7%D9%87%DB%8C-%D8%A8%D8%B1-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-oracle-goldengate-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-o5mvmkx6bm23 معماری اوراکل خیلی مهمه برای درک معماری گلدن گیت معماری اوراکل رو خوب بلد باشیم، برای مطالعه معماری اوراکل 11g می‌تونید از لینک‌های زیر استفاده کنیدنگاهی بر معماری Oracle Database 11g - قسمت اولنگاهی بر معماری Oracle Database 11g - قسمت دومنگاهی بر معماری Oracle Database 11g - قسمت سوممهمترین بخش معماری که باید برای گلدن‌گیت خوب بلد باشید شکل زیر هستش:معماری دیتابیس اوراکلخب میخوام معماری اوراکل رو به صورت سناریو بیس و خلاصه دوباره دوباره تکرار کنم چون مسلط بودن به این معماری از ضروریات کارهمعماری اوراکل از اونجایی شروع میشه که شما پشت سیستم‌اتون نشستید و میخواین به هر طریقی به دیتابیستون وصل بشید بعد از برقراری اتصال شما با نوشتن دستورات SELECT انتظار پاسخ از دیتابیس رو دارید حالا چه اتفاقی می‌افته؟ اول سمت شما که کاربر هستید یک پکیجی آماده میشه که تمام درخواستهای شما داخل این پکیج قرار می‌گیره این پکیج توسط پراسسی داره هدایت میشه که ما بهش user process می‌گیم حالا این پکیج قراره روی بستر شبکه‌ای هدایت بشه پس باید دیتابیس رو توی شبکه پیدا بکنه و درخواست رو بهش بده تا اتصال برقرار بشه الان کامپوننتهای Network اوراکل هم درگیر بازی ما میشن یه بخشی از این کامپوننتهای Networkای مثل لایه‌های شبکه TCP میمونن اونجایی که درخواست شما توسط user procees خونده میشه اولین کار باز کردن header پکیج هستش که داخلش ip, port, sid دیتابیسی ک همیخواد بهش وصل بشه هستش بعد از اینکه user process آی‌پی پکیج رو فهمید میره تو شبکه دنبال این ip و port میگرده تا مقصدش رو پیدا کنهuser process وقتی میفهمه مقصد رو پیدا کرده که با همین مشخصات header پکیج ما listener دیتابیس رو پیدا کرده باشه حالا پشت این listener یکسری process وجود داره(server process) که کارشون اینه که درخواستها رو از user process بگیرن و نتیجه درخواستها رو به user process از طریق listener تحویل بدن تو حالت dedicate هر server process فقط به یک user process سرویس میده و تا کار user process رو به انتها نرسونه به user process دیگه‌ای سرویس نمیدهخب حالا این سناریو رو فرض کنید دیتابیس بالاست اپلیکیشن هم به دیتابیس وصل هستش و session ما برقراره حالا listener ما میوفته تو این حالت چون session برقرار شده و اتصال بین server process و user process ما انجام شده و مدیریت این session یا با کاربر هستش یا با دیتابیس و listener هیچ نقشی تو این مدیریت نداره ولی اگه کسی بیاد درخواست جدیدی رو سمت دیتابیس بفرسته چون listener ای وجود نداره اتصال برقرار نمیشه و session جدیدی رو نمیشه ایجاد کردنکته: پشت listener یک یا چند process میتونه وجود داشته باشهوقتی user procees بتونه listener رو پیدا کنه و server process بهش اختصاص پیدا کنه ایجاد مفهوم Connection در اوراکل میشهحالا این connection باید یکسری ویژگی‌هایی بگیره و بیاد یک لول جلوتر و در نهایت به یک Session تبدیل بشهزمانی Connection به Session تبدیل میشه که server process از instance ما یک مقدار RAM بگیره و متادیتای user process رو تو این قسمت قرار بده تا بدونه موقعی که میخواد پاسخ درخواست user رو بهش بده باید به کدوم user process مراجعه کنه همچنین زمانی که بتونه authentication روی user انجام بده connection ما تبدیل به session میشهپس تو مرحله تبدیل connection به session هستش که پسورد کاربر ما چک میشهمثال:شما دارید به دیتابیس وصل می‌شوید و پیغام خطای ORA-12541: TNS:no listener رو می‌بینید خب الان یعنی user process شما اصلاً نتونسته connection برقرار بکنه و ما باید به بررسی کامپوننتهای Networkای اوراکل بپردازیم مثلاً یا داریم ip رو اشتباه میدیم یا listener ما تو مدار نیست یا شبکه ما مشکل داره و ...حالا فرض کنید به ما پیغام ORA-01017: invalid username/password; logon denied یا ORA-01031: insufficient privileges رو نمایش داده این یعنی connection ما درسته و نیازی نیست بی‌خودی ما TNS رو دست بزنیم یا با کامپوننتهای Network ای سر و کله بزنیم ای مشکل یه چیزی سمت سروره یا server process نتونسته RAM بگیره(PGA) یا واقعاً نام‌کاربری و پسورد ما مشکل داشته یا نتونستیم متادیتا رو منتقل بکنیم درکل این حالت یعنی ما نتونستیم از connection به session تبدیل بشیمخب اولین چیزی که بعد از ایجاد session در PGA قرار می‌گیره متادیتای user process هستشیک تصویر ذهنی از یک فروشگاه داشته باشید که شما به عنوان مشتری فقط می‌تونید تا دم درب فروشگاه برید و به محض رسیدن به درب فروشگاه یکی از کارمندان فروشگاه میاد و از شما لیست خریدهاتون رو میگیره حالا این کاربر همون لحظه دنبال یک سبد میگرده و اگه بتونه سبد خالی از فروشگاه بگیره مشخصات شما رو درون این سبد میندازه تا موقع برگشت بتونه پیداتون کنهاوراکل کلاً معماریش به این شکل هستش میاد میگه سرور تخصیص یافته برای من شامل ۲ قسمت میشه یه بخشی رو بهش میگه instance که مثل یک پلی میمونه که شما رو واقعاً میتونه به دیتای فیزیکی‌تون برسونه این دیتای فیزیکی شما در اصل در بخش storage structures قرار داره (دیتافایل‌های شما) در شکل بالا اگه دقت کنید اوراکل به این بخش Database میگه ولی منظورش مفهوم عامیانه دیتابیس نیست اینجا اوراکل به معنی لغتی دیتابیس اشاره داره یعنی جایی که واقعاً data قرار داره:cpu + ram = instancestorage media = databaseحالا تمام این server processهایی که سبدهاشون رو از دم درب گرفتن وارد سالن اصلی فروشگاه میشن در اینجا همه‌چی قفسه‌بندی شده است پس server process تو این فضای مشترک می‌گرده تا نیازهای user processاش رو تامین بکنهحالا چرا این فضا مشترکه چون باید یکسری کارها مشترک انجام بشه مثلاً فرض کنید یک server processای اومده و میبینه دیتایی که نیاز داره تو قفسه‌ها نیست همونجا درخواستش رو بلند به مسئولش میگه اینجا اگه server process دیگه‌ای بیاد و اونم درخواست همون دیتا رو داشته باشه دیگه درخواست دیتا رو ثبت نمیکنه چون میبینه که قبلاً یکی این درخواست رو ثبت کرده پس ما به یک فضای مشترک برای یکسری کارها احتیاج داریم(SGA)حالا یه ذره ریزتر بشیم server process ما وقتی می‌خواد وارد سالن اصلی(SGA) فروشگاه بشه باید از یکسری غرفه‌ها(checking) بگذره مثلاً یکی از چک‌ها اینه که لیست درخواستهای داخل PGA بازنگری بشه که کاربر نهایی(مشخصاتش داخل PGA بود) دسترسی‌های لازم برای این لیست رو داره یا نه؟ پس تو بافر اول privilege ها رو چک میکنه. توی SGA ما ۶ تا بافر داریم که ۳ تای اونها اجباری هستش یعنی تو همه‌ی SGA ها باید باشهاولین بافر که checkingها در اون انجام میشه shared pool هستش به صورت کلی از نظر syntax، semantic و privilegeای  دستورات چک می‌شوند و اگه نیاز باشه ما می‌تونیم یکسری نتایج رو داخلش نگهداری کنیم.وقتی چک‌های shared pool تموم میشه server process ما وارد بافر بعدی یا همون database buffer cache میشه(اوراکل به صورت بلاک بلاک این بافر رو تشکیل میده و دیتای خام شما از datafileها میاد و وارد این بافر میشه و به صورت بلاکی نگهداری میشه این به این مفهومه که وقتی شما از update استفاده می‌کنید یکبار دیتای شما از دیسک خونده میشه و وارد این بافر میشه و وقتی شما تغییرات رو روی رکوردهاتون می‌دید در حقیقت تغییرات رو روی این بافر انجام دادید و مستقیم با دیسک درگیر نشده‌اید) این بافر شامل تمام غرفه‌هایی که تو سطح سالن ما وجود داره و ما می‌تونیم دیتا رو از این غرفه‌ها برداریم اگه دیتای ما تو این بافر بود که نتیجه رو وارد PGA می‌کنیم.چرا اوراکل اصرار داره که به صورت buffer cache ای عمل کنه؟ همش به خاطر بالا بردن سرعت و performance انجام کارها هستش چون بزرگترین bottlenecks ما همیشه I/O هستش چون هر وقت سرور شما بره سراغ هارد ما دچار bottlenecks I/O می‌شیم پس اوراکل برای اینکه خودشون کمتر درگیر I/O کنه پس تا جایی که بتونه میاد از RAM‌استفاده میکنه و مواقعی که نیاز باشه خودش تشخیص میده که کی باید RAM رو بر روی دیسک بنویسه اصطلاحاً میگن اوراکل دیتابیس deferrable هستش یعنی با تاخیر عملیات‌ها رو انجام میده ولی کاربر از این تاخیر کاملاً tranparent‌ هستشحالا اگه دیتای ما در این بافر نباشه server process درخواست کننده باید بره از انبار(datafile) دیتاها رو به صورت بلاکی بیاره بذاره در database buffer cachce پس چون داره به صورت بلاکی کار میکنه نمیتونه فیلترینگ داده رو تو این قسمت انجام بده بعد از اینکه داده رو از بافر کش برداشت تغییرات مورد نیاز user رو داخل PGA انجام میده و نتیجه رو ذخیره میکنهبلاک‌ها در database buffer cache در حقیقت ۳ حالتی هستند:dirty = یعنی ما یک بلاکی رو آوردیم داخل database buffer cache و اون رو آپدیت کردیم به مقدار جدید پس مقدار قبلی dirty هستشfree = هیچ دیتایی داخل این بلاک نیستشpin = یعنی ما یک بلاک رو از دیسک آوردیم داخل database buffer cache و هنوز بهش احتیاج داریم و داریم باهاش کار می‌کنیماگه اوراکل برای آوردن دیتای جدید در database buffer cache فضا کم بیاره اول میره داخل بلاک‌های free دیتای جدید رو مینویسه و اگه خیلی فضا کم بیاره شروع به خالی کردن بلاک‌های dirty براساس LRU میکنهخب تا الان باهمدیگه مرور کردیم که همه چی ما داخل RAM اتفاق میافته حالا فرض کنیم یکهو برق بره و یا سرور کرش کنه به نظرتون اوراکل چیکار میکنه؟ اوراکل برای اینکه با این موارد مقابله کنه یک بافر اجباری دیگه داخل SGA دارهبه این صورت که هر تغییری که داخل database buffer cache اتفاق بیافته (مثل آپدیت) دستورات اون تغییر رو باید بذاره داخل این بافر این دستورات همون redo entry ها هستن اوراکل برای این موضوع که Zero Data Loss رو تضمین بکنه این بافر رو ایجاد کرده این بافر همون Redo log buffer هستشحالا هر دیتای که وارد Redo log buffer بشه به صورت sequential write و به سرعت در دیسک نوشته می‌شوند فرق این کار با نوشتن مستقیم دیتا در دیتافایل اینه که موقع نوشتن دیتا در دیتافایل باید خیلی دقیق فضاهای خالی در دیسک پیدا بشوند و دیتاها به صورت بلاکی قرار بگیرن (در حقیقت random write باید انجام بشه) و عملاً کندی کار بیشتر هستش (اگه موقع write به صورت random write عمل نکنه کلی فضای بی‌هوده در دیسک ما ایجاد میشه)نکته: فرق بین sequential write و random writeپس وقتی redo log buffer داره در دیسک خالی میشه به صورت sequential write عمل میشه و کافیه اولین آدرس برای نوشتن مشخص بشه تا بدون در نظر گرفتن پارامتری به سرعت دیتاها نوشته بشونددر نهایت شما وقتی دستور commit رو در اوراکل می‌زنید changeهای شما به سرعت در دیسک نوشته شده‌اند اما database buffer cache شما که دیتا رو به صورت بلاکی نگهداری کرده هنوز بلاک جدید رو به دیتافایل شما انتقال نداده تو این وضعیت درسته database buffer cache وارد دیتافایل شما نشده ولی به شما پیغام موفق بودن commit رو میده حالا فرض کنید همین لحظه سرور کرش میکنه یا برق کشور میره خب دیتابیس شما هم کرش میکنه و نکته اینجاست که وقتی هر زمانی بخواد دوباره بالا بیاد و ارتباط instance و database رو برقرار بکنه شروع به انجام عملیات crache recovery میکنه چون باید خودشون به اون نقطه‌ی ثابت که آخرین commit رو به شما داده بود برسونهحالا چجوری crache recovery رو انجام میده؟ به راحتی چون دیتای اولیه که روی دیسک و دیتافایلها بوده دستوری که باعث شده بود دیتاها تغییر بکنند رو هم روی دیسک بوده خب دوباره تمام این دستورات تغییرات اعمال میشه و به اون نقطه قبلی میرسهپس اوراکل با این مکانیزم Zero Data Loss رو تضمین کرده ۳ تا بافر اختیاری دیگه هم داریم که براساس کامپوننتهایی که شما بر روی اوراکل راه‌اندازی می‌کنید می‌تونید اینها رو ایجاد بکنید و ازشون استفاده بکنید.Large pool = موقعی که شما معماری دیتابیس رو از dedicate‌ به shared منتقل می‌کنید احتیاج به یکسری استخرها دارید که یکیش Response Queue هستش و یکیش Request Queue یعنی یه جا همه درخواستهاشون رو وارد می‌کنند و از یه جا همه درخواستهاش رو برمیدارن خب این فضاها در large pool ساخته میشهStreams pool = ما اگه از سولوشن streams اوراکل استفاده بکنیم از این فضا برای راه‌اندازی این سولوشن استفاده میشهJava pool = ما اگه از کدهای جاوا داخل اوراکل استفاده بکنیم و به نوعی JVM داخلی دیتابیس اوراکل رو درگیر بکنیم می‌تونیم از این فضا استفاده بکنیمنکته: اگه این ۳ بافر اختیاری راه‌اندازی نشوند و ما کامپوننتی رو تعریف کرده باشیم ولی بافر مربوطه رو تخصیص نداده باشیم اوراکل خود فضایی رو از Shared pool به صورت پیش‌فرض اختصاص میدهمعماری حافظه در اوراکلحالا سرور پراسس ما رفت دیتا رو از database buffer cache ما خوند ولی درخواست کاربر گذاشتن order by روی دیتاها بود اوراکل میگه سرور پراسس ما حق نداره در shared pool یا فضای دیگه‌ای بیاد اینکار رو انجام بده تنها فضایی که مجازه این عملیات رو در اون انجام بده فضای PGA یا همون سبد کاربر هستش و اگه برای انجام این کارها فضای کافی در PGA نداشته باشه باید از temporary tablespaceها استفاده بکنه و درکل حق نداره order by یا hash join رو در SGA انجام بدهموقعی هست که شما می‌بینید I/O سرور بالا رفته و همش هم به خاطر SELECTهای کاربرها هستش و UPDATE/INSERT/DELETE در سرور انجام نمیشه بعد از بررسی‌های بسیار و سخت به این موضوع می‌رسید که کلی write دیتا در سرور دارید ولی هیچکدوم از statementها این عملیات write رو انجام ندادن و فقط ما SELECT داریم که توقع ما از SELECT اینه که READ داشته باشیم اینجاست که باید به فیلترهای SELECTهاتون توجه کنید مثلاً اگه یک ORDER BYای روی یک دیتای سنگین داشته باشید که روی PGA جا نشه اوراکل شروع به write داده در temp datafileها میکنه تا بتونه داده رو مرتب کنه و بعد از این temp داده رو به صورت مرتب شده read کنه اینجاست که باید PGA اتون رو افزایش بدیدشما حتی اگه به memory advisor اوراکل در OEM سری بزنید یه قسمتی به اسم heat ratio برای PGA داره (نسبت کارهایی که در PGA اتفاق میافته رو به صورت درصدی میده) اگه این عدد زیر ۹۰ باشه در OLTP به درد کار نیمخوره چون داره مقدار زیادی از کارهای PGA رو در tempها انجام میدهنکته: خیلی‌ها این موضوع رو اشتباه برداشت میکنن که اوراکل به ازای هر کاربر یک PGA میسازه در اصل به این شکل نیست و اوراکل به ازای هر Session یک فضای PGA به اون Session‌اختصاص میده پس موقع تخصیص فضای PGA حواستون باشه اگه ۱۰ تا Session از ۱ کاربر دارید باید جوری عدد PGA رو TUNE کنید که مشکلی از نظر منابع ایجاد نشهنکته: رابطه‌ی process با session یک رابطه‌ی ۱ به ۱ هستش و شما فقط امکان این رو دارید که مشخص کنید حداکثر چه تعداد process روی سرور ما ایجاد بشود به طور معمول ۵۰ تا پراسس برای کارهای خود دیتابیس اوراکل در نظر می‌گیریم و اگه روی سرورمون نیازه ۱۰۰ تا session باز بشه من کل پراسسهای این سرور رو روی ۱۸۰ تا تنظیم میکنم یادتون باشه این موضوع هم خطرناکه که تعداد processها رو عدد بالایی در نظر بگیریم چون اینجوری سرور ما به جایی میرسه که کلاً OS اون هنگ میکنه (چون هر کرنلی تا ایجاد یک تعداد process ای تنظیم شده)نکته: یکی از نکاتی که در راه‌اندازی دیتاگارد معمولاً فراموش میشه راه‌اندازی OEM هستش اگه ما روی سرور گارد OEM راه‌اندازی کنیم خود این سرور کلی process ایجاد میکنه و باعث میشه پراسس‌های ما بالا برهنکته: دیتابیس از idle شدن session شما خبردا نمیشه تا وقتی که اپلیکیشن شما session رو از بین ببره یا براساس تنظیمی که بر روی پروفایل کاربر در دیتابیس شده sessionهای idle از بین بروندیکی از مواردی که بهش برخوردم این بود که ما یک اپلیکیشنی داشتیم که روی وبلاجیک بود و دوستان اپلیکیشن ورژن رو ارتقا دادن و بعد همش دیتابیس ما پایین میومد یکی از موارد پیشنهادی بچه‌های اپلیکیشن این بود که سرور منابع کم میاره و باید بره روی معماری shared (یکی از حالتهایی که ما از dedicate به shared می‌ریم کمبود منابع هستش چون ما دیگه نمیایم به ازای هرکس یک server process اختصاص بدیم و با مثلا ۲۰ تا shared server ما کار ۱۰۰ تا server process رو به صورت رندومی انجام میدیم) چون دیتابیس ما داشته کار میکرده من گفتم که نیازی نیست به معماری shared بریم یکی از دلایلیش اینکه ما تعداد کاربرهامون زیاد نشده بود و با همون تعداد کاربر فقط نسخه اپلیکیشن ارتقا یافته بود من این تضمین رو دادم که وبلاجیک TUNE نیست و بعد از TUNE کردن وبلاجیک و بستن processهای idle بعد از اتمام کارشون مشکل حل شد.Process Structureانواع پراسسهای اوراکلuser process: سمت کاربر هستserver process: سمت سروراپلیکیشنهایی که بر روی دیتابیس process ایجاد میکنن مثل application server weblogic خودش یک process بر روی دیتابیس ایجاد میکنههمچنین ما ۲ نوع server process داریم:foreground process = که همون server processای هستش که PGA رو تشکیل میده و به استقبال user process میرهbackground process = که server processهایی هستن که ارتباط RAM رو با DISK برقرار میکنن۵ تا bg اجباری در اوراکل شامل:1- Lgwr = که redo entryهایی که در بافر redo log buffer هستند رو در online redo logها مینویسه، online redo logهای ما حداقل باید ۲ تا گروه باشند و هر گروه هم حداقل یک عضو داشته باشه (به این علت میگه ۲ تا گروه چون به صورت sycle ای مینویسه وقتی گروه ۱ پر میشه باید یک cycle بزنه اگه ببینه گروه دیگه‌ای وجود نداره دوباره باید بیاد روی همون گروه بنویسه که چون این گروه هنوز خالی نشده باعث ایجاد وقفه میشه پس برای همین میگه حداقل باید ۲ تا گروه وجود داشته باشه که یه فرصتی برای خالی کردن گروه قبلی داشته باشه)lgwr هر ۳ ثانیه یکبار و هر commit ای که اتفاق میافته و هر وقتی که ۱/۳ بافرش (redo log buffer) پر بشه و هر وقتی که dbwn بخواد کارش رو شروع بکنه عملیات flush رو به صورت sequential انجام میده (خالی کردن اطلاعات از RAM بر روی Disk)این bg همه‌ی دستورات رو چه به صورت commit شده و چه به صورت uncommit شده رو میاد روی دیسک قرار میده2- DBWn = هرجا شما در هر bg ای یک n دیدید یعنی می‌تونید ازشون چندتا داشته باشید کار این bg اینه که بلاکهای database buffer cache رو روی دیتافایلها به صورت رندوم flush بکنهزمان‌هایی که dbwn فراخوانی میشه: ۱- هر ۳ ثانیه یکبار ۲- موقعی که فضاهای dirty در database buffer cache زیاد شده باشند ۳- مواقعی که checkpoint رخ میدهد (این خودش یک bg به اسم CKPT هستش)3- CKPT = ایجاد checkpointها و کنترلشون رو برعهده داره ما در اصل ۲ نوع checkpoint داریم: 1- partial -2 full or advance partial رو کاربر نمیتونه بزنه و زمان‌هایی میخوره که مثلاً یکی از tablespaceهای شما آفلاین یا آنلاین بشه یا شما دیتافایلی رو پاک کردید و یکی جدید ساختید و یا یه اتفاق خاص روی یک tablespace بیوفته یک checkpint فطق روی همون tbs میخورهadvanceها یا fullها موقعی که شما دیتابیس رو shutdown می‌کنید (در حالتهای normal, transactional, immediate) یک checkpint full میخوره تا نقطه stable بودن دیتابیس ثبت بشه و دیگه نیازی به crache recovery نیستشهمچنین مکانیزم checkpoint در اوراکل با SCNها هستش(system change number) همونطور که می‌دونید ما یکسری فایلهای مهم در دیتابیس اوراکل به اسم control file داریم که محل فیزیکی تمام فایلهای روی دیسک رو بهمون نشون میده (مسیر pfile, spfile, datafile, online redo log fileها و ...) خب به ازای هر دیتافایل هم آخرین SCN ثابت و stable اش رو نگهداری میکنه یعنی اگه ما ۱۰ تا دیتافایل داشته باشیم ۱۰ تا رکورد در controlfile داریم و آخری وضعیت stable این scnها اینجا نگهداری میشه خب خود هر دیتافایل هم یک header ای داره که scn جاری دیتافایل اولش نوشته شده یعنی ممکنه scn داخل controlfile با scn داخل header دیتافایل ما بهم خوره پس موقع startup میاد این ۲ scn رو باهم چک میکنه و ریکاوری رو از روی online redo log fileها شروع میکنه حالا وقتی ما checkpoint میزنیم در حقیقت میخوایم این ۲ تا scn رو باهم یکی کنیم و آخرین scn دیتافایل رو ببریم بنویسیم داخل controlfile امونحالا وقتی میخواد شروع به checkpoint زدن بکنه میاد به دیتافایل میگه آخرین scn ثابتت رو بده دیتافایل میاد میگه من دوست دارم آخرین scn ثابتم رو بهت بدم اما الان یکسری بلاک روی ram هستند که من از وضعیت اونها خبر ندارم اول یه کار کن که وضعیت اون بلاکها stable‌ بشه و من ازشون خبردارد بشم بعد آخرین scn رو بهت میدم خب اینجا ckpt میره پیش dbwn و بهش میگه سلام خوبی؟ اونم میگه خوبم تو چطوری خخ خب حالا ckpt میگه عزیزم تو یسری بلاک روی database buffer cache داری نمخوای تکلیفشون رو مشخص کنی ما رو آواره کردی تو رو خدا اینها رو flush کن روی دیتافایل دیتافایل جوابم رو سربالا میده حالا dbwn که زورش زیاده میگه باشه خیالت راحت من کلی سعی میکنم این کار رو بکنم اما من یه داداشی دارم که خیلی احترامش برام واجبه هر وقت بخوام آب بخورم میرم بهش میگم lgwr کاری نداری اول اون کارهاش رو انجام بده بعد من آبم رو بخورم چون اگه وسط کار workerهای من کرش بکنن اوارکل اگه lgwr کارش رو نکرده باشه نمیتونه crache recovery کنه پس اول dbwn میره به lgwr میگه که flush اش رو انجام بده و بهش خبر بده بعد از اینکه فلاش lgwr تموم میشه dbwn هم بلاکهاش رو هم داخل data fileها فلاش میکنه و تو رو خبر میکنیم که بری از دیتافایل scn ثابتش رو بگیری و ببری بذاری داخل controlfile این عملیات که بدون مشکل انجام بشه یه advance checkpoint یا full checkpoint اتفاق افتادهخب این ۳ bg از ۵ تا bg اجباری ما هر ۳تاشون به صورت single task هستن یعنی یک کار فقط انجام میدن4- SMON = یا Server Monitoring این bg عزیز ما به صورت multi task کار میکنه یکی از کارهاش اینه که فکر کنید کلی server process اومدن و کارها رو انجام دادن و کلی temp segment ایجاد کردن وظیفه برگردوندن این temp ها به عهده server processها نیست چون باید سریع برن به باقی user processها سرویس بدن اینجاست smon عزیز میاد وظیفه‌ی برگردوندن temp segmentها رو داره تا منابع آزاد بشه یکی دیگه از کارهای این عزیز اینه که وقتی دیتابیس شما shutdown abort میشه یا برق قطع میشه یا سرور کرش میکنه و دیتابیس دوباره میخواد بالا بیاد اولین کاری که میکنه اینه که scn ها رو از ctlها با دیتافایلها چک کنه پس smon میفهمه که سرور کرش کرده پس حالا باید عملیات crache recovery انجام بشه مسئول این عملیات recovery با smon هستش5- PMON = یا همون process monitoring این bg  هم به صورت multi task هستش یک پراسس وقتی اجرا میشه کلی lock‌بر روی آبجکتهای مختلف ایجاد میکنه وقتی کاری server process تموم میشه دست به این lockها نمیزنه اینجاست وظیفه PMON نمایان میشه که به سرعت این lockها رو از حالت lock دربیاره یکی دیگه از کارهای PMON یانه که وقتی سرور بالا میاد به listener بگه که instance بالا اومده و حالا میتونی بهش سرویس بدیدرکل listener به ۲ حالت میفهمه که داره به یک instance سرویس میده یا نه:ما به صورت استاتیک register کرده باشیم که listener همیشه به فلان instance سرویس بده (حالا میخواد instance ما بالا باشه یا پایین)به صورت داینامیک register کنیم که اینکار وظیفه PMON هستش به محض بالا اومدن instance بره registerای رو انجام بدهDatabase - Storage Structuresخب ما توی دیسک یکسری فایل داریم که به صورت فیزیکی هستند:controlfile = فایل خیلی مهمی که وظیفه‌ی ارتباط بین instance و storage رو برقرار میکنه، وقتی instance ما از mount‌ میخواد به open بره از روی controlfileها میفهمه که فایلهای فیزیکی کجا قرار دارند و اندازه هر کدوم چقدره و چه scnهایی براشون خوردهparameter file = وقتی دیتابیس بالا میاد اول از همه میره instance رو تشکیل میده یعنی به os میگیم که ما به این اندازه cpu, ram نیاز داریم اوراکل از روی این پارامتر فایلها اندازه cpu, ram اختصاص یافته بهش رو میفهمه مثلا میگه من یه SGA بیست گیگی میخوام و یه PGA پنج گیگی و میخوام اینها رو بدم به یه db unique name ای به فلان اسماین فایل ۲ نوع داره: pfile و spfile که pfileها به صورت text هستن و شما می‌تونید editاش کنید ولی spfile یا server parameter fileها به صورت باینری هستن و ترتیبش هم اینجوریه که وقتی instance ما میخواد بالا بیاد اول میره سراغ spfile و اگه گیرش نیاره میره سراغ pfiledatafileها = محل فیزیکی دیتای جداول در این فایلها قرار دارند شما وقتی یک جدولی دارید و رکوردهایی داخل اون هستش فضای واقعی که در اونها این دیتاها قرار دارند این فایلها هستندonline redo log fileها = این فایلها به صورت گروهی هستند که lgwr میاد redo entry ها رو اینجا مینویسهbackup filetrace file = هر bg ای که کار میکنه یکسریلاگ از عملکرد خودش میذاره خب این لاگها در trace فایل خاص منظوره خودش قرار میگیرهalert log file = لاگ‌های کلی دیتابیس در این فایل‌ها قرار می‌گیره در این فایلها برخی مواقع اشاره‌هایی به فایلهای trace انجام میشه برای همین ما کلی trace file داریم و یک فایل alert logpassword file = پسورد کاربرهایی که role های sysdba و sysoper رو دارند داخل این فایل قرار می‌گیرند چون این کاربرها موقعی که instance هم پایین باشه می‌تونن عملیاتهایی رو انجام بدهند پس نیاز به اعتبارسنجی دارند که با این فایل انجام میشه به علاوه لیست کاربرهای osای که به صورت os auth تعریف شده‌اند(هر کاربر سیستم‌عاملی که عضو گروه os ای dba باشه و در صورتی که os auth دیتابی فعال باشه(غیرفعال کردن این حالت با تنظیم فایل sqlnet و قرار دادن مقدار all یا nts به صورت دستی))نکته: وقتی bgهای اجباری شما نتونن کارهاشون رو انجام بدن مثلا lgwr نتونه فلاش کنه instance شما shutdown میشه حالا شما به عنوان dba باید اولین کاری که انجام بدید این باشه که alert log رو باز کنید حالا بازش کردید می‌بینید که خط آخر گفته shutdown abort به این دلیل که lgwr نتونسته در دیسک عملیات write اش رو انجام بده حالا تو خط بعد آدرس یه trace‌فیال رو داده که میگه لاگ این bg اینجاست بعد شما می‌رید و این trace فایل رو باز می‌کنید و می‌فهمید lgwr دیسکهای online redo log fileها رو نتونسته ببینه و به همین دلیلی نتونسته عملیات رو انجام بدهstructure datafileمعماری که در دیتافایل هستش از نظر اوراکل ۲ لایه هستش: ۱- معماری منطقی ۲- معماری فیزیکییادمون باشه instance اوراکل به طور مستقیم با فایلهای داخل دیسک درگیر نمیشه و تنها چیزی که instance‌ میشناسه tablespaceها هستنددر حقیقت tablespaceها هستند که دیتافایلها رو در دیسک میشناسند، تو هر tbs میشه یک یا چند دیتافایل قرار داد و یک دیتافایل نمیتونه بین چند tbs مشترک باشه (یک datafile حتماً به یک tablespace تعلق داره)در معماری فیزیکی اوراکل کارها رو به چند لایه تقسیم کرده:- سگمنت = در هر tbs یک یا چند سگمنت وجود داره اما هر سگمنت که می‌گیم یعنی چی؟ به هر چیزی در instance ما یک آبجکت می‌گیم مثلا فانکشن، پکیج، پراسیجر، جدول، ایندکس و ... یک آبجکت هستن هر آبجکتی که دیتا داخل دیتافایل بخواد ذخیره کنه باید دیتا رو تبدیل به سگمنت بکنه (مثلا view دیتایی ذخیره نمیکنه پس سگمنتی تولید نمیکنه) پس یک سگمنت متناظر با یک جدول هستش- extend = هر سگمنت تشکیل شده از چند extend هستش تا کارهای ذخیره‌سازی راحتتر و سریعتر انجام بشه مثلاً یک سگمنت یک inital extend, next extend, other extend‌ داره- oracle block = هر extend از oracle blockهای پشت سرهم تشکیل شده وقتی می‌گیم پشت سرهم یعنی یک extend ما حتماً روی یک دیتافایل قرار می‌گیره چون اجزای تشکیل دهنده‌اش پشت سرهم هستن پس حتما باید داخل یک دیتافایل باشندنکته: یک جدول میتونه بین چند دیتافایل توزیع بشه چون یک segment تشکیل شده از چند extend هستش و این extendها میتونن از دیتافایلهای مختلف oracle blockهاشون رو گرفته باشن همه‌ی این مرورها رو کردم که بگم این redo entryها (چه در redo log buffer یا online redo log fileها) هستن که تو GoldenGate اهمیت بالایی دارند و GoldenGate با اینها کار میکنه در حقیقت با استفاده از redo entryهای موجود در online redo log file میاد capture اش رو انجام میده Mahdi Ghaffari Mahdi Ghaffari Sun, 03 Jun 2018 23:09:40 +0430 https://virgool.io/@mghaffari94/%D8%AA%D8%B9%D8%A7%D8%B1%DB%8C%D9%81-%D9%BE%D8%A7%DB%8C%D9%87-oracle-goldengate-xrrupepan8ve گلدن گیت ۲ نوع معماری کلی داره: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 Mahdi Ghaffari Mahdi Ghaffari Sun, 03 Jun 2018 13:35:26 +0430 https://virgool.io/@mghaffari94/%D8%A7%D8%B2-%D9%86%DB%8C%D8%A7%D8%B2-%D8%AA%D8%A7-%D8%A2%DB%8C%D9%86%D8%AF%D9%87-oracle-goldengate-lwklu65dhzf1 سناریوبه عنوان 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توزیع داده یکی از کارهای اصلی گلدن گیت هستشمثلا ما توی وزارت بهداشت کلی دیتا به صورت تجمیعی داریم و می‌خوایم اطلاعات مراکز سلامت استانهای مختلف رو بهشون به صورت تفکیک شده بدیم خیلی راحت می‌تونیم این توزیع دیتا رو با گلدن گیت انجام بدیم یا اصلاً‌برعکس این موضوع ما می‌خوایم اطلاعات تمام مراکز سلامت رو در دیتابیس وزارت بهداشت تجمیع کنیم تا ریپورتهای تجمیعی بگیریم خب ما می‌تونیم از گلدن گیت برای این موضوع استفاده کنیم تا به صورت آنلاین اینکار رو انجام بدیم Mahdi Ghaffari Mahdi Ghaffari Sat, 02 Jun 2018 19:07:15 +0430