برای فعال کردن قابلیت Supplemental Logging در سطح رکورد ما می‌تونیم TRANDATA رو در گلدن‌گیت فعال کنیم، اگه شما از TRANDATA استفاده نکنید دستورات UPDATE و DELETE موقع APPLY توسط REPLICAT قطعاً FAIL می‌شوند و سرویس REPLICAT ممکنه Abend بشه
اگه بخوایم ریپلیکیشن ۲ طرفه راه‌اندازی کنیم نیازه که CheckpointTable رو در سمت سرور مبدا فعال کنیم
اگه این قابلیت رو فعال کنیم گلدن‌گیت در کاربر دیتابیسی مذکور میاد و جدولی بابت Checkpointها براساس اسمی که دادیم میسازه
GGSCI (lx-02-oracle as GGS@orcl) 11> Add CheckpointTable ggs.mycheckpt
Successfully created checkpoint table mycheckpt.
نکته: جداولی که می‌بینید اکثراً به خاطر پیکربندی‌های DDL ای هستش و اگه این پیکربندی‌ها رو انجام نمیدادیم یا نیازی به DDLها نداشتیم این جداول هم ساخته نمی‌شدند.
برای فعال کردن TRANDATA روی یک یا چند جدول می‌تونیم از دستور زیر استفاده کنیم:
GGSCI> Add TranData myschema.*
و یا فعال کردن بر روی یک اسکیما (پارامتر enable_goldengate_replication حتماً باید در سطح اوراکل فعال باشه):
GGSCI> Add SchemaTranData yourschema
خب RBA همیشه در یک رکورد وجود داره مگه اینکه شما چندتا سرویس بسازید و بگید اینها چک پوینت‌های مختلفی داشته باشند در کل به ازای هر کدوم از سرویسهای REPLICAT ما یک رکورد در CHKPOINT داریم. اصل صحبت هم اینه که اگه سرویس REPLICAT گلدن‌گیت به هر دلیلی پایین اومد و بعد طی زمانی بالا اومد بدونه از کدوم RBA باید بقیه دیتا رو بره بخونه
همونطور که گفتم در این جدول فقط checkpointهای مربوط به سرویس replicat قرار میگیرن و checkpointهای باقی سرویسهای گلدن‌گیت مثل Extract در دایرکتوری dirchk قرار میگیرن
[oracle@lx-02-oracle dirchk]$ pwd /u02/app/oracle/ggs/dirchk/
/u02/app/oracle/ggs/dirchk
فعال کردن TRANDATA
خب من برای راه‌اندازی سناریوی تست‌مون چون میخوام تمام UPDATE و DELETE ها هم توسط گلدن‌گیت در سمت مقصد اعمال شوند TRANDATA رو در سطح اسکیمای تست فعال میکنم:
GGSCI (lx-02-oracle) 1> Dblogin userid GGS,password GGS;
Successfully logged into database.
GGSCI (lx-02-oracle as GGS@orcl) 2> ADD TRANDATA TEST_UNIDIRECTIONALGGS.*
2017-11-02 14:50:31 WARNING OGG-06439 No unique key is defined for table TEST_GGS_1. All viable columns will be used to represent the key, but may not guarantee uniqueness. KEYCOLS may be used to define the key.
Logging of supplemental redo data enabled for table TEST_UNIDIRECTIONALGGS.TEST_GGS_1.
TRANDATA for scheduling columns has been added on table 'TEST_UNIDIRECTIONALGGS.TEST_GGS_1'.
Logging of supplemental redo data enabled for table TEST_UNIDIRECTIONALGGS.TEST_GGS_2.
TRANDATA for scheduling columns has been added on table 'TEST_UNIDIRECTIONALGGS.TEST_GGS_2'.
همونطور که می‌بینید بر روی جدول TEST_GGS_1 یک هشداری داده که تمام ستونهای جدول رو به عنوان PK در نظر گرفته و میگه برای یونیک بودن این مسئله گارانتی‌ای نمیده ولی چون جدول TEST_GGS_2 خودش PK داشت دیگه پیغام هشداری نداده
پس ما الان به صورت ریز این آبجکتها رو در لاگ Supplemental داریم و گلدن‌گیت میتونه بر روی اونها عملیات انجام بده