خب تا حالا داشتیم سناریوی Unidirectional رو باهم مرور میکردیم نوبتی هم باشه نوبته معماری Bidirectional هستش
خب تا حالا داشتیم سناریوی Unidirectional رو باهم مرور میکردیم نوبتی هم باشه نوبته معماری Bidirectional هستش
خب فکر کنید ما نیاز داریم join چند جدول از مبدا رو در یک جدول در دیتابیس مقصد بنویسیم خب در گلدنگیت برای این مورد ما باید شروع به نوشتن اسکریپتنویسی با REM کنیم که جزو موارد advanced گلدنگیت محسوب میشه، البته شما میتونید از یه راهکار به مراتب سادهتر اسفاده کنید اونم اینکه جداول مورد نیازتون رو بدون join بیارید به سمت سرور مقصد و روی جدول آخری که میخواد آپدیت بشه شما یک Triger مینویسید که وقتی ۲ تا رکورد از ۲ جدول اومدن join بزنه و روی جدول نهایی بنویسه پس تا stage io رو با گلدنگیت جلو میاریم و از Stage I/O به DWH رو با تریگر جلو میبریم بعد شما چون فقط یک تریگر روی جدول آخر دارید performance بالایی خواهید داشت.
همانطور که گفتم در نسخههای اخیر Oracle GoldenGate جایگزین Oracle Streams شده
در بحث Oracle DataGuard قضیه sync بین primaryها و standbyها یکطرفه است. ولی در سناریو Streaming شما میتونید sync دوطرفه داشته باشید. یعنی ۲ تا پایگاه داده داشته باشید که در هر ۲ وقتی کاربران اطلاعات وارد و یا آپدیت میکنن اطلاعات نوشته میشه و در نهایت این ۲ سرور اط نظر اطلاعات یکی هستند.
همچنین شما میتونید کاربرد خاصتری از streaming بگیرید و فقط یکسری از جداول و schema های خاص رو در هر ۲ باهم sync کنید.(از سرور مبدا به سرور مقصد)
Oracle Streams یا Oracle GoldenGate قابلیت انعطافپذیری بسیار بالایی داره، شما میتونید حتی دیتابیس اوراکل رو با پایگاهدادههای دیگهای غیر از اوراکل (مثل DB2, SQL Server, ...) بیاین و sync کنید.