RAC CR 블록 리시브 타임에 따른 점검사항

1. AVR CR BLOCK RECEVIE TIME < 15ms 


한 Node에서 다른 Node의 데이터를 무결성 읽기를 하기 위해서 기다리는 

시간을 의미 하며 정상적인 경우 15ms보다 작아야 하고, 만약 시간이 많이 

걸리는 경우는 다음과 같은 사항들을 점검해서 문제를 해결해야 한다.


(1) 각 Node의 CPU 부하가 심하거나, CPU 용량이 부족한지 점검 함 

(2) 각 Node간 네트웍 성능에 문제가 없는지 점검 함 

(3) 각 Node간 불필요한 데이터 이동이 많게 데이터 구성이나 SQL이 

수행되는지 확인 함 


SQL> 

select b1.inst_id,

b2.value "CR BLOCKS RECEIVED",

b1.value "CR BLOCK RECEIVE TIME",

((b1.value/b2.value)*10)"AVG CR BLOCK RECEIVE TIME (ms)"

from gv$sysstatb1, gv$sysstatb2

where b1.name = 'globalcache crblock receive time'

and b2.name = 'globalcache crblocksreceived'

and b1.inst_id = b2.inst_id ;


2. GLOBAL CACHE LOCK GET TIME < 20ms 


RAC 환경에서 Cache에 있는 LOCK을 획득하기 위해서 걸리는 시간이 

정상적인 경우 20ms 보다 작아야 하며, 이보다 큰 경우가 자주 발생하는 

경우 이를 해결하기 위해서 다음과 같은 사항들을 점검해야 한다. 


(1) 서로 다른 Node에서 동일 DB Objects를 자주 Access해서 발생하는 

Application Lock이 심한지 점검 함 

(2) 각 Node간 네트웍 성능에 문제가 없는지 점검 함 

(3) 각 Node의 CPU 부하가 심하거나, CPU 용량이 부족한지 점검 함 


SQL> 

select b1.inst_id,

(b1.value + b2.value)"GLOBAL LOCK GETS",

b3.value "GLOBAL LOCK GET TIME",

(b3.value /(b1.value + b2.value)*10)"AVG GLOBAL LOCK GET TIME (ms)"

from gv$sysstatb1,gv$sysstatb2,gv$sysstatb3

where b1.name = 'globallock sync gets'

and b2.name = 'globallock async gets'

and b3.name = 'globallock gettime'

and b1.inst_id = b2.inst_id

and b2.inst_id = b3.inst_id;


RAC 환경에서는 1,2 번을 주기적으로 점검하여 결과치가 적정한 범위를 벗어

나는지 아닌지 모니터링을 하는 것이 바람직하다.

ORA-03137: TTC protocol internal error : [12333] [4] [195] [2] [] [] [] []

ORA-03137: TTC protocol internal error : [12333] [4] [195] [2] [] [] [] []


_optim_peek_user_binds Parameter 변경

1. 에러현상

▶ Forms 화면 쿼리 시 Ora-03114 not connected to oracle 에러 발생.

 

2. 체크사항

2.1 DB 서버 alert 파일 확인

▶ 파일

alert.log

▶ 에러

 ORA-03137: TTC protocol internal error

2.2 DB 서버 trace 파일 확인

▶ora_9896_i184522.trc

▶ 내용 생략.

2.3  메타링크

     ▶ 오라클 메타링크에서 ORA-03137를 검색하니 다음과 같은 버그가 알려져 있음.

Bug 9703463  ORA-3137 [12333] or ORA-600 [kpobav-1] When Using Bind Peeking

This note gives a brief overview of bug 9703463.
The content was last updated on: 17-SEP-2011
Click here for details of each of the sections below.

Affects:
Product (Component)
   
Oracle Server (Rdbms)
Range of versions believed to be affected
   
Versions >= 11.1 but BELOW 12.1
Versions confirmed as being affected

    11.2.0.1
    11.1.0.7

Platforms affected
   

Generic (all / most platforms affected)

Fixed:

This issue is fixed in
   

    12.1 (Future Release)
    11.2.0.2 (Server Patch Set)
    11.2.0.1 Bundle Patch 12 for Exadata Database
    11.1.0.7.8 Patch Set Update
    11.2.0.1 Patch 8 on Windows Platforms
    11.1.0.7 Patch 37 on Windows Platforms

Symptoms:
·         
·         Error May Occur
·         Internal Error May Occur (ORA-600)
·         ORA-3137
·         ORA-600 [kpobav-1]
·         Stack is likely to include kxsPeekBind

Description
               Frequent errors like ORA-3137 [12333] are raised. If the patch for bug:9243912
               has been applied, you will see ORA-600 [kpobav-1] errors.
 
               Rediscovery Notes:
              Optimizer bind peeking in use
              The call stack includes "kpobav opibvg kxsPeekBinds kkscsCompareBinds"

              See note:1243836.1 for a detailed description of the diagnostics

     Workaround

              Disable bind peeking by setting:
              SQL> alter system set "_optim_peek_user_binds"=false;

3. 조치사항

11.2.0.2 (Server Patch Set) 또는 11.2.0.1 Patch 6 on Windows Platforms 버전으로
패치를 해야 하나 할 수 없는 상황이므로 권고한 바 대로 옵티마이저 히든 파라매터 변경 함.
ALTER SYSTEM SET _optim_peek_user_binds=FALSE

4. 조치이후
  현재까지 alert파일에 에러가 기록되지 않았으며, forms 조회시에도 에러 없음.

5. 참고사항 
http://wiki.ex-em.com/index.php/OPTIM_PEEK_USER_BINDS
파라매터명 : _OPTIM_PEEK_USER_BINDS
기본값    :  TRUE
출시버전  :  9.0.1
Scope    :  Instance/Session

Bind Variable Peeking (이하 BVP. 바인드 변수 엿보기) 기능을 활성화할지의 여부를 결정한다.
BVP란 Bind 변수를 포함한 SQL 문장에 대한 최적화 작업을 수행할 때, Bind 변수가 가리키는 값을
참조하는 것을 의미한다.
Oracle은 BVP를 통해 SQL 문장이 실행될 당시의 Bind 값을 이용하기 때문에 최적의 실행 계획을
수립할 수 있다.
BVP를 사용할 경우 Explain Plan 명령문을 통해서 확인한 실행 계획(Execution Plan)이 실제 운영
환경에서는 적용되지 않을 수 있다. Explain Plan 명령문에서는 BVP가 적용되지 않기 때문에 BVP가
적용된 런타임의 실행 계획과는 다른 실행 계획을 보고할 가능성이 있다.

만일 테스트 환경에서 성공적으로 수행된 SQL 문장이 런타임에 느린 성공을 보인다면 일차적으로
BVP에 의한 사이드 이펙트가 아닌지 검증해보아야 한다. 런타임의 실행 계획은 V$SQL_PLAN 뷰를 통해 확인 가능하다.



ORA-20011: Approximate NDV failed: ORA-29913: error in executing ODCIEXTTABLEOPEN callout

 Alert log File information:

DBMS_STATS: GATHER_STATS_JOB encountered errors.  Check the trace file.
Errors in file /u01/app/oracle/admin/testdb/diag/rdbms/testdb/testdb/trace/testdb_j000_22426.trc:
ORA-20011: Approximate NDV failed: ORA-29913: error in executing ODCIEXTTABLEOPEN callout
KUP-11024: This external table can only be accessed from within a Data Pump job.

Trace File Information:

*** 2015-03-26 08:30:18.342
DBMS_STATS: GATHER_STATS_JOB: GATHER_TABLE_STATS('"OPS$ORACLE"','"ET$016FA3770001"','""', ...)
DBMS_STATS: ORA-20011: Approximate NDV failed: ORA-29913: error in executing ODCIEXTTABLEOPEN callout
KUP-11024: This external table can only be accessed from within a Data Pump job.


Cause:
The primary cause of this issue is that an external table existed at some point in time but does not now. However, the database still believes the table exists since the dictionary information about the object has not been modified to reflect the change. When DBMS_STATS is run against the table in question, it makes a call out to the external table which fails because the object is not there.

There are many reasons that an external table may not exist including:
1. Temporary Data pump external tables have not been cleaned up properly. The dictionary information should have been dropped when the DataPump jobs completed.
2. An External table has been removed without clearing up the corresponding data dictionary information. For example: Oracle Demo Schema Tables such as the external table “SALES_TRANSACTIONS_EXT” may have been removed but the dictionary has not been updated to reflect this. The "SALES_TRANSACTIONS_EXT" table is an external table in the "SH" schema which is one of Demo Schema provided by Oracle.

Note:Our issue is due to point one. External tables are not cleaned properly.

Solutions:  To clean up the Orphaned datapump jobs.

Check and cleanup orphaned datapump jobs:

SELECT owner_name, job_name, operation, job_mode,state, attached_sessions FROM dba_datapump_jobs
WHERE job_name NOT LIKE 'BIN$%'
ORDER BY 1,2;


To identify the external tables.

SQL> conn / as sysdba
Connected.

SQL>
set linesize 200 trimspool on
set pagesize 2000
col owner form a30
col created form a25
col last_ddl_time form a25
col object_name form a30
col object_type form a25

select OWNER,OBJECT_NAME,OBJECT_TYPE, status,
to_char(CREATED,'dd-mon-yyyy hh24:mi:ss') created
,to_char(LAST_DDL_TIME , 'dd-mon-yyyy hh24:mi:ss') last_ddl_time
from dba_objects
where object_name like 'ET$%'
/


OWNER                          OBJECT_NAME                    OBJECT_TYPE               STATUS  CREATED                   LAST_DDL_TIME
------------------------------ ------------------------------ ------------------------- ------- ------------------------- -------------------------
OPS$ORACLE                     ET$000E4FF90001                TABLE                     VALID   16-oct-2012 13:10:15      16-oct-2012 13:10:15
OPS$ORACLE                     ET$007360190001                TABLE                     VALID   18-sep-2012 23:17:32      18-sep-2012 23:17:32
OPS$ORACLE                     ET$00F39F430001                TABLE                     VALID   16-oct-2012 13:33:10      16-oct-2012 13:33:10
OPS$ORACLE                     ET$016FA3770001                TABLE                     VALID   16-oct-2012 13:57:36      16-oct-2012 13:57:36

8 rows selected.

SQL> select owner, TABLE_NAME, DEFAULT_DIRECTORY_NAME, ACCESS_TYPE
from dba_external_tables order by 1,2
 /
OWNER                          TABLE_NAME                     DEFAULT_DIRECTORY_NAME         ACCESS_
------------------------------ ------------------------------ ------------------------------ -------
OPS$ORACLE                     ET$000E4FF90001                PRODUCT_REFRESH_DIR            CLOB
OPS$ORACLE                     ET$007360190001                PRODUCT_REFRESH_DIR            CLOB
OPS$ORACLE                     ET$00F39F430001                PRODUCT_REFRESH_DIR            CLOB
OPS$ORACLE                     ET$016FA3770001                PRODUCT_REFRESH_DIR            CLOB


To Drop the external temporary datapump tables.
SQL> drop table OPS$ORACLE.ET$000E4FF90001;
SQL> drop table OPS$ORACLE.ET$007360190001;
SQL> drop table OPS$ORACLE.ET$00F39F430001;
SQL> drop table OPS$ORACLE.ET$016FA3770001;
5.To ensure there is no datapump temporary tables.

SQL> select OWNER,OBJECT_NAME,OBJECT_TYPE, status,
to_char(CREATED,'dd-mon-yyyy hh24:mi:ss') created
,to_char(LAST_DDL_TIME , 'dd-mon-yyyy hh24:mi:ss') last_ddl_time
from dba_objects where object_name like 'ET$%'
/

no rows selected

SQL> select owner, TABLE_NAME, DEFAULT_DIRECTORY_NAME, ACCESS_TYPE from dba_external_tables order by 1,2
 /


Reference doc   1274653.1 

Oracle 11g R2 RAC Datapump error while import, ORA-31693, ORA-29913, ORA-31640, ORA-19505, ORA-27037

Oracle 11g R2 RAC Datapump error while import, ORA-31693, ORA-29913, ORA-31640, ORA-19505, ORA-27037


While importing in Oracle 11g R2 two node RAC setup on Linux machine following error occured –


ORA-31693 ****************


ORA-29913 ****************


ORA-31640 ****************


ORA-19505 ****************


ORA-27037 ****************


Cause


From 11.2, DataPump new parameter CLUSTER is introduced.

  


CLUSTER : Default=Y


Purpose :

 Determines whether Data Pump can use Oracle Real Application Clusters (RAC) resources and start workers on other Oracle RAC instances.Syntax and Description : CLUSTER=[Y | N]



Solution


To force DataPump to use only the instance where the job is started and to replicate pre-Oracle Database 11g release 2 (11.2) behavior, specify CLUSTER=N.


Example:


#> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr_clus%U.dmp CLUSTER=N PARALLEL=3




Above Cause and Action is available in the metalink note :


Cannot Run DataPump With PARALLEL > 1 On 11.2 RAC [ID 1071373.1]

ORA-1688: unable to extend table SYS.WRH$_ACTIVE_SESSION_HISTORY

주의: 여기에 사용된 스크립트는 오라클에서 제공되어진 스크립트를 베이스로 작성되었으나, 사용함에 있어서 리스크가 있음을 명심해야 하며, 사용 전 자신의 DB에 맞는 정확한 내용인지 확인하시기 바랍니다.


SYSAUX에 용량은 있는데 SYS.WRH$_ACTIVE_SESSION_HISTORY 테이블를 확장 할 수 없다고 나올때 처리하는 방법입니다.



SYSAUX의 사용 내역을 확인.

SQL> select occupant_name, space_usage_kbytes from v$sysaux_occupants order by 2;

 

OCCUPANT_NAME                                                    SPACE_USAGE_KBYTES

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

AUDIT_TABLES                                                                      0

ORDIM/ORDPLUGINS                                                                  0

ORDIM/SI_INFORMTN_SCHEMA                                                          0

ULTRASEARCH                                                                       0

TSM                                                                               0

ULTRASEARCH_DEMO_USER                                                             0

STATSPACK                                                                         0

AUTO_TASK                                                                       384

ORDIM                                                                           448

EM_MONITORING_USER                                                              768

STREAMS                                                                        1024

LOGSTDBY                                                                       1408

JOB_SCHEDULER                                                                  1472

PL/SCOPE                                                                       1600

SQL_MANAGEMENT_BASE                                                            1728

SMON_SCN_TIME                                                                  3328

WM                                                                             3584

EXPRESSION_FILTER                                                              3712

TEXT                                                                           3840

SM/OTHER                                                                       8448

XSAMD                                                                          9024

LOGMNR                                                                        13696

ORDIM/ORDDATA                                                                 13888

SM/ADVISOR                                                                    22272

AO                                                                            39104

XSOQHIST                                                                      39104

EM                                                                            47168

SDO                                                                           76032

SM/OPTSTAT                                                                    76288

XDB                                                                          130176

SM/AWR                                                                       550336


쿼리뿐만 아니라 @?/rdbms/admin/awrinfo.sql 스크립트를 이용해 조회 가능

 

COMPONENT        MB SEGMENT_NAME - % SPACE_USED                                           SEGMENT_TYPE

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

...

ASH            19.0 WRH$_ACTIVE_SESSION_HISTORY.WRH$_ACTIVE_2469019682_0          -  94%  TABLE PARTITION

ASH             3.0 WRH$_ACTIVE_SESSION_HISTORY_PK.WRH$_ACTIVE_2469019682_0       -  79%  INDEX PARTITION

RAC             8.0 WRH$_DLM_MISC.WRH$_DLM_MI_2469019682_0                        -  93%  TABLE PARTITION


해당 문제관한 자료는 아래 문서에서 찾을 수 있음.
AWR Data Uses Significant Space in the SYSAUX Tablespace (Doc ID 287679.1)

해당 쿼리를 통해 ASH ROW를 확인할수 있다.

SELECT COUNT(1) Orphaned_ASH_Rows
FROM wrh$_active_session_history a
WHERE NOT EXISTS
(SELECT 1
FROM wrm$_snapshot
WHERE snap_id = a.snap_id
AND dbid = a.dbid
AND instance_number = a.instance_number
);

ORPHANED_ASH_ROWS

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

            62819


해당 예제에는 row가 몇개 없지만 이 것이 굉장히 많을 경우...
아래 쿼리를 이용해서 공간을 정리 할 수 있다.

DELETE
FROM wrh$_active_session_history a
WHERE NOT EXISTS
 (SELECT 1
 FROM wrm$_snapshot
 WHERE snap_id = a.snap_id
 AND dbid = a.dbid
 AND instance_number = a.instance_number
 );
alter table WRH$_ACTIVE_SESSION_HISTORY shrink space; 


위 과정은 단지 정리를 통해 해결 하는 방법으로, 패치를 하지 않으면 지속적으로 발생 할 수 있음.

아래와 같은 스크립트로 문제가 발생하는 것에 대한 추적 로그를 남길수 있는데, 각자의 DB에 맞게 수정해서 사용.



spool ash_purge_job.lst
prompt 2013/10/28 by Jed S. Walker
prompt This procedure is to handle an 11.2.0 bug that results in orphaned records in wrh$_active_session_history
prompt this procedure runs against SYS data so be careful.
prompt As a pre-caution it should not run as the SYS user
prompt Due to this the procedure generates a trace file on completion so that there is
prompt something available to make sure it isn't totally forgotten.
prompt
prompt Hit Enter to continue
prompt
accept continue

-- Do user level stuff
whenever sqlerror exit
accept running_user prompt "Enter the name of the user that will own/run this job: "
accept running_pwd prompt "Enter the password for user &&running_user : "
-- grant necessary privileges only
connect / as sysdba
grant select on sys.wrm$_snapshot to &&running_user;
grant select,delete on wrh$_active_session_history to &&running_user;
grant execute on dbms_system to &&running_user;
-- get password, connect, and install
spool off
connect &&running_user/&&running_pwd
spool ash_purge_job.lst append
whenever sqlerror continue

-- create the procedure
create procedure clean_ash
is
 v_proc_name varchar2(35):='clean_ash';
 v_user_name varchar2(35):='&&running_user';
 v_commit_size number:=10000;
 v_commit_count number;
 v_total_count number;
 v_notes varchar2(4000);
begin
 v_total_count:=0; --initialize
 loop
 DELETE
 FROM sys.wrh$_active_session_history a
 WHERE NOT EXISTS (SELECT 1
 FROM sys.wrm$_snapshot
 WHERE snap_id = a.snap_id
 AND dbid = a.dbid
 AND instance_number = a.instance_number
 )
 and rownum <= v_commit_size;
 v_commit_count:=sql%rowcount;
 commit;
 v_total_count:=v_total_count+v_commit_count;
 if v_commit_count = 0 then
 exit; -- end loop for now
 end if;
 end loop;
 -- write a note for the trace file
 v_notes:=''; -- start variable
 v_notes:=v_notes || 'Written by Jed S. Walker October 28th, 2013 ' || chr(10);
 v_notes:=v_notes || 'WARNING! The author of this script has no liability for any damage caused by your use of this script.' || chr(10);
 v_notes:=v_notes || 'Please reference MOS ID 387914.1' || chr(10);
 v_notes:=v_notes || 'This is a trace file from an automated job running ' || v_user_name || '.' || v_proc_name || chr(10);
 v_notes:=v_notes || 'This job removes orphaned records in WRH$_ACTIVE_SESSION_HISTORY due to an Oracle 11.2.0.x bug' || chr(10);
 v_notes:=v_notes || 'You should make sure the bug still applies if you continue to run this job in releases above 11.2.0.3 ' || chr(10);
 v_notes:=v_notes || 'If your SYSAUX tablespace, specifically component SM/AWR, has grown too large for comfort, you should run' || chr(10);
 v_notes:=v_notes || 'alter table WRH\$_ACTIVE_SESSION_HISTORY shrink space;' || chr(10);
 v_notes:=v_notes || 'to recover the space after this script has cleaned out the orphaned records.' || chr(10);
 v_notes:=v_notes || '' || chr(10);
 v_notes:=v_notes || '' || chr(10);
 if v_total_count = 0 then
 v_notes:=v_notes || 'ORA-20444: This run removed ' || v_total_count || ' orphaned records.' || chr(10);
 v_notes:=v_notes || 'If the count remains zero for several days, then chances are' || chr(10);
 v_notes:=v_notes || 'you are on a version higher than 11.2.0.3 and this bug may have been fixed.' || chr(10);
 v_notes:=v_notes || 'Verify the bug fix and if good then you should remove this job to avoid any unintended consequences.' || chr(10);
 else
 v_notes:=v_notes || 'This run removed ' || v_total_count || ' orphaned records.' || chr(10);
 v_notes:=v_notes || 'It appears the bug is not fixed so you should continue to let this run unless Oracle Support recommends otherwise.' || chr(10);
 v_notes:=v_notes || 'Have a great day!' || chr(10);
 end if;
 -- create the trace file
 sys.dbms_system.ksdwrt(1,v_notes);
exception
 when others then
 v_notes:=v_notes || 'ORA-20445: ' || v_user_name || '.' || v_proc_name || ' failed.' || chr(10);
 v_notes:=v_notes || 'Oracle error "' ||SQLERRM|| chr(10);
 sys.dbms_system.ksdwrt(1,v_notes);
end clean_ash;
/
show errors
-- create the job to run once per day so table never grows too big
begin
 dbms_scheduler.create_job(job_name=>'CLEAN_ASH_JOB',
 job_type=>'STORED_PROCEDURE',
 job_action=>'clean_ash',
 number_of_arguments=>0,
 repeat_interval=>'FREQ=Daily;BYHOUR=12;BYMINUTE=0',
 enabled=>true,
 comments=>'Special job to mitigate MOS ID 387914.1 in Oracle 11.2.0.3.x, see trace files for notes.');
end;
/
-- verify
set pages 50 linesize 120
col owner format a20
col object_type format a20
col object_name format a20
col status format a20
select owner, object_type, object_name, status from dba_objects where object_name in ('CLEAN_ASH','CLEAN_ASH_JOB');

prompt Done, please check for errors
prompt You are currently logged in as:
show user
spool off 



만약 RAC에서 사용하길 원한다면 각각의 노드에서 한번씩 사용.

또는 아래 쿼리를 이용해서 job 스케쥴러를 확인

select log_date, owner, job_name, status, error#, actual_start_date,run_duration, instance_id
from dba_scheduler_job_run_details
where job_name = 'CLEAN_ASH_JOB'
order by actual_start_date;


ORA-38029 : object statistics are locked

원인: object statistics are locked. It turns out that in 10gR2, when you import (imp or impdp) table without data i.e. structure only, oracle will lock the table statistics.


lock 확인


SQL> select table_name, stattype_locked from dba_tab_statistics where owner = '계정' and stattype_locked is not null;


SQL> exec DBMS_STATS.UNLOCK_TABLE_STATS('owner','table name');


테이블이 너무 많은 경우


SQL> set head off

SQL> set feedback off

SQL> set pages 100

SQL> set line 200


SQL> spool unlock_tb.sql


SQL> select 'exec DBMS_STATS.UNLOCK_TABLE_STATS ('''|| owner ||''','''|| table_name ||''');' from dba_tab_statistics where owner = '계정' and stattype_locked is not null;


SQL> spool off


해서 생성 되는 스크립트를 돌려준다.

ORA-00018: maximum number of sessions exceeded

Session Full 해결 방안

ORA-00018: maximum number of sessions exceeded


세션의 상태 확인방법
sql문 : select * from v$resource_limit
         // 세션과 프로세스를 확인할 수 있다.

  processes : 프로세스 개수(백그라운드 + dedicate process)

  session : 동시 접속 세션 수

  current_utilization : 현재 접속 카운트

  max_utilization : 오라클을 시작한 이래로 최대로 접속 했을 때의 수치

  initial_allocation : init.ora 파라미터에서 설정한 수치

-----------------------------------------------------------------------------------
해결 방안

       - 오라클 재기동 하지 않는 방법

       - 오라클 재기동 하는 방법



 

* 오라클을 재기동 하지 않는 방안

 

    - 비활성중인 세션을 Kill 합니다. 근본적인 원인을 해결하는 방법은 아니나

정상화 할 수 있도록 할 수 있습니다.

           - 툴을 이용하는 방법과 쿼리를 이용하는 방법 2가지가 있습니다.

 

   1. 토드 이용 시 툴에서 session 접속하여 inactive인 세션들을 kill 합니다.

   2. 쿼리를 이용하여 해당 세션을 Kill

SQL> alter system kill session 'sid, serial#'; // 한 개 지정

 

* 예외상황 *

- alter session으로 kill이 안될 때 (ORA-00031:session marked for kill이 생길때)

  (kill을 하여도 락이 해제 되지 않는 것은 rollback하는 프로세스가 동작을 하여 kill을 해도 mark만 하고 rollback 중인 상태이므로 락이 풀렸다고 볼 수 없기 때문입니다. 어느 정도 시간을 갖고 기다리면, 결국 테이블 락이 해제는 됩니다.)

 

다음 쿼리를 이용하여 pid를 찾아서 서버에서 직접 kill 을 합니다.

SQL>  select vs.sid, vs.username, vs.osuser, vs.process fq_pid, vp.spid bg_pid

from v$session vs, v$process vp

where vs.paddr = vp.addr

order by sid;

오라클 서버 계정에서 kill -9 [bg_pid]

 

* 오라클을 재기동 하는 방안

 

    - 오라클을 재기동해야 하는 단점이 있으나 근본적인 해결방안이 될 수 있습니다.

    - 관련 파일은 init.ora 또는 spfile[SID].ora 입니다.

          오라클 기동 시 spfile[SID].ora 파일을 보고 환경 셋팅을 하여 기동하게 됩니다.

          이 파일이 없으면 기본 파일인 init.ora 이 사용됩니다.

 

1. 쿼리를 이용하여 세션의 수를 수정한 뒤 오라클 재기동

SQL> alter system set processes=[지정하고 싶은 수] scope=spfile;

SQL> alter system set open_cursors=[지정하고 싶은 수] scope=both;

ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O

ORA-27090:  Unable to reserve kernel resources for asynchronous disk I/O


Linux 에서 발생하는 에러로 aio limit 제한에 걸렸을때 나오는 에러 메세지.


Cause:  The system call to reserve kernel resources for asynchronous I/O has failed.

   -> 비동기 I/O를 위한 커널 리소스예약 할 수 있는 시스템 호출에 실패.

-> Disk I/O에 제한이 걸려 DB의 성능 저하 발생.

 

Solution:  /etc/sysctl.conf 수정 후 적용


다음 파라미터 값 추가


fs.aio-max-nr = 3145728

 

저장 후 Shell 에서 다음 명령 실행.

 

# sysctl –p

 

재부팅 필요 없음.