ORACLE/TroubleShooting2011. 12. 28. 23:54
반응형
"Pmon Failed To Acquire Latch" Messages in Alert Log -Database Hung [ID 468740.1]

  수정 날짜 15-SEP-2010     유형 PROBLEM     상태 MODERATED  

In this Document
  Symptoms
  Cause
  Solution
  References


Platforms: 1-914CU;

This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review.

Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.1.0.7 - Release: 10.2 to 11.1
Information in this document applies to any platform.
***Checked for relevance on 15-Sep-2010***

Symptoms

Database Instance hangs and connections to database using 'sqlplus' are also not possible.

Checking alert.log we see following messages

PMON failed to acquire latch, see PMON dump
Fri Oct 5 10:33:00 2007
PMON failed to acquire latch, see PMON dump
Fri Oct 5 10:34:05 2007
PMON failed to acquire latch, see PMON dump
Errors in file /dwrac/BDUMP/dwhp_pmon_1912834.trc:

This will also dump a systemstate dump and the location will be mentioned in alert.log

Also at OS level, we see that MMAN is consuming lot of CPU.






.


Cause

This issue was worked upon by development in

Bug 6488694 - DATABASE HUNG WITH PMON FAILED TO ACQUIRE LATCH MESSAGE

Bug 6488694 was closed as a duplicate of Bug 7039896.



Solution

Apply the patch for Bug 7039896.

Issue is fixed in:

Workarounds that can be used:

Disable Automatic Shared Memory Management (ASMM) i.e Setting SGA_TARGET=0

or

Set the init.ora parameter _enable_shared_pool_durations=false

References


관련 정보 표시 관련 자료


제품
  • Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition
오류
ERROR 0
반응형

'ORACLE > TroubleShooting' 카테고리의 다른 글

Memory Notification: Library Cache Object loaded into SGA  (0) 2012.03.06
ora-4031 and shared pool duration  (0) 2011.12.28
ORA-04031  (0) 2011.12.06
Share pool과 성능문제  (0) 2011.12.06
KGH: NO ACCESS" Memory Allocation  (0) 2011.11.23
Posted by [PineTree]
ORACLE/SQL2010. 6. 18. 14:51
반응형

출처 : http://energ.tistory.com/187

일반적으로 IN operation은 특정 table(view) data의 row 값에 따른 다른 table의 데이터를 추출해내고자 할 때 자주 사용되는데, 가끔 IN operation을 row가 있는지 check하는 용도로 사용하기도 한다. 그러나 row가 존재하는지에 대해서는 EXISTS라는 근사한 operation을 따로 제공하고 있다. 

주의해야 할 점은 EXISTS와 IN은 다른 점이 존재하므로 이에 대해 유의해야 한다.  EXISTS는 단지 해당 row가 존재하는지만 check하고 더이상 수행되지 않으나 IN은 실제 존재하는 데이터들의 모든 값까지 확인한다. 따라서 일반적으로 EXISTS operation이 더 좋은 성능을 보이므로 가능하면 EXISTS를 사용하는 것이 바람직해 보인다.

또한가지 EXISTS와 IN 사용시 주의해야 할 점은 join 되는 column에 NULL을 갖는 row가 존재한다면, NOT EXISTS는 true값을, NOT IN은 false 가 return 된다. 즉, NOT IN을 사용하면 조건에 맞는 데이터가 있다고 하더라도 NULL이 존재하면 "no rows selected"라고 나오게 된다. 따라서 NVL을 이용한 NULL 처리가 꼭 필요하다.

다음은 NOT EXISTS operation을 이용한 방법이다.
예제의 products table의 product_type_id column 데이터 중 일부가 NULL로 입력되어 있다.

SELECT product_type_id, name
FROM product_types outer
WHERE NOT EXISTS
  (SELECT 1
   FROM products inner
   WHERE inner.product_type_id = outer.product_type_id);

PRODUCT_TYPE_ID NAME
--------------- ----------
              5 Magazine

다음은 동일한 데이터에 대해 NOT IN을 사용했을 경우다. NULL data에 의해 조건 자체가 false가 되어 "no rows selected"라는 결과가 발생한다.

SELECT product_type_id, name
FROM product_types
WHERE product_type_id NOT IN
  (SELECT product_type_id
   FROM products);

no rows selected

다음은 NVL()을 이용해 NULL값을 처리한 후의 결과이다.

SELECT product_type_id, name
FROM product_types
WHERE product_type_id NOT IN
  (SELECT NVL(product_type_id, 0)
   FROM products);

PRODUCT_TYPE_ID NAME
--------------- ----------
              5 Magazine

NOT IN operation의 경우 위와 같은 사실을 미리 인지하고 있지 않다면 나중에 이러한 경우를 찾기는 매우 어려울 수 있다. 따라서 NULL에 대한 operation이나 table의 default column 값등의 지정 등의 세심한 주의가 필요하다.
반응형
Posted by [PineTree]