سناریوی Unidirectional - قسمت ششم (سرویس Capture)

برای ساخت این سرویس اول از همه باید فایل پیکربندی اون رو بسازیم:

edit param eora1

و پیکربندی زیر رو درون اون قرار بدیم:

EXTRACT eora1 
USERID ggs, & 
PASSWORD ggs
TRANLOGOPTIONS EXCLUDEUSER ggs, asmuser sys@ASM, asmpassword sys
ENCRYPTTRAIL AES128 KEYNAME supermaskey
EXTTRAIL dirdat/l1
DDL INCLUDE MAPPED
TABLE TEST_USER.*;

خط اول: ما مشخص میکنیم که یک سرویس extract به اسم eora1 میخوایم

خط دوم: مشخص میکنیم که نام‌کاربری ما چیه

خط سوم: پسورد رو کاربر گلدن‌گیتمون رو وارد میکنیم (می‌تونیم به صورت هش شده اون رو وارد کنیم)

نکته: توی گلدن‌گیت برای اضافه کردن سرویسها باید به صورت اسکرپت‌نویسی عمل کنیم یعنی هر خط اینجا یک دستور جدید محسوب میشه برای اینکه ادامه‌ی دستوری رو خط بعدش بنویسیم از & استفاده می‌کنیم 

خط چهارم: با دستور TRANLOGOPTIONS ما بر روی TRAIN Fileها مدیریت انجام می‌دیم یکی از آپشنهای این دستور EXCLUDEUSER هستش که با دادن کاربر ggs من از ایجاد loop جلوگیری کردم.

نکته: اگه دیتابیس شما با ASM پیکربندی شده چون Redo Log های ما در دیسک گروه‌های ASM وجود دارن و گلدن‌گیت نیاز داره به طور مستقیم با Online Redo Log Fileها کار بکنه ما باید مشخصات کاربر ASM رو هم بهش بدیم که اینکار رو با آپشنهای asmuser, asmpassword در دستور TRANLOGOPTIONS انجام می‌دیم.

سناریوی Unidirectional - قسمت پنجم (پیکربندی GLOBAL)

GLOBAL یک فایل بدون پسوند هستش که ما می‌تونیم تعدادی از پارمترهای عمومی رو درون اون مشخص کنیم و با بالا اودن سرویس‌های گلدن‌گیت این تنظیمات اعمال می‌شوند. تا نسخه‌های قبلی می‌تونستیم اسم CheckpointTable رو همینجا درون این فایل مشخص کنیم اما تو نسخه‌های جدید گلدن‌گیت دیگه به این پارمتر کاری نداره و ازش تبعیت نمیکنه و شما حتما باید موقع ساخت CheckpointTable اسمی رو هم براش انتخاب کنید

نمونه‌ای از فایل GLOBALS

CHECKPOINTTABLE CHKTABLE
GGSCHEMA GGS
ENABLEMONITORING

سناریوی Unidirectional - قسمت چهارم (راه‌اندازی TRANDATA)

برای فعال کردن قابلیت Supplemental Logging در سطح رکورد ما می‌تونیم TRANDATA رو در گلدن‌گیت فعال کنیم، اگه شما از TRANDATA استفاده نکنید دستورات UPDATE و DELETE موقع APPLY توسط REPLICAT قطعاً FAIL می‌شوند و سرویس REPLICAT ممکنه Abend بشه

سناریوی Unidirectional - قسمت سوم (اسکیمای TEST)

برای راه‌اندازی سناریوی تست من یک اسکیما با تعدادی جدول میسازم:

DROP USER TEST_UNIDIRECTIONALGGS CASCADE;

CREATE USER TEST_UNIDIRECTIONALGGS
 IDENTIFIED BY <password>
 DEFAULT TABLESPACE USERS
 TEMPORARY TABLESPACE TEMP
 PROFILE DEFAULT
 ACCOUNT UNLOCK;
 -- 2 Roles for TEST_UNIDIRECTIONALGGS 
 GRANT CONNECT TO TEST_UNIDIRECTIONALGGS;
 GRANT DBA TO TEST_UNIDIRECTIONALGGS;
 ALTER USER TEST_UNIDIRECTIONALGGS DEFAULT ROLE ALL;
 -- 2 System Privileges for TEST_UNIDIRECTIONALGGS 
 GRANT CREATE SESSION TO TEST_UNIDIRECTIONALGGS;
 GRANT UNLIMITED TABLESPACE TO TEST_UNIDIRECTIONALGGS;
 -- 1 Tablespace Quota for TEST_UNIDIRECTIONALGGS 
 ALTER USER TEST_UNIDIRECTIONALGGS QUOTA UNLIMITED ON USERS;

سناریوی Unidirectional - قسمت دوم (سرویس Manager)

خب همونطور که یادتونه در مراحل نصب، گلدن‌گیت سرویس MGR رو ساخته و میدونیم استارت شده برای اینکه ببینیم چه سرویس‌هایی در گلدن‌گیت پیکربندی شده‌اند از دستور زیر استفاده می‌کنیم:

GGSCI (lx-02-oracle) 1> info all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING

برای اینکه محتویات فایل MGR رو ببینیم از دستور زیر استفاده می‌کنیم:

GGSCI (lx-02-oracle) 2> edit param mgr

نکته: با زدن این دستور فایل پیکرندی شما با ادیتور پیشفرض تنظیم شده باز میشه

برای باز کردن فایل در محل فیزیکی اون هم به مسیر زیر می‌ریم و فایل مربوطه رو در دایکتوری مربوطه باز می‌کنیم:

نکته: دایرکتوری مربوط به پیکرندی‌های گلدن‌گیت (dirprm) هستش

[root@lx-02-oracle ~]# cd /u02/app/oracle/ggs/dirprm/
[root@lx-02-oracle dirprm]# ll
total 8
-rwxr-x--- 1 oracle oinstall 103 Aug  7  2014 jagent.prm
-rw-r--r-- 1 oracle oinstall  10 Nov  1 17:13 mgr.prm

سناریوی Unidirectional - قسمت اول (راه‌اندازی مبداء)

راه‌اندازی مبدا

بردن دیتابیس به حالت ArchiveLog

اول از همه یادمون باشه ما دیتابیس اوراکلی رو می‌تونیم به حالت آرشیو ببریم که وقتی دیتابیس‌امون رو 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 در Oracle GoldenGate - مقدمه

نگاهی بر معماری Oracle GoldenGate - قسمت پنجم

خب تا حالا داشتیم سناریوی Unidirectional رو باهم مرور میکردیم نوبتی هم باشه نوبته معماری Bidirectional هستش

نگاهی بر معماری Oracle GoldenGate - قسمت چهارم

خب فکر کنید ما نیاز داریم join چند جدول از مبدا رو در یک جدول در دیتابیس مقصد بنویسیم خب در گلدن‌گیت برای این مورد ما باید شروع به نوشتن اسکریپت‌نویسی با REM کنیم که جزو موارد advanced گلدن‌گیت محسوب میشه، البته شما می‌تونید از یه راهکار به مراتب ساده‌تر اسفاده کنید اونم اینکه جداول مورد نیازتون رو بدون join بیارید به سمت سرور مقصد و روی جدول آخری که میخواد آپدیت بشه شما یک Triger می‌نویسید که وقتی ۲ تا رکورد از ۲ جدول اومدن join‌ بزنه و روی جدول نهایی بنویسه پس تا stage io رو با گلدن‌گیت جلو میاریم و از Stage I/O به DWH رو با تریگر جلو می‌بریم بعد شما چون فقط یک تریگر روی جدول آخر دارید performance بالایی خواهید داشت.

قابلیت‌ها

Filtering

نگاهی بر معماری Oracle GoldenGate - قسمت سوم

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 میخوره