About DATABASE

"opiino: Attach failed! error=-1 ifvp=0" written in Database UDUMP file [ID 399727.1]
		수정 날짜 10-JUN-2011     유형 PROBLEM     상태 PUBLISHED

In this Document
  Symptoms
  Changes
  Cause
  Solution
  References

---

Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.4 - Release: 10.2 to 10.2
Oracle Net Services - Version: 10.2.0.1.0 to 10.2.0.4.0   [Release: 10.2 to 10.2]
Information in this document applies to any platform.
Checked for relevance on 09-JUNE-2011

Symptoms

When a client process is abnormally disconnected from the Database (server) process, specifically at a point where the Database needs to negotiate and communicate certain OCI / TWO-TASK data to the client such as with character sets, OCI, etc., then the Database may throw one of the following errors in a UDUMP trace:

or


Changes

Perhaps an abnormally high increase in connection activity from App Servers or a network condition or change causing instability.

Cause

There are various reasons why this error might be reported by the Database and some are offered below, but it should be noted that it is "post-connection" generated meaning that the Client connection has been handed off successfully by the Listener process (shown as "Established" in the listener log and services summary) and is generated by the Database itself.

1. The error is being caused by an abnormal disconnection at the OPI / OCI (TWO-TASK) level of the Client process by the Database.
This will occur if the client is terminated (abnormally) before the Database can complete the TWO-TASK communication functions. Please see the reference note on TWO-TASK analysis and resolution.

2. Another possible cause and one that can contribute to a high increase of connections or a cause of disconnections, is a default (or lower) setting of the INBOUND_CONNECT_TIMEOUT value introduced with 10g and which was found to have a default value that was too low for many environments. Another error that might be reported in the Database alert log for the same type of abnormal disconnection and especially with 11g, is ORA-609 "opiodr aborting process unknown ospid". These two are very similar in that they are generated from the "opi" Database layer and due to an abnormal client termination (with the "ORA-609" being more common in 11g and the "Attach failed" being more common in 10g).

3. Another potential (but rare) cause is if the Listener being used for Client access is of a LOWER version than the Database being accessed. For example, using a 9.2.x listener to access a 10.x Database which is not certified or supported and will cause abnormal conditions for connections.

Solution

1. Due to the fact that this is a generic error within the Database OPI code, the error itself is not useful in determining any actual cause or in assisting to provide a solution.
Analysis needs to be done on what was happening between the clients and the Database server at the time these were thrown and which caused the failure.
Some examples of questions to ask and data to collect:
- was the network between the affected clients and the Database in a stable condition?
- was there a sudden and abnormal increase in connection activity that may have flooded the Database with connections?
- was the Client abnormally terminated on its side (such as a machine failure)?

2. To ensure that this is not related to a possible INBOUND_CONNECT_TIMEOUT issue (IBCT), make certain to set both the IBCT in the listener.ora file and sqlnet.ora file on the Database Server side (these are INBOUND CONNECT settings so only affect incoming client connections requests) to a higher value, such as 120.
Please note, that this increase in IBCT will not have a negative effect on how long a client connection will take to be established. This setting is a security feature and is a threshold used to determine how long to wait before an unresponsive connection is terminated (used specifically to prevent Denial of Service attacks on the Database). See the notes referenced for complete details.

3. If this occurs ALL the time and there is an indication that a lower version listener is used for a higher version Database, then the same (or higher) version listener should be started and used for the Database.
See reference notes following on this.

References

NOTE:1012295.102 - HOW TO SUPPORT TWO-TASK COMMON ERRORS
NOTE:149628.1 - Creating Multiple Listeners on UNIX - Including Migration or Upgrades
NOTE:151812.1 - Setting up Multiple Listeners on Windows - Including Migration or Upgrades
NOTE:345197.1 - Connections that Used to Work in Oracle 10.1 Now Intermittently Fail with ORA-3113,ORA-3106 or ORA-3136 from 10.2 Onwards
NOTE:609.1 - ORA-609 TNS-12537 and TNS-12547 in 11g Alert.log
NOTE:1121357.1 - Troubleshooting ORA-609 : opiodr aborting process unknown ospid

관련 자료 제품 Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition Oracle Database Products > Oracle Database > Net Services > Oracle Net Services 오류 ORA-609

출처 : http://blog.naver.com/gseducation/20096197660

 

Clone Database를 이용한 복구 (RMAN을 이용할 경우)

 

RMAN을 이용해서 Duplicate(clone) database를 생성할 수 있다.

오라클의 매뉴얼에 자세한 순서와 설명이 있다.

 

• Preparing the RMAN DUPLICATE Auxiliary Instance: Basic Steps

아래 영어 설명은 매뉴얼 내용을 일부 발췌한 것이다.

• By default, the DUPLICATE command creates the duplicate database from the most recent backups
  of the target database and then performs recovery to the most recent consistent point contained
  in the archived redo logs.
  
  
• You can duplicate a database as it stood at a past point in time in the current incarnation,
  by using a RUN block with a SET UNTIL command, or by including an UNTIL clause with the DUPLICATE command to cause RMAN to recover the duplicate database to a past point in time within the current incarnation.
  
  

(1) Archive 모드임을 확인한 뒤에 백업을 수행한다.

 

[oracle@ora10gr2 ~]$ export ORACLE_SID=devdb
[oracle@ora10gr2 ~]$ sqlplus / as sysdba

SQL> startup force

SQL> archive log list

Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     0
Next log sequence to archive   1
Current log sequence           1

 

SQL> exit

 

[oracle@ora10gr2 ~]$ mkdir /u01/app/oracle/oradata/devdb_rman_backup
[oracle@ora10gr2 ~]$ export ORACLE_SID=devdb

[oracle@ora10gr2 ~]$ rman target /

 

RMAN> backup database format='/u01/app/oracle/oradata/devdb_rman_backup/devdb_%d_%s_%p.bus';

RMAN> exit

 

(2) 복구 완료를 확인할 테이블 생성

 

[oracle@ora10gr2 ~]$ sqlplus / as sysdba

SQL> alter system switch logfile;
SQL> alter system switch logfile;
SQL> alter system switch logfile;
SQL> alter system switch logfile;

SQL> create table phil.t2 (col1 varchar2(20));
SQL> insert into  phil.t2 values ('Recovery done!');
SQL> commit;

 

SQL> alter system switch logfile;
SQL> alter system switch logfile;

 

SQL> -- 복구의 기준이 되는 시간이므로 잘 기억하도록 한다.

SQL> !date

 

  2009. 12. 21. (월) 23:43:47 KST

 

(3) 유저 실수로 테이블이 삭제되는 상황 연출

 

SQL> alter system switch logfile;
SQL> alter system switch logfile;

SQL> -- 장애 발생
SQL> drop table phil.t2 purge;
SQL> exit

 

(4) Clone Database를 이용한 복구 시작

Task 1: Create an Oracle Password File for the Auxiliary Instance

 

[oracle@ora10gr2 ~]$ cd
[oracle@ora10gr2 ~]$ cd $ORACLE_HOME/dbs
[oracle@ora10gr2 dbs]$ orapwd file=orapwdevdbaux password=oracle entries=5

 

 Task 2: Establish Oracle Net Connectivity to the Auxiliary Instance

 

[oracle@ora10gr2 dbs]$ cd $ORACLE_HOME/network/admin
[oracle@ora10gr2 admin]$ vi tnsnames.ora

 

devdbaux =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.10)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = devdbaux)
    )
  )

 

Task 3: Create an Initialization Parameter File for the Auxiliary Instance

 

[oracle@ora10gr2 admin]$ export ORACLE_SID=devdb
[oracle@ora10gr2 admin]$ sqlplus / as sysdba

SQL> create pfile='$ORACLE_HOME/dbs/initdevdbaux.ora' from spfile;

SQL> !mkdir /u01/app/oracle/oradata/devdbaux

SQL> !vi $ORACLE_HOME/dbs/initdevdbaux.ora

 

DB_NAME=devdbaux
CONTROL_FILES='/u01/app/oracle/oradata/devdbaux/control01.ctl'
DB_FILE_NAME_CONVERT=('/u01/app/oracle/oradata/devdb', '/u01/app/oracle/oradata/devdbaux')
LOG_FILE_NAME_CONVERT=('/u01/app/oracle/oradata/devdb', '/u01/app/oracle/oradata/devdbaux')
db_block_size=4096
sga_target=200m
pga_aggregate_target=60m

 

SQL> exit

 

Task 4: Start the Auxiliary Instance

 

[oracle@ora10gr2 ~]$ export ORACLE_SID=devdbaux
[oracle@ora10gr2 ~]$ sqlplus / as sysdba
SQL> startup force nomount
SQL> exit

Task 5: Mount or Open the Target Database

 

[oracle@ora10gr2 ~]$ export ORACLE_SID=devdb
[oracle@ora10gr2 ~]$ sqlplus / as sysdba
SQL> startup force
SQL> exit

 

Task 6: Make Sure You Have the Necessary Backups and Archived Redo Logs

 

Make sure backups all target datafiles are accessible on the duplicate host.
Archived redo logs required to recover the duplicate database to the desired point in time

must be accessible at the same path by the node where the duplicate database is to be created.

 

 Task 7: Allocate Auxiliary Channels if Automatic Channels Are Not Configured

 

[oracle@ora10gr2 ~]$ export ORACLE_SID=devdbaux
[oracle@ora10gr2 ~]$ export NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'
[oracle@ora10gr2 ~]$ export NLS_LANG=american
[oracle@ora10gr2 ~]$ rman TARGET sys/oracle＠devdb AUXILIARY /

 

RMAN> run {
 ALLOCATE AUXILIARY CHANNEL aux1 DEVICE TYPE DISK;
 DUPLICATE TARGET DATABASE TO devdbaux UNTIL TIME '2009/12/21 23:43:47';
}

 

Task 8 : 마무리

 

[oracle@ora10gr2 ~]$ export ORACLE_SID=devdbaux
[oracle@ora10gr2 dbs]$ sqlplus / as sysdba

SQL> select * from phil.t2;

 

COL1
--------------------
Recovery done!

SQL> !exp phil/phil file=t2.dmp tables=t2
SQL> exit

 

[oracle@ora10gr2 dbs]$ export ORACLE_SID=devdb
[oracle@ora10gr2 dbs]$ sqlplus phil/phil

SQL> select * from t2;

 

select * from t2
              *
ERROR at line 1:
ORA-00942: table or view does not exist

 

SQL> !imp phil/phil file=t2.dmp tables=t2
SQL> select * from t2;

 

COL1
--------------------
Recovery done!

 

 

____________________________________________________________________________________________________________________

 

참고1.

A duplicate database is a copy of a target database

that you can run independently for a variety of purposes.

 

For example, you can use it to:

 

  - Test backup and recovery procedures

  - Export data such as a table that was inadvertently dropped from the production database,

    and then import it back into the production database

 

참고2.

 

As part of the duplicating operation, RMAN automates the following steps:

 

 - Creates a control file for the duplicate database

 - Restores the target datafiles to the duplicate database and performs incomplete recovery

   by using all available incremental backups and archived redo logs

 - Shuts down and starts the auxiliary instance

 - Opens the duplicate database with the RESETLOGS option after incomplete recovery

    to create the online redo logs (except when running DUPLICATE ... FOR STANDBY,

    in which case RMAN does not open the database)

 - Generates a new, unique DBID for the duplicate database (except when you create a standby database

   with DUPLICATE ... FOR STANDBY, in which case RMAN does not create a unique DBID)

 

During duplication, RMAN must perform incomplete recovery because the online redo logs in the target are not backed up and cannot be applied to the duplicate database. The farthest that RMAN can go in recovery of the duplicate database is the most recent redo log archived by the target database.

How to Disable Asynch_io on HP to Avoid Ioctl Async_config Error Errno = 1 [ID 302801.1]

--------------------------------------------------------------------------------
 
  수정 날짜 12-MAY-2011     유형 HOWTO     상태 PUBLISHED  

In this Document
  Goal
  Solution
  References

 

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

 

Applies to:
Oracle Server - Enterprise Edition - Version: 9.2.0.1 to 11.2.0.2 - Release: 9.2 to 11.2
HP-UX PA-RISC (64-bit)
HP-UX Itanium

Goal
How to disable async_io on Oracle in HP-UX to avoid this message in trace file:
Ioctl ASYNC_CONFIG error, errno = 1
Solution
If /dev/async is present and correctly configured, Oracle (for HP only) will use it for memory locking which is needed for async i/o for SGA memory pages via ioctl.

Oracle (for HP only) opens /dev/async successfully only if the /dev/async HP-UX device driver is properly configured for read and write.

This is irrespective of whether the DISK_ASYNC_IO parameter is set to TRUE.

Problem is Oracle (for HP only) still uses async I/O regardless of the value of init settings
(disk_asynch_io=FALSE and filesystemio_options=none).
The parameter filesystemio_options=none doesn't work.

From the 9.2 until 10.1 version, to inactivate ASYNCH_IO with Oracle, the workaround is to:

chown bin:bin /dev/async
chmod 660 /dev/asyncNote: This may impact other applications that wish to use asynch I/O.
It is recommended to shutdown Oracle database before inactivating asynch I/O.

Grant dba group the MLOCK privilege to avoid the Ioctl ASYNC_CONFIG trace file errors:

(1) # /usr/sbin/setprivgrp dba MLOCK
(2) # vi /etc/privgroup
-- This should contain dba MLOCK RTSCHED RTPRIO
(3) # cat /etc/privgroup
dba MLOCK RTSCHED RTPRIO
Since the Oracle 10.2 version, the problem is resolved as these settings stop the tracing:
disk_asynch_io=FALSE
filesystemio_options=none

References

 관련 자료

 

--------------------------------------------------------------------------------
제품
--------------------------------------------------------------------------------

•Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition
키워드
--------------------------------------------------------------------------------
DISK_ASYNCH_IO; FILESYSTEMIO_OPTIONS

 

   PARAMETERS
     level - tablespace number+1. If the value is 2147483647 then
             temp segments in ALL tablespaces are dropped, otherwise, only
             segments in a tablespace whose number is equal to the LEVEL
             specification are dropped.

   NOTES
     This routine does what SMON does in the background, i.e. drops
     temporary segments. It is provided as a manual intervention tool which
     the user may invoke if SMON misses the post and does not get to
     clean the temp segments for another 2 hours. We do not know whether
     missed post is a real possibility or more theoretical situation, so
     we provide this event as an insurance against SMON misbehaviour.

     Under normal operation there is no need to use this event.

     It may be a good idea to
        alter tablespace <tablespace> coalesce;
     after dropping lots of extents to tidy things up.

 *SQL Session (if you can connect to the database):     
    alter session set events 'immediate trace name DROP_SEGMENTS level TS#+1';

     The TS# can be obtained from v$tablespace view:
     select ts# from v$tablespace where name = '<Tablespace name>';

     Or from SYS.TS$:

     select ts# from sys.ts$ where name = '<Tablespace name>' and online$ != 3;
    
     If ts# is 5, an example of dropping the temporary segments in that tablespace
     would be:

    alter session set events 'immediate trace name DROP_SEGMENTS level 6';

9i부터는 Shared_pool의 관리를 좀더 효율적으로 하고 System의 CPU를 효과적으로 사용하기 위해
하나의 heap memory를 사용하던 것을 subheap으로 나누어 관리를 하고 있다.
이렇게 sub-heap으로 나누어 관리하다 보니 작은 공간이 sub heap에 동시에 있더라도  이를 잘 활용하지 못해서 발생하는 경우가 발행할 수 있다.
이러한 이유로 ORA-4031 Error의 원인이 되는 경우가 종종 발생할 수 잇다.

현재 시스템이 Multi CPU인 경우에는 아마도 이 값이 1보다 큰 값으로 정의되어 있을 것이다..

그래서 아래의 Query로 조회해 본 후 그 값이 1보다 큰 값이라면 init.ora에서  _kghdsidx_count=1로 지정한다.

 

select x.ksppinm, y.ksppstvl from x$ksppi x , x$ksppcv y
where x.indx = y.indx and x.ksppinm like '_kghdsidx_count%' escape ''
order by x.ksppinm;

 

 

SELECT * FROM v$sqltext;
SELECT substr(sql_text, 1, 40) AS “SQL”,
count(*) AS cnt,
sum(executions) AS “TotExecs”,
sum(sharable_mem) AS mem,
min(first_load_time) AS start_time,
max(first_load_time) AS end_time,
max(hash_value) AS hash
from v$sqlarea
where executions < 5 --> 수행 횟수가 5번 이하인 것.
group by substr(sql_text, 1, 40)
having count(*) > 30 –> 비슷한 문장이 30개 이상.
order by 2 desc;
프로그램 시작 (세션 시작시)
alter session set cursor_sharing=force;
…
프로그램 작성
…
프로그램 종료 (세션 종료시)
alter session set cursor_sharing=exact;
강제로 메모리 정리
alter system flush shared_pool;
..

=======================================================================================
-----에러내용
ORA-04031: 4064 바이트의 공유 메모리를 할당할 수 없습니다 ("shared pool","select * from fm_org_chg_inf...","sga heap(2,0)","kglsim heap")

 

-----원인

Duplicate entries for SHARED_POOL_SIZE and JAVA_POOL_SIZE.

SGA_TARGET is set and also duplicate entries in parameter file found as below

"shared_pool_size" and "<SID>.__shared_pool_size"
    "java_pool_size" and "<SID>.__java_pool_size"
Upgrade fails with ORA-04031, When both SGA_TARGET and  Manual shared Memory Parameters

 

 

-----해결방안

1- Remove either of the entry of SGA_TARGET and Manual shared Memory Parameters from pfile
2- If SGA_TARGET is removed, then make sure <SID>.__parameters also removed.
3- Make sure SHARED_POOL_SIZE and JAVA_POOL_SIZE is more than 200 MB as mentioned in Note 376612.1 "ORA-04031: unable to allocate xxxx bytes of shared memory" during upgrade to 10gR2

 

---사견

SHARED_POOL_SIZE를 늘리라는 얘기를 하는데.

SGA_TARGET잡은 상태에서는 SHARED POOL, DATA CACHE는 바꿀수가 없습니다.

그렇게 할려면 SGA_TARGET라는 파라메터를 쓰지 말라는 말씀입니다..^^

다시말하면 오라클 버그라는 말이지요..망할 오라클..

 

아래 쿼리를 수행해서 DB_CACHE_SIZE,SHARED_POOL_SIZE가 SGA_TARGET 잡힌 상태에서

얼마나오는지 보고 수동으로 잡는게 좋을거 같습니다.

 

 

alter system set sga_target = 0 ;
ALTER SYSTEM SET DB_CACHE_SIZE=3791650816 ;
ALTER SYSTEM SET SHARED_POOL_SIZE=3892314112;

 

col NAME for a50
col VALUE for a50
set linesize 120
set pagesize 100
select nam.KSPPINM name,val.ksppstvl value
from x$ksppi nam, x$ksppsv val where
nam.indx=val.indx and nam.ksppinm like '%shared%' order by 1;

col NAME for a50
col VALUE for a50
set linesize 120
set pagesize 100
select nam.KSPPINM name,val.ksppstvl value
from x$ksppi nam, x$ksppsv val where
nam.indx=val.indx and nam.ksppinm like '%cache%' order by 1;

[출처] ORA-04031|작성자 5racle

이 에러의 원인은 크게 3가지로 나뉘어 진다.

1. 다수의 사용자로 인한 SharedPoolSize부족문제

2. 구동중인 App에 비해 현저히 부족한 SharedPool사용으로 인한 문제

3. 덩치 큰 SQL 구동을 위한 연속된 SharedPool할당 불가로 인한 문제

이중 1,2는 같은 맥락에서 접근할 수 있으므로 크게 2가지라고 볼 수도 있다.

이 문제는 OTN 에서 꽤나 유명한 에러로서 아래와 TechBulletin에는 아래와 같이 언급되어 있다.

No. 10095

ORA-4031 조치 방법 과 DBMS_SHARED_POOL STORED PROCEDURE 사용법
==============================================================

Purpose
-------

다음과 같은 작업 수행 시 Oracle 이 Shared pool 에서 연속적인 메모리 부분을 찾지 못해 ORA-4031 에러를 발생시키는 것을 볼 수 있다.

. PL/SQL Routine
. Procedure 수행 시
. Compile 시
. Forms Generate 또는 Running 시
. Object 생성하기 위해 Installer 사용 시

본 자료에서는 이러한 에러에 대한 대처 방안을 설명 하고자 한다.

Problem Description
-------------------

Error 발생의 주된 원인은 Shared Pool의 사용 가능한 Memory 가 시간이 흐름에 따라 작은 조각으로 분할되어 진다는 것이다. 그래서 큰 부분의
Memory 를 할당하려 한다면 Shared Memory가 부족하다는 ORA-4031 Error가 발생한다. 즉, 전체적으로는 많은 양의 사용 가능한 Space가 있다 하더라도
충분한 양의 연속적인 공간이 없으면 이 Error가 발생한다.

1. Shared Pool과 관련된 인스턴스 파라미터
다음 3가지 파라미터는 본 자료를 이해 하는데 매우 중요하다.

* SHARED_POOL_SIZE - Shared Pool 의 크기를 지정 한다. 정수를 사용하며 "K" 나 "M" 을 덧붙일 수 있다.

* SHARED_POOL_RESERVED_SIZE - 공유 풀 메모리에 대한 대량의 연속 공간 요청에 대비해서 예약하는 영역의 크기를 지정한다. 이 영역을 사용하기
위해서는 SHARED_POOL_RESERVED_MIN_ALLOC 보다 큰 영역 할당 요청이어야 한다. 일반적으로 SHARED_POOL_SIZE 의 10% 정도를 지정한다.

* SHARED_POOL_RESERVED_MIN_ALLOC - 예약 메모리 영역의 할당을 통제한다.
이 값보다 큰 메모리 값이 할당 요청되었을 때 공유 풀의 free list 에 합한 메모리 공간이 없으면 예약된 메모리 공간의 리스트에서 메모리를 할당해 준다.
이 값은 8i부터는 내부적으로만 사용된다.

Workaround
-----------
Re-start the instance

Solution Description:
---------------------
이 Error 해결방안을 살펴 보면 다음과 같다.

1. 혹시 알려진 제품 문제에 해당 되지 않는지 확인 한다.

* BUG 1397603: ORA-4031 / SGA memory leak of PERMANENT memory occurs for buffer handles. (Workaround: _db_handles_cached=0, Fixed: 8172,901 )
* BUG 1640583: ORA-4031 due to leak / cache buffer chain contentionfrom AND-EQUAL access. (Fixed: 8171,901 )
* BUG 1318267: INSERT AS SELECT statements may not be shared when they should be if TIMED_STATISTICS. It can lead to ORA-4031. (Workaround: _SQLEXEC_PROGRESSION_COST=0, Fixed: 8171, 8200)
* BUG 1193003: Cursors may not be shared in 8.1 when they should be (Fixed: 8162, 8170, 901)

2. Object를 Shared Pool에 맞추어 Fragmentation을 줄인다.
(Dbms_Shared_Pool Procedure 이용)

다음은 크기가 크고 빈번히 access되는 package들임.

standard packages
dbms_standard
diutil
diana
dbms_sys_sql
dbms_sql
dbms_utility
dbms_describe
pidl
dbms_output
dbms_job

3. Shared Pool 을 효율적으로 사용하도록 Application Program을 조절한다.

4. 메모리 할당을 조정한다.

우선 다음 쿼리로 library cache 문제인지 shared pool reserved space 문제인지 진단한다.

SELECT free_space, avg_free_size, used_space, avg_used_size, request_failures, last_failure_size FROM v$shared_pool_reserved;

만일 REQUEST_FAILURES is > 0 and LAST_FAILURE_SIZE is > SHARED_POOL_RESERVED_MIN_ALLOC
이면 ORA-4031 은 Shared Pool 의 연속 공간 부족의 결과이다.

해결책: SHARED_POOL_RESERVED_MIN_ALLOC 값을 증가 시켜서 shared pool reserved space 에 올라가는 오브젝트의 수를 줄인다. 그리고
SHARED_POOL_RESERVED_SIZE 와 SHARED_POOL_SIZE 를 충분히 확보해 준다.

만일 REQUEST_FAILURES is > 0 and LAST_FAILURE_SIZE is < SHARED_POOL_RESERVED_MIN_ALLOC
이거나
REQUEST_FAILURES is 0 and LAST_FAILURE_SIZE is < SHARED_POOL_RESERVED_MIN_ALLOC
이면 ORA-4031 은 library cache 내의 연속된 공간 부족의 결과 이다.

해결책: SHARED_POOL_RESERVED_MIN_ALLOC 을 줄여서 shared pool reserved space 를 보다 쉽게 사용할 수 있도록 해준다. 그리고 가능하면 SHARED_POOL_SIZE 를 증가시킨다.

5. DBMS_SHARED_POOL STORED PROCEDURE 사용법

이 stored package는 dbmspool.sql을 포함하며 7.0.13 이상 version에서 사용가능하다. 이는 다음과 같이 3가지 부분으로 나누어 진다.

Procedure sizes(minsize number):-> Shared_Pool_size 안에서 정해진 Size 보다 큰 Object를 보여준다.

Procedure keep(name varchar2, flag char Default 'P'):
-> Object (Only Package)를 Shared Pool 에 유지한다. 또한 일단 Keep한 Object는 LRU Algorithm에 영향을 받지 않으며 "Alter System Flush Shared_Pool" Command 에 의해 Package 의 Compiled
Version 이 Shared Pool에서 Clear되지 않는다.

Procedure unkeep(name varchar2):-> keep() 의 반대 기능이다

이 Procedure들과 사용법에 대해 보다 더 자세한 정보를 위해서는 $ORACLE_HOME/rdbms/admin/dbmspool.sql script 또는 오라클 레퍼런스 매뉴얼을 참조하기 바람.

Reference Documents
-------------------
Diagnosing and Resolving Error ORA-04031.

위의 내용과 관련하여 SharedPoolSize 조절 방법은 아래와 같다.

이미 공지의 사실이지만 서두로 언급하면 Oracle은 Background Process와 SGA영역으로 구분된다.

그중 SGA는 SharedPool과 RedoLogBuffer, BufferCache로 이루어져 있다.

이중 SharedPool은 SQL Area와 Data Structure로 이루어져 있다.

SharedPool Size를 산정하는 방법은 아래와 같다.

계산 공식　　　　　　　　

Session당 최대메모리사용량(Max Session Memory) * 동시 접속하는 User의 수　
+　 Shared SQL 영역으로 사용되는 메모리양　　　　　　　　　
+　 Shared PLSQL을 위해 사용하는 메모리 영역　　　　　　　　　　
+　 최소 30%의 여유 공간　

계산 예제　　　　　　　　　

　 (1) 적당한 user session에 대한 session id를 찾는다.　　　　　　　　
　　　　　　　　　
　　　　　　　 SQLDBA>　 select sid from v$process p, v$session s　　　　　　　　　　
　　　　　　　　　　　　 where p.addr=s.paddr and s.username='SCOTT';　　　　　　　　　

　　　　　　　　　　　　　 SID　　　　　　　　　
　　　　　　　　　　 ----------　　　　　　　　　
　　　　　　　　　　　　　　 29　　　　　　　　　
　　　　　　　 1 rows selected.　　　　　　　　　

　 (2) 이 session id에 대한 maximum session memory를 찾는다.　　　　　　　　
　　　　　　　　　
　　　　　　　 SQLDBA> select value from v$sesstat s, v$statname n　　　　　　　　　　
　　　　　　　　　　　 where s.statistic# = n.statistic#　　　　　　　　　　
　　　　　　　　　　　 and n.name = 'session uga memory max' and sid=29;　　　　　　　　　

　　　　　　　　　　 VALUE　　　　　　　　　　　　　　
　　　　　　　　　　 -----------　　　　　　　　　
　　　　　　　　　　　 273877　　　　　　　　　　　　　　　　　
　　　　　　　 1 rows selected.　　　　　　　　　
　　　　　　　　　
　 (3) Total shared SQL area를 구한다.　　　　　　　　
　　　　　　　　　
　　　　　　　 SQLDBA>　 select sum(sharable_mem) from v$sqlarea;　　　　　　　　　

　　　　　　　 SUM(SHARAB　　　　　　　　　
　　　　　　　 ---------------------　　　　　　　　　
　　　　　　　　　　　　　　 8936625　　　　　　　　　
　　　　　　　 1 row selected.　　　　　　　　　
　　　　　　　　　
　 (4) PLSQL sharable memory area를 구한다.　　　　　　　　　
　　　　　　　　　
　　　　　　　 SQLDBA>　 select sum(sharable_mem) from v$db_object_cache;　　　　　　　　　

　　　　　　　 SUM(SHARAB　　　　　　　　　
　　　　　　　 ------------------　　　　　　　　　
　　　　　　　　　　　 4823537　　　　　　　　　
　　　　　　　 1 row selected.　　　　　　　　　
　　　　　　　　　
　　　　　　　　　
　 (5) Shared pool size를 계산한다.　　　　　　　　　
　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　 274K shared memory　 *　 400 users　　　　　　　　　
　　　　　　　 +　　　　　 9M Shared SQL Area　　　　　　　　　　　　　　
　　　　　　　 +　　　　　 5M PLSQL Sharable Memory　　　　　　　　　　
　　　　　　　 +　　　　　 60M Free Space (30%)　　　　　　　　　　　　　　

　　　　　　　 =　　　 184M Shared Pool　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　
　　　　　　　　　　
　　 이 예제에서는 Shared pool의 size는 184M가 적당하다고 할 수 있다. 이때 Free Space(60M) 계산 방법은 전제 184 M 에 대한 30 % 정도의 추정치 이다.　　　　　　　　
　　　　　　　　　
Shared Memory부족 (ORA-4031)에 대한 대처

　다음과 같은 방법으로 에러를 피해 갈 수 있다.- "Sys.dbms_shared_pool.keep" procedure사용.　　　　　　　　

[참고] 위 package를 사용하려면 ?/rdbms/admin/dbmspool.sql,prvtpool.sql를 수행시켜 package를 create시킨 후 사용한다.　　　　　　　　
　　　 (자세한 사항은 bulletin 10095,Oracle7 Server Tuning 4장12를 참조한다.)　　　　　　　　　
　　　　　　　　　

ORACLE_HOME/dbs/initSID.ora에 보시면 Processes=???값과 sessions=?????라는
값에 좌우가 되는데 시스템에서 허락되는
User별 process값이 있고 이 범위내에서 허용이 된다.
SQL> show parameter process;

NAME TYPE VALUE
------------------------------------ ------- ------------------------------
aq_tm_processes integer 0
db_writer_processes integer 1
job_queue_processes integer 0
log_archive_max_processes integer 1
processes integer 300
SQL> show parameter session;

NAME TYPE VALUE
------------------------------------ ------- ------------------------------
java_max_sessionspace_size integer 0
java_soft_sessionspace_limit integer 0
license_max_sessions integer 0
license_sessions_warning integer 0
mts_sessions integer 330
session_cached_cursors integer 0
session_max_open_files integer 10
sessions integer 335
SQL>

[출처] ORA-04031|작성자 메치니

 

출처 : http://ukja.tistory.com/239

오라클 2009/08/11 17:40

사람의 기억력이 지구상의 동물들 중에서 제일 좋다고는 하지만, 그것이 “까먹지 않음”을 보장 하는 것은 아니다. 평상시 root계정으로 패스워드 쳐서 백만번씩 들어가던 사람도 순간 패스워드를 잊어 버릴 수 있다. “포맷 해버리면 그만이지 뭐!!” 라고 생각도 잠시, 이 컴퓨터 안에 수많은 “야구 동영상”이 들어있다는 생각에 이러지도 저러지도 못하는 상황이 발생한다. 이런 긴급상황에 어떻게 대처하는 지 알아보자.

준비물이 하나 있다. 부팅CD를 준비하도록 하자.

 

CD로 부팅하기 위해 각자의 메인보드에서 BIOS로 들어가는 키를 눌러 BIOS화면으로 들어간다.

boot탭에 CD-ROM이 보일 것이다. 이것을 부팅 우선순위 맨 위에다 놓는다. 그리고 F10을 눌러 저장하고 종료한다.

 
 

이제 다시 부팅한다.

새로이 뜨는 화면의 boot: 부분에 linux rescue라고 쓴 후 엔터를 누른다.

 

 
언어 선택으로 넘어간다. Korean이 있을 것이라는 기대는 금물. 세계 공통어 English를 선택한다.

 

Keyboard Type이다. 역시 us를 선택하자.

 

root암호를 해제하는 것에 network은 필요 없다. no를 선택하자.

 

 

/mnt/sysimage 디렉토리에 Linux 인스톨을 mount하겠다고 써있다. Continue를 누르면 마운트된 파일 시스템을 read-write, Read-only를 누르면 read만 하겠다고 한다. Skip를 누르면 바로 커맨드 창으로 간다고 한다. Continue를 누르자.

 
 

root환경으로 만들려면 나중에 commend창에 chroot /mnt/sysimage를 입력하라고 써있다. OK를 눌러 커맨드 창으로 가자.

이제 commend창이다. 위에서 입력하면 root환경으로 간다는 chroot /mnt/sysimage를 입력한다.

sh-3.2# chroot /mnt/sysimage

 

각 계정의 password가 있는 파일은 /etc/shadow이다. vi editor을 열어 들어가도록 하자.

sh-3.2# vi /etc/shadow

 

파일을 열면 맨 윗쪽에 root라고 써 있고, 콜론이 찍혀있다. 빨간 줄이 그어져 있는 부분이 암호화된 비밀번호이다. 이 부분을 다 지우도록 하자(빨간 줄 앞뒤의 콜론은 지우지 않도록 한다)

암호화된 비밀번호를 지운 후 vi commend mode에서 :wq!를 입력해서 저장한다. 읽기 전용의 파일이므로 끝에 느낌표를 붙이지 않으면 저장되지 않음을 유의하자.

 

                               (/etc/shadow : 저 읽기 전용이예요~ 그것도 root계정만!!)

 

Sync를 입력 한 후 reboot를 입력하여 재부팅 한다. 필자가 입력하려고 했던 init 0은 되지 않았다.

sh-3.2# sync

sh-3.2# reboot

 

부팅 처음 화면에서 BIOS로 가는 키를(필자는 F2) 입력하여 BIOS화면에 들어간다.

그 후 CD-ROM위에 hard drive를 두어 다시 부팅 되었을 때 도로 하드로 부팅되도록 한다. 다음과 같이 바꾼 후 F10키를 눌러 저장 후 종료한다.

다시 부팅되고 Linux의 유저 입력 화면이 나왔다. 이제 root 계정으로 접속 해 보자.

 

패스워드를 확인 하지 않고 바로 X 윈도우 화면으로 넘어 감을 확인 할 수 있다.

 

다시는 root 암호를 까먹지 않는다는 다짐과 함께 새로운 password를 입력 해 주자.

 

■ LG파워콤 DNS
기본 DNS : 164.124.101.2
보조 DNS : 203.248.252.2

 

■ KT DNS
기본 DNS 서버 : 168.126.63.1
보조 DNS 서버 : 168.126.63.2

■ 하나로(현 SK브로드밴드) DNS
기본 DNS서버 : 219.250.36.130
보조 DNS서버 : 210.220.163.82

독일 뮌헨에서 'BMW 드라이버 트레이닝' 훈련에 참가했다. BMW는 1977년, 세계에서 최초로 운전자 훈련을 실시한 자동차 제조사다. 매년 15000명 이상의 운전자가 BMW드라이버트레이닝센터에서 운전을 배워 나간다. 지금까지 총 25만명이 BMW로부터 운전을 배웠다.

'BMW 드라이버 트레이닝'은 차를 안전하게 운전하기 위해 어떻게 해야 하는지를 배우는 반일짜리 기본 프로그램부터 유럽 뉘르부르크링에서 2일을 꼬박 달리며 레이서 못지 않은 스킬을 쌓을 수 있는 프로그램이나 아프리카 나미비아공화국에서 본격적인 오프로드를 달리는 8일짜리 코스까지 다양하다.

이 번엔 연비 운전을 위한 '이코노미컬 드라이빙(Economical Driving)' 훈련을 받았다. BMW와 연비운전이라니 마치 두 단어가 충돌하는 느낌이었지만, BMW측은 '연비운전'이 '다이내믹'과 반대되는 개념이 아니라고 말했다. 연비운전을 하면서도 충분히 역동적으로 주행할 수 있다는 것이었다. 드라이빙의 재미를 강조하는 BMW가 내놓는 연비 운전 비결이라니, 과연 어떤 차이가 있는지 알기 위해 훈련에 집중했다.

◆ '블랙박스' 이용해 연비, 운전 실력 모두 기록

연비 운전 훈련을 위해 사용된 차는 BMW 준중형 스포츠세단인 330i로 3.0리터 가솔린 엔진을 장착한 수동변속기 차량이다. 이 차의 자동변속기 모델은 국내서 공인 연비 9.2km/l에 불과할 정도로 연비가 좋지 못하다.

이 차에는 블랙박스가 장착돼 각 운전자의 운전방법과 습관을 그대로 기록한다. 주행이 끝나면 가속페달을 얼마나 밟았는지, 기어는 몇단을 이용했는지, RPM은 어떻게 활용하는지를 상세히 살펴볼 수 있게 된다. '블랙박스'라고는 하지만 차에 장치된 박스는 흰색이었다.

"연비 운전의 기본은 알고 있겠죠?" 랠리 레이서 출신이라는 오스트리아인 강사는 당연하다는 듯이 물어본다. 더듬더듬 거리며 가속페달, 브레이크 페달은 덜 밟고, 기어를 빨리 변속하면서 천천히 운전하는 것이라 답했지만 그는 웃기만 했다. 만족하지 못한 눈치다. 그거 말고 뭐가 더 있나 곰곰히 생각해봤지만 달리 떠오르지 않는다.

도로를 조금만 벗어나면 자연환경이 아름답게 가꿔진 도로가 뻗어 있다.

▲ 도로를 조금만 벗어나면 자연환경이 아름답게 가꿔진 도로가 뻗어 있다.

일단 약 35km에 달하는 거리를 달리며 연비운전 습관을 보기로 했다. 테스트 장소는 뮌헨 외곽이어서 거리가 비교적 한산했지만 차들도 조금 있었고 신호등도 반드시 지키며 달렸다.

간 만에 다뤄보는 수동변속기가 조금 생소했지만 달리다보니 이내 기분이 좋아진다. BMW의 자동변속기는 수동 못지 않은 직결감이 매력적이지만, 수동 변속기는 그 수준을 넘어 마치 강철로 연결한 듯하다. 무게도 더 가볍고 연비 향상에도 큰 도움이 될 것 같았다. 계기반 화면에 평균 연비가 나타나도록 해놓고 최적의 연비가 되도록 주의를 기울이며 살금살금 운전했다.

약 38분 동안 39km를 달린 후 블랙박스를 조사해보니, 연료는 총 2.8리터를 사용했다. 3.0리터 차로 13.8km/l의 연비를 기록한 셈이다. 원래 연비 운전에 소질이 좀 있는데다 독일의 도로환경이 서울에 비해선 훨씬 나은편이어서 연비가 비교적 잘 나왔다. 도로 상당수가 신호등 대신 로터리 방식을 채택하고 있어서 멈춰서지 않고 달릴 수 있던 것도 한 몫했다. 함께 참가한 다른 운전자들에 비해서도 월등히 우수한 수준이어서 이보다 더 나은 연비가 나오는건 불가능해보였다. 하지만 BMW의 오스트리아인 강사는 일단 BMW의 '연비향상 비법'을 교육한 후 다시 한번 같은 길을 달려보자고 했다.

◆ BMW가 공개한 '연비운전 비법'

당 연한 얘기지만 일반적인 연비 운전 방법이 먼저 설명됐다. 우선 서비스 주기를 잘 지키라고 했다. 특히 타이어 공기압은 연비에 매우 직접적인 영향을 미치기 때문에 주의해 살펴야 한다고 했다. 트렁크도 자주 관리해야 한다. 짐 100kg이 실리면 연비가 즉각 3% 떨어진다는 것이다.

이어 BMW가 말하는 '연비 운전 비결'이 몇가지 더 있었다. 이중 일부는 기존의 상식과 크게 달라 쉽게 믿어지지 않았다.

1. 워밍업을 하지 말고 바로 출발할 것 - 최신 차종들은 워밍업이 불필요하다.

2. 멀리 내다보고 균형있게 운전할 것(교통신호와 교통의 흐름을 잘 살펴볼 것) - 속도를 얼마나 줄여야 할지에 따라 가속페달을 일찍 떼거나 혹은 기어를 중립으로 옮기는 방식을 선택할 것.

3. 온보드컴퓨터를 통해 순간연비와 변속 시점을 계속 살펴볼 것.

4. 가속페달에서 발을 보다 일찍 뗄 것 - 브레이크를 밟는 대신 퓨얼컷을 이용해서 감속할 것.

5. 신호대기나 교통정체시 시동을 끌 것 - 스타트앤스톱 기능을 활용.

6. 높은 기어를 넣고 강하게 가속할것 - 가속할 때 평소보다 더 높은 기어를 이용하고 가속페달은 2/3 가량만 밟을 것

7. 50km/h에서 100km/h로 가속할 때 3단기어보다 5단 기어를 이용하면 연비 10%가 향상된다.

가 속페달에서 밟을 먼저 떼 연료 공급이 끊기도록 하는 '퓨얼컷'을 이용하는 것은 기본적인 기술에 속했다. 강사는 연비 운전을 위해 더 빠르게 가속 해야 한다는 급진적인 주장도 내놨다. BMW 자료에 따르면 빠르게 가속하면 높은 기어를 빨리 이용할 수 있고 더 쉽게 연비가 향상된다고 한다.

연비 운전을 위해 주행 중 기어를 중립으로 옮기라는 설명은 워낙 급진적이어어서 참가자들 사이에서도 잠시 옥신각신 토론이 이어졌다. 기어를 중립에 넣지 않아야 발생하는 '퓨얼컷'을 강조하던 기존의 연비 운전 방식과 배치되는 것이기 때문이었다. 하지만 BMW의 강사는 기어를 중립으로 옮기지 않으면 퓨얼컷을 이용할 수는 있지만, 엔진브레이크로 인해 차가 금방 감속돼 다시 가속페달을 밟아야 한다는 점을 지적했다. 예를들어 고속도로를 달리다가 빠져나가야 하는 진출로가 1km뒤에 있다면 퓨얼컷 대신 변속기를 중립으로 놓아야 한다는 설명이다. 자동변속기 또한 달리며 기어노브를 중립(N) 모드로 옮기거나 드라이브(D)모드로 옮기는 방식으로 주행하면 연비운전에 도움이 된다고 했다. 그러고보니 자동변속기의 D와 N사이는 별다른 조작없이 쉽게 움직일 수 있도록 만들어져 있는것도 이런 이유인 듯 했다.

신 호대기 중 시동을 꺼야 한다는 점도 일반적인 연비 운전 상식과 달랐다. 일반적으로는 재시동시 연료가 소비되기 때문에 시동을 끄지 않는 것이 유리한 것으로 알려졌지만, 최신 자동차들은 재시동에 그리 많은 연료를 소비하지 않기 때문에 시동을 수시로 끄는 것이 오히려 바람직하다는 결론이 났다는 설명이다.

◆ 좋은 차를 만드는건 두번째, 운전자들이 발전하는게 첫번째

연 비 운전 교육을 받은 후 다시 운전에 나섰다. 1단-2단을 거쳐 3단을 거치지 않고 바로 5단으로 점프했다. 차가 약 시속 80km 이상으로 달리게 되면 다시 기어를 변속했다. 전방을 살펴 앞으로 1km 이후에 감속을 해야 할 것 같으면 중립을 넣고 관성 주행을 했고, 1km 이내에서 감속을 해야 할 것 같으면 가속페달에서 발을 떼고 퓨얼컷을 이용했다. 머리 속에서는 이상적인 주행방법을 그렸지만, 실제로는 잘 이뤄지지 않는 경우도 많았다, 좀 더 익숙해져야 할 것 같았다.

빨간색이 이전의 주행 형태, 파란색은 이후의 주행 형태다. 아래 그래프 중 'Leerl'이 중립을 뜻하는 것이다.

원래 극단적인 연비운전을 해왔기 때문에 두번째 주행이라고 큰 향상은 없을듯 했지만 마른 수건을 쥐어짜듯 5.9% 가량 연비 향상이 이뤄졌다. 3.0리터 차라고는 믿기 힘든 14.7km/l의 연비다.

블 랙박스의 내용을 그래프를 통해 살펴보니 속도는 오히려 이전에 비해 좀 빨라졌다. 역시 1단 2단만 사용하고 바로 6단으로 올렸던 것이 효과를 봤다. 엔진회전수(RPM)은 극단적으로 낮게 활용했고, 브레이크도 훨씬 적게 이용했다. 이대로 운전하면 서울에 있는 2.0리터 자동변속기 차량의 연비는 이보다 더 높은 연비를 낼 수 있을 듯 했다. (실제 서울에서 주행해보니 연비는 13km/l 정도가 됐다)

오스트리아인 강사는 BMW가 이같은 교육시스템을 만든 이유에 대해 도로, 차, 운전자가 하나로 뭉쳐 교통을 만든다고 생각하고 있기 때문이라고 설명한다. BMW는 단순히 차를 만드는 회사가 아니라 더 나은 교통을 위해 노력하는 회사라는 것이다. 환경을 위해선 차를 잘 만들어야 할 뿐 아니라 운전자도 차를 잘 운전할 수 있도록 해야 한다는 설명이다. 그는 수십개의 BMW 드라이빙 스쿨에 대해 설명을 마치더니 한국의 자동차 회사들은 어떤 드라이빙 스쿨을 운영하고 있느냐고 물었다. 순간 혼잡한 한국의 도로가 떠오르며 얼굴이 붉어졌다.

/whynot@top-rider.com 김한용 기자