امروز موقع اجرای اسکریپت 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 برسیم
اول از همه یادمون باشه ما دیتابیس اوراکلی رو می‌تونیم به حالت آرشیو ببریم که وقتی دیتابیس‌امون رو 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 میخوره
بعد از اینکه با معماری اوراکل خوب آشنا شدید و شناخت این موضوع که اوراکل گلدن‌گیت کجای سازمان ما میتونه باشه و چه راه‌کارهایی رو میتونه به ما ارائه بده به معماری خود گلدن‌گیت می‌رسیم. در کل همین اول کار بهتره بدونید گلدن‌گیت عملاً از یکسری سرویس تشکیل شده یعنی اینکه اگه فکر می‌کنید اپلیکیشن گرافیکی هستش و دیتابیسی پشتش قرار می‌گیره نه این اتفاق در گلدن‌گیت صورت نمی‌گیره.
گلدن‌گیت در اصل یکسری سرویسه اینکه من تو پست‌های قبلی همش تاکید می‌کردم ما 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 - قسمت سوم
مهمترین بخش معماری که باید برای گلدن‌گیت خوب بلد باشید شکل زیر هستش:
خب میخوام معماری اوراکل رو به صورت سناریو بیس و خلاصه دوباره دوباره تکرار کنم چون مسلط بودن به این معماری از ضروریات کاره
