خب تا حالا داشتیم سناریوی Unidirectional رو باهم مرور میکردیم نوبتی هم باشه نوبته معماری Bidirectional هستش
خب فکر کنید ما نیاز داریم join چند جدول از مبدا رو در یک جدول در دیتابیس مقصد بنویسیم خب در گلدنگیت برای این مورد ما باید شروع به نوشتن اسکریپتنویسی با REM کنیم که جزو موارد advanced گلدنگیت محسوب میشه، البته شما میتونید از یه راهکار به مراتب سادهتر اسفاده کنید اونم اینکه جداول مورد نیازتون رو بدون join بیارید به سمت سرور مقصد و روی جدول آخری که میخواد آپدیت بشه شما یک Triger مینویسید که وقتی ۲ تا رکورد از ۲ جدول اومدن join بزنه و روی جدول نهایی بنویسه پس تا stage io رو با گلدنگیت جلو میاریم و از Stage I/O به DWH رو با تریگر جلو میبریم بعد شما چون فقط یک تریگر روی جدول آخر دارید performance بالایی خواهید داشت.
SCN رو که یادتونه؟ همون بچهای که هر تغییری توی دیتابیس ما بخوره یکی میخوره تو سرش و Counter یکی میره بالا (حتی اگه time دیتابیس تغییر بکنه) خب یادمون هم هستش که redoها براساس SCNها هستن که در Online Redo Log Fileهای ما قرار میگیرند خب گلدنگیت خودش با SCN کاری نداره و بین سرویسهاش از مکانیزم دیگهای استفاده میکنه ولی موقعی که Extract میخواد فاز Capture رو شروع بکنه اینجاست که SCNهای دیتابیس رو میخونه و آخرین SCN خونده شده رو نگه میداره تا بدونه آخرین تغییری که خونده تا کجا بوده و اگه Gapای افتاد بتونه Gap رو برطرف بکنه خب گلدنگیت به محض اینکه SCN رو خوند و عملیات Capture رو انجام داد دیگه به SCN ما کار نداره
حالا اگه شما بخواین تو داخل مکانیزم گلدنگیت بین رکوردها جا به جا بشید باید با مفهوم RBA آشنا بشید (Relative Byte Address) یعنی ترتیبی که فایلهای capture ما در trail فایلها نوشته میشوند هر کدوم یک RBA میخورن و بر اساس این RBA این رکوردها از هم جدا و تفکیک میشوند
یکی از مزایای گلدنگیت اینه که میتونه چندین Trail فایل داشته باشه برای اینکار موقعی که نیازه Captureها اجرا بشوند باید یکسری Trail File ساخته بشوند که نام این فایلها توسط اوراکل به صورت ۸ کاراکتری در نظر گرفته میشه که ۲ کاراکتر اول توسط شما مشخص میشه مثلاً SH, SA, T1, L1 و ۶ کارکتر بعدی توسط اوراکل counter میخوره
بعد از اینکه با معماری اوراکل خوب آشنا شدید و شناخت این موضوع که اوراکل گلدنگیت کجای سازمان ما میتونه باشه و چه راهکارهایی رو میتونه به ما ارائه بده به معماری خود گلدنگیت میرسیم. در کل همین اول کار بهتره بدونید گلدنگیت عملاً از یکسری سرویس تشکیل شده یعنی اینکه اگه فکر میکنید اپلیکیشن گرافیکی هستش و دیتابیسی پشتش قرار میگیره نه این اتفاق در گلدنگیت صورت نمیگیره.
گلدنگیت در اصل یکسری سرویسه اینکه من تو پستهای قبلی همش تاکید میکردم ما 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)
خیلی مهمه برای درک معماری گلدن گیت معماری اوراکل رو خوب بلد باشیم، برای مطالعه معماری اوراکل 11g میتونید از لینکهای زیر استفاده کنید
نگاهی بر معماری Oracle Database 11g - قسمت اول
نگاهی بر معماری Oracle Database 11g - قسمت دوم
نگاهی بر معماری Oracle Database 11g - قسمت سوم
مهمترین بخش معماری که باید برای گلدنگیت خوب بلد باشید شکل زیر هستش:
خب میخوام معماری اوراکل رو به صورت سناریو بیس و خلاصه دوباره دوباره تکرار کنم چون مسلط بودن به این معماری از ضروریات کاره
گلدن گیت ۲ نوع معماری کلی داره:
در این سناریو گلدن گیت وابسته به ورژن باینری خودش بر روی پلتفرم مورد نظر هستش و گلدن گیت باید کنار هر دیتابیس در سرور مبدا و مقصد نصب بشود
در این معماری گلدن گیت بر روی یک سرور در کنار یک دیتابیس نصب میشه و با agentهایی دیتابیسها باید logهای خودشون رو به این سرور ارسال کنند و capture (بازکردن لاگها) در سرور گلدن گیت انجام میشه. مثلاً شما میتونید گلدن گیت رو بر روی یک سرور لینوکسی نصب و راهاندازی کنید و ریپلیکیشن بین دیتابیسهای سرورهای ویندوزی راهاندازی کنید.
اگر سرور گلدن گیت با یکی از دیتابیسها یکی باشه بهش integrate capture میگن ولی اگه کلاً سرور گلدن گیت جدا از سرورهای دیتابیس باشه بهش integrate capture downstream میگن
نکته: یادمون باشه مبنای سناریوی integrate کلاً انجام عملیات logminer هستش
-- توپولوژیهایی که GG میتونه برای ما ساپورت بکنه به صورت کلی شکل زیر هستش راجع به هر توپولوژی من یک توضیح مختصری میدم:
سناریو
به عنوان 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 را به ما میدهد.
فکر کنید شما یک ماشین DL380-G9 برای نصب سیستمعامل و دیتابیس در اختیار دارید. همونطور که میدونید این ماشین دارای ۴ پورت شبکه به صورت Onboard هستش و اگه ما به صفحه مشخصات این ماشین در سایت HP مراجعه کنیم (HPE ProLiant DL380 Gen9 Server) میبینیم که در قسمت SPECIFICATIONS در مشخصات کنترلر شبکه ۴ پورت رو نوشته که بسته به مدل و سفارش میتونه متفاوت باشه برای اطلاعات بیشتر میتونید به راهنمای کاربر این ماشین مراجعه کنید:
HPE-ProLiant-DL380-Gen9-Server-User-Guide
حجم: 14.9 مگابایت
خب اگه شما هم مثل من حافظه خوبی نداشته باشید یا به سروری وصل شدید و ادمین مسئول نصب داکیومنت بهتون نداده باید خودتون آستینها رو بالا بزنید
یکی از موارد خیلی مبهم تو سروهایی که اپلیکیشن خودش جاوا رو نصب میکنه پیدا کردن مسیر دایرکتوری جاواست
مثلا فرض کنید نیاز دارید با استفاده از keytool به لیست certificateهای نصب شده دسترسی داشته باشید یا certificateای رو اضافه کنید
به عنوان مثال نیازه از دستور زیر استفاده بشه:
keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts
خب اینجا باید مسیر JAVA_HOME$ رو داشته باشیم که یا باید به داکیومنتهای نصب مراجعه کنیم یا از دستور زیر برای پیدا کردن JAVA_HOME سیستم استفاده کنیم:
jrunscript -e 'java.lang.System.out.println(java.lang.System.getProperty("java.home"));'
خب در آخر به نتیجه دلخواهمون میرسیم:
keytool -list -keystore /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.79.x86_64/jre/lib/security/cacerts
نکته: بهتره بعد از پیدا کردن مسیر اون رو به صورت یک متغیر در پروفایل کاربر تعریف کنیم.
نکته: پسورد دیفالت keystore جاوا
Enter keystore password: changeit