Upgrade/Downgrade to/from oracle 12c

ارتقا نسخه اوراکل به 12c، به روشهای مختلفی قابل انجام است که هر کدام بسته به شرایطی ممکن است مطلوب تر باشند و همه این روشها را می توان در دو دسته upgrade(In Place Upgrade) و migration(Out of place Upgrade) قرار داد به عبارتی دیگر می توان از روشهای upgrade و یا  migration برای این کار بهره گرفت منظور از upgrade، اصلاح data dictionary به طوری که با نسخه جدید اوراکل سازگار باشد ولی در روشهای migration، می توانیم data dictionary بانک فعلی را نادیده بگیریم و تنها داده کاربری را به بانک جدید که دارای data dictionary نسخه جدید است، منتقل کنیم و در این صورت ممکن است سیستم عامل، کارکترست، ساختار بانک اطلاعاتی و … هم تغییر کنند البته migration به دلیل اینکه با اطلاعات کاربر سروکار دارد، ممکن است مدت زمان زیادی را از dba بگیرد ولی در عوض ممکن است downtime بانک را به حداقل برساند(بطور مثال در زمان استفاده از goldengate).

ابزارهای زیر نمونه ای از روشهای ارتقا به 12c می باشند:

  1. Database Upgrade Assistant (DBUA)
  2. command-line Upgrade
  3. Transportable Tablespace
  4. Data Pump
  5. Original Export/Import
  6. Golden Gate
  7. Oracle Streams
  8. DataGuard

دو روش اول خصوصیات مشابهی دارند با این تفاوت که DBUA به صورت گرافیکی اجرا می شود و روش دوم از طریق CMD. این دو روش تنها ارتقا مستقیم را پشتیبانی می کنند که شبه جدول زیر نشان می دهد امکان ارتقا مستقیم از کدام نسخه به 12c وجود دارد.

ارتقا مستقیم:

10.2.0.5  ,   11.1.0.7   ,  >=11.2.0.2

ارتقا غیرمستقیم: <=9.2.0.8  ,  10.1.0.5  ,  10.2.0.2/3/4  ,  11.1.0.6  ,  11.2.0.1

 

نسخه هایی که ارتقا مستقیم را پشتیبانی نمی کنند، در ابتدا باید نسخه آنها به یکی از نسخه های قابل ارتقا مستقیم ارتقا یابد تا بعد به 12c قابل ارتقا باشد البته می توان بدون انجام این کار، از روشها دیگر ارتقا نسخه همانند expdp/impdp، TTS و … برای انجام این کار بهره گرفت.

در جدول زیر مقایسه ای بین بعضی از روشهای مذکور صورت گرفته است تا مزیت هر کدام نسبت به دیگری مشخص شود.

روش پیچیدگی سرعت حداقل نسخه بانک مبدا انتقال به سرور جدید تغییر

 سیستم عامل

تعییر کارکترست، فشرده سازی، رمزنگاری و

Database Upgrade

Assistant

Low Fastest 10.2.0.5 No No No
Command-line

Upgrade

Med Fastest 10.2.0.5 Yes No No
Full Transportable

Export/Import

Med Faster 11.2.0.3 Yes Yes No

Transportable

Tablespaces

High Faster 8.1.5 Yes Yes(از 10.1) No
Data Pump

expdp/impdp

Med Fast 10.1 Yes Yes Yes
Original

export/import

Med slow 5 Yes Yes Yes

 

در ادامه  قصد داریم تا مختصرا مطالبی را در مورد بعضی از این روشها ارائه کنیم:

command-line Upgrade

اجرای ارتقا در این روش در 56 فاز انجام می شود که بعضی از این فازها امکان اجرا به صورت موازی را خواهند داشت که این اجرای موازی، باعث افزایش حدود 40 درصدی سرعت ارتقا شده است. برای ارتقا نیازی به اوراکل 11g نخواهیم داشت و تنها نرم افزار 12c کافی خواهد بود.زمان اجرای ارتقا در این روش با روش DBUA یکسان است.

زمانی که بانک اطلاعاتی با نسخه 11 را در نرم افزار 12c استارت می کنیم، خطای زیر را دریافت خواهیم کرد:

SQL> startup

ORACLE instance started.

Total System Global Area 3140026368 bytes

Fixed Size                  2686512 bytes

Variable Size             771752400 bytes

Database Buffers         2348810240 bytes

Redo Buffers               16777216 bytes

Database mounted.

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00704: bootstrap process failure

ORA-00604: error occurred at recursive SQL level 2

ORA-00904: “I”.”UNUSABLEBEGINNING#”: invalid identifier

Process ID: 11512

Session ID: 220 Serial number: 3

برای اینکه مانع از خطای ذکر شده شویم، نیاز است تا بانک را با گزینه upgrade استارت کنیم:

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.

این کار سبب می شود تا در زمان باز شدن بانک، دستورات زیر اجرا شوند:

ALTER SYSTEM enable restricted session;

ALTER SYSTEM SET  “_system_trig_enabled”=FALSE SCOPE=MEMORY;

ALTER SYSTEM SET  “_undo_autotune”=FALSE SCOPE=MEMORY;

ALTER SYSTEM SET undo_retention=900 SCOPE=MEMORY;

ALTER SYSTEM SET aq_tm_processes=0 SCOPE=MEMORY;

ALTER SYSTEM SET enable_ddl_logging=FALSE SCOPE=MEMORY;

ALTER SYSTEM SET recyclebin=’OFF’ DEFERRED SCOPE=MEMORY;

همانطور که می دانید برای ارتقا comman-lineای به اوراکل 11g از catupgrd.sql استفاده می شد ولی برای ارتقا به اوراکل 12c از catctl.pl استفاده می شود. البته می توانیم دوباره از روش قبلی استفاده کنیم که در این صورت روش جدید را به ما نشان خواهد داد:

SQL>  @/u01/oracle/12c/rdbms/admin/catupgrd.sql

Session altered.

DOC>    The catupgrd.sql is being deprecated in the 12.1 release of the

DOC>    Oracle Database.  Customers are encouraged to use catctl.pl as

DOC>    the replacement for catupgrd.sql when upgrading the database dictionary.

DOC>                    cd $ORACLE_HOME/rdbms/admin

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

DOC>    Refer to the Oracle Database Upgrade Guide for more information.

DOC>    This database upgrade procedure must be called with the following

DOC>    argument when invoking from the SQL prompt:

DOC>                    @catupgrd.sql PARALLEL=NO

old   2: WHERE  UPPER(‘&&1’) = ‘PARALLEL=NO’ OR

new   2: WHERE  UPPER(”) = ‘PARALLEL=NO’ OR

old   3:        UPPER(‘&&1’) = ‘PARALLEL=YES’

new   3:        UPPER(”) = ‘PARALLEL=YES’

SELECT (to_number(count(*)))/(to_number(count(*))) FROM DUAL

ERROR at line 1:

ORA-01476: divisor is equal to zero

Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 – 64bit Production

With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

با توجه به اینکه بعضی از مراحل ارتقا به صورت موازی قابل انجام هستند، می توانیم تعدادی پروسس را مسئول ارتقا قرار دهیم که مقدار پیش فرض آن، متناسب با تعداد هسته cpu پیشنهاد می شود. با اجرا دستور زیر، ارتقا با چهار پروسس انجام خواهد شد.

cd $ORACLE_HOME/rdbms/admin

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

Using 4 processes.

Serial   Phase #: 0 Files: 1      Time: 222s

….

Serial   Phase #:51 Files: 2      Time: 1853s

…..

Serial   Phase #:56 Files: 1      Time: 40s

Grand Total Time: 3757s

متناسب با تعداد پروسسی که دستور با آن اجرا شده، فایلهای لاگ با نام catupgrdn.log در مسیر $ORACLE_HOME/rdbms/admin ایجاد می شوند که می توانیم برای یافتن خطای احتمالی، از آنها استفاه کنیم.

tail –f /u01/oracle/12c/rdbms/admin/catupgrd0.log

معمولا در شروع ارتقا، امکان چک کردن وضیعت جاری کامپوننتها وجود ندارد:

SQL> select comp_name,version,status from dba_registry;

select comp_name,version,status from dba_registry                                     *

ERROR at line 1:

ORA-04063: package body “SYS.DBMS_REGISTRY” has errors

زمانی که عمل ارتقا به پایان رسید، دوباره دستور زیر را اجرا می کنیم که خواهیم دید کامپوننتها به نسخه جدید ارتقا یافته اند:

col COMP_NAME format a40;

col VERSION format a12;

col STATUS format a10;

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.

@/u01/oracle/12c/rdbms/admin/utlu121s.sql

باید دقت داشته باشیم که بعد از پایان ارتقا، تعداد اشیاهای نامعتبر به همان مقدار قبل از ارتقا رسیده باشند وگرنه نیاز به یکبار recompile کامل بانک خواهیم داشت.

 

dbua

در این روش نیاز است تا هر دو نسخه اوراکل(11g و 12c) به طور همزمان بر روی سرور نصب شده باشند.در صورتی که در حین اجرای DBUA، خطایی رخ دهد یا اجرای آن توسط dba کنسل شود، باید مراحل ارتقا را با دستورات cmd ادامه دهیم به عبارت دیگر این روش، restartable نیست.

برای شروع ارتقا با این روش، ابتدا نیاز است تا پیشنیازهای ارتقا را با اسکریپتهای زیر بیابیم و نیز درخواستهای احتمالی آن را مورد بررسی قرار دهیم:

@/u01/oracle/12c/rdbms/admin/preupgrd.sql

Results of the checks are located at:

 /u01/oracle/cfgtoollogs/USEF11G/preupgrade/preupgrade.log

Pre-Upgrade Fixup Script (run in source database environment):

 /u01/oracle/cfgtoollogs/USEF11G/preupgrade/preupgrade_fixups.sql

Post-Upgrade Fixup Script (run shortly after upgrade):

 /u01/oracle/cfgtoollogs/USEF11G/preupgrade/postupgrade_fixups.sql

SQL> @/u01/oracle/cfgtoollogs/USEF11G/preupgrade/preupgrade_fixups.sql

Fix Summary:   Execute emremove.sql prior to upgrade.

**************** Pre-Upgrade Fixup Script Complete

 

در این قسمت یازده مرحله ای که بعد از اجرای dbua اجرا می شوند را نشان خواهیم داد. نکته این که dbua باید از oracle_home مربوط به 12c اجرا شود.

/u01/oracle/12c/bin/dbua

 مرحله یک: گزینه Upgrade Oracle Database را انتخاب کنید.

مرحله دوم: در این مرحله مشخصات همه بانکهایی که sid آنها در فایل /etc/oratab ثبت شده نشان داده می شوند. پس در صورتی که مشخصات بانک مورد نظر دیده نشد، باید به این فایل اضافه شود.

مرحله سوم: این مرحله پیش نیازها را چک می کند و در صورتی که در این مرحله با خطایی مواجه شویم که قابل fix شدن نباشد، احتمالا توصیه های اسکریپت preupgrd.sql را به خوبی اجرا نکرده ایم.

مرحله چهارم: این مرحله نسبت به مراحل قبلی نیاز به توجه بیشتری دارد. در این مرحله می توان تعداد پروسسهایی که در زمینه ارتقا مسئول هستند را مشخص کرد همانطور که قبلا گفته شد، مقداری که اوراکل بطور پیش فرض برای آن پیشنهاد می دهد، بر اساس تعداد هسته cpu می باشد. همچنین این امکان وجود دارد که بعد از اجرای ارتقا، یکبار recompile انجام شود این کار می تواند به صورت موازی انجام شود البته می توان به جای انتخاب این گزینه، همانند نسخه 11g، از اسکریپت utlrp.sql ، بعد از اجرای عملیات ارتقا استفاده کرد.

در این کادر امکان و قابلیتهای دیگر از قبیل بروزرسانی time zone به آخرین نسخه وجود دارد که در مرحله post-upgrade قابل انجام خواهد بود. با انتخاب Gather Statistics Before Upgrade هم می توان آمارهای data dictionary را تازه تر کرد که این کار می تواند سرعت عملیات ارتقا را بهبود بخشد.

مرحله پنجم: OEM 11g توسط 12c منسوخ شده است که می توانیم نسخه جدید آن را پیکربندی کنیم.

 مرحله ششم: در این مرحله امکان جابجایی database fileها به مکانی غیر از مکان فعلی ممکن می شود.

مرحله هفتم: در این مرحله می توانیم بانک اطلاعاتی را با listenerهای موجود ارائه شده رجیستر کنیم.

مرحله هشتم: در زمان ارتقا یا بعد از آن ممکن است با خطاهایی مواجه شویم که کار ما را با مختل سازد به همین دلیل نیاز است که قبل از ارتقا از بانک اطلاعاتی backup داشته باشیم البته قابلیت flashback هم از طریق این کادر ممکن می شود که هر دو اینها نیاز به هزینه اضافی دارند.

مرحله نهم: کادر زیر گزارشی را به ما ارائه می دهد تا قبل از اجرا، دید کلی تری از کار داشته باشیم.

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

مرحله یازدهم: گزارشی از کارهای انجام شده.

حال باید به اوراکل 12c وصل شویم و دستور زیر را اجرا کنیم که نشان می دهد که componentها در کدام نسخه قرار دارند:

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   VALID

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   VALID

Oracle Database Packages and Types     12.1.0.1.0   VALID

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.

@/u01/oracle/12c/rdbms/admin/utlu121s.sql

 

Transportable Tablespace

 

همانطور که می دانید تعدادی از tablespaceها به صورتی سیستمی و در زمان ابجاد بانک اطلاعات ساخته می شوند که معمولا به آنها administrative tablespaces می گویند(SYSTEM،  SYSAUX،UNDO  و TEMP) و تعدادی دیگر از tablespaceها که الزامی نیستند میتوانند برای کار کاربر ایجاد شوند که به آنها در صورت وجود، user tablespaces می گویند.

در صورتی که همه اطلاعات کاربر در user tablespace وجود داشته باشد، الزامی برای ارتقا admin tablespace نخواهیم داشت و تنها می توانیم tablespaceهایی که اطلاعات کاربر در آنها موجود است را به نسخه جدید ارتقا دهیم همچنین در صورتی که اطلاعات کاربر در داخل admin tablespace باشد، می توانیم ابتدا آنها را به user tablespace منتقل کنیم و سپس این tablespaceها را به نسخه جدید ارتقا دهیم. با توجه به ویژگی Transportable Tablespace این قابلیت وجود دارد که tablespaceها را به بانک جدیدی که نسخه اوراکل آن متفاوت است منتقل کنیم.

در ادامه قصد داریم tablespaceهایی که اطلاعات کاربر در آنها قرار دارند را با این روش به 12c ارتقا دهیم.

فرض کنید با توجه به شناختی که از بانک داریم، تنها دو tablespace با نامهای USEF_TBS1 و USEF_TBS2 اطلاعات کاربر را در خود دارند.

SQL> select TABLESPACE_NAME,STATUS from dba_tablespaces;

TABLESPACE_NAME                STATUS

—————————— ———

SYSTEM                       ONLINE

SYSAUX                        ONLINE

UNDOTBS1                  ONLINE

TEMP                           ONLINE

USERS                          ONLINE

USEF_TBS1                  ONLINE

USEF_TBS2                  ONLINE

یکی از ویژگی های TTS آن است که هیچ کدام از اشیاهای داخل tablespaceای که قرار است منتقل شود، نباید به شی‏ای خارج از این tablespace وابسته باشد. با دو دستور زیر بررسی می کنیم که کدام شی این قانون را نقض کرده است و در صورت نقض قانون، باید اشیا مرتبط را در یک tablespace قرار دهیم.

SQL> EXECUTE DBMS_TTS.TRANSPORT_SET_CHECK(‘USEF_TBS1,USEF_TBS2’, TRUE);

PL/SQL procedure successfully completed.

SQL> SELECT * FROM TRANSPORT_SET_VIOLATIONS;

no rows selected

برای شروع کار ابتدا این دو tablespace را در وضیعت read only قرار می دهیم.

SQL> alter tablespace USEF_TBS1 read only;

Tablespace altered.

SQL> alter tablespace USEF_TBS2 read only;

Tablespace altered.

از متادیتاهای مربوط به این دو tablespace، با استفاده از expdp دامپی تهیه می کنیم.

expdp   directory=usef dumpfile=usef1.dmp transport_tablespaces=USEF_TBS2,USEF_TBS1 transport_full_check=y

Export: Release 11.2.0.4.0 – Production on Thu Oct 15 14:49:58 2015

Copyright © 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 – 64bit Production

Starting “SYS”.”SYS_EXPORT_TRANSPORTABLE_01″:  sys/******** AS SYSDBA directory=usef dumpfile=usef1.dmp transport_tablespaces=USEF_TBS2,USEF_TBS1 transport_full_check=y

Datafiles required for transportable tablespace USEF_TBS1:

  /u01/oracle/oradata/orcl4/usef1.dbf

Datafiles required for transportable tablespace USEF_TBS2:

  /u01/oracle/oradata/orcl4/usef2.dbf

Job “SYS”.”SYS_EXPORT_TRANSPORTABLE_01″ successfully completed at Thu Oct 15 14:50:38 2015 elapsed 0 00:00:32

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

scp /u01/oracle/oradata/orcl4/usef*  10.45.10.15:/u01/oracle/oradata/USEF12C/datafile/

usef1.dbf                                     100% 5128KB   5.0MB/s   00:00   

usef2.dbf                                     100% 5128KB   5.0MB/s   00:00 

با دستور زیر دامپ گرفته شده را که حاوی اطلاعاتی از متادیتا دو tablespace است را در بانک مقصد بر می گردانیم البته قبل از import باید اسکیمای مورد نظر را بسازیم و در صورتی که اندازه بلاک این tablespaceها هم اندازه بلاکهای پیش فرض بانک مقصد نباشد، باید پارامتر db_n_cache_size را تنظیم کنیم:

impdp  directory=usef dumpfile=usef1.dmp  transport_datafiles=’/u01/oracle/oradata/USEF12C/datafile/usef1.dbf’,’/u01/oracle/oradata/USEF12C/datafile/usef2.dbf’

Import: Release 12.1.0.1.0 – Production on Thu Oct 15 18:06:42 2015

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 – 64bit Production

Master table “SYS”.”SYS_IMPORT_TRANSPORTABLE_01″ successfully loaded/unloaded

Source TSTZ version is 14 and target TSTZ version is 18.

Starting “SYS”.”SYS_IMPORT_TRANSPORTABLE_01″:  sys/******** AS SYSDBA directory=usef dumpfile=usef1.dmp transport_datafiles=/u01/oracle/oradata/USEF12C/datafile/usef1.dbf,/u01/oracle/oradata/USEF12C/datafile/usef2.dbf

Job “SYS”.”SYS_IMPORT_TRANSPORTABLE_01″ successfully completed at Thu Oct 15 18:06:55 2015 elapsed 0 00:00:03

همانطور که در این قسمت می بینید، دو tablespace به بانک جدید اضافه شده اند:

SQL> select TABLESPACE_NAME,STATUS from dba_tablespaces;

TABLESPACE_NAME                STATUS

—————————— ———

SYSTEM                         ONLINE

SYSAUX                         ONLINE

UNDOTBS1                       ONLINE

TEMP                           ONLINE

USERS                          ONLINE

USEF_TBS1                      READ ONLY

USEF_TBS2                      READ ONLY

7 rows selected.

در انتهای کار این دو tablespace را در حالت read write قرار می دهیم:

SQL> alter tablespace USEF_TBS1 read write;

Tablespace altered.

SQL>  alter tablespace USEF_TBS2 read write;

Tablespace altered.

Full Transportable Export/Import

در صورتی که اطلاعات قابل توجهی از کاربران در درون system tablespace قرار داشته باشند شاید به صرفه باشد این اطلاعات را به طور مستقیم به بانک جدید منتقل کنیم(بدون انتقال به user tablespace) برای این کار از روش TTS full استفاده می کنیم که فرق اصلی این روش با روش قبلی در استفاده از عبارت full=y transportable=always در هنگام اکسپورت گرفتن می باشد که سبب می شود اطلاعات کاربری موجود در tablespaceهای سیستمی از طریق EXPDP، همراه اطلاعات متادیتا در دامپ ذخیره شوند.همچنین نسخه بانک مبدا باید حداقل 11.2.0.3 باشد. در ادامه نمونه ای از این کار را خواهیم دید:

select tablespace_name from dba_tablespaces;

TABLESPACE_NAME

——————————

SYSTEM,     SYSAUX,      UNDOtbs1,                       TEMP,          USERS,         USEF_TBS1,                      USEF_TBS2

alter tablespace USEF_TBS1  read only;

alter tablespace USEF_TBS2   read only;

alter tablespace USERS   read only;

expdp directory=usef dumpfile=usef5.dmp full=y transportable=always logfile=usef:TTS.log version=12

Export: Release 11.2.0.4.0 – Production on Sun Oct 18 17:27:17 2015

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 – 64bit Production

Starting “SYS”.”SYS_EXPORT_FULL_01″:  sys/******** AS SYSDBA directory=usef dumpfile=usef5.dmp full=y transportable=always logfile=usef:TTS.log version=12

. . exported “SYSTEM”.”REPCAT$_REPCOLUMN”                    0 KB       0 rows

Master table “SYS”.”SYS_EXPORT_FULL_01″ successfully loaded/unloaded

Dump file set for SYS.SYS_EXPORT_FULL_01 is:

  /u01/usef5.dmp

Datafiles required for transportable tablespace USEF_TBS1:

  /u01/oracle/oradata/usef11g/usef1.dbf

Datafiles required for transportable tablespace USEF_TBS2:

  /u01/oracle/oradata/usef11g/usef2.dbf

Datafiles required for transportable tablespace USERS:

  /u01/oracle/oradata/usef11g/users01.dbf

Job “SYS”.”SYS_EXPORT_FULL_01″ successfully completed at Sun Oct 18 17:30:29 2015 elapsed 0 00:03:07

scp -r /u01/usef5.dmp 10.45.10.15:/u01/oracle/

usef5.dmp                                     100%   75MB  74.6MB/s   00:01

scp -r /u01/oracle/oradata/usef11g/use* 10.45.10.15:/u01/oracle/oradata/usef11g

usef1.dbf                                     100% 5128KB   5.0MB/s   00:00

usef2.dbf                                     100% 5128KB   5.0MB/s   00:00

users01.dbf                                   100% 5128KB   5.0MB/s   00:00

 sqlplus “/as sysdba”

SQL*Plus: Release 12.1.0.1.0 Production on Sun Oct 18 20:17:33 2015

Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 – 64bit Production

SQL> select tablespace_name from dba_tablespaces;

TABLESPACE_NAME

——————————

SYSTEM

SYSAUX

UNDOTBS1

TEMP

impdp directory=usef dumpfile=usef5.dmp FULL=Y VERSION=12 TRANSPORT_DATAFILES=’/u01/oracle/oradata/usef11g/usef1.dbf’,’/u01/oracle/oradata/usef11g/usef2.dbf’,’/u01/oracle/oradata/usef11g/users01.dbf’

…..

. . imported “WMSYS”.”E$WORKSPACES_TABLE”                14.51 KB       1 rows

. . imported “WMSYS”.”E$WORKSPACE_PRIV_TABLE”            6.851 KB       8 rows

 

Transient Standby

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

این ویژگی جدید به طور موقت physical standby را به logical standby تبدیل می کند تا بتوان عملیات upgrade را بر روی آن انجام داد و در نهایت آن را به همان نقش قبلی خود بر می گرداند. برای انجام این کار لازم است تا اوراکل 12c را در هر دو سرور نصب کنیم(سرور بانک اصلی و استندبای) و فضای اضافه ای را برای flashback در نظر بگیریم و همچنین باید دو بار downtime را برای switchover بانک اصلی در نظر داشته باشیم. در عمل این نوع از ارتقا میزان downtime را از چند ساعت به چند دقیقه کاهش می دهد.

قبل از شروع ارتقا با این روش باید Data Guard Broker را غیرفعال باشد و همچنین پارامتر COMPATIBLE تا زمانی که ارتقا در هر دو طرف اتفاق نیفتاد، به یک مقدار تنظیم شوند.

در مدت زمانی کوتاهی که به حالت logical standby منتقل می شویم، نیاز است در مورد نوع داده ای کهlogical standby پشتیبانی نمی کند، تصمصمی گرفت(البته قبل از آن که به logical standby منتقل شویم) در صورتی که آنها را در درون بانک شناسایی کرده ایم، و در صورت امکان بتوانیم در این مدت زمان کوتاه از تغییر آن جلوگیری کنیم ولی در صورتی که این کار ممکن نبود، می توانیم از DBA_LOGSTDBY_EVENTS استفاده کنیم و تغییراتی که به این دلیل درlogical standby اعمال نشده‏اند را شناسایی و با Export/Import آنها را به صورت دستی مرتفع کنیم.

مراحلی که در این قسمت برای انجام ارتقا خواهیم دید، تقسیم منطقی ندارند و بیشتر برای خلط نکردن دستورات با هم، بیان شده اند. ضمنا برای انجام بعضی از مراحل می توان از اسکریپت physru استفاده کرد که البته آن مراحل را به طور دستی در اینجا انجام داده ایم.

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

on prim:

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

MAX(SEQUENCE#)    THREAD#

————– ———-

            70          1

stb:

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

   THREAD# MAX(SEQUENCE#)

———- ————–

         1             70

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

on prim:

SQL> create restore point upgrade_usef1 guarantee flashback database;

Restore point created.

on stb:

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 در دو طرف نداشته باشیم.

on prim:

SQL> exec dbms_logstdby.build;

PL/SQL procedure successfully completed.

on stb:

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;

ERROR at line 1:

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

خطای بالا به دلیل فقدان standby redo log در data guard رخ داده است که دلیل آن هم به پیش فرض بودن مود دیتاگارد بر می گردد(یعنی maximum performance بدون LGWR).

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

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

on prim:

alter system set log_archive_dest_state_2=DEFER scope=memory;

on stb:

SQL> alter database stop logical standby apply;

Database altered.

shutdown immediate;

Run DBUA   OR Comman_Line upgrade

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

on prim:

create user usef identified by usef;

grant dba,connect,resource;

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

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

commit;

SQL> select * from usef.upgrading;

         A B

———- ———

         1 19-OCT-15

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

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

on prim:

alter system set log_archive_dest_state_2=enable scope=memory;

on stb:

shutdown immediate;

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

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

on prim:

SQL>  select switchover_status from v$database;

SWITCHOVER_STATUS

——————–

TO STANDBY

 

SQL>  alter database commit to switchover to logical standby;

Database altered.

 

on stb:

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  برگردانیم:

on original  stb(current prim):

alter system set log_archive_dest_state_2=DEFER scope=memory;

on original prim(current stb):

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.

on original  stb(current prim):

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

System altered.

on original prim(current stb):

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

on original  stb(current prim):

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.

on original prim(current stb):

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.

 

fallback strategy

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

  1. همه اطلاعات بعد از ارتقا از دست می رود:

restore a backup, flashback, offline upgrade

  1. هیچ اطلاعاتی را از دست نمی دهیم:

export/import, downgrade, Oracle Streams, Oracle Golden Gate

در اینجا قصد داریم روشهای  downgrade(catdwgrd)، offline upgrade و flashback را به طور مختصر مورد بررسی قرار دهیم:

offline upgrade

قبل از تشریح کیفیت این روش باید گفت که در صورت داشتن یک سرور و فضای اضافه می توان یک استندبای برای این بانک ایجاد کرد و در صورت به خطا خوردن در حین ارتقا، به آن بازگشت(البته در زمان ارتقا، استندبای را باید استاپ کنیم). حال در صورتی که فضای کافی در اختیار نباشد می توانیم از این روش استفاده کنیم به این صورت که قبل از ارتقا همه user tablespace  بانک را در حالت read only قرار دهیم و از همه database fileهای سیستمی بانک کپی تهیه کنیم و در صورتی که به خطا خوردیم، می توانیم database fileها را جایگزین database fileهای فعلی کنیم و بانک را دوباره در ورژن قبلی استارت کرد.

Flashback Database

این روش سرعت بسیار خوبی دارد ولی نیاز به فضای اضافه خواهیم داشت و نیز برای استفاده از این روش نباید پارامتر  COMPATIBLE را به نسخه جدید ارتقا داد. برای استفاده از این روش هم می توان از روش دستی استفاده کرد به این صورت که ابتدا باید بانک را در حالت flashback قرار دهیم و نیز قبل از ارتقا دستور زیر را برای ایجاد guaranteed restore point بزنیم:

create restore point upgrade_usef1 guarantee flashback database;

همچنین در صورت رخ دادن خطا می توانیم از دستور زیر برای برگشت به قبل از ارتقا استفاده کنیم:

SHUTDOWN IMMEDIATE

STARTUP MOUNT;

flashback database to restore point upgrade_usef1;

SHUTDOWN IMMEDIATE

start on old version with resetlogs;

روش دوم:

می توانیم از DBUA برای این کار استفاده کنیم به این صورت که در مرحله هشتم، گزینه مربوط به استفاده از flashback را انتخاب کنیم.

Downgrade

همانطور که قبلا گفته شد، امکان Direct upgrade به اوراکل 12c از نسخه های 10.2.0.5، 11.1.0.7 و 11.2.0.2 و نسخه های بالاتر از آن، ممکن خواهد بود ولی امکان downgrade از 12c به  10.2.0.5 ممکن نخواهد بود(در صورتی که برای بقیه نسخه ها امکان پذیر است) دلیل این موضوع هم به پارامتر compatible بر می گردد یعنی زمانی که می خواهیم بانکی را با اوراکل 12c استارت کنیم، حداقل مقدار compatible باید برابر با 11.0.0 باشد و همانطور که در ادامه خواهید دید، امکان برگشت به نسخه قبل از پارامتر compatible وجود ندارد.

برای استفاده از روش catdwgrd، مهمترین نکته پارامتر compatible است یعنی اگر این پارامتر برابر با 12.1.0 شده باشد، امکان استفاده از این روش ممکن نخواهد بود.

در این قسمت سناریوی برگشت به نسخه قبلی با این روش آورده شده است:

دستورات زیر باید در اوراکل 12c انجام شود:

Shutdown immediate

sqlplus “/as sysdba”

SQL*Plus: Release 12.1.0.1.0 Production on Sat Oct 17 14:21:59 2015

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

Connected to an idle instance.

SQL> Startup downgrade;

ORACLE instance started.

Total System Global Area 8351150080 bytes

Fixed Size                  2701528 bytes

Variable Size            7348422440 bytes

Database Buffers          989855744 bytes

Redo Buffers               10170368 bytes

Database mounted.

Database opened.

SQL> @$ORACLE_HOME/rdbms/admin/catdwgrd.sql

select comp_name,version,status from dba_registry;

COMP_NAME                                            VERSION                  STATUS

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

OWB                                                          11.2.0.4.0             VALID

Oracle Application Express                       3.2.1.00.12            DOWNGRADED

OLAP Catalog                                                            11.2.0.4.0              OPTION OFF

Spatial                                                      11.2.0                    DOWNGRADED

Oracle Multimedia                                  11.2.0                     DOWNGRADED

Oracle XML Database                             11.2.0                    DOWNGRADED

Oracle Text                                             11.2.0                       DOWNGRADED

Oracle Workspace Manager                    11.2.0.1.0               DOWNGRADED

Oracle Database Catalog Views              11.2.0                     DOWNGRADED

Oracle Database Packages and Types      11.2.0                    DOWNGRADED

JServer JAVA Virtual Machine                 11.2.0                     DOWNGRADED

Oracle XDK                                               11.2.0                      DOWNGRADED

Oracle Database Java Packages               11.2.0                    DOWNGRADED

OLAP Analytic Workspace                               11.2.0             DOWNGRADED

Oracle OLAP API                                           11.2.0                DOWNGRADED

15 rows selected.

دستورات زیر باید در اوراکل 11g انجام شود و مدت زمان انجام آن، تقریبا برابر با مدت زمان ارتقا بانک می باشد:

sqlplus “/as sysdba”

SQL*Plus: Release 11.2.0.4.0 Production on Sat Oct 17 15:15:30 2015

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

Connected to an idle instance.

SQL> startup upgrade

ORACLE instance started.

Total System Global Area 8351150080 bytes

Fixed Size                  2269872 bytes

Variable Size            7298092368 bytes

Database Buffers         1040187392 bytes

Redo Buffers               10600448 bytes

Database mounted.

Database opened.

SQL> @?/rdbms/admin/catrelod.sql

col COMP_NAME format a40;

col VERSION format a12;

col STATUS format a10;

select comp_name,version,status from dba_registry;

COMP_NAME                                           VERSION                  STATUS

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

OWB                                                       11.2.0.4.0                VALID

Oracle Application Express                     3.2.1.00.12              INVALID

OLAP Catalog                                          11.2.0.4.0                VALID

Spatial                                                     11.2.0.4.0                INVALID

Oracle Multimedia                                 11.2.0.4.0                VALID

Oracle XML Database                             11.2.0.4.0                VALID

Oracle Text                                                             11.2.0.4.0                VALID

Oracle Workspace Manager                   11.2.0.4.0                VALID

Oracle Database Catalog Views             11.2.0.4.0               INVALID

Oracle Database Packages and Types      11.2.0.4.0              VALID

JServer JAVA Virtual Machine                11.2.0.4.0                VALID

Oracle Database Java Packages            11.2.0.4.0                VALID

OLAP Analytic Workspace                      11.2.0.4.0                 VALID

Oracle OLAP API                                     11.2.0.4.0                VALID

15 rows selected.

در پایان کار باید بانک را یکبار دیگر کامپایل کنیم.

@?/rdbms/admin/utlrp.sql

نکات:

  1. یادآوری مجدد اینکه، اگر پارامتر compatible برابر با 12.1.0 شده باشد، یعنی امکان استفاده از catdwgrd ممکن نخواهد بود.
  2. اگر از data vault استفاده می کنیم، باید آن را قبل از downgrade غیرفعال کنیم.
  3. اگر از Oracle Label Security استفاده می کنیم، باید از اسکریپت olspredowngrade.sql برای downgrade آن استفاده کنیم.
  4. Timezone version باید با نسخه 11g یکسان باشد.
  5. اگر از cluster database استفاده می کنیم باید پارامتر CLUSTER_DATABASE را غیرفعال کنیم و بعد از downgrade، آن را TRUE برگردانیم.

 

پاسخ دهید

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