وبلاگ مسعود حاجی حسن پور

راهکار های عملی اوراکل

راهکار های عملی اوراکل

این وبلاگ جهت به اشتراک گذاری تجربیات و راهکار های عملی در زمینه پایگاه داده اوراکل می باشد.

دستاوردها
طبقه بندی موضوعی

۶ مطلب با کلمه‌ی کلیدی «database» ثبت شده است

OPatch failed

OPatch faild
سلام دوستان عزیز

امروز قصد دارم یکی از تجربیات خود را در زمینه patch نمودن پایگاه داده Oracle و Clusterware خدمت شما عنوان کنم.

  • وضعیت جاری:

OCW: 11.2.0.4

DB: 11.2.0.4

Patch number= 27475913 (11.2.0.4.180417) BP
در زمان patch psu در پایگاه داده با خطای زیر مواجه شدم:

[root@s2dbv3 OPatch]# ./opatch auto /home/oracle/patches/bundel/27475913 -ocmrf /u01/ocm.rsp
Executing /u01/app/oracle/product/11.2.0/gi_1/perl/bin/perl /u01/app/oracle/product/11.2.0/gi_1/OPatch/crs/patch11203.pl -patchdir /home/oracle/patches/bundel -patchn 27475913 -ocmrf /u01/ocm.rsp -paramfile /u01/app/oracle/product/11.2.0/gi_1/crs/install/crsconfig_params

This is the main log file: /u01/app/oracle/product/11.2.0/gi_1/cfgtoollogs/opatchauto2018-07-14_15-09-18.log

This file will show your detected configuration and all the steps that opatchauto attempted to do on your system:
/u01/app/oracle/product/11.2.0/gi_1/cfgtoollogs/opatchauto2018-07-14_15-09-18.report.log

2018-07-14 15:09:18: Starting Oracle Restart Patch Setup
Using configuration parameter file: /u01/app/oracle/product/11.2.0/gi_1/crs/install/crsconfig_params

Stopping RAC /u01/app/oracle/product/11.2.0/db_1 ...
Stopped RAC /u01/app/oracle/product/11.2.0/db_1 successfully

patch /home/oracle/patches/bundel/27475913/27338049  apply failed  for home  /u01/app/oracle/product/11.2.0/db_1

Stopping CRS...
Stopped CRS successfully

patch /home/oracle/patches/bundel/27475913/27338049  apply failed  for home  /u01/app/oracle/product/11.2.0/gi_1

Starting CRS...
CRS-4123: Oracle High Availability Services has been started.

Starting RAC /u01/app/oracle/product/11.2.0/db_1 ...
Started RAC /u01/app/oracle/product/11.2.0/db_1 successfully

opatch auto succeeded.


برای مشخص شدن، حزییات لاگ را بررسی نمودم و مشکل را پیدا کردم:

The following make actions have failed :

 Re-link fails on target "client_sharedlib".
 Re-link fails on target "client_sharedlib".
 Re-link fails on target "liborasdksh".
 Re-link fails on target "liborasdkbase".
 Re-link fails on target "ldapaddmt".
 Re-link fails on target "ldapadd".
 Re-link fails on target "ldapmodify".
 Re-link fails on target "ldapmodifymt".


 Do you want to proceed? [y|n]
 N (auto-answered by -silent)
 User Responded with: N

 Restoring "/u01/app/oracle/product/11.2.0/db_1" to the state prior to running NApply...
 Checking if OPatch needs to invoke 'make' to restore some binaries...
 Make failed to invoke "/usr/bin/make -f ins_rdbms.mk client_sharedlib ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1"....'genclntsh: genclntsh: Could not locate  /u01/app/oracle/product/11.2.0/db_1/network/admin/shrept.lst

مشکل در حقیقت نبود فایل shrept.lst بود.

  • فایل shrept.lst چیست و پراسس genclntsh چه میکند.
در حقیقت genclntsh یک اسکریپت در Home اوراکل است که symbol list ها ای از shared library برای پایگاه داده و OCW میسازد. همچنین shared library ها در فایل shrept.lst مشخص شده اند.

  • چگونگی حل مشکل

برای حل مشکل، در گام اول باید فایل shrept.lst را در مسیر مشخص شده داشته باشید. برای این منظور دو راه وجود دارد یا از یک پایگاه داده دیگر به مکان مشخص شده انتقال دهید (نکته حتما باید برای ورژن 11.2.0.4 باشد). یا آن را از مسیر نصب استخراج کنید و به مسیر مشخص شده انتقال دهید.

1:
scp shrept.lst oracle@<ipaddress or name>:/u01/app/oracle/product/11.2.0/db_1/network/admin

2:
cd $ORACLE_HOME
jar xvf <path>/stage/Components/oracle.network.rsf/11.2.0.4.0/1/DataFiles/filegroup6.jar network/admin/shrept.lst

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

-rw-r--r-- $ORACLE_HOME/network/admin/shrept.lst

تا اینجا همه چیز به نظر خوب می آید. حالا دوباره shared library ها را میسازیم. برای این کار باید وارد db_home شوید

cd $ORACLE_HOME/bin
./relink all


بسایر خوب حالا دوباره شروع به parch نمودن database و ocw میکنیم

[root@s2dbv3 OPatch]# ./opatch auto /home/oracle/patches/bundel/27475913 -ocmrf /u01/ocm.rsp
Executing /u01/app/oracle/product/11.2.0/gi_1/perl/bin/perl /u01/app/oracle/product/11.2.0/gi_1/OPatch/crs/patch11203.pl -patchdir /home/oracle/patches/bundel -patchn 27475913 -ocmrf /u01/ocm.rsp -paramfile /u01/app/oracle/product/11.2.0/gi_1/crs/install/crsconfig_params

This is the main log file: /u01/app/oracle/product/11.2.0/gi_1/cfgtoollogs/opatchauto2018-07-14_15-41-07.log

This file will show your detected configuration and all the steps that opatchauto attempted to do on your system:
/u01/app/oracle/product/11.2.0/gi_1/cfgtoollogs/opatchauto2018-07-14_15-41-07.report.log

2018-07-14 15:41:07: Starting Oracle Restart Patch Setup
Using configuration parameter file: /u01/app/oracle/product/11.2.0/gi_1/crs/install/crsconfig_params

Stopping RAC /u01/app/oracle/product/11.2.0/db_1 ...
Stopped RAC /u01/app/oracle/product/11.2.0/db_1 successfully

patch /home/oracle/patches/bundel/27475913/27338049  apply successful for home  /u01/app/oracle/product/11.2.0/db_1 
patch /home/oracle/patches/bundel/27475913/27441052/custom/server/27441052  apply successful for home  /u01/app/oracle/product/11.2.0/db_1 

Stopping CRS...
Stopped CRS successfully

patch /home/oracle/patches/bundel/27475913/27338049  apply successful for home  /u01/app/oracle/product/11.2.0/gi_1 
patch /home/oracle/patches/bundel/27475913/27441052  apply successful for home  /u01/app/oracle/product/11.2.0/gi_1 
patch /home/oracle/patches/bundel/27475913/22502505  apply successful for home  /u01/app/oracle/product/11.2.0/gi_1 

Starting CRS...
CRS-4123: Oracle High Availability Services has been started.

Starting RAC /u01/app/oracle/product/11.2.0/db_1 ...
Started RAC /u01/app/oracle/product/11.2.0/db_1 successfully

opatch auto succeeded.

همانگونه که مشاهده نمودید مشکل حل شد.


دوستان عزیز امیدوارم مطلب کاربردی بوده باشد.

شاد و پیروز باشید.

Exporting views

با شروع Oracle 12.1 این قابلیت وجود دارد که شما یک view را به عنوان table خروجی (export) بگیرید. این به این معنی است که export شامل DDL ساخت table و همچنین دیتای آن می باشد. در صورتی که object اصلی یک view است.
به عنوان مثال اگر شما از دستور زیر استفاده کنید:
expdp masoud/masoud dumpfile=myView.dmp include=view query=\"where c1=1\";

دستور بالا view را به عنوان view خروجی میگیرد (export شامل create view می باشد).

حالا از دستور VIEWS_AS_TABLES استفاده میکنیم:

expdp masoud/masoud dumpfile=myTable.dmp query=\"where c1=1\" views_as_tables=myTable;

دستور بالا query را اجرا میکند و DDL ساخت table میسازد. درحقیقت زمان import شما جدولی به نام myTable خواهید داشت که شامل data آن view می باشد.


دوستان عزیز امیدوارم مطلب کاربردی بوده باشد.

شاد و پیروز باشید.

پیدا کردن کارکتر غیر عددی در یک ستون

data type


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

ERROR at line 1:
ORA-01722: invalid number

بعد از بررسی مشخص شد که در column  مقادیر عددی ذخیره شده است، که data type آن از نوع varchar می باشد. اما در جدول حدود ۳۰۰۰۰۰۰۰۰ رکورد اطلاعات وجود داشت که واقعا پیدا کردن داده مشکل دار را سحت مینمود.

حالا با من همراه باشید که با یک شبیه سازی نشان دهم چگونه چنین مشکلی به وجود میاید و چگونه اطلاعات مشکل دار را پیدا کنیم.


خوب اول یک جدول ایجاد میکنیم و مقداری داده در آن قرار میدهیم:

create table mytest (c1 number primary key, c2 varchar (20));

Table created.

insert into mytest values (1, '20000000');

1 row created.

insert into mytest values (1, '300000000');
insert into mytest values (1, '300000000')
*
ERROR at line 1:
ORA-00001: unique constraint (HR.SYS_C0016539) violated

insert into mytest values (2, '300000000');

1 row created.

insert into mytest values (3, '300000000+');

1 row created.

select * from mytest;

        C1 C2
---------- --------------------
         1 20000000
         2 300000000
         3 300000000+

خوب حالا یک عملیات ریاضی مثل جمع انجام میدهیم و تا مقدار کل را به دست آوریم:

select sum(c2) from mytest;
select sum(c2) from mytest
           *
ERROR at line 1:
ORA-01722: invalid number

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


با دستور زیر میتوان رکوردی که داده غیر عددی دارد مشخص نمود:

select *
from mytest
where regexp_like(c2, '[^0-9]+');

        C1 C2
---------- --------------------
         3 300000000+

خوب دوستان چند نکته در مورد طراحی قابل ذکر است:

  1. در صورتی که واقعا نیاز شما فقط عدد هست از نوع داده ای غیر عددی مثل varchar یا varchar2 ... برای ذخیره اعداد استفاده ننمایید، چون برای انجام عملیات های ریاضی هر چند بسیار ناچیز implicitly type conversion overhead خواهید داشت. همچنین احتمال بروز چنین مشکلاتی نیز افزایش می یابد.
  2. دوستان برنامه نویس در که صورتی ناگزیر به استفاده از داده غیر عددی برای ذخیره عداد هستید، حتما بررسی کنید که کارکتر غیر عددی در ستونی که قرار است بر روی آن اعمال ریاضی انجام گردد قرار ندهند (حتما در برنامه جلوی آن گرفته شود) تا در ادامه با چنین مشکلاتی رو به رو نشوید.

دوستان عزیز امیدوارم مطلب کاربردی بوده باشد.

شاد و پیروز باشید.

Nologging and Recovery !

recovery

این امکان وجود دارد که شما برای بعضی از کار ها از پایگاه داده بخواهید که redo برای آنکار تولید نکند. مثل create table as select, insert into select, create index, ... اگر شما بعد از این عملیات ها بکاپ تهیه کنید هیچ مشکلی نیست و شما به درستی زمان کمتری برای انجام آنکارها گذاشته اید. ولی اگر قبل از بکاپ دیتافایل آسیب ببیند چه مشکلی بوجود می آید ؟

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


اول یک tablespace و user جدا و دسترسی های لازم را ایجاد میکنیم:

[oracle@myos ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Mon Jul 3 11:09:42 2017

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


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options
SYS@db11g> create tablespace mas datafile '+DATA';

Tablespace created.

SYS@db11g> create user masoud account unlock identified by masoud default tablespace mas quota unlimited on mas;

User created.

SYS@db11g> grant create table, create session, create sequence to masoud;

Grant succeeded.

SYS@db11g> disc
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options

@> conn masoud
Enter password:
Connected.

MASOUD@db11g> create sequence myseq;

Sequence created.

MASOUD@db11g> create table t (c1 number, c2 varchar(10));

Table created.

خوب در اینجا ما یک user به نام masoud  داریم که tablespace پیش فرض اون mas هست حال داده در جدول t  میریزیم

begin 
  for i in 1..1000 loop 
    insert into t values (myseq.nextval, 'my val'); 
  end loop;
  commit;
end;
/

حال یک بکاپ از tablespace میگیریم :

RMAN> backup tablespace mas;

Starting backup at 03-JUL-2017 11:25:01
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2591 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=11 device type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=528 device type=DISK
allocated channel: ORA_DISK_4
channel ORA_DISK_4: SID=1044 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00019 name=+DATA/db11g/datafile/mas.265.948366897
channel ORA_DISK_1: starting piece 1 at 03-JUL-2017 11:25:04
channel ORA_DISK_1: finished piece 1 at 03-JUL-2017 11:25:07
piece handle=+FRA/db11g/backupset/2017_07_03/nnndf0_tag20170703t112504_0.284.948367505 tag=TAG20170703T112504 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 03-JUL-2017 11:25:07

Starting Control File and SPFILE Autobackup at 03-JUL-2017 11:25:08
piece handle=+FRA/db11g/autobackup/2017_07_03/s_948367508.429.948367511 comment=NONE
Finished Control File and SPFILE Autobackup at 03-JUL-2017 11:25:15

حالا وضعیت قابل ریکاور بودن datafile رو ببینیم:

RMAN> report unrecoverable;

Report of files that need backup due to unrecoverable operations
File Type of Backup Required Name
---- ----------------------- -----------------------------------

پس همانگونه که میبینید هیچ datafile unrecoverable نیست (در حقیقت همه در صورت media failure قابل بازگشت هستند) حال یک عملیات nologging انجام میدهیم:


MASOUD@db11g> create index ix_t_c1 on t(c1) nologging;

Index created.

RMAN> report unrecoverable;

Report of files that need backup due to unrecoverable operations
File Type of Backup Required Name
---- ----------------------- -----------------------------------
19   full or incremental     +DATA/db11g/datafile/mas.265.948366897

SYS@db11g> select file#,to_char(UNRECOVERABLE_TIME,'yyyy-mm-dd:hh24:mi:ss')
from v$datafile where file#=19;

     FILE# TO_CHAR(UNRECOVERAB
---------- -------------------
        19 2017-07-03:14:17:01

همانگونه که مشاهده نمودید datafile شماره ۱۹ unrecoverable شد.


بیاید فرض کنیم که دیتافایل دچار آسیب شده و حال میخواهیم آن را recover کنیم:

RMAN> sql 'alter database datafile 19 offline';

using target database control file instead of recovery catalog
sql statement: alter database datafile 19 offline

RMAN> restore datafile 19;
.
.
.
Finished restore at 03-JUL-2017 14:30:43

RMAN> recover datafile 19;

Starting recover at 03-JUL-2017 14:31:06
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4

starting media recovery
media recovery complete, elapsed time: 00:00:03

Finished recover at 03-JUL-2017 14:31:10

RMAN> sql 'alter database datafile 19 online';

sql statement: alter database datafile 19 online

بسیار خوب فایل recover شد حال یک select میزنیم و سعی میکنیم تا از index استفاده شود.

MASOUD@db11g> select * from t where c1=7;
select * from t where c1=7
              *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 19, block # 140)
ORA-01110: data file 19: '+DATA/db11g/datafile/mas.265.948366897'
ORA-26040: Data block was loaded using the NOLOGGING option

بدرستی با مشکل رو به رو شدیم، چون ما redo برای این index ایجاد نکرده بودیم پس index هم زمان recovery نخواهیم داشت. ولی میتوانیم ببنیم دفیقا کدام index این مشکل رو ایجاد کرده و با کمی پیچیدگی میتوانیم این مشکل را حل کنیم:

MASOUD@db11g> select index_name,status,logging from user_indexes where tablespace_name='MAS';

INDEX_NAME                     STATUS   LOG
------------------------------ -------- ---
IX_T_C1                        VALID    NO

MASOUD@db11g> alter index IX_T_C1 rebuild nologging;
alter index IX_T_C1 rebuild nologging
* ERROR at line 1: ORA-01578: ORACLE data block corrupted (file # 19, block # 140)
ORA-01110: data file 18: '+DATA/db11g/datafile/mas.265.948366897'
ORA-26040: Data block was loaded using the NOLOGGING option MASOUD@db11g> alter index IX_T_C1 unusable; MASOUD@db11g> alter index ix_t_c1 rebuild nologging; Index altered. MASOUD@db11g> select * from t where c1=7; C1 C2 ---------- ---------- 7 my val

بسیار خوب همانگونه که دیدید مشکل حل شد و حال دوباره از tablespace بکاپ میگیریم که مشکل unrecoverable نیز نداشته باشیم.

RMAN> backup tablespace mas;

Finished backup at 03-JUL-2017 14:56:27

RMAN> report unrecoverable;

Report of files that need backup due to unrecoverable operations
File Type of Backup Required Name
---- ----------------------- -----------------------------------


حالا رفتار insert nologging را ببینیم:

MASOUD@db11g> alter table t nologging;

Table altered.

MASOUD@db11g> insert /*+ append */ into t select * from t;

1000 rows created.

SYS@db11g> select file#,to_char(UNRECOVERABLE_TIME,'yyyy-mm-dd:hh24:mi:ss') from v$datafile where file#=19;

     FILE# TO_CHAR(UNRECOVERAB
---------- -------------------
        19 2017-07-03:15:00:01

RMAN> report unrecoverable;

Report of files that need backup due to unrecoverable operations
File Type of Backup Required Name
---- ----------------------- -----------------------------------
19   full or incremental     +DATA/db11g/datafile/mas.265.948366897

RMAN> sql 'alter database datafile 19 offline';

sql statement: alter database datafile 19 offline

RMAN> restore datafile 19;

Starting restore at 03-JUL-2017 15:05:49
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00019 to +DATA/db11g/datafile/mas.265.948366897
channel ORA_DISK_1: reading from backup piece +FRA/db11g/backupset/2017_07_03/nnndf0_tag20170703t145624_0.393.948380185
channel ORA_DISK_1: piece handle=+FRA/db11g/backupset/2017_07_03/nnndf0_tag20170703t145624_0.393.948380185 tag=TAG20170703T145624
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
Finished restore at 03-JUL-2017 15:05:52

RMAN> recover datafile 19;

Starting recover at 03-JUL-2017 15:05:59
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4

starting media recovery
media recovery complete, elapsed time: 00:00:02

Finished recover at 03-JUL-2017 15:06:03

RMAN> sql 'alter database datafile 19 online';

sql statement: alter database datafile 19 online

MASOUD@db11g> select * from t;
.
.
.
ERROR:
ORA-01578: ORACLE data block corrupted (file # 19, block # 136)
ORA-01110: data file 19: '+DATA/db11g/datafile/mas.265.948366897'
ORA-26040: Data block was loaded using the NOLOGGING option

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


 دوستان عزیز امیدوارم مطلب کاربردی بوده باشد.

شاد و پیروز باشید.

Patching in Oracle

patch

گاهی اوقات ممکن است که شما در پایگاه داده با یک اشکال رو به رو شده و در نهایت با جستجو نمودن در اینترنت متوجه یک باگ شوید که اوراکل به شما پیشنهاد patch نمودن میکند. یا گروه امنیت شرکت از شما بخواهد که پایگاه داده را به دلیل مسائل امنیتی patch  نمیایید. ولی وقتی وارد سایت oracle support شوید با انواع اسامی روبرو خواهید شد که ممکن است گیج کننده باشد. پس در ادامه به تعاریف انواع patch و بزار های مورد نیاز و versioning در محصولات اوراکل میپردازیم.


اعداد در ورژن اوراکل چه معنایی میدهد ؟


در محصولات اوراکل ورژن ها به شکل 11.2.0.1.0 یا 12.2.0.1.1 میباشد اما دفیقا این اعداد چه هستند ؟


  • سه عدد اول را base version یا base release میگویند که ورژن آن محصول را نمایش میدهد. به عنوان مثال
Oracle database 10gR2 10.2.0.x.x
Oracle database 11gR2 11.2.0.x.x
Oracle database 12cR1 12.0.1.x.x

  • عدد چهارم patchset هست که full patch پایگاه داده میباشد. قبل از ورژن 11.1 ما patch رو دانلود میکردیم و بر روی home جاری نصب میکردیم. اما از ورژن 11.2 به بعد patchset ها به عنوان full installation به بازار عرضه می شود.  مثال:
Oracle database 11gR2 11.2.0.4.0 ----> x.x.x.4.x

  • و در مورد عدد پنجم نیز توضیح خواهم داد...

انواع patch

در محصولات اوراکل patch های متنوع ای وجود دارد که به اختصار توضیح خواهم داد:

  1. Patchset: در patch های محصولات اوراکل معمولا بیشترین حجم و بیشترین تغییرات را دارا میباشد (عدد چهارم) و بوسیله OUI نصب میگردد.
  2. One-off patch: یک patch کوچک هست که برای حل مشکل یک bug خاص ایجاد شده است. و بوسیله opatch نصب میگردد.
  3. CPU - Critical Patch Update یا SPU - Security Patch Update: این patch ها هر سه ماه یک بار وارد بازار میگردد و در مورد حل نمودن مشکلات امنیتی محصول میباشد. CPU ها به صورت cumulative میباشند و با بروز رسانی تمام نسخه های پیشین CPU ها را پوشش میدهند. همچنین این patch ها با opatch قابل نصب می باشند.
  4. PSU Patch Set Update / PB Patch Bundle: باید گفت که PSU برای سیستم های UNIX/LINUX هست و PB برای سیستم های WINDOWS/EXADATA این patch ها هم هر سه ماه یک بار توسط شرکت اوراکل ارائه میگردد و در صورت patch کردن محصول به صورت cumulative میباشد. یعنی اگر patch 11.2.0.4.8 را روی محصول بزنید، در حقیقت patch های 11.2.0.4.6 و 11.2.0.4.7 و ... را نیز زده اید. این patch شامل چندین one-off میباشد که عدم ناسازگاری (Conflicts)  مورد بررسی قرار گرفته و مابین one-off های آن ناسازگاری وجود ندارد و فرایند patching را ساده تر میسازد. همچنین PSU ها شامل SPU ها میباشند که تا تاریخ انتشار PSU بروز رسانی شده است. درصورتی که شما بر روی محصول ( مثلا پایگاه داده ) PSU زده باشید دیگر نمیتوانید SPU بزنید مگر اینکه خود محصول رو برروز رسانی نمایید. این patch نیز به وسیله opatch نصب میگردد. PSU/BP ها شامل عدد پنجم در شماره ورژن میگردند، به عنوان مثال:
Oracle database 11gR2 11.2.0.4.8 ----> x.x.x.x.8

patch کردن یا نکردن مسئله این است !

بعد از بروز رسانی و patch کردن محصول ممکن است رفتار پایگاه داده دچار تغییر یا مشکل گردد. حال بررسی میکنیم که چگونه برروز رسانی یا patching ممکن است پایگاه داده را تحت تاثیر فرار دهد ؟

  • در حقیقت patchset یکم ریسکی هست. در patchset ها معمولا ویژگی های جدید به ندرت اضافه میشود ولی به هر حال ممکن است این ویژگی جدید دارای باگ باشد. همچنین ممکن است یک procedure در یک package خاص، دارای تغییرات پارامتر باشد و در صورتی که شما PL/SQL نوشته باشید که در حال استفاده از آن procedure باشد ممکن است دچار اشکال گردد. همچنین ممکن است رفتار optimizer دچار تغییر شده باشد و شما انتظار execution plan قبل را برای یک کوئری خاص داشته باشد که آن هم دچار تغییر گردد. ولی در مورد one-off, SPU, PSU, PB جای نگرانی نیست چون این patch ها معمولا برای رفع مشکل موجود ایجاد شده اند.

جدید چه خبر ؟

  • 12.1: از این ورژن به بعد شرکت اوراکل یک بازنگری در تنوع patch ها نمود و تصمیم بر این گرفت که دیگر CPU/SPU ندهد و آنها را در غالب PSU/PB انتشار دهد. پس از این ورژن به بعد CPU/SPU تا الان نخواهیم داشت مگر اینکه شرکت اوراکل در این مورد تجدید نظر کند.

ابزار بروزرسانی و patching

  1. OUI: همانگونه که گفته شده در از ورژن 11.2 به بعد حالتی به نام out of place upgade ایجاد شد و شما به راحتی با ابزار های OUI مثل DBCA, DBUA میتوانید پایگاه داده را بروزرسانی نمایید.
  2. opatch: این یک ابزار مخصوص patch کردن محصول هست که در home تمام محصولات موجود میباشد. oracle  پیشنهاد میکند که قبل از استفاده کردن از opatch خود opatch را به آخرین ورژن به روز رسانی نمایید. مثلا برای patch کردن پایگاه داده 11.2.0.4 از opatch ورژن 11.2.0.3.15 استفاده نمایید.
  • برای دیدن مسیر و ورژن ابزار opatch از دستور زیر استفاده کنید:
cd $ORACLE_HOME/OPatch

./opatch version
OPatch Version: 11.2.0.3.15

OPatch succeeded.

  • برای دیدن وضعیت patch های که روی محصول زده شده از دستور زیر استفاده نمایید:
./opatch lsinventory
Oracle Interim Patch Installer version 11.2.0.3.15
Copyright (c) 2017, Oracle Corporation.  All rights reserved.


Oracle Home       : /u01/app/grid/product/11.2.0/grid
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/grid/product/11.2.0/grid/oraInst.loc
OPatch version    : 11.2.0.3.15
OUI version       : 11.2.0.4.0
Log file location : /u01/app/grid/product/11.2.0/grid/cfgtoollogs/opatch/opatch2017-05-15_10-06-06AM_1.log

Lsinventory Output file location : /u01/app/grid/product/11.2.0/grid/cfgtoollogs/opatch/lsinv/lsinventory2017-05-15_10-06-06AM.txt

--------------------------------------------------------------------------------
Local Machine Information::
Hostname: myos
ARU platform id: 226
ARU platform description:: Linux x86-64

Installed Top-level Products (1):

Oracle Grid Infrastructure 11g                                       11.2.0.4.0
There are 1 products installed in this Oracle Home.


Interim patches (3) :

Patch  22502505     : applied on Thu Apr 13 09:52:54 IRDT 2017
Unique Patch ID:  19880366
Patch description:  "ACFS Patch Set Update : 11.2.0.4.160419 (22502505)"
   Created on 17 Feb 2016, 00:12:23 hrs PST8PDT
   Bugs fixed:
     21369858, 16318126, 19690653, 17503605, 17203009, 17359415, 20140148
     17611362, 17164243, 19053182, 17696547, 17488768, 18168684, 21519796
     18143006, 21208140, 17428148, 17070158, 20438706, 17510275, 17172303
     18610307, 17376318, 17721778, 22198405, 17699423, 18915417, 18155334
     18321597, 19919907, 18185024, 17636008, 17363999, 20681968, 17475946

Patch  23054319     : applied on Thu Apr 13 09:50:41 IRDT 2017
Unique Patch ID:  20209287
Patch description:  "OCW Patch Set Update : 11.2.0.4.160719 (23054319)"
   Created on 15 Jul 2016, 14:38:17 hrs PST8PDT
   Bugs fixed:
     18328800, 19270660, 18691572, 18508710, 20038451, 21251192, 22162062
     20365005, 21232394, 17387214, 17750548, 17617807, 14497275, 20219458
     17733927, 18180541, 23757020, 18962892, 17292250, 17378618, 16759171
     20110156, 17843489, 17065496, 13991403, 21694632, 17273020, 22762046
     17155238, 18261183, 18053580, 20012766, 21245437, 20218012, 17013634
     17886392, 20995001, 17039197, 16317771, 17947785, 10052729, 20340620
     22353346, 16237657, 20317221, 18199185, 15917869, 18399991, 20186278
     18024089, 17374271, 16849642, 20246071, 20746251, 14270845, 20552947
     18414137, 18882642, 17001914, 17927970, 14378120, 16346413, 15986647
     18068871, 21222147, 16206997, 18143836, 21982225, 19168690, 18343490
     20235511, 21875360, 16613232, 19276791, 17722664, 20440643, 12928658
     18226143, 18520351, 16249829, 18952577, 17172091, 18229842, 16076412
     18265482, 20676340, 17818075, 20091753, 18231837, 14373486, 17483479
     20136892, 20551654, 18120545, 18729166, 13843841, 17405302, 21225209
     18709496, 18330979, 18744838, 14525998, 18187697, 17087371, 20531190
     20598625, 14385860, 18348155, 19479503, 12928592, 17516024, 18370031
     17764053, 19272663, 17551223, 14671408, 18272135, 14207615, 21255373
     17500165, 18875012, 14769643, 19558324, 18464784, 18848125, 19241857
     17955615, 14851828, 14693336, 20315294, 16284825, 17352230, 20014326
     17238586, 17089344, 17405605, 17531342, 21327402, 19398098, 17159489
     17640316, 13823394, 16543190, 22024217, 17983675, 20795241, 17481314
     18346135, 17598201, 16281493, 15986311, 17208793, 19601468, 18999857
     18700935, 14076173, 18428146, 17435488, 18352845, 18352846, 20408163
     17592037, 19616601, 17387779, 17391726, 14777968, 15851860, 16206882
     20141091, 15832129, 17305100, 20175174, 21113068, 19885321, 16901346
     17985714, 18536826, 17780903, 18752378, 18946768, 16876500, 16875342
     17769597, 19955755, 16429265, 18336452, 17273003, 17209968, 16988311
     19319357, 20094984, 17046460, 17059927, 18053631, 16867761, 18774591
     21442094, 20235486, 19359787, 15869775, 17447588, 19642566, 21152052
     16798862, 15920201

Patch  24006111     : applied on Thu Apr 13 09:46:44 IRDT 2017
Unique Patch ID:  20508568
Patch description:  "Database Patch Set Update : 11.2.0.4.161018 (24006111)"
   Created on 26 Aug 2016, 05:54:48 hrs PST8PDT
Sub-patch  23054359; "Database Patch Set Update : 11.2.0.4.160719 (23054359)"
Sub-patch  22502456; "Database Patch Set Update : 11.2.0.4.160419 (22502456)"
Sub-patch  21948347; "Database Patch Set Update : 11.2.0.4.160119 (21948347)"
Sub-patch  21352635; "Database Patch Set Update : 11.2.0.4.8 (21352635)"
Sub-patch  20760982; "Database Patch Set Update : 11.2.0.4.7 (20760982)"
Sub-patch  20299013; "Database Patch Set Update : 11.2.0.4.6 (20299013)"
Sub-patch  19769489; "Database Patch Set Update : 11.2.0.4.5 (19769489)"
Sub-patch  19121551; "Database Patch Set Update : 11.2.0.4.4 (19121551)"
Sub-patch  18522509; "Database Patch Set Update : 11.2.0.4.3 (18522509)"
Sub-patch  18031668; "Database Patch Set Update : 11.2.0.4.2 (18031668)"
Sub-patch  17478514; "Database Patch Set Update : 11.2.0.4.1 (17478514)"
   Bugs fixed:
     17184721, 21538558, 16091637, 18092127, 17381384, 15979965, 18441944
     13837378, 16314254, 16731148, 17835048, 13558557, 17201159, 17853498
     17246576, 18356166, 18440047, 18681862, 16875449, 19788842, 17296856
     21330264, 14010183, 17648596, 17551063, 17025461, 17267114, 22507210
     17912217, 17889583, 18202441, 17040764, 16524926, 17478145, 19358317
     22148226, 18747196, 18641419, 17036973, 17811789, 14285317, 16542886
     18009564, 16618694, 8322815, 16692232, 18247991, 22507234, 17570240
     17848897, 17441661, 14034426, 17465741, 16596890, 17437634, 20506706
     21343897, 21453153, 18339044, 22321741, 17951233, 18430495, 21787056
     22380919, 20506715, 17811429, 19721304, 18230522, 19554106, 19458377
     6599380, 17612828, 22092979, 22321756, 17040527, 17811438, 18641461
     14657740, 13364795, 21387964, 17346671, 17588480, 18235390, 17889549
     19309466, 16472716, 20596234, 18331850, 18641451, 17344412, 21179898
     17546761, 18203835, 18964939, 18203838, 18203837, 17313525, 22195457
     18139690, 22296366, 14106803, 16837842, 17842825, 22657942, 21352646
     20657441, 16360112, 22195441, 17389192, 14565184, 17205719, 14354737
     22195448, 14764829, 13944971, 16571443, 21868720, 17186905, 17080436
     18673342, 17027426, 19972569, 19972568, 19972566, 17282229, 19972564
     16870214, 19615136, 17390431, 18762750, 16613964, 18098207, 17957017
     18471685, 19730508, 21538485, 18264060, 17323222, 17754782, 17600719
     18317531, 17852463, 17596908, 17655634, 20074391, 16228604, 19972570
     18996843, 19854503, 16042673, 17835627, 20334344, 18000422, 20861693
     17393683, 17551709, 20506699, 19006849, 18456514, 18277454, 17258090
     17174582, 17242746, 16399083, 17824637, 17762296, 17397545, 16450169
     12364061, 20067212, 18856999, 19211724, 19463893, 21343775, 19463897
     17853456, 18673304, 20004021, 21668627, 16194160, 17477958, 16538760
     12982566, 20296213, 18293054, 17610798, 19699191, 18135678, 17311728
     16785708, 10136473, 17786518, 18315328, 18334586, 12747740, 19032867
     18096714, 17390160, 17232014, 16422541, 18673325, 18155762, 14015842
     19827973, 22683225, 17726838, 18554871, 23177648, 18051556, 20803583
     18282562, 17922254, 15990359, 21972320, 16855292, 16668584, 21343838
     20299015, 17446237, 18093615, 17694209, 17288409, 17274537, 13955826
     16934803, 17634921, 17501491, 16315398, 22683212, 17006183, 13829543
     18191164, 17655240, 19393542, 18384391, 21538567, 16198143, 21847223
     17892268, 20142975, 19584068, 17165204, 18508861, 21756699, 16901385
     18554763, 18189036, 17443671, 17385178, 17936109, 14829250, 20925795
     17478514, 16850630, 13951456, 16595641, 15861775, 14054676, 16912439
     17299889, 17297939, 18619917, 16833527, 17798953, 17816865, 18607546
     17571306, 21286665, 17341326, 17851160, 20558005, 17586955, 19049453
     21051840, 17587063, 16956380, 18328509, 14133975, 18061914, 21051833
     18522509, 18765602, 18199537, 17332800, 13609098, 18384537, 22502493
     14338435, 17945983, 21067387, 16392068, 17752995, 21051862, 17237521
     16863422, 18244962, 19544839, 24433711, 17156148, 18973907, 17877323
     17449815, 18180390, 17088068, 17037130, 20004087, 19466309, 11733603
     18084625, 21051858, 18674024, 21051852, 18091059, 16306373, 18306996
     19915271, 18193833, 17787259, 20631274, 16344544, 14692762, 18614015
     17346091, 18228645, 17721717, 18436307, 11883252, 21756677, 17891943
     22353199, 16384983, 19121551, 12816846, 17982555, 17761775, 22243719
     17265217, 17071721, 16721594, 21756661, 18262334, 15913355, 17891946
     17672719, 17602269, 17239687, 17042658, 17238511, 17811456, 17284817
     17752121, 17394950, 16579084, 17011832, 22195465, 14602788, 18325460
     24476265, 24476274, 12611721, 16903536, 17006570, 16043574, 18783224
     16494615, 21526048, 19197175, 16069901, 17811447, 17308789, 22195477
     17865671, 19013183, 17343514, 18316692, 17325413, 16180763, 17348614
     14368995, 21983325, 17393915, 16285691, 20331945, 17883081, 24316947
     17705023, 17614227, 22195485, 14084247, 13645875, 16777840, 19727057
     14852021, 18744139, 18674047, 17716305, 18482502, 19289642, 17622427
     22195492, 14458214, 18723434, 17767676, 19258504, 17786278, 17082983
     21351877, 13498382, 18331812, 16065166, 18031668, 22893153, 16943711
     21517440, 17649265, 13866822, 18094246, 24528741, 14245531, 17783588
     17082359, 20448824, 18280813, 23330119, 16268425, 17302277, 18018515
     17215560, 19271443, 17016369, 20777150, 23330124, 20441797, 19769489
     17545847, 18260550, 13853126, 23536835, 17227277, 9756271, 18868646
     17614134, 17546973, 19680952, 18704244, 18828868, 18273830, 17050888
     17360606, 16992075, 17375354, 12905058, 18362222, 17571039, 17468141
     18436647, 17235750, 21168487, 16220077, 16929165



--------------------------------------------------------------------------------

OPatch succeeded.

همانگونه که در خروجی بالا میبینید من ACFS, OCW, DATABASE را PSU patch کرده ام.


یک پیشنهاد:


  •  به نظر من اگر پایگاه داده شما نیاز به patch ندارد و همه چی بدرستی کار میکند بی مورد patch نکنید و اگر میخواهید patch کنید، به نظر من بهترین patch PSU هست چون شامل تمامی one-off ها هست که ناسازگاری ندارند و SPU ها هم تا تاریخ انتشار PSU شامل میشود.


 دوستان عزیز امیدوارم مطلب کاربردی بوده باشد.

شاد و پیروز باشید.





پارتیشن بندی آنلاین یک جدول با dbms_redefinition

redefinition
اگر شما بخواهید در سایت عملیاتی یک جدول که مدام زیر بار هست رو تغییر ساختار بدید، ۲ راه دارید یا downtime بدید یا از پکیج dbms_redefinition استفاده کنید. خوب پس با من هراه باشید تا با 100% availability تغییرات رو انجام بدیم.

تغییرات ساختار هر چیزی میتواند باشد، در اینجا قصد داریم یک heap table را به partitioned table بدون downtime همراه با dml کاربران تغییر ساختار بدیم.

  • چون این کار را برای تست انجام میدهیم اول یک یوزر معمولی می سازیم و دسترسی های مورد نیاز رو به آن میدهیم:
create user masoud account unlock identified by masoud quota unlimited on users;
grant create table, create session to masoud;
grant create sequence to masoud;

  • حال با آن کاربر متصل شده و یک جدول معمولی ایجاد میکنیم و آن را با ۵۰،۰۰۰ رکورد پر میکنیم:
create sequence masoud_seq;

create table mytab (
id  number(20),
cdate date
);

begin
  for i in 1..1000 loop
    for j in 1..50 loop
      insert into mytab values (masoud_seq.nextval, sysdate + i);
    end loop;
  end loop;
  commit;
end;
/

تا الان ما یک جدول داریم به نام mytab که پارتیشن شده نیست و از الان به بعد با دستورات dbms_redefinition میخواهمیم آن را در حالی که کاربران حال query زدن و اجرای DML هستند به یک جدول پارتیشن شده تیدیل کنیم.

  • اول بررسی میکنیم ببینیم جدول جاری میتواند از تکنیک dbms_redefinition استفاده کند یا خیر :
 select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE    11.2.0.4.0      Production
TNS for Linux: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Production

begin
DBMS_REDEFINITION.CAN_REDEF_TABLE(
  UNAME => 'MASOUD',
  TNAME => 'MYTAB',
  OPTIONS_FLAG => DBMS_REDEFINITION.CONS_USE_ROWID
);
end;
/

PL/SQL procedure successfully completed.
همانگونه که میبینید خروجی با مشکلی رو به رو نشد و error هم نداشتیم پس جدول رو میتوانیم به صورت online تغییر ساختار بدیم. یک نکته در مورد CONS_USE_ROWID هست اون هم اینکه جدول یا باید دارای primary key باشد یا اگر نیست از تکنیک فوق استفاده کنید. درصورتی که این option رو انتخاب نکنید توی روال با مشکل رو به رو میشوید.
  • در این مرحله یک جدول با ساختار partition شده میسازیم که میخواهیم جدول mytab به شکل آن باشد:
create table interim (
id  number(20),
cdate date
)
partition by range(cdate) interval (numtodsinterval(1,'day'))
(PARTITION "P1"  VALUES LESS THAN (TO_DATE(' 2017-05-06 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')));

جدول جاری من در حال حاضر ۵۰،۰۰۰ رکورد داد. پارتیشن های من در ساختار جدید هرکدام ۵۰ رکورد دارد، اگر query ها ای که به سمت پایگاه داده می آید table full scan باشد و اگر ما دنبال یک رکورد خاص با جستجو روی cdate باشیم احتمال partition pouring  بسیار زیاد است و سرعت اجرای query به مراتب بیشتر خواهد بود.


  • خوب حال شروع به انجام redefinition میکنیم:
BEGIN
DBMS_REDEFINITION.START_REDEF_TABLE
 (uname=>'MASOUD',
 orig_table=>'MYTAB',
 int_table=>'interim',
 options_flag=>DBMS_REDEFINITION.CONS_USE_ROWID);
end;
/

PL/SQL procedure successfully completed.
اگر این مرحله بسیار زمان بر بود بهتره که SYNC_INTERIM_TABLE گهگاه اجرا کنیم تا در مرحله  FINISH_REDEF_TABLE زمان lock کمتری داشته باشیم.

  • در این مرحله وابستگی ها و object های مرتبط را به جدول interim میدهیم:
vari p_errors number;

BEGIN
DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS
 (uname=>'MASOUD',
 orig_table=>'MYTAB',
 int_table=>'INTERIM',
 num_errors=>:p_errors);
END;
/

PL/SQL procedure successfully completed.

SQL> print p_errors;
P_ERRORS
----------
0
در صورتی که روال بالا به مشکل رو به رو شده باشد p_errors مقدار خواهد داشد، که الان مشکلی را نشان نمیدهد.

  • تا الان جدول mytab بصورت قلبی پابرجاست و حدول interim پارتیشن شده است و اطلاعات mytab در درون آن کپی شده است.
SQL> select table_name from user_part_tables;

TABLE_NAME
------------------------------
INTERIM

  • درصورت مشکل در هرکدام از مراحل فوق  با دستور زیر فرایند redefinition را متوفق نمایید:
begin
  DBMS_REDEFINITION.ABORT_REDEF_TABLE
  (
    UNAME=>'MASOUD',
    ORIG_TABLE=>'MYTAB',
    INT_TABLE=>'interim');
end;
/

PL/SQL procedure successfully completed.
  • و این هم آخرین مرحله از redefinition:
begin
dbms_redefinition.finish_redef_table
 (uname=>'MASOUD',
 orig_table=>'MYTAB',
 int_table=>'INTERIM');
end;
/

PL/SQL procedure successfully completed.
در این مرحله اسم جداول با یکدیگر جابجا شده و DML ها به صورت واقعی جدول با ساختار جدید را تحت تاثیر قرار میدهد.

  • در نهایت بررسی میکنیم ببینیم جدول پارتیشن شده است یا خیر:
select table_name,partitioning_type from user_part_tables;

TABLE_NAME                     PARTITION
------------------------------ ---------
MYTAB                          RANGE

select count(1) as cnt from user_tab_partitions;

       CNT
----------
      1001

select index_name,table_name from user_indexes;

INDEX_NAME                     TABLE_NAME
------------------------------ ------------------------------
MYTAB_ID_PX                    MYTAB
TMP$$_MYTAB_ID_PX0             INTERIM


دوستان عزیز امیدوارم مطلب کاربردی بوده باشد.

شاد و پیروز باشید.