مهاجرت از Oracle 11g به 19c با Near-Zero Downtime؛ راهنمای کامل Transient Logical Standby

database administration بازدید: 88

ارتقای Oracle Database 11g به 19c با استفاده از Transient Logical Standby

این مقاله، روش ارتقای یک دیتابیس Oracle Database 11g به Oracle Database 19c را با استفاده از روش Transient Logical Standby توضیح می‌دهد. در این روش، دیتابیس مقصد ابتدا به‌عنوان Physical Standby ساخته می‌شود، سپس به Logical Standby تبدیل شده و در ادامه، بدون نیاز به ارتقای هم‌زمان دیتابیس اصلی، به Oracle Database 19c ارتقا می‌یابد.

پیش‌فرض محیط: یک دیتابیس Oracle Database 11g نسخه 11.2.0.4 که روی Oracle Linux 7.9 Restore شده است. Oracle Database 19c با RU 19.32 نیز از قبل نصب شده و هدف، انتقال نقش Primary به دیتابیس 19c با کمترین زمان قطعی ممکن و بدون استفاده از Data Guard Broker است.

بخش ۱: مفهوم راهکار

۱-۱. Transient Logical Standby چیست؟

در این روش، ابتدا یک Physical Standby از دیتابیس Primary ایجاد می‌شود. پس از همگام‌سازی کامل، Physical Standby به Logical Standby تبدیل می‌شود. Logical Standby به‌جای اعمال فیزیکی بلوک‌ها، Redo را با استفاده از SQL Apply و LogMiner به دستورات منطقی SQL تبدیل و آن‌ها را اجرا می‌کند.

پس از تبدیل به Logical Standby، دیتابیس مقصد می‌تواند در Oracle Home نسخه 19c راه‌اندازی و Upgrade شود، در حالی که دیتابیس Primary نسخه 11g همچنان در حال سرویس‌دهی است. در پایان، پس از اطمینان از دریافت و اعمال همه تغییرات، نقش Primary به دیتابیس 19c منتقل می‌شود.

۱-۲. چرا Logical Standby و نه Physical Standby؟

Physical Standby باید از نظر ساختار فیزیکی با Primary سازگار باشد. بنابراین، اجرای هم‌زمان نسخه‌های متفاوت Oracle روی Primary و Physical Standby محدودیت‌های جدی دارد.

Logical Standby با استفاده از SQL Apply، تغییرات Redo را در سطح منطقی اعمال می‌کند. به همین دلیل، امکان Upgrade کردن Logical Standby به نسخه بالاتر، در حالی که Primary هنوز روی نسخه قدیمی‌تر قرار دارد، فراهم می‌شود.

محدودیت مهم: Logical Standby برای همه نوع داده‌ها، همه DDLها و همه ساختارهای دیتابیس مناسب نیست. پیش از شروع عملیات، باید محدودیت‌های Logical Standby و فهرست اشیای پشتیبانی‌نشده بررسی شوند.

۱-۳. غیرفعال‌کردن Data Guard Broker

در این سناریو، تمام مراحل به‌صورت دستی کنترل می‌شوند. برای جلوگیری از دخالت Broker در مدیریت نقش‌ها و فرآیندهای Data Guard، پارامتر زیر باید روی دیتابیس‌ها غیرفعال باشد.

ALTER SYSTEM SET DG_BROKER_START=FALSE SCOPE=BOTH;

دستور بالا Data Guard Broker را غیرفعال می‌کند و تنظیم آن را هم در حافظه و هم در فایل پارامتر ذخیره می‌نماید.

بخش ۲: آماده‌سازی Primary

۲-۱. بررسی وضعیت دیتابیس Primary

SELECT DBID,
       NAME,
       DB_UNIQUE_NAME,
       DATABASE_ROLE,
       LOG_MODE,
       OPEN_MODE,
       FORCE_LOGGING
FROM   V$DATABASE;

SELECT THREAD#,
       SEQUENCE#,
       STATUS,
       ENABLED
FROM   V$THREAD
ORDER BY THREAD#;

کوئری اول شناسه دیتابیس، نام دیتابیس، نقش دیتابیس، حالت Archive، وضعیت Open و وضعیت Force Logging را نمایش می‌دهد.

کوئری دوم وضعیت Threadهای Redo را بررسی می‌کند. در دیتابیس‌های RAC، باید وضعیت تمام Threadها بررسی شود؛ در دیتابیس تک‌نمونه‌ای معمولاً فقط Thread شماره ۱ وجود دارد.

۲-۲. فعال‌کردن FORCE LOGGING

ALTER DATABASE FORCE LOGGING;

این دستور باعث می‌شود عملیات‌هایی مانند برخی عملیات‌های Direct Path و NOLOGGING، تا حد امکان در Redo ثبت شوند. فعال‌بودن Force Logging برای جلوگیری از ایجاد داده‌های غیرقابل‌بازسازی روی Standby بسیار مهم است.

وضعیت فعال‌بودن Force Logging را با دستور زیر بررسی کنید:

SELECT NAME,
       FORCE_LOGGING
FROM   V$DATABASE;

۲-۳. فعال‌کردن Supplemental Logging

Logical Standby برای شناسایی دقیق ردیف‌های تغییرکرده به اطلاعات تکمیلی در Redo نیاز دارد. بنابراین باید Supplemental Logging در دیتابیس Primary فعال شود.

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA
    (PRIMARY KEY, UNIQUE) COLUMNS;

ALTER SYSTEM ARCHIVE LOG CURRENT;

دستور اول حداقل Supplemental Logging را فعال می‌کند.

دستور دوم اطلاعات Primary Key و Unique Key را به لاگ‌های تکمیلی اضافه می‌کند تا Logical Standby بتواند ردیف صحیح را هنگام اجرای UPDATE و DELETE شناسایی کند.

دستور سوم یک Redo Log جاری را Archive می‌کند تا تغییرات Supplemental Logging در جریان Redo تثبیت شوند.

وضعیت Supplemental Logging را بررسی کنید:

SELECT SUPPLEMENTAL_LOG_DATA_MIN,
       SUPPLEMENTAL_LOG_DATA_PK,
       SUPPLEMENTAL_LOG_DATA_UI
FROM   V$DATABASE;

مقدار ستون SUPPLEMENTAL_LOG_DATA_MIN باید معمولاً YES باشد. ستون‌های Primary Key و Unique نیز باید مقدار مناسب مانند YES یا IMPL داشته باشند.

۲-۴. بررسی جداول فاقد Primary Key

جداول فاقد Primary Key ممکن است در Logical Standby هنگام اجرای UPDATE و DELETE باعث کاهش کارایی، خطا یا نیاز به شناسایی تکمیلی شوند. فهرست این جداول را با دستور زیر بررسی کنید:

SELECT dt.OWNER,
       dt.TABLE_NAME
FROM   DBA_TABLES dt
WHERE  NOT EXISTS
       (
           SELECT 1
           FROM   DBA_CONSTRAINTS dc
           WHERE  dc.OWNER = dt.OWNER
           AND    dc.TABLE_NAME = dt.TABLE_NAME
           AND    dc.CONSTRAINT_TYPE = 'P'
       )
AND    dt.OWNER NOT IN
       (
           'SYS',
           'SYSTEM',
           'SH',
           'MDSYS',
           'XDB'
       )
ORDER BY dt.OWNER,
         dt.TABLE_NAME;

در محیط واقعی، باید تصمیم بگیرید که برای این جداول Primary Key ایجاد شود، Supplemental Logging سطح جدول فعال شود یا آن جدول در Logical Standby به‌صورت خاص مدیریت گردد.

۲-۵. بررسی اشیای پشتیبانی‌نشده

Oracle فهرستی از جداول و اشیایی که ممکن است توسط SQL Apply پشتیبانی نشوند در اختیار قرار می‌دهد. این فهرست را پیش از ادامه عملیات بررسی کنید:

SELECT OWNER,
       TABLE_NAME,
       COLUMN_NAME,
       DATA_TYPE
FROM   DBA_LOGSTDBY_UNSUPPORTED
ORDER BY OWNER,
         TABLE_NAME,
         COLUMN_NAME;

اگر این کوئری اطلاعاتی برگرداند، باید پیش از Upgrade مشخص شود که این اشیا چگونه در مقصد مدیریت خواهند شد.

بخش ۳: ساخت دیکشنری LogMiner

۳-۱. اجرای DBMS_LOGSTDBY.BUILD

Logical Standby برای تفسیر Redo و تبدیل آن به SQL به دیکشنری LogMiner نیاز دارد. این دیکشنری با اجرای دستور زیر روی Primary ساخته می‌شود:

EXEC DBMS_LOGSTDBY.BUILD;

اجرای این Procedure اطلاعات ساختاری و متادیتای لازم را در Redo ثبت می‌کند. این اطلاعات بعداً روی Standby برای SQL Apply استفاده می‌شوند.

پس از اجرای Procedure، چند بار لاگ جاری را Archive کنید تا لاگ حاوی اطلاعات دیکشنری بسته شده و به مقصد ارسال شود:

ALTER SYSTEM ARCHIVE LOG CURRENT;

ALTER SYSTEM ARCHIVE LOG CURRENT;
 

۳-۲. بررسی لاگ‌های Archive روی Primary

SELECT THREAD#,
       SEQUENCE#,
       FIRST_TIME,
       NEXT_TIME,
       DEST_ID,
       APPLIED,
       STATUS
FROM   V$ARCHIVED_LOG
ORDER BY THREAD# DESC,
         SEQUENCE# DESC;

این کوئری وضعیت لاگ‌های Archive را نمایش می‌دهد. ستون‌های THREAD# و SEQUENCE# برای پیگیری ترتیب لاگ‌ها، ستون DEST_ID برای شناسایی مقصد و ستون APPLIED برای بررسی Apply شدن لاگ‌ها استفاده می‌شوند.

۳-۳. بررسی دریافت لاگ روی Physical Standby

روی Standby بررسی کنید که لاگ‌های جدید از Primary دریافت شده باشند:

SELECT THREAD#,
       SEQUENCE#,
       FIRST_TIME,
       NEXT_TIME,
       APPLIED,
       REGISTRAR,
       DICTIONARY_BEGIN,
       DICTIONARY_END
FROM   V$ARCHIVED_LOG
ORDER BY THREAD# DESC,
         SEQUENCE# DESC;

وجود لاگی با مقدار DICTIONARY_END='YES' نشان می‌دهد که انتهای دیکشنری LogMiner در یکی از لاگ‌ها ثبت شده است.

بخش ۴: تبدیل Physical Standby به Logical Standby

۴-۱. توقف Managed Recovery Process

پیش از تبدیل، فرآیند Physical Standby Recovery باید متوقف شود:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

این دستور Managed Recovery Process را متوقف می‌کند. اگر Recovery از قبل متوقف باشد، ممکن است خطای ORA-16136 نمایش داده شود. این خطا در این مرحله به معنی فعال‌بودن Recovery نیست و معمولاً قابل چشم‌پوشی است.

۴-۲. انتقال دیتابیس به حالت MOUNT

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

دستور SHUTDOWN IMMEDIATE دیتابیس را به‌صورت کنترل‌شده خاموش می‌کند. دستور STARTUP MOUNT Instance را راه‌اندازی کرده و Control File را Mount می‌کند، اما دیتابیس را Open نمی‌کند.

نکته حیاتی: دستور تبدیل نباید زمانی اجرا شود که دیتابیس Open یا Read Only باشد. اجرای آن باید در وضعیت MOUNT انجام شود.

۴-۳. اجرای تبدیل

ALTER DATABASE RECOVER TO LOGICAL STANDBY vahiddb;

این دستور Control File و وضعیت دیتابیس را از Physical Standby به Logical Standby تبدیل می‌کند. مقدار vahiddb باید نام دیتابیس Primary باشد.

در صورت موفقیت، خروجی زیر نمایش داده می‌شود:

Database altered.

۴-۴. رفع مشکل Hang شدن دستور تبدیل

در برخی شرایط، دستور تبدیل ممکن است مدت زیادی در حالت انتظار باقی بماند. در Alert Log معمولاً پیام‌هایی مشابه عبارت زیر مشاهده می‌شود:

Media Recovery Waiting for thread 1 sequence XX (in transit)

این وضعیت معمولاً به این معنی است که Standby هنوز لاگ لازم، به‌خصوص لاگ حاوی انتهای دیکشنری، را به‌صورت کامل دریافت یا نهایی نکرده است.

در این شرایط، دستور تبدیل را در Standby متوقف نکنید. در یک نشست جداگانه روی Primary، دستورات زیر را اجرا کنید:

EXEC DBMS_LOGSTDBY.BUILD;

ALTER SYSTEM ARCHIVE LOG CURRENT;

ALTER SYSTEM ARCHIVE LOG CURRENT;

در صورت نیاز، اجرای Procedure و Archive کردن لاگ را یک بار دیگر تکرار کنید. پس از رسیدن لاگ موردنیاز به Standby، اجرای دستور تبدیل باید ادامه پیدا کند و پیام Database altered. نمایش داده شود.

توجه: اجرای مجدد DBMS_LOGSTDBY.BUILD در این شرایط یک اقدام عملیاتی معتبر است و در محیط‌های واقعی می‌تواند مشکل ناقص‌ماندن یا دیررسیدن نشانگرهای دیکشنری را برطرف کند.

۴-۵. بازکردن Logical Standby

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

ALTER DATABASE OPEN RESETLOGS;

پس از تبدیل، دیتابیس باید با RESETLOGS باز شود. این کار ساختار شاخه Redo را برای نقش جدید دیتابیس تنظیم می‌کند.

۴-۶. شروع SQL Apply

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

این دستور فرآیند SQL Apply را با حالت بلادرنگ فعال می‌کند. در این وضعیت، لاگ‌های دریافتی از Primary به دستورات SQL تبدیل و روی Logical Standby اجرا می‌شوند.

۴-۷. بررسی وضعیت Logical Standby

SELECT DATABASE_ROLE,
       OPEN_MODE,
       GUARD_STATUS
FROM   V$DATABASE;

SELECT *
FROM   V$LOGSTDBY_STATE;

SELECT TYPE,
       STATUS_CODE,
       STATUS
FROM   V$LOGSTDBY_PROCESS
ORDER BY TYPE;

کوئری اول نقش دیتابیس، وضعیت Open و وضعیت Database Guard را نمایش می‌دهد. در این مرحله انتظار می‌رود نقش دیتابیس LOGICAL STANDBY باشد.

کوئری دوم وضعیت کلی SQL Apply و کوئری سوم وضعیت فرآیندهای LogMiner و SQL Apply را نمایش می‌دهد.

بخش ۵: ارتقای Logical Standby به Oracle 19c

در این مرحله Primary نسخه 11g همچنان در حال سرویس‌دهی است و فقط Logical Standby برای ارتقا خاموش می‌شود.

۵-۱. توقف SQL Apply

ALTER DATABASE STOP LOGICAL STANDBY APPLY;

این دستور اجرای SQL Apply را متوقف می‌کند تا دیتابیس برای خاموش‌شدن و تغییر Oracle Home آماده شود.

۵-۲. خاموش‌کردن دیتابیس

SHUTDOWN IMMEDIATE;

این دستور دیتابیس را به‌صورت کنترل‌شده خاموش می‌کند. پس از مشاهده پیام Database closed، Database dismounted و ORACLE instance shut down می‌توان Oracle Home را تغییر داد.

۵-۳. تنظیم Oracle Home نسخه 19c

export ORACLE_HOME=/u01/app/oracle/product/19c/dbhome
export PATH=$ORACLE_HOME/bin:$PATH
export ORACLE_SID=vahiddbg

sqlplus -v

سه دستور اول، Oracle Home، مسیر اجرایی و SID مربوط به دیتابیس Standby را تنظیم می‌کنند. دستور sqlplus -v نیز برای اطمینان از استفاده از باینری 19c اجرا می‌شود.

۵-۴. انتقال Password File

cp /u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwvahiddbg \
   /u01/app/oracle/product/19c/dbhome/dbs/

Password File برای اتصال‌های مدیریتی مانند اتصال SYSDBA و برخی عملیات Data Guard استفاده می‌شود. در صورت استفاده از Password File، باید نسخه قابل‌استفاده آن در مسیر dbs مربوط به Oracle Home جدید وجود داشته باشد.

۵-۵. انتقال یا معرفی SPFILE

Oracle هنگام اجرای STARTUP ابتدا فایل‌هایی مانند spfile<SID>.ora و سپس init<SID>.ora را در مسیر $ORACLE_HOME/dbs جست‌وجو می‌کند.

ابتدا SPFILE نسخه قبلی را به Oracle Home جدید منتقل کنید:

cp /u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfilevahiddbg.ora \
   /u01/app/oracle/product/19c/dbhome/dbs/

سپس بررسی کنید که فایل واقعاً وجود دارد:

ls -l $ORACLE_HOME/dbs/spfile${ORACLE_SID}.ora

اگر لازم است از PFILE استفاده شود، فایل زیر را ایجاد یا اصلاح کنید:

vi $ORACLE_HOME/dbs/init${ORACLE_SID}.ora

در صورتی که SPFILE در مسیر دیگری قرار دارد، محتوای PFILE باید فقط به مسیر واقعی SPFILE اشاره کند:

SPFILE='/u01/app/oracle/product/19c/dbhome/dbs/spfilevahiddbg.ora'
نکته: اگر PFILE به SPFILEای اشاره کند که وجود ندارد، خطاهای ORA-01565 و ORA-27037 دریافت خواهید کرد. بنابراین پیش از اجرای Startup، مسیر فایل را با دستور ls -l بررسی کنید.

۵-۶. راه‌اندازی دیتابیس در حالت Upgrade

sqlplus / as sysdba

STARTUP UPGRADE;

دستور STARTUP UPGRADE دیتابیس را در حالتی راه‌اندازی می‌کند که برای اجرای فرآیند Upgrade مناسب است. این دستور باید با باینری Oracle 19c اجرا شود.

۵-۷. اجرای Database Upgrade

از یک نشست Shell لینوکس، ابزار dbupgrade را اجرا کنید:

cd $ORACLE_HOME/bin

./dbupgrade -n 4

گزینه -n 4 تعداد پردازش‌های موازی Upgrade را مشخص می‌کند. مقدار مناسب باید بر اساس تعداد هسته‌های CPU، منابع حافظه و بار سیستم انتخاب شود.

توجه: هنگام اجرای dbupgrade، گزارش‌ها و فایل‌های Log را بررسی کنید. پایان فرآیند فقط با بازگشت Shell مشخص نمی‌شود؛ باید وضعیت خروجی و Logهای مربوط به مراحل Upgrade نیز بررسی شوند.

۵-۸. بررسی Registry و کامپایل آبجکت‌ها

sqlplus / as sysdba

STARTUP;

SELECT COMP_ID,
       COMP_NAME,
       VERSION,
       STATUS
FROM   DBA_REGISTRY
ORDER BY COMP_ID;

@?/rdbms/admin/utlrp.sql

دستور STARTUP دیتابیس را به‌صورت عادی باز می‌کند.

کوئری DBA_REGISTRY وضعیت اجزای نصب‌شده دیتابیس را نمایش می‌دهد. وضعیت اجزا باید بررسی شود و مواردی مانند INVALID یا وضعیت‌های غیرمنتظره پیگیری شوند.

اسکریپت utlrp.sql آبجکت‌های Invalid را مجدداً Compile می‌کند.

۵-۹. بررسی نقش و نسخه دیتابیس

SELECT BANNER_FULL
FROM   V$VERSION;

SELECT DATABASE_ROLE,
       OPEN_MODE,
       GUARD_STATUS
FROM   V$DATABASE;

کوئری اول نسخه Oracle Database و کوئری دوم نقش و وضعیت فعلی Logical Standby را نمایش می‌دهد.

۵-۱۰. راه‌اندازی مجدد SQL Apply

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

پس از پایان Upgrade و بررسی سلامت دیتابیس، SQL Apply را مجدداً فعال کنید. سپس دریافت و اجرای تراکنش‌های Primary را روی دیتابیس 19c بررسی نمایید.

۵-۱۱. بررسی تأخیر Apply

SELECT NAME,
       VALUE,
       UNIT
FROM   V$LOGSTDBY_STATS
WHERE  NAME IN
       (
           'event',
           'latest checkpoint',
           'coordinator state',
           'completed transactions',
           'highest scn recorded'
       )
ORDER BY NAME;

این اطلاعات برای بررسی وضعیت Apply، آخرین Checkpoint و وضعیت اجرای تراکنش‌ها استفاده می‌شوند.

بخش ۶: انتقال نهایی نقش به دیتابیس 19c

تفاوت مهم: این مرحله یک انتقال برنامه‌ریزی‌شده نقش است، نه Failover اضطراری. پیش از اجرای آن باید سرویس‌های برنامه روی Primary متوقف یا دسترسی نوشتن کاربران کنترل شود تا پس از آخرین Archive، تراکنش جدیدی روی Primary ایجاد نشود.

۶-۱. توقف فعالیت کاربران روی Primary

در این مرحله باید برنامه‌ها، سرویس‌ها یا دسترسی‌های نوشتاری به Primary متوقف شوند. روش انجام این کار به معماری برنامه و محیط عملیاتی بستگی دارد.

۶-۲. Archive کردن آخرین Redo روی Primary

ALTER SYSTEM ARCHIVE LOG CURRENT;

این دستور Redo جاری را Archive می‌کند تا آخرین تغییرات قابل ارسال به Logical Standby شوند.

پس از اجرای دستور، روی Logical Standby بررسی کنید که لاگ‌های جدید دریافت و Apply شده باشند:

SELECT THREAD#,
       SEQUENCE#,
       APPLIED,
       DICTIONARY_BEGIN,
       DICTIONARY_END
FROM   V$ARCHIVED_LOG
ORDER BY THREAD# DESC,
         SEQUENCE# DESC;

۶-۳. اطمینان از پایان Apply

SELECT TYPE,
       STATUS_CODE,
       STATUS
FROM   V$LOGSTDBY_PROCESS
ORDER BY TYPE;

SELECT *
FROM   V$LOGSTDBY_STATE;

پیش از فعال‌کردن Logical Standby به‌عنوان Primary جدید، باید اطمینان حاصل شود که لاگ‌های دریافت‌شده Apply شده‌اند و تراکنش معوقی در صف باقی نمانده است.

۶-۴. فعال‌کردن Logical Standby به‌عنوان Primary جدید

ALTER DATABASE STOP LOGICAL STANDBY APPLY;

ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY;

دستور اول SQL Apply را متوقف می‌کند.

دستور دوم Logical Standby را فعال کرده و با گزینه FINISH APPLY تلاش می‌کند تغییرات باقی‌مانده در صف Apply را پیش از فعال‌شدن نقش جدید اعمال کند.

نکته مربوط به از دست‌ندادن داده: گزینه FINISH APPLY فقط تغییراتی را اعمال می‌کند که به Logical Standby رسیده باشند. بنابراین Zero Data Loss فقط زمانی قابل انتظار است که آخرین Redoها به مقصد رسیده و بدون خطا Apply شده باشند.

۶-۵. غیرفعال‌کردن Database Guard

ALTER DATABASE GUARD NONE;

Logical Standby ممکن است برای جلوگیری از اجرای DML مستقیم در وضعیت Guard قرار داشته باشد. این دستور Database Guard را غیرفعال می‌کند تا دیتابیس جدید بتواند به‌عنوان Primary مستقل فعالیت کند.

۶-۶. بازکردن دیتابیس در صورت نیاز

ALTER DATABASE OPEN;

اگر دیتابیس پس از فعال‌سازی در وضعیت Open قرار نگرفته باشد، با این دستور آن را باز کنید. پیش از اجرای دستور، وضعیت دیتابیس را بررسی کنید.

۶-۷. بررسی نهایی نقش دیتابیس

SELECT DBID,
       NAME,
       DB_UNIQUE_NAME,
       DATABASE_ROLE,
       OPEN_MODE,
       LOG_MODE,
       FORCE_LOGGING,
       GUARD_STATUS
FROM   V$DATABASE;

خروجی مورد انتظار این است که:

  • مقدار DATABASE_ROLE برابر PRIMARY باشد.
  • مقدار OPEN_MODE برابر READ WRITE باشد.
  • مقدار GUARD_STATUS برابر NONE باشد.
  • مقدار FORCE_LOGGING مطابق سیاست محیط عملیاتی تنظیم شده باشد.

بخش ۷: آزمون پس از انتقال نقش

۷-۱. بررسی وضعیت سرویس‌ها 

از etc/oratab خانه دیتابیس 11 را به 19 تبدیل کنید و همچنین زمانی که با oracle home 11 وصل هستید، srvctl دیتابیس را از oracle_home قبلی حذف کنید و در oracle home جدید دوباره بسازید.

srvctl status database -d vahiddbg

دستور lsnrctl status وضعیت Listener و سرویس‌های ثبت‌شده را نمایش می‌دهد. دستور srvctl status database برای محیط‌هایی است که دیتابیس با ابزارهای Clusterware مدیریت می‌شود.

۷-۲. آزمایش یک تراکنش

این کار را با یک کاربر غیرسیستمی انجام دهید.

CREATE TABLE migration_test
(
    test_id      NUMBER PRIMARY KEY,
    test_time    TIMESTAMP DEFAULT SYSTIMESTAMP,
    description  VARCHAR2(200)
);

INSERT INTO migration_test
(
    test_id,
    description
)
VALUES
(
    1,
    'Post-migration validation'
);

COMMIT;

SELECT *
FROM   migration_test
WHERE  test_id = 1;

این آزمایش باید فقط پس از انتقال موفق نقش و روی Primary جدید انجام شود. هدف آن بررسی ساده عملکرد DDL، DML و Commit در دیتابیس 19c است.

بخش ۸: محدودیت‌ها و ملاحظات Logical Standby

۸-۱. انواع داده و اشیای پشتیبانی‌نشده

برخی انواع داده و اشیای خاص ممکن است توسط SQL Apply پشتیبانی نشوند یا نیازمند مدیریت جداگانه باشند. از جمله مواردی که باید با دقت بررسی شوند:

  • BFILE
  • ROWID و UROWID
  • برخی User-Defined Typeها
  • برخی عملیات مربوط به Advanced Queuing
  • برخی DDLهای خاص و عملیات وابسته به فایل‌های خارجی

۸-۲. عملیات مربوط به فضای ذخیره‌سازی

برخی عملیات فیزیکی مانند تغییر اندازه Datafile، ایجاد فایل جدید، تغییر ساختار Tablespace یا عملیات وابسته به مسیر فایل‌ها ممکن است به‌صورت خودکار مانند Logical DML روی Standby اعمال نشوند.

این عملیات باید به‌صورت جداگانه در مقصد بررسی و در صورت نیاز اجرا شوند.

۸-۳. عملیات NOLOGGING

عملیات NOLOGGING می‌توانند باعث شوند اطلاعات لازم برای بازسازی تغییرات در Redo ثبت نشود. بنابراین استفاده از Force Logging و کنترل عملیات NOLOGGING در محیط Primary ضروری است.

۸-۴. جداول فاقد Primary Key

جداول فاقد Primary Key می‌توانند باعث کاهش کارایی SQL Apply شوند. برای این جداول باید راهکار مشخصی مانند ایجاد Primary Key، فعال‌کردن Supplemental Logging مناسب یا مدیریت اختصاصی Apply در نظر گرفته شود.

۸-۵. تفاوت نقش‌ها پس از انتقال

پس از فعال‌شدن Logical Standby به‌عنوان Primary جدید، این دیتابیس دیگر یک Standby موقت نیست و باید مانند یک Primary مستقل مدیریت شود. تنظیمات Listener، سرویس‌ها، Backup، Monitoring، Alerting و Jobهای زمان‌بندی‌شده باید بررسی و با نقش جدید هماهنگ شوند.

بخش ۹: چک‌لیست نهایی

  1. بررسی نسخه و وضعیت Primary.
  2. فعال‌کردن Force Logging.
  3. فعال‌کردن Supplemental Logging.
  4. بررسی جداول فاقد Primary Key.
  5. بررسی اشیای پشتیبانی‌نشده توسط Logical Standby.
  6. اجرای DBMS_LOGSTDBY.BUILD روی Primary.
  7. اجرای چندباره ALTER SYSTEM ARCHIVE LOG CURRENT.
  8. توقف MRP روی Physical Standby.
  9. اجرای تبدیل در وضعیت MOUNT.
  10. بازکردن Logical Standby با RESETLOGS.
  11. فعال‌کردن SQL Apply.
  12. توقف Apply و خاموش‌کردن دیتابیس.
  13. تغییر Oracle Home به نسخه 19c.
  14. بررسی Password File و SPFILE.
  15. اجرای STARTUP UPGRADE.
  16. اجرای dbupgrade.
  17. بررسی DBA_REGISTRY و اجرای utlrp.sql.
  18. فعال‌کردن مجدد SQL Apply.
  19. متوقف‌کردن سرویس‌های نوشتاری روی Primary قدیمی.
  20. Archive کردن آخرین Redo.
  21. اطمینان از دریافت و Apply همه لاگ‌ها.
  22. اجرای ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY.
  23. غیرفعال‌کردن Database Guard.
  24. بررسی نهایی نقش، حالت Open و سرویس‌های دیتابیس.

جمع‌بندی

روش Transient Logical Standby امکان ارتقای مرحله‌ای Oracle Database 11g به 19c را فراهم می‌کند؛ به‌گونه‌ای که دیتابیس Primary تا پایان بخش عمده عملیات Upgrade در دسترس باقی می‌ماند.

مهم‌ترین بخش عملی این فرآیند، ساخت صحیح دیکشنری LogMiner، ارسال کامل لاگ‌های مربوط به دیکشنری، اجرای تبدیل در وضعیت MOUNT و کنترل دقیق SQL Apply است. در محیط‌هایی که تبدیل در حالت انتظار باقی می‌ماند، اجرای مجدد DBMS_LOGSTDBY.BUILD و Archive کردن چندباره لاگ جاری می‌تواند مشکل دریافت ناقص یا دیررسیدن نشانگرهای دیکشنری را برطرف کند.

با کنترل دقیق وضعیت Apply، بررسی محدودیت‌های Logical Standby و انتقال برنامه‌ریزی‌شده نقش، می‌توان زمان قطعی سرویس را به حداقل رساند و دیتابیس 19c را با ریسک کنترل‌شده به‌عنوان Primary جدید عملیاتی کرد.