ارتقا به اوراکل 12c با کمک قابلیت Transient Standby

از اوراکل 11g قابلیت جدیدی با عنوان Rolling Upgrade using Transient Logical Standby database ارائه شد که از طریق آن می توان با کمترین downtime ارتقا را انجام داد. البته مشابه این قابلیت، قابلیت دیگری با عنوان standard rolling upgrade هم از نسخه های قبلی(قبل از اوراکل 11g) وجود داشت که بین این دو قابلیت تفاوتهای قابل توجهی دارد.

همانطور که از نام این قابلیت بر می آید، این روش از ارتقا با کمک دیتاگارد انجام می شود به این صورت که، برای ارتقا، ابتدا به طور موقت نقش physical standby را به logical standby تبدیل می کنیم در همین حال، عملیات ارتقا را انجام داده و در نهایت، بعد از ارتقا logical standby به اوراکل نسخه 12c، نقش آن را مجددا به همان نقش قبلی اش یعنی physical standby بر می گردانیم.

 

پیش نیاز های انجام ارتقا به روش Transient Standby

1.اوراکل نسخه 12c را در هر دو سرور نصب می کنیم(سرور بانک اصلی و استندبای).

2.Data Guard Broker باید غیرفعال شود.

3.پارامتر COMPATIBLE تا زمانی که ارتقا در هر دو طرف(دیتاگارد و بانک اصلی) اتفاق نیفتاد، باید به یک مقدار تنظیم شوند.

همانطور که می دانید، logical standby بعضی از data typeها را پشتیبانی نمی کند، به همین دلیل زمانی که برای انجام عملیات ارتقا، نقش دیتاگارد به logical standby تغییر می کند، باید به دنبال راهکاری باشیم که داده هایی که نوعشان توسط logical standby پشتیبانی نمی شوند را از دست ندهیم.

برای این مسئله، دو راهکار وجود دارد:

یک: در صورت امکان، در مدت زمان ارتقا logical standby، از هرگونه تغییر در این نوع از داده ها جلوگیری کنیم.

دو: با کمک ویوی DBA_LOGSTDBY_EVENTS، تغییراتی که درlogical standby اعمال نشده ‏اند را شناسایی کرده و از طریق ابزار Export/Import آنها را به صورت دستی اعمال کنیم.

 

مراحل ارتقا به روش Transient Standby

در ادامه با ارائه چند مرحله، روند ارتقا اوراکل نسخه 11g به نسخه 12c، از طریق قابلیت Transient Standby را شرح خواهیم داد.

مرحله یک: برای بانک اصلی یک physical standby ایجاد کرده ایم که در حال حاضر در وضیعت sync قرار دارد.

–primary:

SQL>  select max(sequence#),thread# from v$archived_log group by thread#;

MAX(SEQUENCE#)    THREAD#

————– ———-

            70          1

–standby:

SQL>  select THREAD#,max(SEQUENCE#) from gv$archived_log where applied=’YES’ group by thread#;

   THREAD# MAX(SEQUENCE#)

———- ————–

         1             70

مرحله دوم: قبل از شروع عملیات ارتقا، نیاز داریم تا قابلیت flashback database را فعال کرده و restore pointای را ایجاد کنیم. restore point ایجاد شده در زمان انتقال موقت نقش دیتابیس از primary به physical standby کاربرد دارد و سبب می شود تا مشکل ناسازگاری در incarnation دو بانک بوجود نیاید:

–primary:

SQL> create restore point upgrade_usef1 guarantee flashback database;

Restore point created.

–standby:

SQL> recover managed standby database cancel;

Media recovery complete.

SQL> create restore point upgrade_usef_stb1 guarantee flashback database;

Restore point created.

SQL> alter database recover managed standby database;

مرحله سوم: همانطور که قبلا هم بیان شد، برای انجام عملیات ارتقا، نیاز است تا موقتا نقش physical standby را به logical standby تغییر دهیم.

برای این کار لازم است بر روی بانک اصلی، Log Miner dictionary ایجاد کرده و همچنین physical standby را از حالت recover خارج کنیم و با دستور recover to logical standby keep identity به نقشlogical standby منتقل شویم.

یکی از تفاوتهای transient logical standby با روش standard SQL Apply rolling upgrade در این است که در روش transient logical standby، از keep identity برای انتقال به logical standby استفاده می شود این کار به منظور عدم تغییر DBID و DB_NAME در دو طرف انجام می شود.

–primary:

SQL> exec dbms_logstdby.build;

PL/SQL procedure successfully completed.

–standby:

SQL>  recover managed standby database cancel;

Media recovery complete.

  SQL>  shutdown immediate;

   SQL>  startup mount

SQL> alter database recover to logical standby keep identity;

Database altered.

 alter database open;

SQL>alter database start logical standby apply immediate;

ORA-16239: IMMEDIATE option not available without standby redo logs

خطای بالا به دلیل نبود standby redo log در data guard رخ داده است.

SQL> alter database add standby logfile group 4 size 50m;

Database altered.

SQL> alter database add standby logfile group 5 size 50m;

Database altered.

SQL>alter database start logical standby apply immediate;

Database altered.

بعد از اینکه دستور زیر عبارت IDLE را نشان داد، می توانیم به مرحله بعد برویم:

SQL>select state from v$logstdby_state;

STATE

—————————————————————-

APPLYING

مرحله چهارم: در این مرحله، عملیات ارتقا را بر روی logical standby انجام خواهیم داد برای این کار، ابتدا استندبای را از حالت apply خارج کرده و مانع از ارسال اطلاعات به آن می شویم بعد از آن باید با یکی از دو روش DBUA و یا comman_line ارتقا را بر روی logical standby انجام دهیم.

–primary:

alter system set log_archive_dest_state_2=DEFER scope=memory;

–standby:

SQL> alter database stop logical standby apply;

Database altered.

SQL> shutdown immediate;

–Run Logical standby with software 12c:

SQL> startup upgrade;

ORACLE instance started.

Total System Global Area 8551575552 bytes

Fixed Size                  2702112 bytes

Variable Size            2550138080 bytes

Database Buffers         5989466112 bytes

Redo Buffers                9269248 bytes

Database mounted.

Database opened.

cd $ORACLE_HOME/rdbms/admin

$ORACLE_HOME/perl/bin/perl catctl.pl –n 4 catupgrd.sql

در حین اجرای عملیات ارتقا بر روی استندبای، بانک اصلی در حال سرویس دهی می باشد و ممکن است در همین زمان کاربری به بانک اصلی وصل شده و تغییراتی را انجام دهد برای مثال در نظر بگیرید دستورات زیر بر روی بانک اصلی در زمان ارتقا اجرا شده اند:

–primary:

SQL>create user usef identified by usef;

SQL>grant dba,connect,resource;

SQL>create table usef.upgrading(a number,b date);

SQL>insert into usef.upgrading values(1, sysdate);

SQL>commit;

SQL> select * from usef.upgrading;

         A B

———- ———

         1 19-OCT-15

باید بعد از انجام عملیات ارتقا، استندبای را مورد بررسی قرار دهیم تا اطمینان حاصل کنیم تغییرات بالا که در حین ارتقا انجام شده، بر روی آن اعمال شده است یا نه.

مرحله پنجم: بعد از ارتقای logical standby، لارم است تا تغییراتی که در حین ارتقا بر روی دیتابیس اصلی انجام شده، در logical standby هم اعمال شوند:

–primary:

alter system set log_archive_dest_state_2=enable scope=memory;

–standby:

SQL>shutdown immediate;

SQL>startup

SQL>  alter database start logical standby apply immediate;

Database altered.

محتویات alert نشان می دهد که تغییرات در حال اعمال شدن هستند:

LOGMINER: Begin mining logfile for session 1 thread 1 sequence 87, /u01/arch/1_87_893171811.dbf

Mon Oct 19 17:52:50 2015

LOGMINER: End   mining logfile for session 1 thread 1 sequence 87, /u01/arch/1_87_893171811.dbf

Mon Oct 19 17:52:50 2015

LOGMINER: Begin mining logfile for session 1 thread 1 sequence 88, /u01/oracle/flash_recovery_area/USEFST/onlinelog/o1_mf_4_c29q4mlg_.log

Mon Oct 19 17:53:21 2015

RFS LogMiner: RFS id [18163] assigned as thread [1] PING handler

Mon Oct 19 17:53:21 2015

RFS LogMiner: RFS id [18163] assigned as thread [1] PING handler

بعد از اتمام اعمال تغییرات، می بینیم که تغییرات ما هم لحاظ شده اند:

select * from usef.upgrading;

         A B

———- ———

         1 19-OCT-15

مرحله ششم: از این مرحله به بعد قصد داریم تغییرات صورت گرفته بر روی logical standby را بر روی بانک اصلی اعمال کنیم به همین دلیل نیاز است تا به طور موقت، نقش آنها را با هم عوض کنیم:

–primary:

SQL>  select switchover_status from v$database;

SWITCHOVER_STATUS

——————–

TO STANDBY

SQL>  alter database commit to switchover to logical standby;

Database altered.

–standby:

select switchover_status from v$database;

SWITCHOVER_STATUS

——————–

TO PRIMARY

SQL>  alter database commit to switchover to logical primary;

Database altered.

مرحله هفتم: در این مرحله استندبای جدید را به زمان قبل از upgrade برمی گردانیم(flashback ) تا با مشکل  ناسازگاری incarnation مواجه نشویم.

و بعد از آن استندبای جدید را در نسخه جدید(12c) استارت می کنیم تا ابتدا آن را به حالت physical standby برده(با این کار، ارتقا به صورت خودکار بر روی آن انجام شود) و در نهایت هم آن را به  نقش primary  برمی گردانیم:

–old standby(current primary):

alter system set log_archive_dest_state_2=DEFER scope=memory;

–old primary(current standby):

SQL>  flashback database to restore point upgrade_usef1;

Flashback complete.

sqlplus “/as sysdba”

SQL*Plus: Release 12.1.0.1.0 Production on Mon Oct 19 15:21:45 2015

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup mount

ORACLE instance started.

Total System Global Area 1252737024 bytes

Fixed Size                  2287816 bytes

Variable Size            1191184184 bytes

Database Buffers           50331648 bytes

Redo Buffers                8933376 bytes

Database mounted.

SQL> alter database convert to physical standby;

Database altered.

–old standby(current primary):

SQL> alter system set log_archive_dest_state_2=enable scope=memory;

System altered.

–old primary(current standby):

SQL> recover managed standby database using current logfile disconnect;

Media recovery complete.

Clearing online log 3 of thread 1 sequence number 60

Clearing online redo logfile 3 complete

Tue Oct 20 11:34:17 2015

Archived Log entry 120 added for thread 1 sequence 13 rlc 893543729 ID 0xf619d5

83 dest 2:

Tue Oct 20 11:34:17 2015

Archived Log entry 121 added for thread 1 sequence 14 rlc 893543729 ID 0xf619d5

83 dest 2:

Tue Oct 20 11:34:17 2015

Archived Log entry 122 added for thread 1 sequence 15 rlc 893543729 ID 0xf619d5

83 dest 2:

Tue Oct 20 11:34:17 2015

Media Recovery Log /u01/arch/1_21_893531977.dbf

–old standby(current primary):

SQL>  select switchover_status from v$database;

SWITCHOVER_STATUS

——————–

TO STANDBY

SQL> alter database commit to switchover to standby;

Database altered.

SQL> recover managed standby database using current logfile disconnect;

Media recovery complete.

–old primary(current standby):

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS

——————–

TO PRIMARY

SQL>  alter database commit to switchover to primary;

Database altered.

select comp_name,version,status from dba_registry;

COMP_NAME                                            VERSION                 STATUS

—————————————-           ————                 ———-

Oracle Application Express                4.2.0.00.27             VALID

OWB                                                        11.2.0.4.0               VALID

OLAP Catalog                                         11.2.0.4.0                OPTION OFF

Spatial                                                     12.1.0.1.0                INVALID

Oracle Multimedia                               12.1.0.1.0                VALID

Oracle XML Database                          12.1.0.1.0                VALID

Oracle Text                                            12.1.0.1.0                VALID

Oracle Workspace Manager               12.1.0.1.0                VALID

Oracle Database Catalog Views           12.1.0.1.0                UPGRADED

Oracle Database Packages and Types   12.1.0.1.0             UPGRADED

Jserver JAVA Virtual Machine                12.1.0.1.0                VALID

Oracle XDK                                                 12.1.0.1.0                VALID

Oracle Database Java Packages              12.1.0.1.0                VALID

OLAP Analytic Workspace                       12.1.0.1.0               VALID

Oracle OLAP API                                          12.1.0.1.0               VALID

15 rows selected.

ارتباط با نویسنده مطلب:vahidusefzadeh@ کانال تخصصی اوراکل و لینوکس: OracleDB@

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد.