روشهای متوقف کردن job مربوط به export

برای متوقف کردن یک job در حال اجرا در export data pump به دو روش زیر می توان عمل کرد:

1-ابتدا از view زیر وضعیت jobها به همراه نامشان را مشاهده کنید:

select * from dba_datapump_jobs

سپس job مورد نظر که در وضعیت executing می باشد را جستجو کنید.

SYS SYS_EXPORT_FULL_01 EXPORT FULL EXECUTING

پس از مشاهده job_name باید با دستور زیر وارد محیط export data pump شوید:

oracle@dbserver ~]$ expdp system/manager attach=SYS_EXPORT_FULL_01]

پس از مشاهده مشخصات باید job را بصورت زیر متوقف کنید:

Export> KILL_JOB

Are you sure you wish to stop this job ([yes]/no): yes

[oracle@dbserver ~]$

روش دیگر استفاده از دستور زیر در محیط sql است:

SQL> DECLARE

h1 NUMBER;

BEGIN

h1:=DBMS_DATAPUMP.ATTACH(‘SYS_EXPORT_FULL_01‘,’SYSTEM‘);

DBMS_DATAPUMP.STOP_JOB (h1,1,0);

END;

/

ALTER TABLE...SPLIT PARTITION

 

ALTER TABLE...SPLIT PARTITION

از دستور فوق برای تقسیم یک پارتیشن به دو پارتیشن استفاده می شود و محتویات پارتیشن اول را در دو پارتیشن جدید منتقل  می کند.این دستور فقط  در جداول حاوی range partition و list partition قابل استفاده است (و نمی توان برای hash partiotion استفاده کرد).فرم نوشتاری دستور به دو صورت است:

فرم اول جدول دارای range partition   را به دو پارتیشن تقسیم می کند:

 

ALTER TABLE table_name SPLIT PARTITION partition_name

  AT (range_part_value)

  INTO 

  (

    PARTITION new_part1

      [TABLESPACE tablespace_name],

    PARTITION new_part2 

      [TABLESPACE tablespace_name]

  );

 

فرم دوم جدول حاوی list partition را به دو پارتیشن تقسیم می کند:

 

 

ALTER TABLE table_name SPLIT PARTITION partition_name

  VALUES (value[, value]...) 

  INTO 

  (

    PARTITION new_part1

      [TABLESPACE tablespace_name],

    PARTITION new_part2 

      [TABLESPACE tablespace_name]

  );

 

مثال یک:

جدول sales را با سه پارتیشن ذیل در نظر بگیرید:

 

CREATE TABLE sales

  PARTITION europe VALUES('FRANCE', 'ITALY'),

  PARTITION asia VALUES('INDIA', 'PAKISTAN'),

(

  dept_no     number,  

  part_no     varchar2,

  country     varchar2(20),

  date        date,

  amount      number

)

PARTITION BY LIST(country)

(

  PARTITION americas VALUES('US', 'CANADA')

);

دستور زیر پارتیشن Americas را به دو پارتیشن us و Canada تقسیم می کند:

 

ALTER TABLE sales SPLIT PARTITION americas 

 VALUES ('US')

 INTO (PARTITION us, PARTITION canada);

 

 

مثال دو:

CREATE TABLE sales

(

  dept_no     number,

  part_no     varchar2,

  country     varchar2(20),

  date        date,

  amount      number

)

PARTITION BY RANGE(date)

(

  PARTITION q1_2012 

    VALUES LESS THAN('2012-Apr-01'),

  PARTITION q2_2012 

    VALUES LESS THAN('2012-Jul-01'),

  PARTITION q3_2012 

    VALUES LESS THAN('2012-Oct-01'),

  PARTITION q4_2012 

    VALUES LESS THAN('2013-Jan-01')

);

 

جدول از چهار پارتیشن زیر تشکیل شده است:

q1_2012, q2_2012, q3_2012, and q4_2012

 

دستور زیر q4_2012  را به دو پارتیشن  q4_2012_p1  و  q4_2012_p2 تقسیم می کند:

 

ALTER TABLE sales SPLIT PARTITION q4_2012

  AT ('15-Nov-2012')

  INTO 

  (

    PARTITION q4_2012_p1,

    PARTITION q4_2012_p2

  );

 

توجه : اگر tablespace جدیدی برای پارتیشنها تعریف نشود از tablespace پیش فرض استفاده می گردد.

 

 

 

 

استفاده از پارامتر version در data pump

کاربرد پارامتر version در data pump زمانیست که می خواهیم بطور مثال از اطلاعات دیتابیس اوراکل با نسخه 12، export بگیریم و در یک دیتابیس با نسخه 11، import کنیم.

  expdp user1/password dumpfile=dir1:dumpfile1.dmp logfile=dir1:logfile1.log  version=11.2

دستور ALTER SESSION ADVISE COMMIT

قبل از هر چیز به تعریف دو اصطلاح می پردازیم:

Distributed Transaction:تراکنشی که در سطح شبکه بین دو دیتابیس انجام می شود.

In-Doubt Transaction: تراکنش نیمه تمامی از نوع Distributed که وضعیت commit یا rollback آن مشخص نیست.

اگر چنین تراکنشی در دیتابیس انجام شود و به دلایلی نیمه تمام باقی بماند پس از اجرای مجدد آن هنگام COMMIT با سه خطای پی در پی به شرح زیر مواجه می شویم:

ora-02050: transaction  21.534654 rolled back,some remote DBs may be in-doubt

ora-02056: bad two phase command number rdonly from coord

ora-02063: preceding line from BANK

برای رفع مشکل می توانیم از دستورات ALTER SESSION ADVISE COMMIT یا ALTER SESSION ADVISE ROLLBACK قبل از کوئری خود استفاده کنیم.

مثال :

insert into SUPERIORCUSTS

 SELECT B.BRANCH_CODE BR,trunc(INSERT_SYSDATE) as INSERT_DATE,COUNT(*) as cnt

 FROM VC.ORGANIZATION A  JOIN RP.VW_CLIENT_INFO_BANK@REMOTE B  ON A.CIF = B.EXTERNAL_REF

 WHERE B.CLIENT_TYPE = 1 and trunc(INSERT_SYSDATE) = trunc(sysdate - 1) 

 GROUP BY B.BRANCH_CODE, trunc(INSERT_SYSDATE);   

commit; 

insert انجام می شود ولی بعد از commit خطاهای مذکور را دریافت می کنیم.کافیست قبل از اجرای مجدد کوئری فوق، یک یا دو بار دستور ALTER SESSION ADVISE COMMIT را اجرا کنیم.(یا چنانچه بخواهیم تغییرات حاصل از کوئری قبل را cancel کنیم بجای commit از rollback استفاده می کنیم)

جلوگیری از SORTهای ناخواسته در دستور SQL

ممکن است گاهی متوجه عملیات مرتب سازی (SORT) در دستورات خود نشوید.SORT معمولا در موارد زیر استفاده می شود:

•       CREATE INDEX
•       GROUP BY
•       ORDER BY
•       INTERSECT
•       MINUS
•       UNION
•       DISTINCT
•       Unindexed table joins
•       Some correlated subqueries

 

ههدف شما می بایست همیشه کاهش یا حذف SORT در دستور SQL  باشد.استفاده از SORT در لایه application اتفاق می افتدبنابراین برنامه نویس باید به گونه ای دستورSQL  خود را بنویسد که از SORTهای ناخواسته جلوگیری شود.نکاتی در ذیل مطرح می شود که باید در کد ملاحظه کرد:

1-  از distinct اجتناب کنید مگر اینکه واقعا نیاز باشد.

2-  از UNION ALL به جای UNION استفاده شود مگر اینکه نیاز باشد رکوردهای مشابه حذف گردند.

3- سعی کنید از HASH JOIN بجای SORT_MERGE_JOIN استفاده شود.ضمنا استفاده از HINTها باعث می شود OPTIMIZER از INDEX HINT های مناسب استفاده کند تا از SORTها جلوگیری شود.مثلا cost based optimizer  از عملیات SORT اجتناب می کند وقتیکه FIRST_ROWS hint استفاده شود.

4-  از مناسبترین ایندکسها در کد خود استفاده کنید.

چنانچه در مانیتورینگ با مشکلاتی ناشی از SORT مواجه شدید افزایش مقدار پارامتر SORT_AREA_SIZE متناظر با میزان کل فضای حافظه قابل ملاحظه است.

دستور Recover database until available redo

برای بازگردانی اطلاعات در فرآیند ریکاوری Rman پس از دستور restore database  می توانیم از دستور Recover database until available redo استفاده کنیم که از ویژگیهای اوراکل نسخه 12 می باشد.در نسخه های قبل، پس از دستور recover database ممکن بود به دلیل مواجه شدن با مشکل، ریکاوری ناتمام بماند و مجبور بودیم به محیط sqlplus سوئیچ کرده و برای اتمام فرآیند از دستور recover database using backup controlfile until cancel استفاده کنیم ویا متناظر با archivefile دچار مشکل از عبارت until time و یا until sequence استفاده کنیم.اما در نسخه 12cR2 پس از اجرای دستور Recover database until available redo فرآیند ریکاوری بطور اتوماتیک تا آخرین log موجود انجام می شود و از بروز خطاهای RMAN-06053: unable to perform media recovery because of missing log و(بطور مثال) RMAN-06025: no backup of archived log for thread 1 with sequence 1 and starting SCN of 543788891 found to restore جلوگیری می شود.

برخی اصطلاحات موجود در RAC

Cache Fusion

مکانیزمی در رک که بلاکها  از حافظه یک instance به حافظه instance دیگری کپی می شود. هنگامیکه یک user process بدنبال بلاکهایی برای انجام عملیات مورد درخواست کاربر می باشد ممکن است بلاکهای مورد نیاز در حافظه ی نود دیگری موجود باشد که در این مکانیزم با دسترسی به buffer cache نود دیگر  پاسخگویی به فرآیند موجود تسریع می گردد.ضمنا در این مکانیزم از تداخل فرآیندهای مربوط به کاربران و دستورات sql جلوگیری می شود.

 (Global Cache Service (GCS

پروسسی که cache fusion را پیاده سازی می کند و مسئول انتقال بلاکها مابین instanceها می باشد.

 Voting disk

یک فایل است که اطلاعاتی را مورد node ها ارائه می کند.Oracle Clusterware برای اینکه مشخص کند کدام instanceها اعضای یک cluster  هستند از voting disk  استفاده می کند.Voting disk باید در shared disk ها قرار داشته باشند و توصیه می شود حداقل سه voting disk در پیکره بندی رک وجود داشته باشد.

 

(Oracle Cluster Registry (OCR

برای نگهداری و مدیریت اطلاعات در مورد کامپوننتهایی که oracle clusterware را کنترل می کنند ( مانند دیتابیسهای موجود در رک ، listener ها، VIPها، سرویسها و applicationها ) از OCR استفاده می شود.OCR می بایست در shared disk قرار داشته باشد تا توسط همه node ها در کلاستر قابل دسترسی باشد.

 

(Cluster Ready Services (CRS

CRS برنامه اصلی برای مدیریت رک جهت افزایش دسترسی به دیتابیس در کلاستر می باشد.هر چیزی که پردازه CRS مدیریت می کند بعنوان cluster resource شناخته می شود که می تواند یک دیتابیس،instance،service،listener،virtual IP address یا یک application process باشد.CRS موارد مذکور را  بر اساس اطلاعات پیکره بندیشان که در OCR ذخیره شده است ، مدیریت می کند.

(Cluster Synchronization Services (CSS

پیکره بندی کلاستر را با کنترل نودهایی که عضو کلاستر هستند مدیریت می کند و به دیگر node ها اتصال و قطعی nodeهای دیگر را اعلان می کند.

 

(Event Management (EVM

یک background process است که eventهای ایجاد شده توسط oracle clusterware را منتشر می کند.

 

(Global Dynamic Performance views (GV$

ویوهایی که اطلاعاتی را در خصوص instance های موجود در رک ارائه می کنند.

(Grid Naming Service (GNS

سرویسی برای mapping نام host ها به IP در DNS zone

(Transparent Application Failover (TAF

یکی از ویژگیهای موجود در رک  است که چنانچه اتصال مابین client applicationها  و دیتابیس قطع شود بطور خودکار reconnect انجام می گردد.

اعتبارسنجی Datafile ها و Backup ها با دستور VALIDATE

برای چک کردن corruption  در datafileها ،archivefileها ، controlfileها و spfile  می توانید از Rman استفاده نمایید.ضمنا می توانید مشخص کنید که یک backupset قابل restore می باشد یا خیر.دستور RMAN VALIDATE برای چک کردن موارد ذکر شده کاربرد دارد.

VALIDATE

BACKUP…VALIDATE

RESTORE…VALIDATE

طریقه استفاده از دستور به صورت زیر است:

Rman>validate database;

و برای اعتبارسنجی controlfile:

RMAN>validate current controlfile;

برای چک کردن آرشیو فایلها:

RMAN>validate archivelog all;

بصورت ترکیبی هم در دستور می توان چک کردن آیتمهای مختلف را بیان کرد:

RMAN>validate check logical database include current controlfile plus archivelog

تنظیم پارامتر cluster=no در export data pump

هنگام اجرای export data pump در RAC database چنانچه از پارامتر cluster استفاده نکنیم مقدار پیش فرض آن که YES می باشد در هنگام اجرا لحاظ می گردد و به این معنی است که process مربوطه از تمامی instance های موجود در RAC جهت اجرای export  استفاده می کند.اگر این پارامتر را در دستور expdp خود بصورت cluster=no استفاده کنیم به این معنی است که فقط instance ی که دستور در آن اجرا شده است مورد استفاده قرار می گیرد و در برخی موارد مزیت آن جلوگیری از cluster wait می باشد.

تبدیل select تودرتو به join برای بهبود سرعت اجرا

گاهی نیاز است برای بهبود سرعت پرس و جو ، بجای  select تو در تو از join استفاده کنیم.مثال زیر نمونه ای از این تبدیل می باشد:

 select *
  FROM emp A
  WHERE A.sal between 800 and 2000
  AND A.deptno NOT IN
 (SELECT B.deptno
  FROM dept B
  WHERE B.deptno = A.deptno
  AND B.dname = 'sales');
  //-----------------------------------
  SELECT *  
  FROM emp A
  left join dept B on B.deptno = A.deptno AND B.dname='sales'
  WHERE   A.sal between 800 and 2000
  and B.dname is null