راهنمای جامع مهاجرت صفر دیتابیس اوراکل 11g به 19c با استفاده از Oracle GoldenGate و Data Pump

مقدمه و استراتژی معماری

در سامانه‌های حساس بانکی و سازمانی، امکان خاموش کردن پایگاه‌داده برای ساعت‌های متمادی جهت ارتقا یا جابه‌جایی وجود ندارد. روش مهاجرت با زمان توقف نزدیک به صفر (Near-Zero Downtime Migration) پاسخی به این نیاز حیاتی است.

در این سناریو، مهاجرت شامل دو شریان اصلی است:

  1. انتقال داده‌های پایه (Initial Load): با استفاده از ابزار قدرتمند Oracle Data Pump در یک نقطه مشخص از زمان بر اساس شماره تغییرات سیستم (SCN).
  2. همگام‌سازی پیوسته تغییرات (CDC - Change Data Capture): با استفاده از Oracle GoldenGate جهت خواندن لاگ‌های Redo/Archive از نقطه شروع و اعمال آن‌ها در دیتابیس مقصد بدون ایجاد تداخل.

جریان همگام‌سازی و انتقال داده‌ها در این سناریو به صورت دو مسیر موازی و مکمل پیاده‌سازی شده است:

  1. مسیر همگام‌سازی لحظه‌ای (Real-time CDC):

    • پروسس Extract (EXT1) بر روی سرور سورس 11g اجرا می‌شود. این پروسس با استفاده از قابلیت DBLOGREADER تغییرات را مستقیماً از لاگ‌های Redo و Archive مستقر بر روی ASM استخراج می‌کند.
    • تغییرات استخراج‌شده درون فایل‌های تریل محلی (Local Trail) با مسیر ./dirdat/et بر روی سرور مبدأ نوشته می‌شوند.
    • پروسس Data Pump (PUMP1) فایل‌های تریل محلی را بازخوانی کرده و از طریق پروتکل TCP/IP و پورت اختصاصی سرویس Manager (پورت 7809) روی بستر شبکه به سرور مقصد ارسال می‌کند.
    • سرویس Manager در سرور مقصد 19c، داده‌های دریافتی از شبکه را در قالب فایل‌های تریل ریموت (Remote Trail) با مسیر ./dirdat/rt ذخیره می‌کند.
    • پروسس Replicat (REP1) در سرور مقصد، فایل‌های تریل ریموت را خوانده و با اعمال شرط AFTERCSN (تنها تغییرات پس از نقطه شروعِ اکسپورت)، تراکنش‌ها را بر روی دیتابیس مقصد (PDB) درج و اعمال می‌کند.
  2. مسیر بارگذاری اولیه داده‌ها (Initial Load):

    • ابزار Data Pump Export (expdp) با استفاده از پارامتر FLASHBACK_SCN از داده‌های مبدأ تا همان تیک زمانی مشخص یک خروجی سازگار تهیه می‌کند.
    • فایل دامپ حاصل (hr_migrate_11g.dmp) به سرور مقصد منتقل شده و توسط Data Pump Import (impdp) درون ساختار PDB دیتابیس 19c بارگذاری می‌شود.
    • پروسس Replicat دقیقاً از این نقطه به بعد را تحویل گرفته و ادامه می‌دهد تا هیچ رکوردی مفقود یا تکرار نشود.

 

معماری گلدن‌گیت: مقایسه معماری کلاسیک (Classic) و میکروسرویس (Microservices Architecture)

شرکت اوراکل از نسخه 12.3 به بعد، تحولی اساسی در معماری GoldenGate ایجاد کرد و مدل نوین مبتنی بر وب‌سرویس و REST API را معرفی نمود.

 

۱. معماری کلاسیک (Classic Architecture)

این معماری، ساختار سنتی و پرکاربرد گلدن‌گیت است که بر پایه خط فرمان و ابزارهای سیستم‌عاملی کار می‌کند (همان معماری استفاده‌شده در این سناریو).

  • روش مدیریت: تعامل کاربر و ادمین فقط از طریق ابزار خط فرمانی GGSCI (GoldenGate Software Command Interpreter) انجام می‌شود.
  • پروسس مرکزی (MGR): سرویس MANAGER مسئولیت کنترل فرایندها، مانیتورینگ منابع، اختصاص پورت و تخصیص حافظه را دارد.
  • فایل‌های تنظیمات: کلیه رفتارهای پروسس‌ها در قالب فایل‌های متنی ساده با پسوند .prm (مانند ext1.prm و mgr.prm) درون پوشه dirprm مدیریت می‌شوند.
  • مزایا:
    • بسیار سبک، بهینه و بدون سربار اضافی منابع.
    • سادگی در پیکربندی و اتوماسیون با Bash Script و کارهای روزمره ادمین‌های لینوکس/اوراکل.
    • پشتیبانی وسیع از نسخه‌های قدیمی پایگاه‌داده اوراکل (از جمله 11g).
  • محدودیت‌ها: نبود داشبورد بومی وب، مدیریت سنتی دسترسی‌ها، دشواری مانیتورینگ متمرکز چند نود بدون نصب ابزارهای جانبی.

 

۲. معماری جدید میکروسرویس (Microservices Architecture - MA)

معماری MA ساختاری مدرن، ابری (Cloud-Ready) و ماژولار است که در آن هر بخش از گلدن‌گیت به عنوان یک سرویس مستقل تحت وب عمل می‌کند.

  • روش مدیریت: دارای یک کنسول تحت وب غنی (Web GUI) به همراه واسط برنامه‌نویسی کاملاً استاندارد REST API است. در این حالت ابزار خط فرمانی به نام Admin Client جایگزین GGSCI می‌شود.
  • سرویس‌های تشکیل‌دهنده:
    • Service Manager: پروسس مادر برای مدیریت چرخه حیات (Start/Stop) سایر سرویس‌ها.
    • Administration Service: مدیریت و ایجاد پروسس‌های Extract و Replicat.
    • Distribution Service: جایگزین پیشرفته پروسس پمپ سنتی؛ انتقال تریل‌ها از طریق پروتکل‌های امن و بهینه تحت وب.
    • Receiver Service: دریافت داده‌های ارسال‌شده توسط Distribution Service بر روی سرور مقصد.
    • Performance Metrics Service: پایش بلادرنگ عملکرد، پهنای باند و منابع مصرفی پروسس‌ها.
  • مزایا:
    • امنیت بالاتر با پشتیبانی داخلی از SSL/TLS و احراز هویت توکن‌محور.
    • داشبورد وب کارآمد برای مشاهده بلادرنگ وضعیت صف‌ها، لگ‌ها و پروسس‌ها بدون نیاز به لاگین لینوکسی.
    • یکپارچگی سریع با اکوسیستم‌های DevSecOps و ابزارهای مانیتورینگ سازمانی مثل Grafana و Prometheus.
  • محدودیت‌ها: مصرف منابع حافظه و CPU بالاتر به نسبت معماری کلاسیک، و همچنین عدم پشتیبانی کامل برخی نسخه‌ها/قابلیت‌های بسیار قدیمی دیتابیس اوراکل (مانند 11.2.0.4 بدون پچ‌های خاص).

 

 

مشخصات بستر پیاده‌سازی

  • دیتابیس سورس (Source):

    • نام هاست و آی‌پی: oracle4upgrade (192.168.56.61)
    • نسخه: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 (Non-CDB بر بستر ASM)
    • نام دیتابیس و نمونه: vahid4up
    • نسخه باینری OGG: بیلد OGG 19.1.0.0.4 کامپایل‌شده برای 11g
  • دیتابیس مقصد (Target):

    • نام هاست و آی‌پی: dc1 (192.168.56.63)
    • نسخه: Oracle Database 19c Enterprise Edition Release 19.27 (Multitenant PDB)
    • نام کانتینر ریشه و پلاگین: ریشه vahiddb و پلاگین PDB
    • نسخه باینری OGG: بیلد OGG 19.1.0.0.4 کامپایل‌شده برای 19c
  • اسکیمای نمونه مورد مهاجرت: HR

 

فاز ۱: آماده‌سازی دیتابیس سورس (Oracle 11g)

پیش از نصب گلدن‌گیت، دیتابیس سورس باید قابلیت تولید لاگ‌های تکمیلی و ارائه آن‌ها به پروسس‌های بیرونی را داشته باشد.

۱. فعال‌سازی Supplemental Logging و پارامتر طلایی ریپلیکیشن

وارد سرور سورس شده و با کاربر SYS دستورات زیر را اجرا کنید:

sqlplus / as sysdba


ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;


ALTER SYSTEM ARCHIVE LOG CURRENT;

ALTER SYSTEM SET enable_goldengate_replication = TRUE SCOPE=BOTH;

  • تحلیل خط‌به‌خط:
    • دستور ALTER DATABASE ADD SUPPLEMENTAL LOG DATA: اوراکل به صورت پیش‌فرض تنها ستون‌های تغییر یافته را در Redo لاگ می‌نویسد. برای آنکه GoldenGate بتواند رکوردهای مقصد را شناسایی و آپدیت کند، نیاز به اطلاعات کلید اصلی دارد که این دستور اطلاعات پایه شناسه رکورد را در ردولاگ ثبت می‌کند.
    • دستور ALTER SYSTEM ARCHIVE LOG CURRENT: آرشیو‌لاگ فعلی را بسته و هدرهای جدید لاگ را با ساختار سازگار با Supplemental Log فعال می‌سازد.
    • دستور ALTER SYSTEM SET enable_goldengate_replication = TRUE: فعال‌ساز درونی پکیج‌ها و زیرساخت ثبت تراکنش‌های اختصاصی گلدن‌گیت است. عدم فعال‌سازی آن منجر به خطای OGG-00303 حین استارت Extract می‌شود.

۲. ساخت کاربر و اعطای دسترسی‌های امنیتی OGG در سورس

CREATE TABLESPACE TBS_OGG DATAFILE SIZE 200M AUTOEXTEND ON NEXT 50M;

CREATE USER oggadmin IDENTIFIED BY "OGG_Admin123#"
  DEFAULT TABLESPACE TBS_OGG
  TEMPORARY TABLESPACE TEMP
  QUOTA UNLIMITED ON TBS_OGG;

GRANT CONNECT, RESOURCE TO oggadmin;
GRANT SELECT ANY DICTIONARY TO oggadmin;
GRANT SELECT ANY TRANSACTION TO oggadmin;
GRANT FLASHBACK ANY TABLE TO oggadmin;
GRANT EXECUTE ON DBMS_FLASHBACK TO oggadmin;

GRANT EXECUTE ON DBMS_STREAMS TO oggadmin;

GRANT EXECUTE ON DBMS_GOLDENGATE_AUTH TO oggadmin;

GRANT SELECT_CATALOG_ROLE TO oggadmin;

GRANT EXECUTE ON SYS.DBMS_STREAMS TO oggadmin;
GRANT EXECUTE ON SYS.DBMS_STREAMS_ADM TO oggadmin;
GRANT EXECUTE_CATALOG_ROLE TO oggadmin;

GRANT ALTER ANY TABLE TO oggadmin;

 GRANT SELECT ANY TABLE TO oggadmin;

 GRANT FLASHBACK ANY TABLE TO oggadmin;

  • تحلیل خط‌به‌خط:
    • ایجاد TBS_OGG: ایزوله کردن متادیتای گلدن‌گیت از Tablespaceهای سیستمی و بیزنسی.
    • اعطای SELECT ANY DICTIONARY: به Extract اجازه می‌دهد متادیتای جداول را از دیکشنری بخواند.
    • اعطای SELECT ANY TRANSACTION: خواندن تغییرات تمام تراکنش‌های ثبت‌شده در لاگ‌ها را امکان‌پذیر می‌سازد.
    • اعطای دسترسی‌های DBMS_FLASHBACK: برای برقراری همگام‌سازی تراکنشی و بازخوانی داده‌ها بر پایه SCN.

فاز ۲: آماده‌سازی دیتابیس مقصد (Oracle 19c PDB)

در معماری چندمستأجری (Multitenant) 19c، پیکربندی‌ها عمدتاً درون Pluggable Database هدف صورت می‌پذیرد، با یک استثنای حیاتی در سطح ریشه.

۱. تنظیم پارامتر در سطح CDB$ROOT

sqlplus / as sysdba

ALTER SYSTEM SET enable_goldengate_replication=TRUE SCOPE=BOTH;

  • نکته کلیدی رفع اشکال: تلاش برای اجرای این دستور درون کانتینر PDB به خطای ORA-65040: operation not allowed from within a pluggable database منجر خواهد شد. این پارامتر فقط باید در سطح ریشه (CDB) فعال گردد و اثر آن به تمام PDBها ارث می‌رسد.

۲. ورود به PDB و ساخت کاربر و اعطای نقش‌های 19c

ALTER SESSION SET CONTAINER = pdb;

CREATE TABLESPACE TBS_OGG DATAFILE SIZE 500M AUTOEXTEND ON NEXT 50M;

CREATE USER oggadmin IDENTIFIED BY "OGG_Admin123#"
  DEFAULT TABLESPACE TBS_OGG
  TEMPORARY TABLESPACE TEMP
  QUOTA UNLIMITED ON TBS_OGG;

GRANT CONNECT, RESOURCE TO oggadmin;
GRANT UNLIMITED TABLESPACE TO oggadmin;

GRANT INSERT ANY TABLE TO oggadmin;
GRANT UPDATE ANY TABLE TO oggadmin;
GRANT DELETE ANY TABLE TO oggadmin;
GRANT SELECT ANY TABLE TO oggadmin;

-- در صورتی که ساختار DDL هم قرار است ریپلیکیت شود:
GRANT CREATE ANY TABLE TO oggadmin;
GRANT ALTER ANY TABLE TO oggadmin;
GRANT DROP ANY TABLE TO oggadmin;


BEGIN
  DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE(
    grantee          => 'oggadmin',
    privilege_type   => 'APPLY',
    grant_select_privileges => TRUE
  );
END;
/

 

  • تحلیل خط‌به‌خط:
    • پروسیجر DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE: در نسخه‌های 12c به بالا اوراکل، این پروسیجر استانداردترین روش برای اختصاص کلیه مجوزهای لازم به پروسس Replicat جهت اعمال داده‌ها در معماری چندمستأجری است.
    • دسترسی‌های DML صریح: جلوگیری از بروز خطای متداول ORA-01031: insufficient privileges در زمان اعمال عملیات توسط پروسس Replicat.

فاز ۳: نصب سایلنت باینری‌های GoldenGate و تنظیم محیط

در هر دو سرور، فایل نصبی درون دایرکتوری /home/oracle/stage_ogg اکسترکت شده و بدون نیاز به محیط گرافیکی نصب می‌گردد.

۱. نصب در سورس (11g - سرور oracle4upgrade)

cd /home/oracle/stage_ogg/fbo_ggs_Linux_x64_shiphome/Disk1

./runInstaller -silent -nowait \
  oracle.install.responseFileVersion=/oracle/install/rspfmt_ogginstall_response_schema_v19_1_0 \
  INSTALL_OPTION=ORA11g \
  SOFTWARE_LOCATION=/u01/app/oracle/product/ogg19c \
  INVENTORY_LOCATION=/u01/app/oraInventory \
  oracle.install.engine.downloadSites=false

 

۲. نصب در مقصد (19c - سرور dc1)

cd /home/oracle/stage_ogg/fbo_ggs_Linux_x64_shiphome/Disk1

./runInstaller -silent -nowait \
  oracle.install.responseFileVersion=/oracle/install/rspfmt_ogginstall_response_schema_v19_1_0 \
  INSTALL_OPTION=ORA19c \
  SOFTWARE_LOCATION=/u01/app/oracle/product/ogg19c \
  INVENTORY_LOCATION=/u01/app/oraInventory \
  oracle.install.engine.downloadSites=false

 

۳. تنظیم متغیرهای محیطی در ~/.bash_profile (روی هر دو سرور)

cat << 'EOF' >> ~/.bash_profile

# OGG Environment Configuration
export OGG_HOME=/u01/app/oracle/product/ogg19c
export PATH=$OGG_HOME:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$OGG_HOME:$LD_LIBRARY_PATH
EOF

source ~/.bash_profile

 

فاز ۴: پیکربندی و راه‌اندازی پروسس‌های سورس (Source Pipeline)

۱. مقداردهی ساختار پوشه‌ها و تنظیم Manager در سورس

وارد پوشه OGG شده و ابزار خط فرمان را باز کنید:

cd /u01/app/oracle/product/ogg19c
./ggsci

 

CREATE SUBDIRS
EDIT PARAMS MGR

 

محتوای فایل MGR سورس:

PORT 7809
DYNAMICPORTLIST 7810-7820
PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPDAYS 3
AUTORESTART EXTRACT *, RETRIES 3, WAITMINUTES 2, RESETMINUTES 60

 

پروسس را استارت کنید:

START MGR
INFO MGR
 
۲. فعال‌سازی Supplemental Logging جداول (ADD TRANDATA)
 
DBLOGIN USERID oggadmin, PASSWORD OGG_Admin123#
ADD TRANDATA HR.*
 
  • توضیح: این دستور کلیدهای اصلی (PK) تمام جداول اسکیمای HR را بررسی و ثبت کلیدها را در ردولاگ قطعی می‌کند تا OGG بتواند رکوردها را متمایز کند.

۳. تعریف و پیکربندی پروسس Extract اولیه (EXT1)

ADD EXTRACT EXT1, TRANLOG, BEGIN NOW
ADD EXTTRAIL ./dirdat/et, EXTRACT EXT1, MEGABYTES 100
EDIT PARAMS EXT1

 

محتوای فایل پارامتر EXT1.prm:

EXTRACT EXT1
USERID oggadmin, PASSWORD OGG_Admin123#
TRANLOGOPTIONS DBLOGREADER
EXTTRAIL ./dirdat/et
TABLE HR.*;

 

  • تحلیل خط‌به‌خط:
    • TRANLOGOPTIONS DBLOGREADER: یک پارامتر حیاتی. در دیتابیس 11g مستقر بر روی ASM، بدون این پارامتر اکسترکت به خطای OGG-02829 (ناتوانی در خوانش مستقیم لاگ‌ها از دیسک‌گروپ ASM) می‌خورد. این پارامتر به پروسس دستور می‌دهد لاگ‌ها را از طریق لایه کلاینتی دیتابیس استخراج کند.
    • EXTTRAIL ./dirdat/et: تغییرات به صورت قطعات ۱۰۰ مگابایتی محلی در این مسیر با پیشوند et ذخیره می‌شوند.

پروسس را استارت کنید:

START EXT1
INFO EXT1

 

۴. تعریف و پیکربندی پروسس پمپ شبکه (PUMP1)

پروسس پمپ، تریل محلی را خوانده و با شبکه به سرور مقصد می‌فرستد:

ADD EXTRACT PUMP1, EXTTRAILSOURCE ./dirdat/et
ADD RMTTRAIL ./dirdat/rt, EXTRACT PUMP1, MEGABYTES 100
EDIT PARAMS PUMP1

 

محتوای فایل پارامتر PUMP1.prm:

EXTRACT PUMP1
PASSTHRU
RMTHOST 192.168.56.63, MGRPORT 7809
RMTTRAIL ./dirdat/rt
TABLE HR.*;

 

  • تحلیل خط‌به‌خط:
    • PASSTHRU: به پروسس اعلام می‌کند نیازی به بررسی دیکشنری یا دستکاری دیتا ندارد؛ لاگ‌های باینری را مستقیماً از روی دیسک مبدأ بردارد و روی شبکه پمپ کند (کاهش چشمگیر بار پردازشی CPU).
    • RMTHOST ... RMTTRAIL: مقصد بسته‌ها را به IP سرور 19c، پورت منیجر 7809 و مسیر تریل ریموت با پیشوند rt هدایت می‌کند.

پروسس را استارت کنید:

START PUMP1
INFO ALL

 

فاز ۵: همگام‌سازی داده‌های پایه (Initial Load با Data Pump و SCN)

اکنون پروسس‌های OGG تمام تغییرات لحظه‌ای را ضبط می‌کنند. برای انتقال داده‌های موجود، یک نقطه زمانی ثابت نیاز داریم.

۱. استخراج SCN جاری دیتابیس

در سرور سورس:

sqlplus / as sysdba

SELECT CURRENT_SCN FROM V$DATABASE;

فرض می‌کنیم خروجی به دست آمده برابر است با :1129555

CURRENT_SCN=1129555

۲. اکسپورت داده‌های سورس با قفل منطقی بر روی SCN

expdp \"/ as sysdba\" \
  SCHEMAS=HR \
  DIRECTORY=DATA_PUMP_DIR \
  DUMPFILE=hr_migrate_11g.dmp \
  LOGFILE=expdp_hr_migrate.log \
  FLASHBACK_SCN=1129555

 

  • توضیح: پارامتر FLASHBACK_SCN=1129555 تضمین می‌کند کل داده‌های خارج‌شده دقیقاً مطابق با وضعیت دیتابیس در همین تیک زمانی هستند، حتی اگر کاربران همزمان در حال درج یا ویرایش داده باشند.

۳. انتقال فایل دامپ به سرور مقصد و ایمپورت در PDB

فایل را به سرور مقصد منتقل کنید:

scp /u01/app/oracle/admin/vahid4up/dpdump/hr_migrate_11g.dmp این آدرس ایمیل توسط spambots حفاظت می شود. برای دیدن شما نیاز به جاوا اسکریپت دارید:/tmp/
 
در سرور مقصد، فایل را درون مسیر دایرکتوری Data Pump مربوط به PDB قرار داده و ایمپورت کنید:
 
impdp \"sys/Oracle_123#@192.168.56.63:1521/pdb as sysdba\" \
  DIRECTORY=DATA_PUMP_DIR \
  DUMPFILE=hr_migrate_11g.dmp \
  LOGFILE=impdp_hr_migrate.log \
  SCHEMAS=HR
 

فاز ۶: اقدامات حیاتی پس از ایمپورت (Triggers, Sequences, Constraints)

این بخش ضامن سلامت داده‌هاست که پیش از روشن کردن موتور Replicat باید در دیتابیس مقصد تنظیم شوند.

۱. غیرفعال‌سازی تریگرها در دیتابیس مقصد

در دیتابیس مقصد (PDB)، تریگرها را موقتاً غیرفعال کنید تا مانع اجرای دوباره کدهای بیزنسی شوند:

sqlplus sys/Oracle_123#@192.168.56.63:1521/pdb as sysdba

 

BEGIN
  FOR t IN (SELECT owner, trigger_name FROM all_triggers WHERE owner = 'HR') LOOP
    EXECUTE IMMEDIATE 'ALTER TRIGGER "' || t.owner || '"."' || t.trigger_name || '" DISABLE';
  END LOOP;
END;
/

 

۲. بررسی وضعیت جاب‌های پس‌زمینه در مقصد

برای جلوگیری از تداخل برنامه‌های زمان‌بندی‌شده:

ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0 SCOPE=MEMORY;

 

فاز ۷: پیکربندی و راه‌اندازی پروسس Replicat در مقصد

اکنون دیتابیس مقصد شامل داده‌ها تا نقطه SCN 1129555 است. باید به GoldenGate بگوییم تنها تغییراتی را اعمال کند که بعد از این SCN در تریل ثبت شده‌اند.

۱. ساخت جدول Checkpoint و تعریف Replicat

در کنسول GGSCI سرور مقصد (dc1):

cd /u01/app/oracle/product/ogg19c
./ggsci

 

DBLOGIN USERID این آدرس ایمیل توسط spambots حفاظت می شود. برای دیدن شما نیاز به جاوا اسکریپت دارید:1521/pdb, PASSWORD OGG_Admin123#
ADD CHECKPOINTTABLE oggadmin.ggschkpt
ADD REPLICAT REP1, EXTTRAIL ./dirdat/rt, CHECKPOINTTABLE oggadmin.ggschkpt
EDIT PARAMS REP1

 

محتوای فایل پارامتر REP1.prm:

REPLICAT REP1
USERID این آدرس ایمیل توسط spambots حفاظت می شود. برای دیدن شما نیاز به جاوا اسکریپت دارید:1521/pdb, PASSWORD OGG_Admin123#
ASSUMETARGETDEFS
DISCARDFILE ./dirrpt/rep1.dsc, PURGE
MAP HR.*, TARGET HR.*;

 

  • تحلیل خط‌به‌خط:
    • CHECKPOINTTABLE: جدولی است که Replicat آخرین وضعیت خواندن تریل و SCN اعمال‌شده را در آن ذخیره می‌کند تا در صورت ریست سرور، دیتایی دوبار درج یا از دست نرود.
    • ASSUMETARGETDEFS: اعلام می‌کند ساختار جداول سورس و مقصد دقیقاً یکسان است و نیازی به تولید فایل Defgen مجزا نیست.
    • DISCARDFILE: رکوردهایی که احیاناً به دلیل خطای دیتا اعمال نشوند، به جای توقف کل پروسس در این فایل ثبت می‌شوند.

۲. استارت Replicat با فیلتر CSN

START REPLICAT REP1, AFTERCSN 1129555

  •  کلید همگام‌سازی بدون تکرار داده همین عبارت AFTERCSN است. Replicat تمام رکوردهای قدیمی‌تر را رد می‌کند و دقیقاً از اولین تغییر پس از اکسپورت شروع به نوشتن در دیتابیس مقصد می‌کند.

بررسی سلامت پروسس:

INFO ALL
INFO REP1

(مقدار Lag at Chkpt باید 00:00:00 و وضعیت RUNNING باشد).


فاز ۸: تست در لحظه (Live Replication Test)

جهت اعتبارسنجی عملیاتی:

۱. درج رکورد در سورس (11g)

sqlplus hr/این آدرس ایمیل توسط spambots حفاظت می شود. برای دیدن شما نیاز به جاوا اسکریپت دارید:1521/vahid4up

 

INSERT INTO hr.regions (region_id, region_name) VALUES (99, 'OGG_Zero_Downtime_Test');
COMMIT;

 

۲. بررسی رکورد در مقصد (19c)

sqlplus sys/Oracle_123#@192.168.56.63:1521/pdb as sysdba

SELECT * FROM hr.regions WHERE region_id = 99;

 

مشاهده رکورد بالا نشان‌دهنده برقراری خط لوله کامل بدون خطا است.


فاز ۹: دستورالعمل اجرایی روز انتقال نهایی (Production Cutover Playbook)

در موعد انجام جابه‌جایی نهایی:

گام اول: مسدودسازی دسترسی کاربران به سورس

توقف سرویس اپلیکیشن یا رید-اونلی کردن دیتابیس سورس:

ALTER SYSTEM SET TRANSACTION READ ONLY;

گام دوم: اطمینان از تخلیه صف لاگ‌ها (Drain Pipeline)

در محیط GGSCI سورس و مقصد، بررسی کنید که میزان تأخیر به صفر مطلق رسیده باشد:

-- در سورس:
SEND EXTRACT EXT1, SHOWCHKS
SEND EXTRACT PUMP1, SHOWCHKS

-- در مقصد:
SEND REPLICAT REP1, STATUS

وقتی پیام At EOF, no more records to process دریافت شد، پروسس‌ها را متوقف کنید:

 

-- سورس:
STOP EXTRACT PUMP1
STOP EXTRACT EXT1

-- مقصد:
STOP REPLICAT REP1

گام سوم: همگام‌سازی و جلو بردن Sequenceها در مقصد

از آنجا که Sequenceها حین ریپلیکیشن در سورس پیش رفته‌اند اما در مقصد تغییر نکرده‌اند، با اسکریپت زیر در مقصد، آخرین مقادیر سورس را دریافت کرده و در مقصد بازتنظیم کنید:

-- در دیتابیس مقصد 19c با اجرای بلاک PL/SQL زیر برای هر سکوئنس:
-- مثال برای EMPLOYEES_SEQ با فرض اینکه آخرین عدد در سورس 2500 است:


ALTER SEQUENCE hr.employees_seq RESTART WITH 3000;

 

(یا با روش جنریک تولید اسکریپت بر اساس تفاضل LAST_NUMBER از دیتابیس سورس به همراه یک بافر ۵۰۰ تا ۱۰۰۰ عددی).

گام چهارم: فعال‌سازی تریگرها و جاب‌ها در مقصد

-- فعال‌سازی مجدد همه تریگرها
BEGIN
  FOR t IN (SELECT owner, trigger_name FROM all_triggers WHERE owner = 'HR') LOOP
    EXECUTE IMMEDIATE 'ALTER TRIGGER "' || t.owner || '"."' || t.trigger_name || '" ENABLE';
  END LOOP;
END;
/

-- فعال‌سازی جاب‌های زمان‌بندی‌شده
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=40 SCOPE=BOTH;

 

گام پنجم: تغییر Connection String اپلیکیشن

کانکشن استرینگ اپلیکیشن از سرور قدیمی به مقصد تغییر می‌یابد:

jdbc:oracle:thin:@192.168.56.63:1521/PDB

اپلیکیشن استارت می‌شود. کل زمان قطعی کاربر (Downtime) تنها محدود به چند دقیقه زمان تغییر IP و اتصال مجدد وب‌سرورها بوده است.


راهنمای عیب‌یابی و چالش‌های رایج (Troubleshooting)

در طول فرآیند مهاجرت با استفاده از Oracle GoldenGate، ممکن است با خطاهای زیر مواجه شوید. در اینجا علت ریشه‌ای و راهکار حل هر کدام آورده شده است:

۱. خطای ORA-65040 (Operation not allowed):

این خطا زمانی رخ می‌دهد که تلاش می‌کنید پارامتر enable_goldengate_replication را درون یک Pluggable Database (PDB) فعال کنید. از آنجا که این یک پارامتر سیستمی سطح بالا است، فعال‌سازی آن درون PDB مجاز نیست. برای رفع این مشکل، دستور را حتماً در سطح کانتینر ریشه (CDB$ROOT) اجرا کنید.

۲. خطای OGG-00303 (عدم فعال بودن پارامتر ریپلیکیشن):

این خطا به این دلیل است که پارامتر enable_goldengate_replication در دیتابیس سورس 11g تنظیم نشده است. راهکار آن اجرای دستور ALTER SYSTEM SET enable_goldengate_replication=TRUE SCOPE=BOTH; در دیتابیس سورس است تا زیرساخت لازم برای فعالیت گلدن‌گیت فراهم شود.

۳. خطای OGG-02829 (Cannot find archive log):

این خطا در دیتابیس‌های 11g که از ASM استفاده می‌کنند رایج است و دلیل آن ناتوانی پروسس Extract در خواندن مستقیم فایل‌های لاگ از روی دیسک‌گروپ‌های ASM است. راهکار اصلاحی، افزودن عبارت TRANLOGOPTIONS DBLOGREADER به فایل پارامتر EXT1.prm است تا خوانش لاگ‌ها از طریق لایه کلاینت دیتابیس انجام شود.

۴. خطای ORA-01950 (No privileges on tablespace):

این خطا ناشی از عدم تخصیص کووتا (Quota) به کاربر oggadmin بر روی Tablespace پیش‌فرض است. برای رفع این مشکل، باید دستور GRANT UNLIMITED TABLESPACE TO oggadmin; اجرا شود یا سهمیه مشخصی برای کاربر بر روی آن Tablespace تعیین گردد.

۵. خطای ORA-01031 (Insufficient privileges):

این خطا زمانی رخ می‌دهد که پروسس Replicat دسترسی کافی برای اعمال تغییرات DML (مانند Insert، Update یا Delete) بر روی جداول مقصد را ندارد. راهکار آن اعطای مستقیم مجوزهای ذکر شده بر روی جداول هدف به کاربر oggadmin در دیتابیس مقصد است.

۶. خطای کلید تکراری پس از استارت اپلیکیشن:

اگر پس از کات‌اوور با خطای کلید تکراری مواجه شدید، به این دلیل است که Sequenceها در دیتابیس مقصد مطابق با داده‌های جدید جلو نرفته‌اند. برای حل این مشکل، در فاز Cutover باید مقادیر Sequenceهای مقصد را با استفاده از دستور ALTER SEQUENCE ... RESTART WITH به آخرین مقدار ثبت شده در سورس (به علاوه یک بافر ایمن) به‌روزرسانی کنید.

۷. تغییرات ناخواسته داده‌ها حین ریپلیکیشن:

اگر حین عملیات ریپلیکیشن متوجه شدید داده‌ها به‌صورت غیرمنتظره تغییر می‌کنند، احتمالاً تریگرهای دیتابیس مقصد فعال هستند و با هر عملیات Replicat دوباره شلیک می‌شوند. راهکار استاندارد این است که تمام تریگرها در دیتابیس مقصد تا لحظه نهایی کات‌اوور در وضعیت غیرفعال (Disabled) باقی بمانند.