از اوراکل 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.
وحید یوسف زاده
ارائه خدمات مشاوره ، پشتیبانی و نصب و راه اندازی پایگاه داده اوراکل در سراسر کشور...................... تلفن: 09128110897 ایمیل:vahidusefzadeh@gmail.com