About DATABASE

In this Document
  Purpose
  Scope
  How to Configure Solaris Link-based IPMP for Oracle VIP
  References

Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.2.0.2 - Release: 10.2 to 11.2
Oracle Solaris on SPARC (64-bit)
Oracle Solaris on x86-64 (64-bit)

Purpose

This note will give a sample configuration for Link-based failure detection mode for IPMP which is introduced in Sun Solaris 10 platform.

Before Sun Solaris 10, there is only Probe-based failure detection IPMP configuration that you can find the example in note 283107.1

The main different between Probe-based IPMP and Link-based IPMP
- In Probe-based IPMP, beside the host's Physical IP address you also need to assign a test IP address for each NIC card. And one target system, normally default gateway, where multipathing daemon used for ICMP probe message.

- In Link-based IPMP, only the host's Physical IP address is required.

Scope

By default, link-based failure detection is always enabled in Solaris 10, provided that the driver for the interface supports this type of failure detection. The following Sun network drivers are supported in the current release

Network Requirement
--------------------------------
There is no different for Probe-based and Link-based in term of hardware requirement.

It is only one Physical IP address required per cluster node. The following is list of NIC Card and IP addresses that will be used in the following example.
- Public Interface: ce0 and ce1
- Physical IP: 130.35.100.123
- Oracle RAC VIP: 130.35.100.124

How to Configure Solaris Link-based IPMP for Oracle VIP

IPMP Configuration
-----------------------------
1. ifconfig ce0 group racpub
2. ifconfig ce0 addif 130.35.100.123 netmask + broadcast + up
3. ifconfig ce1 group racpub

To preserve the IPMP configuration across reboot, you need to update the /etc/hostname.* files as following
1. The entry of /etc/hostname.ce0 file
130.35.100.123 netmask + broadcast + group racpub up

2. The entry of /etc/hostname.ce1 file
group racpub up

Before CRS installation , the 'ifconfig -a' output will be

Since no test IP assigned to public interfaces, the IP address of ce0 is the physical IP address and ce1 is 0.0.0.0.

CRS / VIPCA configuration
----------------------------------------
Upon successful of root.sh on the CRS installation, vipca will only make the primary interface as the public interface. If you start vipca application manually, the second screen (VIP Configuration Assistant, 1 of 2) will only list ce0 as the available public interface.

After that, you need to update CRS for the second NIC (ce1) information with srvctl command

After CRS is installed and Oracle VIP is running, the 'ifconfig -a' output will be

When the primary interface on the public network failed, either NIC faulty or the LAN cable broken, Oracle VIP will follow the physical IP failover to standby interface. As the following output of 'ifconfig -a' shows

References

NOTE:283107.1 - Configuring Solaris IP Multipathing (IPMP) for the Oracle 10g VIP
NOTE:368464.1 - How to Setup IPMP as Cluster Interconnect
docs.oracle.com/cd/E19253-01/816-4554/mpoverview/index.html

Automatic Tuning of Undo_retention Causes Space Problems [ID 420525.1]

--------------------------------------------------------------------------------
 
  수정 날짜 09-FEB-2011     유형 PROBLEM     상태 PUBLISHED  

In this Document
  Symptoms
  Cause
  Solution
  References

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

Applies to:
Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.3 - Release: 10.2 to 10.2
Information in this document applies to any platform.
Oracle Server Enterprise Edition - Version: 10.2.0.1 to 10.2.0.3 -- fixed by patchset 10.2.0.4 and no issues on this at 11g
Symptoms
You have verified that Note 413732.1 is not applicable and the problem is not a misunderstanding in the way EXPIRED/UNEXPIRED are used and reused over time.

Look for:

1.) System (Automatic) Managed Undo
undo_management=auto in init.ora file

2.) Fixed size undo tablespace
SQL> select autoextensible from dba_data_files where tablespace_name='<current_undo_tablespace >'

returns "No" for all the undo tablespace datafiles.

3.) The undo tablespace is already sized such that it always has more than enough space to store all the undo generated within the undo_retention time, and the in-use undo space never exceeds the undo tablespace warning alert threshold (see below for the query to show the thresholds).

4.) The tablespace threshold alerts recommend that the DBA add more space to the undo tablespace:

SQL> select creation_time, metric_value, message_type,reason, suggested_action from dba_outstanding_alerts where object_name='<current_undo_ts>';

returns a suggested action of: "Add space to the tablespace"

Or,

This recommendation has been reported in the past but the condition has now cleared:
SQL> select creation_time, metric_value, message_type, reason, suggested_action, resolution from dba_alert_history where object_name='<current_undo_ts>';

5.) The undo tablespace in-use space exceeded the warning alert threshold at some point in time:

To see the warning alert percentage threshold:

SQL> select object_type, object_name, warning_value, critical_value from dba_thresholds where object_type='TABLESPACE';

To see the (current) undo tablespace percent of space in-use:
SQL> select
((select (nvl(sum(bytes),0))
from dba_undo_extents
where tablespace_name='<current_undo_ts>'
and status in ('ACTIVE','UNEXPIRED')) *100) /
(select sum(bytes)
from dba_data_files
where tablespace_name='<current_undo_ts>')
"PCT_INUSE"
from dual;

Cause
This is due to Bug 5387030 that is fixed in 10.2.0.4 patchset of RDBMS server.

Solution
Apply the patch for the Bug 5387030. Check the Oracle Support Portal for patch availability for your platform and RDBMS version.

Workaround

There are 3 possible alternate workarounds (any one of these should resolve the problem of the alerts triggering unnecessarily):

1.) Set the autoextend and maxsize attribute of each datafile in the undo ts so it is autoextensible and its maxsize is equal to its current size so the undo tablespace now has the autoextend attribute but does not autoextend:

SQL> alter database datafile '<datafile_flename>'
autoextend on maxsize <current_size>;

With this setting, v$undostat.tuned_undoretention is not calculated based on a percentage of the undo tablespace size, instead v$undostat.tuned_undoretention is set to the maximum of (maxquerylen secs + 300) undo_retention specified in init.ora file.

2.) Set the following hidden parameter in init.ora file:
_smu_debug_mode=33554432

or

SQL> Alter system set "_smu_debug_mode" = 33554432;

With this setting, v$undostat.tuned_undoretention is not calculated based on a percentage of the fixed size undo tablespace, instead v$undostat.tuned_undoretention is set to the maximum of (maxquerylen secs + 300) undo_retention specified in init.ora file.

3.) Set the following hidden parameter in init.ora:
_undo_autotune = false

or

SQL> Alter system set "_undo_autotune" = false;

With this setting, v$undostat (and therefore v$undostat.tuned_undoretention) is not maintained and the undo_retention used is the one specified in init.ora file.   NOTE:  This means you loose all advantages in having automatic undo management and is not an ideal long term fix.

NOTE: Even with the patch fix installed, the autotuned retention can still grow under certain circumstances.  The fix attempts to throttle back how aggressive that autotuning will be.  Options 2 and 3 may be needed to get around this aggressive growth in some environments.

References
NOTE:413732.1 - Full UNDO Tablespace In 10gR2

 관련 자료

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

•Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition
키워드
--------------------------------------------------------------------------------
TABLESPACE; UNDO_MANAGEMENT; UNDO_RETENTION; UNDO TABLESPACE

● 개요

● 오라클 넷 서비스(Oracle Net Services)
   ◎ 정의
       : 네트워크 connection을 가능하게 하는 소프트웨어

   ◎ 전체 구조도

   ◎ 리스너에 추가하는 법

       ○ telnet으로 추가
           - 리스너가 동작중인지 확인

           - linstener.ora가 있는 디렉토리로 이동 후 확인

           - listener.ora의 내용을 확인

           - 내용을 확인해보면 다음과 같다. 빨간색 부분을 추가한다.(띄어쓰기 안맞을 경우 에러 발생할 가능성이 있다.)

           - 리스너를 start시킨다.
             기본은 1521 포트의 리스너가 start되지만 리스너를 명시해서 start, stop을 할 수 있다.

           - lsnrctl 명령으로도 가능

       ○ Oracle Net Manager로 추가

       ○ Oracle Configuration Assistant로 추가

       ○ EM으로 추가



 ※ Server에 기본 리스너외에 추가 리스너 등록

※ RAC환경에서의 설정
    - SID는 중복 불가, SERVICE_NAME은 중복 가능

- haha라는 서비스명으로 접속하므로 i1이 shutdown되어 있더라도 i2로 접속이 가능
  SID=i1으로 할 경우 문제가 생길 소지가 있음. SERVICE_NAME으로 하는 것이 좋음

※ instance name이 같은 서버가 있어도 도메인으로 식별 가능

※ Dedicated Server vs. Shared Server

  Dedicated Server
    - 하나의 유저에 하나의 서버 프로세스가 담당.
    - sserver process당 PGA가 생긴다.

    dedicate server로 접속시 client의 tnsnames.ora설정 파일

  Shared Server
    - 일정 갯수의 서버 프로세스를 유저서버프로세스가 공유하는 형식
    - UGA(user session data, cursor state, sort data)가 SGA내에 생김(서버 프로세스가 공유하기 위해서)
    - 아래의 파일들을 설정해주어야 함

    shared server 접속시 client의 tnsnames.ora 설정 파일

      server의 파라미터 파일 설정

기타참고사항

- JDBC 드라이버
    : Java Database Connectivity의 약자. 번역기. DBMS의 벤더들이 만든다.
      oracle net을 simmulate한 것
      사용시에 오라클의 버전에 맞게 사용할 것

- 리스너가 살아있는지 확인(서버가 살아있는지 확인하는 것은 아님)
   tnsping 172.16.122.106:1521/orcl

- name resolution
  : connect identifier(network alias, service alias)를 connect descriptor로 바꾸는 행위를 말한다.

- linux : oerr ora 12154 명령을 치면 에러에 대한 내용이 나옴.

- 오라클에서의 connection과 session
   - connection
      : communication path way
   - session
      : log in ~ log out

RAC 10g R2 patch.pdf

dbworks 에서 받은 파일입니다.

Oracle Silent Install Guide.pdf

오라클 매거진 2007년 가을호 발췌자료입니다.

일반적으로 RAC의 Inter-Connects의 성능과 가장 연관이 깊은것이 UDP Buffer의 크기이다. 오라클이 공식적으로 권고하는 UDP
Buffer 크기는 256K이고 대부분의 시스템에서 적절한 성능을 보장하고있다. Inter-Connect을 통해 주고 받는 Data량이 많은 경우 UDP Buffer Size를 1M~2M 정도 사용하기도 하며 Transaction에 비해 UDP Buffer Size 가 작을 경우 Packet Loss 현상이 발생할 수 있다. Packet Loss 현상이 자주 발생할 경우“gc cr block lost”,“gc current block lost”의 Oracle Wait Event가 나타난다. 이는 각 OS 별 Monitoring Tool인 nmon, topas, glance이나 Network 명령인 ifconfig, netstat 등과
Network 진단 Tool을 통해 UDP Packet Receive Error나 Dropped 된비율을 Monitoring 하도록 한다.
[oracle@rac1]$ netstat -s
Ip: ………
Tcp: …….

PURPOSE
-------

This note was written to help DBAs and Support Analysts Understand Inter-Instance
Performance and Tuning in RAC.


SCOPE & APPLICATION
-------------------

Real Application Clusters uses the interconnect to transfer blocks and messages 
between instances.  If inter-instance performance is bad, almost all database 
operations can be delayed.  This note describes methods of identifying and 
resolving inter-instance performance issues.


TUNING INTER-INSTANCE PERFORMANCE IN RAC AND OPS
------------------------------------------------




SYMPTOMS OF INTER-INSTANCE PERFORMANCE PROBLEMS
-----------------------------------------------

The best way to monitor inter-instance performance is to take AWR or statspack 
snaps on each instance (at the same time) at regular intervals.  

If there are severe inter-instance performance issues or hung sessions, you 
may also want to run the racdiag.sql script from the following note 
to collect additional RAC specific data:

  Note 135714.1 
  Script to Collect RAC Diagnostic Information (racdiag.sql) 

The output of the script has tips for how to read the output.  

Within the AWR, statspack report, or racdiag.sql output, you can use the wait 
events and global cache statistics to monitor inter-instance performance.  It 
will be important to look for symptoms of inter-instance performance issues.  
These symptoms include:

1. The average cr block receive time will be high.  This value is calculated by
dividing the 'global cache cr block receive time' statistic by the 
'global cache cr blocks received' statistic:

	global cache cr block receive time
	----------------------------------
     	 global cache cr blocks received

Multiply this calculation by 10 to find the average number of milliseconds.  In a 
9.2 statspack report you can also use the following Global Cache Service Workload 
characteristics:

Ave receive time for CR block (ms):                        4.1

The following query can also be run to monitor the average cr block receive time 
since the last startup:

set numwidth 20
column "AVG CR BLOCK RECEIVE TIME (ms)" format 9999999.9
select b1.inst_id, b2.value "GCS CR BLOCKS RECEIVED", 
b1.value "GCS CR BLOCK RECEIVE TIME",
((b1.value / b2.value) * 10) "AVG CR BLOCK RECEIVE TIME (ms)"
from gv$sysstat b1, gv$sysstat b2
where b1.name = 'global cache cr block receive time' and
b2.name = 'global cache cr blocks received' and b1.inst_id = b2.inst_id ;

The average cr block receive time or current block receive time should typically be 
less than 15 milliseconds depending on your system configuration and volume, is the 
average latency of a consistent-read request round-trip from the requesting instance 
to the holding instance and back to the requesting instance. 

Please note that if you are on 9i and the global cache current block receive 
time is abnormally high and the average wait time for the 'global cache null 
to x' wait event is low (under 15ms) then you are likely hitting bug 2130923 
(statistics bug).  This is a problem in the way statstics are reported and does 
not impact performance.

More about that issue is documented in the following note:

  Note 243593.1 
  RAC: Ave Receive Time for Current Block is Abnormally High in Statspack 

2. "Global cache" or "gc" events will be the top wait event.  Some of these wait
events show the amount of time that an instance has requested a data block for a 
consistent read or current block via the global cache.  



When a consistent read buffer cannot be found in the local cache, an attempt is 
made to find a usable version in another instance. There are 3 possible outcomes, 
depending on whether any instance in the cluster has the requested data block 
cached or not: 

a) A cr block is received (i.e. another instance found or managed to produce the 
   wanted version).  The "global cache cr blocks received" statistic is incremented. 
b) No other instance has the block cached and therefor the requesting instance 
   needs to read from disk, but a shared lock will be granted to the requestor 
   The "global cache gets" statistic is incremented 
c) 9i RAC+ Only --> A current block is received (the current block is good enough for 
   the query ).  The " global cache current blocks received" statistic is 
   incremented.

In all three cases, the requesting process may wait for global cache cr request.
The view X$KCLCRST (CR Statistics) may be helpful in debugging 'global cache cr 
request' wait issues.  It will return the number of requests that were handled for 
data or undo header blocks, the number of requests resulting in the shipment of a 
block (cr or current),  and the number of times a read from disk status is returned.

It should be noted that having 'global cache' or 'gc' waits does not always
indicate an inter-instance performance issue.  Many times this wait is 
completely normal if data is read and modified concurrently on multiple
instances.  Global cache statistics should also be examined to determine if 
there is an inter-instance performance problem.

3. The GES may run out of tickets.  When viewing the racdiag.sql output 
(Note 135714.1) or querying the gv$ges_traffic_controller or 
gv$dlm_traffic_controller views, you may find that the TCKT_AVAIL shows '0'.  To 
find out the available network buffer space we introduce the concepts of tickets.  
The maximum number of tickets available is a function of the network send buffer 
size. In the case of lmd and lmon, they always buffer their messages in case of 
ticket unavailability.  A node relies on messages to come back from the remote 
node to release tickets for reuse.

4. The above information should be enough to identify an inter-instance performance
problem but additional calculations can be made to monitor inter-instance 
performance can be found in the documentation.


IDENTIFYING AND RESOLVING INTER-INSTANCE PERFORMANCE PROBLEMS
-------------------------------------------------------------

Inter-Instance performance issues can be caused by:

1. Under configured network settings at the OS.  Check UDP, or other network protocol 
settings and tune them.  See your OS specific documentation for instructions on how 
to do this.  If using UDP, make sure the parameters relating to send buffer space, 
receive buffer space, send highwater, and receive highwater are set well above the 
OS default.  The alert.log will indicate what protocol is being used.  Example:

	cluster interconnect IPC version:Oracle RDG
	IPC Vendor 1 proto 2 Version 1.0

Changing network parameters to optimal values:

 Sun (UDP Protcol) 
	UDP related OS parameters can be queried with the following command:
		ndd /dev/udp udp_xmit_hiwat
		ndd /dev/udp udp_recv_hiwat 
                ndd /dev/udp udp_max_buf 
	Set the udp_xmit_hiwat and udp_recv_hiwat to the OS maximum with:
		ndd -set /dev/udp udp_xmit_hiwat <value>
		ndd -set /dev/udp udp_recv_hiwat <value> 
                ndd -set /dev/udp udp_max_buf <1M or higher>
 IBM AIX (UDP Protocol)
	UDP related OS parameters can be queried with the following command:
		no -a
	Set the udp_sendspace and udp_recvspace to the OS maximum with:
		no -o <parameter>
 Linux (edit files)
	/proc/sys/net/core/rmem_default 
	/proc/sys/net/core/rmem_max
	/proc/sys/net/core/wmem_default
	/proc/sys/net/core/wmem_max 
 HP-UX (HMP Protocol):
	The file /opt/clic/lib/skgxp/skclic.conf contains the Hyper Messaging Protocol (HMP)
        configuration parameters that are relevant for Oracle:
	- CLIC_ATTR_APPL_MAX_PROCS Maximum number of Oracle processes. This includes
	  the background and shadow processes. It does not
	  include non-IPC processes like SQL client processes.
	- CLIC_ATTR_APPL_MAX_NQS This is a derivative of the first parameter; it will 
          be removed in the next release. For the time being, this should be set to 
          the value of CLIC_ATTR_APPL_MAX_PROCS.
	- CLIC_ATTR_APPL_MAX_MEM_EPTS Maximum number of Buffer descriptors. Oracle 
	  seems to require about 1500-5000 of them depending on the block size (8K or 
	  2K). You can choose the maximum value indicated above.
	- CLIC_ATTR_APPL_MAX_RECV_EPTS Maximum number of Oracle Ports. Typically, 
	  Oracle requires as many ports as there are processes. Thus it should be 
	  identical to CLIC_ATTR_APPL_MAX_PROCS.
	- CLIC_ATTR_APPL_DEFLT_PROC_SENDS Maximum number of outstanding sends. You 
	  can leave it at the default value of 1024.
	- CLIC_ATTR_APPL_DEFLT_NQ_RECVS Maximum number of outstanding receives on a 
	  port or buffer. You can leave it at the default value of 1024.
 HP-UX (UDP Protcol):
	Not tunable before HP-UX 11i Version 1.6
      For HP-UX 11i Version 1.6 or later be able to use below command to set socket_udp_rcvbuf_default & socket_udp_sndbuf_default 
      ndd -set /dev/udp socket_udp_rcvbuf_default 1048576
      echo $?
      ndd -set /dev/udp socket_udp_sndbuf_default 1048576
      echo $? 
 HP Tru64 (RDG Protocol):
	RDG related OS parameters are queried with the following command:
		/sbin/sysconfig -q rdg 
	The most important parameters and settings are:
	- rdg_max_auto_msg_wires - MUST be set to zero.
	- max_objs - Should be set to at least <# of Oracle processes * 5> and up to 
	  the larger of 10240 or <# of Oracle processes * 70>. Example: 5120
	- msg_size - Needs to set to at least <db_block_size>, but we recommend 
	  setting it to 32768, since Oracle9i supports different block sizes for each 
	  tablespace.
	- max_async_req - Should be set to at least 100 but 256+ may provide better 
	  performance.
	- max_sessions - Should be set to at least <# of Oracle processes + 20>, 
	  example: 500	
 HP TRU64 (UDP Protocol):
	UDP related OS parameters are queried with the following command:
		/sbin/sysconfig -q udp 
	udp_recvspace 
	udp_sendspace 


2. If the interconnect is slow, busy, or faulty, you can look for dropped packets,
retransmits, or cyclic redundancy check errors (CRC).  You can use netstat commands
to check the networks.  On Unix, check the man page for netstat for a list of options.  
Also check the OS logs for any errors and make sure that inter-instance traffic is 
not routed through a public network.  


With most network protcols, you can use 'oradebug ipc' to see which interconnects 
the database is using:

  SQL> oradebug setmypid
  SQL> oradebug ipc

This will dump a trace file to the user_dump_dest.  The output will look something 
like this:

SSKGXPT 0x1a2932c flags SSKGXPT_READPENDING     info for network 0
        socket no 10    IP 172.16.193.1         UDP 43749
        sflags SSKGXPT_WRITESSKGXPT_UP  info for network 1
        socket no 0     IP 0.0.0.0      UDP 0...

So you can see that we are using IP 172.16.193.1 with a UDP protocol.


3. A large number of processes in the run queue waiting for CPU or scheduling
delays.  If your CPU has limited idle time and your system typically processes 
long-running queries, then latency may be higher.  Ensure that LMSx processes get 
enough CPU.

4. Latency can be influenced by a high value for the DB_FILE_MULTIBLOCK_READ_COUNT 
parameter. This is because a requesting process can issue more than one request 
for a block depending on the setting of this parameter.  


ADDITIONAL RAC AND OPS PERFORMANCE TIPS
---------------------------------------

1. Poor SQL or bad optimization paths can cause additional block gets via the
interconnect just as it would via I/O.  

2. Tuning normal single instance wait events and statistics is also very 
important.

3. A poor gc_files_to_locks setting can cause problems.  In almost all cases 
in RAC, gc_files_to_locks does not need to set at all.  


4. The use of locally managed tablespaces (instead of dictionary managed) with 
the 'SEGMENT SPACE MANAGEMENT AUTO' option can reduce dictionary and freelist 
block contention.  Symptoms of this could include 'buffer busy' waits.  See the 
following notes for more information:

  Note 105120.1
  Advantages of Using Locally Managed vs Dictionary Managed Tablespaces 

  Note 103020.1 
  Migration from Dictionary Managed to Locally Managed Tablespaces 

  Note 180608.1
  Automatic Space Segment Management in RAC Environments


Following these recommendations can help you achieve maximum performance in
your clustered environment.


RELATED DOCUMENTS
-----------------
Oracle Documentation
Note 188135.1 - Documentation Index for Real Application Clusters and Parallel Server 
Note 94224.1 FAQ- STATSPACK COMPLETE REFERENCE 
Note 135714.1 - Script to Collect RAC or OPS Diagnostic Information 
Note 157766.1 - Sessions Wait Forever for 'global cache cr request' Wait Event...
Note 151051.1 - PARAMETER:CLUSTER_INTERCONNECTS
Note 120650.1 - Init.ora Parameter "OPS_INTERCONNECTS" Reference Note

*  유닉스는 내부 프로세스 간의 커뮤니케이션을 위하여 세마포어를 사용한다.
 세마포어는 유닉스에 의해서 증감되는 정수(integer) 값 이다. 하나의
 세마포어에 대해서 하나의 프로세스만이 작업을 할 수 있도록 하여 프로세스
 간의 동기화를  유지하는데 이용된다.  다른 프로세스가 사용 중인 세마포어를
 이용하고자 하는  프로세스는 세마포어의 상태가 증가되거나 0 이 될 때 까지
 기다리게 된다.  (옵션에 따라 다를 수 있다).

*  유닉스에서의 세마포어는 한개 씩 이용되는 경우는 거의 없기 때문에 보통
 세마포어 집합으로 관리된다. 유닉스 커널이 설정될 때 시스템에서 사용
 가능한  세마포어의 최대 갯수와 세마포어 집합 당 최대 세마포어 갯수 및 할당
 가능한 세마포어 집합의 최대 갯수가 설정된다. 이 값들은 유닉스 커널을 다시
 만들고  시스템을 리부팅 하여야만 변경이 가능하다.

       <오라클과 세마포어>

   오라클은 백그라운드 프로세스들 간의 Concurrency 를 조절하기 위하여
 세마포어를 사용한다.  그리고 Fast(Shared Memory) Driver 가 사용되는 경우
 유저 프로세스와  쉐도우 프로세스 간의 Two-Task Communication 에도
 사용된다.

      <사용 중인 세마포어>

  현재 시스템에 할당된 세마포어를 확인하는 명령은 다음과 같다.

  # ipcs -sb

 이 명령은 할당된 모든 세마포어 집합과 ID Number, Owner, 각 집합의
 세마포어 수 등을 보여준다.  때때로 비정상적으로 종료된 오라클 프로세스에
 의해서  점유된  리소스가 릴리스 되지 않고 남아 있는 경우가 있다.  만약,
 오라클이 Shutdown 상태인데도 불구하고  ipcs  -sb 를 통해서 보았을 때
 오라클이 점유한 세마포어가 사용중으로 나온다면 그것들을 IPCRM명령으로
 Free 시켜야 한다.
 즉,  오라클이 할당한 세마포어 집합에 대하여

              #ipcrm -s ID   (ID는 ipcs 에서 출력됨)

 명령으로 릴리스 시킨다.   아니면 시스템을 리부팅 하여도 된다.

      <데이타베이스의 기동>

  오라클은 백그라운드 프로세스에 필요한 모든 세마포어를 데이타베이스
 기동시에 할당한다. init<SID>.ora 화일의 Processes 파라미터는 오라클에서
 할당할 최대 세마포어  갯수를 결정한다.

 ?가장 흔하게 발생하는 에러는 데이타베이스 기동시에 나타나는 다음과 같은
 에러이다.
     
      ORA-7279  :  spcre:semget error, unable to get first semaphore set

  시스템은 한 집합내에 가장 많은 세마포어를 가진 것이나  Processes 변수에
 의해 설정되는 세마포어 갯수 중 적은 값을 가진 첫번 째 세마포어 집합을
 할당하려고  한다.  만약, 시스템에 설정된 세마포어가 부족하거나, 세마포어가
 이미 너무  많이  사용중이거나, 사용중이지 않은 세마포어 집합이 세마포어를
 너무 많이  갖고 있는가를 체크해 보고 그렇지 않다면 시스템에 충분한
 세마포어를  할당하도록  한다.

 ?설정된 세마포어가 없거나 모든 세마포어가 이미 할당된 상태라면 다음과
 같은 에러가 발생한다.
   
      ORA-7251  :  spcre:semget error, could not allocate any semaphores

 ?첫번째 세마포어 집합이 할당되었지만 두번째 세마포어를 할당받지 못하면
 다음과 같은 에러가 발생한다.
 
      ORA-7252  :  spcre:semget error, could not allocate semaphores
 
  죽어있는 오라클 프로세스에 의해서 세마포어가 점유되어 있는가를 확인하고
 만약 그런 문제가 아니라면 더 많은 세마포어를 할당함으로써  문제를 해결할
 수 있다.
 
    <shutdown abort>
 
  Shutdown abort 명령이 내려지면 사용자 Process가 끝나기를 기다리지 않고
 오라클 백그라운드 프로세스는 죽게되고 그것에 의해서 점유된 세마포어는
 Release 된다. 사용자는 세마포어를 늘리거나 줄여서 데이타베이스에
 작업을요구할 때야 비로소 데이타베이스가 Shutdown 되었음을 알게 된다. 이
 때  사용자에 의한 세마포어 변경 요구는 실패하게 되며  유저 프로세스와
 오라클 Shadow Process도 함께 죽게 된다. 그러면서 다음과 같은 에러가
 발생한다.
 
       ORA-7264  :  spwat:semop error, unable to decrement semaphore
       ORA-7265  :  sppst:semop error, unable to increment semaphore

     <MIPS RISC 기반의 유닉스 시스템>

  DEC RISC Ultrix, MIPS machine 같은 MIPS RISC 기반의 유닉스 시스템의
 경우에는 오라클은 Startup시에 Latching을 위하여 별도의 세마포어를
 할당한다. 오라클은 이 때 할당된 세마포어를 사용자가 데이타베이스에 접속할
 때 Latch 로 사용한다. 프로세스가 죽게되면 프로세스에 의해서 변경된
 세마포어는 원래의 상태로 되돌아 간다. 따라서 접속하는 모든 프로세스는 Undo
 Structure를 할당할 수 있어야 하는데 Undo Structure가 충분하지 못하면
 다음과 같은 에러가 발생한다.

        ORA-9702  :  sem_acquire: cannot acquire latch semaphore

 해결방법은 Undo Structure가 사용가능할 때까지 기다리든지 시스템의 Undo
 Structure 의 최대값(SEMMNU)를 늘리면 된다.

        <Fast Driver의 사용>

  Fast Driver에 의해서 데이타베이스에 접속되는 경우에는 Shared Memory
 Buffer에 대한 사용허가를 관리하기 위하여 세마포어가 사용된다. 이 때 하나의
 접속되는 세션마다 3개의 세마포어로 구성된 세마포어 집합이 할당된다.

 ?시스템의 세마포어가 모두 할당되었다면 다음과 같은 에러가 발생한다.

          ORA-2721  :  osnseminit: cannot create semaphore set

  이 경우에는 이용가능한 세마포어가 생길 때 까지 기다려야 한다. 그리고
 비정상적으로  프로세스를 종료하는 경우에는 할당된 세마포어가 Release되지
 못하며 어떤 프로세스가 어떤  세마포어를 사용하는가를 구분하기 힘드므로
 사용상의 주의가 필요하다.

      <세마포어 사용 계획>

 세마포어 커널 파라미터의 이름, 조정 방법 및 커널 재생성 방법은 시스템에
 따라서 다르다.  필요한 세마포어의 갯수는 다음의 공식으로 구할 수 있다.

   proc(init<SID>.ora에서의 processes 파라미터)
   +  test(MIPS RISC 프로세서를 쓰는 경우는 1, 그 외에는 0)
   + 3 * f(fast driver connection 갯수)
   + sys(오라클 외의 프로그램에서 필요한 세마포어 수)
  ------------------------------------------------------------
   = tot(필요한 최소한의 세마포어 수)

  세마포어의 최대 갯수를 지정하는 파라미터(보통 SEMMNS)는 최소한 위에서
 계산한  값보다 커야 한다.

  일반적으로 하나의 집합마다 가능한 세마포어의 최대 갯수(보통 SEMMSL)는
 10~25 정도이다. fast driver를 많이 쓰는 경우라면 세마포어 집합의 갯수가 더
 많이  필요하다.

제목 : 화일의 손상 여부를 확인하는 dbv 사용 방법
==============================================

dbv 란 database verify 의 약자로, 7.3.2 부터 지원되는 유틸리티입니다.
dbv 는 data 나 index block 이 어느 정도 신뢰성이 있는지, 손상(corruption)의
유무에 대한 정도를 점검해 줍니다. dbv 는 block level 까지만 점검하기
때문에, 'ANALYZE TABLE .. VALIDATE STRUCTURE CASCADE' 와는 달리 index 와
data block 간의 일치성 점검은 수행하지는 않습니다.

(dbv 는 analyze 시 table lock(TM) 이 걸리는 문제 때문에, analyze 할 수
없는 상황에서 유용하게 사용될 수 있습니다.)

사용 방법
~~~~~~~~

  Unix:         dbv FILE [options]
       
  Windows NT: DBVERFxx FILE [options]  (xx 는 Oracle server ersion)
                                     (즉, Oracle 8.0 에서는DBVERF80)
 
  옵션:
        Keyword   Description        (Default)
        ----------------------------------------------
        FILE      File to Verify     (NONE)
        START     Start Block        (First Block of File)
        END       End Block          (Last Block of File)
        BLOCKSIZE Logical Block Size (2048)
        LOGFILE   Output Log         (NONE)
        FEEDBACK  Display Progress   (0)

1. dbv 유틸리티는 data file 에 대해서만 사용될 수 있습니다.
redo log 나 control file 에 대해서는 작업할 수 없습니다.

2. raw device 에 대해서는 직접 dbv 를 수행할 수 없고, 다음과 같이
symbolic link 를 사용해야 합니다. 또한, link name 은 반드시
확장자(extension)를 주십시오

예) ln -s /dev/rvol/tools01 /user2/oraclerc/mytools01.dbf

3. raw device 에 대해서는  START 와 END 를 사용해야 합니다.
end 값을 지나치게 크게 주면, file 의 마지막 block 을 corrupt 로
report 할 수 있으니, 가급적 analyze 를 이용하십시오.

예) START=1 END=<num blocks -1>

주의 사항
~~~~~~~~
1. page number 는 해당 화일 내의 database block number 입니다.

2. 'Marked Corrupt' 나 'Failing' 이 있다면, 다시 dbv 를 수행하여
일시적인 현상인지 확인합니다.
(Datafile들은 db 가 open 된 상태이고, read-only 일 때 정확한 결과를
얻을 수 있습니다.)

만약, 재수행 시에도 위 에러가 발생한다면, 어떤 block 인지 찾아서 index
이면 ANALYZE INDEX .. VALIDATE STRUCTURE, table 이면 ANALYZE TABLE ..
VALIDATE STRUCTURE CASCADE 를 하십시오.

참고) object 찾는 방법은 FILE ID # 6, BLOCK # 82 일때,

svrmgrl
connect internal;
select * from dba_extents
where file_id = 6 and 82 between block_id and block_id + blocks -1;

예) dbv 의 결과

$ dbv file=/mnt3/rctest73/app/oracle/oradata/RC73/tools01.df

DBVERIFY: Release 7.3.4.0.0 - Production on Mon Nov 23 13:51:14 1998

Copyright (c) Oracle Corporation 1979, 1996.  All rights reserved.

DBVERIFY - Verification starting : FILE =
/mnt3/rctest73/app/oracle/oradata/RC7f

DBVERIFY - Verification complete

Total Pages Examined         : 15360
Total Pages Processed (Data) : 3086
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 2385
Total Pages Failing   (Index): 0
Total Pages Empty            : 9201
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0

cve-2012-1675개요

2012년 5월 1일, Oracle사는 자사 보안업데이트 발표 체계인 Critical Patch Update(CPU)를 통해 패치가 되지 아니한 Oracle 데이터베이스 제품 취약점에 대한 임시 조치 권고 발표[1]
CPU를 통해 패치되지 아니한 취약점에 대해 개념증명코드(PoC)가 공개되어 패치 전에 취할 수 있는 조치에 대한 보안권고
 

설명

TNS listener와 관련된 취약점으로 원격에서 사용자 인증 없이 데이터베이스에 대한 악용이 가능함
※ TNS(Transparent Network Substrate) : Oracle에서 개발한 기술로 서로 다른 Network 구성을 가지고 있는 Client/Server 또는 Server/Server 간에도 Data의 전송을 가능하게 해주는 Network 기술
 

해당 소프트웨어

Oracle Database 11g Release 2, versions 11.2.0.2, 11.2.0.3
Oracle Database 11g Release 1, version 11.1.0.7
Oracle Database 10g Release 2, versions 10.2.0.3, 10.2.0.4, 10.2.0.5
 

임시 조치 방안

 Real Application Clusters(RAC) 사용자는 My Oracle Support Note 1340831.1 참고 [2]
※ RAC(Real Application Clusters) : Oracle 데이터베이스 환경에서 클러스터링과 고가용성 기능을 가능케 하는 추가 기능
Real Application Clusters(RAC) 미사용자는 My Oracle Support Note 1453883.1 참고 [3]
상기 문서를 검토하고 벤더사 및 유지보수업체와 협의/검토 후 조치 요망
 

기타 문의사항

 한국인터넷진흥원 인터넷침해대응센터: 국번없이 118
 

[참고사이트]
[1] http://www.oracle.com/technetwork/topics/security/alert-cve-2012-1675-1608180.html
[2] https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1340831.1
[3] https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1453883.1