iMac 2017 Unboxing

게시 날짜: 2017/07/13, 카테고리: IT, New Things..

2009년쯤, 형이 사용하던 아이팟 터치를 보며 엄청난 충격에 빠진 적이 있었다. 그 조그만한 기계안에서 Resident Evil 이란 3D게임을 즐길 수 있었으며 수많은 음악을 넣고 이동중에 음악을 편히 들을 수 있었다. 또한 음악을 들으며 Wi-fi 가 연결되면 인터넷도 동시에 즐길 수 있었으니, 당시 스카이 im-7000 핸드폰을 사용하고 있던 나에게는 크나큰 IT 의 문화충격으로 다가올 수 밖에 없었다.

이 엔트리의 나머지 읽기 »

무언가 오랜만..

게시 날짜: 2017/07/01, 카테고리: Uncategorized

많은 내용을 기록하자, 그리고 많이 공유하자.

이런 다짐으로 시작한 이곳이 몇년째 이렇게 방치되어 있다. 물론 중간중간 필요한 부분이 있을 때마다 들어와서 참고하기는 했다. 주로 SQL Trace 관련된 부분.. 그 이외에는 없었다.

다른 블로그들을 보면 신기하긴 하다. 어떻게 그렇게 관리를 할까.. 난 정말 꾸준하지 못하다고, 금방 지쳐버리는 구나 라는 반성을 한다. 그런데 이런 반성은 언제까지 유효할까.. 그것도 걱정이긴 하다.

아무튼, 오랜만에 한글을 타이핑 하는 키감을 느껴본다.

나쁘지 않네..

Installing Oracle 11gR2(11.0.2.4) on Oracle Linux 7

게시 날짜: 2014/09/16, 카테고리: ORACLE, RAC

Install Oracle 11gR2 (11.0.2.4) on Oracle Linux 7 <Virtual Machine>

  1. Setting Up Virtual Machine

기본적으로 vmware 에서 가상 머신을 생성한다. 기본적인 VM 설정은 생략. 이더넷 어뎁터를 2개 잡는다. 따로 RAC 를 위한 공유 스토리지 디스크를 생성한다. 공유스토리지로 사용할 디스크는 SCSI 1:0 번부터 설정하여 준다.  또한 할당할 공간을 미리 포맷 하여야 한다.

가상 머신이 생성 되었으면 가상머신의 환경설정 파일(*.vmx)을 열어 아래와 같이 추가해 준다.

disk.locking = “FALSE”
diskLib.dataCacheMaxSize = “0”
scsi1.sharedBus = “virtual”

또한 각 공유 디스크에 아래와 같이 추가해 준다.

scsi1:0.deviceType = “disk”

각 디바이스별로 (공유 디스크) 추가해 주면 된다. 이 엔트리의 나머지 읽기 »

좋은 자료 찾았다.
ORA00054 발생시 참고하면 좋은 문서.

 

출처 :  http://arjudba.blogspot.kr/2009/01/ora-00054-resource-busy-and-acquire.html

 

Problem Description
In my production database Oracle 10.2g while I was adding column to one of my transaction table it fails with ORA-54 error as below.

SQL> alter table student add b number;
alter table student add b number
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified

Description of the Problem
Let’s try to produce the problem in our development environment. I have opened two session that connected to database under a schema. In one session, I have created a table and inserted data into it.
SQL> create table a (a number);

Table created.

SQL> insert into a values(1);

1 row created.

I did not yet committed data in session 1. Now in another session whenever I try to any ddl like (alter table, drop table) ORA-00054 will produce.

In another session,
SQL> alter table a add b number;
alter table a add b number
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified

SQL> drop table a;
drop table a
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified

SQL> lock table a in exclusive mode nowait;
lock table a in exclusive mode nowait
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified

Cause of the Problem
Whenever you try to do any structural changes on a table oracle try to lock the table exclusively with NOWAIT option(this is in 10.2g while in 11g you can change the wait timeout). If oracle fails to lock the table exclusively then ORA-00054 will occur.

Solution of the Problem
In 10.2g you are limited to several choices to solve the problem. To avoid it,

-Re run the DDL at a later time when the database become idle.
or,

-Kill the sessions that are preventing the exclusive lock.
or,

-Prevent end user to connect to the database and then run the DDL.

You have different views to see locking information about the table.
1)DBA_BLOCKERS: Displays a session if it is not waiting for a locked object but is holding a lock on an object for which another session is waiting. In our scenario this view will not help.

2)DBA_DDL_LOCKS: It lists all DDL locks held in the database and all outstanding requests for a DDL lock.

3)DBA_DML_LOCKS: It lists all DML locks held in the database and all outstanding requests for a DML lock.
If you query from it in the mode_held field you will see ‘row exclusive lock’.
SQL> select mode_held from dba_dml_locks where owner=’MAXIMSG’;

MODE_HELD
————-
Row-X (SX)

4)DBA_LOCK: It lists all locks or latches held in the database, and all outstanding requests for a lock or latch.

5)DBA_LOCK_INTERNAL: It displays a row for each lock or latch that is being held, and one row for each outstanding request for a lock or latch.

6)DBA_LOCKS is a synonym for DBA_LOCK.

7)DBA_WAITERS: Shows all the sessions that are waiting for a lock.

8)V$LOCK: It lists the locks currently held by the Oracle Database and outstanding requests for a lock or latch.

9)V$LOCK_ACTIVITY: This view is deprecated.

10)V$LOCKED_OBJECT: This view lists all locks acquired by every transaction on the system.

In order to see locked object query,

SQL> set linesize 130
SQL> set pages 100
SQL> col username       format a20
SQL> col sess_id        format a10
SQL> col object format a25
SQL> col mode_held      format a10
SQL> select     oracle_username || ' (' || s.osuser || ')' username
,  s.sid || ',' || s.serial# sess_id
,  owner || '.' || object_name object
,  object_type
,  decode( l.block
,       0, 'Not Blocking'
,       1, 'Blocking'
,       2, 'Global') status
,  decode(v.locked_mode
,       0, 'None'
,       1, 'Null'
,       2, 'Row-S (SS)'
,       3, 'Row-X (SX)'
,       4, 'Share'
,       5, 'S/Row-X (SSX)'
,       6, 'Exclusive', TO_CHAR(lmode)) mode_held
from       v$locked_object v
,  dba_objects d
,  v$lock l
,  v$session s
where      v.object_id = d.object_id
and        v.object_id = l.id1
and        v.session_id = s.sid
order by oracle_username
,  session_id
/

USERNAME             SESS_ID    OBJECT                    OBJECT_TYPE         STATUS       MODE_HELD
-------------------- ---------- ------------------------- ------------------- ------------ ----------
MAXIMSG (A)          142,232    MAXIMSG.A                 TABLE               Not Blocking Row-X (SX)
OMS (DBA2\ershad)    143,280    OMS.T                     TABLE               Not Blocking Row-X (SX)
OMS (DBA2\ershad)    143,280    OMS.T1                    TABLE               Not Blocking Row-X (SX)

Here we see there is 3 types of locking. In our case the object is A. And we see the sid=142 and serial#=232 is preventing us from locking the table in exclusive mode. So to achieve our task we can kill the session as below.

오라클 데이터베이스를 운영하다보면 종종 cursor: pin S wait on X 이벤트가 계속 발생하는 경우가 있다. 그저 그때 대처할 수 있는 거라곤 해당 대기 이벤트들을 KILL 해주는게 전부이지만 근본적으로 해당 mutex 를 가지고 놓아주지 않는 세션을 잡아서 KILL 해 주는게 제일 좋다.

이 엔트리의 나머지 읽기 »

TOP n SQL Ordered by CPUTIME

게시 날짜: 2012/04/05, 카테고리: ADMIN, ORACLE

특정 기간동안 CPU TIME 을 많이 가져가는 TOP 20 SQL 을 알려달라는 요청을 받았다. 지금 일하는 이 사업장에서 기존 정보를 저장해 두고 각 STAT 을 뽑아볼 수 있는 툴이 제공되기는 하지만 무언가 잘못되었는지 해당 기간동안의 TOP SQL 을 확인할 수 없었다. AWR 레포트를 통해서 확인을 해 보아도 TOP 10 은 나오지만 TOP 20 은 보여주질 못해 한번 직접 해당 정보를 뽑아볼 수 있는 쿼리를 작성해 보았다.

이 쿼리는 AWR 이 지원되는 10g 이상의 버전에서 사용할 수 있다.

이 엔트리의 나머지 읽기 »

Table Recovery using Clone DB

게시 날짜: 2011/11/15, 카테고리: ADMIN, ORACLE
태그:, ,

Table 을 purge 를 이용하여 드롭하였을 경우 플래시백 테이블 명령을 통해 복구할 수 없다. 우연찮게도 필요 없을 줄 알고 깨끗하게 지우기 위해 drop table tablename purge 를 사용하였는데, 갑자기 현업에서 그 테이블의 데이터가 필요하다고 요청이 오면 적지 않이 당황할 수 있다.

이 엔트리의 나머지 읽기 »