ممکنه وقتی Oracle Fusion Middleware یا Oracle WebLogic Server 12c رو نصب کرده باشید موقع استارت و یا اجرای اسکریپت autostart وبلاجیک به خطای زیر برخورد کرده باشید:
"weblogic.nodemanager.common.ConfigException: Identity key store file not found"
همونطور که خطا مشخص کرده دنبال موجودیتی به نام DemoIdentity.jks هستیم که در دایرکتوری security دامنه سرور وبلاجیک آن را پیدا نمیکنیم. خطای کلی مشابه زیر است:
امروز موقع اجرای اسکریپت autostart وبلاجیک (نسخه 12.2.1.3.0) با خطای زیر برخورد کردم:
Error: Could not find or load main class utils.CertGen
رفع این خطا به شکل زیر امکان پذیر است:
حداقل ۲۰ گیگ دیسک برای نصب ۲ محصول Oracle Database, Oracle Grid Infrastructure بر روی OEL 6.x الزامی است.
ابتدا ISO را وارد میکنیم و ماشین را از روی دیسک boot میکنیم تا به نصاب Anaconda برسیم
یکی از بهترین کتابهای موجود برای یادگیری عملی محصول Oracle GoldenGate کتاب Oracle GoldenGate 11g Implementer's guide نوشته شده توسط John P. Jeffries و انتشار یافته توسط انتشارات packt است.
اول از همه یادمون باشه ما دیتابیس اوراکلی رو می‌تونیم به حالت آرشیو ببریم که وقتی دیتابیس‌امون رو shutdown میکنیم تا به حالت mount برسیم instance recovery ای اتفاق نیوفتد یعنی لازمه حتما SCNها یکی شده باشند.
پس اگه ما shutdown abort کنیم و رو حالت mount ببریم و بخوایم دیتابیس رو به حالت آرشیو ببریم امکانش وجود نخواهد داشت.
دیتابیس رو shutdown میکنیم:
SQL> shut immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
دیتابیس رو به حالت mount می‌بریم:
SQL> startup mount;
ORACLE instance started.
Total System Global Area 1653518336 bytes
Fixed Size 2253784 bytes
Variable Size 1543506984 bytes
Database Buffers 100663296 bytes
Redo Buffers 7094272 bytes
Database mounted.
دیتابیس رو روی حالت آرشیو می‌ذاریم:
SQL> alter database archivelog;
Database altered.
حالا دیتابیس رو open میکنیم تا instance تشکیل بشه
SQL> alter database open;
Database altered.
برای چک کردن این موضوع که دیتابیس ما تو حالت آرشیو لاگ هستش یا نه از دستور زیر در SQLPLUS استفاده میکنیم:
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 109
Next log sequence to archive 111
Current log sequence 111
خب همونطور که می‌بینید مکانیزم آرشیو لاگ در این سرور فعال هستش و مقصد ذخیره آرشیوها در پارامتر db_recovery_file_dest تنظیم شده که اینجا همون فضای FRA ما هستش
حالا اگه یک Switch Logfile دستی بزنیم مشاهده میکنیم Online Redo Log File ما آرشیو شده
SQL> alter system switch logfile;
System altered.
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 110
Next log sequence to archive 112
Current log sequence 112
خب تا حالا داشتیم سناریوی Unidirectional رو باهم مرور میکردیم نوبتی هم باشه نوبته معماری Bidirectional هستش
خب فکر کنید ما نیاز داریم join چند جدول از مبدا رو در یک جدول در دیتابیس مقصد بنویسیم خب در گلدن‌گیت برای این مورد ما باید شروع به نوشتن اسکریپت‌نویسی با REM کنیم که جزو موارد advanced گلدن‌گیت محسوب میشه، البته شما می‌تونید از یه راهکار به مراتب ساده‌تر اسفاده کنید اونم اینکه جداول مورد نیازتون رو بدون join بیارید به سمت سرور مقصد و روی جدول آخری که میخواد آپدیت بشه شما یک Triger می‌نویسید که وقتی ۲ تا رکورد از ۲ جدول اومدن join بزنه و روی جدول نهایی بنویسه پس تا stage io رو با گلدن‌گیت جلو میاریم و از Stage I/O به DWH رو با تریگر جلو می‌بریم بعد شما چون فقط یک تریگر روی جدول آخر دارید performance بالایی خواهید داشت.
یه مشکل اساسی که میتونه برای هر کسب و کاری رخ بده خاموش شدن ماشین فیزیکی سرورها هستش. ممکنه براتون پیش بیاد که تمام برق دیتاسنتر قطع شده و بعد از مدتی دوباره برق برگرده و به مجرد برگشت برق به ماشین شما اگه ESXi بر روی ماشین داشته باشید ماشین فیزیکی به طور خودکار روشن میشه
خب ماشین فیزیکی شما روشن هستش ولی تکلیف مایشنهای مجازی شما چی میشه؟
اینجا بر هر ادمین VMware ای واجبه که ماشینهای مجازی اش رو روشن بکنه ولی اگه شما ادمین ندارید! و یا صلاح کسب و کار شما این هستش که ماشینهای مجازی بعد از بوت ماشین فیزیکی و بالا اومدن ESXi به طور خودکار روشن بشوند پس نیاز به این پیکربندی دارید:
با vSphere Client به ESXi لاگین کنید(اگه vCenter دارید به اون لاگین کنید)
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 میخوره
