Undo tablespace

- 사용자가 DML 을 수행할 경우 원본 데이터(undo data)들을 저장해 두는 특별한 Tablespace

- 사용자가 생성 가능하며 관리 할 수 있음

- Undo 라는 용어는 8i 버전까지 rollback 이라는 용어로 사용됨

1. Undo tablespace 의 특징

- Oracle Server Process 는 이 Tablespace 에 Undo segment 를 생성하고 기본적으로 각 사용자 별로 undo segment(ex: _SYSMU1$) 를 할당하여 관리하며 사용자는 관여할 수 없음

- Undo tablespace 는 Instance 당 여러 개가 동시에 존재 할 수 있지만 사용되는 것은 한번에 1개이다.

-> create undo tablespace undo01 datafile '/~~~~/undo01.dbf' size 10M 으로 만들어 줘도 파라미터에 적용 시키지 않으면 바뀌지 않음

- 관리 방법은 AUM(Automatic Undo Management) 과 MUM(Manual Undo Management) 이 있음 -> 9i 버전 부터는 AUM 방식을 권장

2. Undo Tablespace 의 사용 목적

- Transaction Rollback – 사용자가 rollback 이라는 명령어를 수행할 경우에 이곳에 저장된 undo data를 사용해서 rollback 을 수행함

- Read Consistency (읽기 일관성) –CR 작업을 통해 트랙잭션이 끝나지 않은 데이터는 변경 전 데이터를 보여줌.

- 다음 그림과 같이 update 가 발생하면 Datafile 에서 DB Buffer Cache 로 데이터 블록을 불러오게 되며 블록에는 lock 이 설정되어 아무도 내용을 볼 수 없는 상태

- 또한 원본 Data(Undo Data) 는 undo segment 에 저장되게 된다.

 - Update 가 수행되던 중 사용자 2에 의해서 select 가 수행되었을 때 undo segment 에서 DB Buffer Cache 로 원본 Data 를 복사하여 사용자 2에게 결과값을 보여주게 됩니다. 대신 1(홍길동) Data 는 lock 이 설정되어 commit 이나 rollback 이 수행되기 전까지는 1 block 에 다른 사용자가 접근할 수 없습니다.

- Transaction Recovery (Instance recovery) : 운영 중이던 DB 서버가 비정상적으로 종료 되었을 때 Roll Forward 와 Roll backward 작업을 수행해서 Dirty Database 를 Clean DB 로 만들어 주는 과정에 사용됨

- Undo Parameter 확인

- 신규 Undo Tablespace 생성

SQL>create undo tablespace undo01

2 datafile '/data/temp2/undo01.dbf' size 10M

3 autoextend on;

Tablespace created.

- Undo tablespace 를 생성 하여도 파라미터 파일을 변경 하여야 함.

SQL>alter system set undo_tablespace=undo01;

-PFILE 의 경우 파라미터 값을 직접 변경해야 나중에 다시 DB Open 시 문제가 발생하지 않는다.

- 각 세션 별로 사용중인 undo segment 확인

SQL>select s.sid,s.serial#,s.username,r.name "ROLLBACK SEG"

1 from v$session s,v$transaction t,v$rollname r

2 where s.taddr=t.addr

3 and t.xidusn = r.usn;

3. Undo segment 할당되는 원리

- Undo tablespace 는 Data file 의 크기가 증가만 되고 절대 줄어들지 않는다.

<하늘색 : 트랜잭션 완료, 갈색 : 트랜잭션 미완료>

다음과 같이 사용자가 DML(E) 을 수행하게 되면 가장 먼저 Server Process 는 Undo Segment 를 확보하게 되는데 이 때 기존에 만들어져 있던 Segment 중 트랜잭션이 완료된 것이 없는지를 확인한 후 그 곳에 덮어쓰게 됩니다.

- 다음과 같이 완료된 트랜잭션이 존재하지 않을 경우 새로운 undo segment 를 새로 생성하게 됩니다.

- 이런 식으로 더 이상 빈 공간이 존재하지 않을 경우 Data file 의 저장 공간이 허요하는 범위까지 늘어나다가 만약 더 이상 공간이 없게 되면 하나의 Segment 에 2개 세션 이상의 undo data를 함께 기록하게 됩니다. 이것조차 불가능하게 된다면 해당 트랜잭션은 에러를 발생 합니다.

- Undo tablespace 의 용량을 줄이기 위해서는 새로운 Undo Tablespace 를 생성후 파라미터 값을 변경시킨 다음 기존 Undo Tablespace 를 삭제 하셔야 합니다.

4. 주요 Parameter

- undo_retention àcommit 수행 후에도 해당 undo segment 내의 데이터를 다른 서버 프로세스가 덮어 쓰지 못하고 일정 시간동안 대기 시켜주는 파라미터이며 이 파라미터는 undo segment 의 여분이 존재할 경우에만 적용되며 항상 보장하지 않습니다.

- undo_retention_guarantee à undo_retention 파라미터는 여분이 존재하지 않을 경우 undo segment 가 재사용 되어지는데 반해 undo_retention_guarantee 파라미터는 설정된 시간동안 무조건 보장해줍니다.

- Oracle 10g 버전 부터는 ORA-01555:Snapshot too old 라는 에러를 줄이기 위해 undo retention 을 자동으로 관리하는 기능을 제공합니다.

- 다음은 undo tablespace 를 확인하고 guarantee 로 바꿔주는 명령어

SQL>alter tablespace undotbs retention noguarantee;

- no guarantee 로 변경하는 명령어

- NOT APPLY 는 Undo tablespace 가 아니므로 적용할 수 없습니다.

출처 - http://thankyeon.tistory.com/31

DML 문의 처리과정
==================

1. 해당 트랜잭션에 대해 언두 세그먼트를 할당한다.  이 경우 현재 온라인 상태인 언두 세그먼트 중
   하나를 우선적으로 사용한다. 언두 세그먼트의 선택은 랜덤하게 이루어지며, 다른 트랜잭션이 사용
   중이면 3번까지 재시도 한다.(undo segment는 block 단위로 owner ship을 갖는다.)
   이 과정에서 실패하면 오프라인 상태의 언두 세그먼트를 온라인화해서 사용한다.
   만인 이과정까지 실패하면, 새로운 언두 세그먼트를 생성한다.
   위 과정에서 언두 세그먼트를 할당받지 못하면 오라클 8i까지 사용하던 롤백 세그먼트
   알고리즘을 사용한다. 즉, 이미 다른 트랜젝션에 의해 사용 중인 언두 세그먼트 중 가장 사용량이
   적은 것을 사용한다. 서버 프로세스가 언두 세그먼트를 획득하는 시점에 적당한 온라인 상태의
   언두 세그먼트가 없으면 온라인 상태의 언두 세그먼트가 확보될 때까지 
   enq: US - contention 이벤트를 대기한다.
   
2. 언두 세그먼트를 할당받으면, 언두 세그먼트 헤더에 트랜잭션 테이블 슬롯(Transaction table slot)을
   생성한다.
   
3. 트랜젝션 테이블을 생성하고 나면 TXID(Transaction ID)를 생성하고, 현재 트랜잭션에 할당한다.
   TXID는 V$TRANSACTION 뷰의 XIDUSN, XIDSLOT, XIDSQN으로 표현되는데, 이 값은 트랜젝션에 할당된
   언두 영역의 언두 세그먼트 헤더에 존재하는 트랜잭션 테이블의 정확한 위치를 가리킨다. 트랜잭션은
   반드시 언두 영역을 할당받은 다음에 ID를 부여받은 것에 유의하자.
 
4. 트랜잭션의 대상이 되는 블록들을 버퍼 캐시로 적재하고 블록 헤더의 ITL(Interested Transaction List)에
   트랜잭션 엔트리(Transaction Entry)를 등록한다. 만일 ITL에 엔트리를 등록할 공간이 없다면, 공간이
   확보될 때까지 enq:TX - allocate ITL entry 이벤트를 대기한다.
   
5. 변경할 블록들의 변경 정보는 PGA에 체인지 벡터라는 이름으로 저장된다. 보통 하나의 로우가 변경되는 경우
   각각 언두 헤더 블록(체인지 벡터#1), 언두 블록(체인지 벡터#2), 데이터 블록(체인지 벡터#3)에 해당하는
   체인지 벡터들이 생긴다. 프로세스는 PGA의 체인지 벡터들을 리두 레코드(또는 리두 엔트리)라는 이름으로
   리두 버퍼(Redo Buffer)로 복사한다. 리두 버퍼에 변경 내용을 복사하는 과정에서 redo copy 래치, redo
   allocation 래치, redo writing 래치를 획득해야 한다. 이 과정에서 래치 경합이 발생하면 각각 
   latch: redo copy, latch: redo allocation, latch:redo writing 이벤트를 대기한다.
   
6. 이전 이미지(Before Image)에 대한 정보를 언두 블록에 기록하고, 데이터 블록을 변경한다. 변경된
   데이터 블록은 더티(Dirty) 상태가 된다. 또한 변경된 데이터 블록에 대한 CR 블록이 버퍼 캐시에 생성된다.
   만일 변경하고자 하는 로우가 현재 다른 트랜잭션에 의해 변경 중(즉 변경 후 아직 트랜잭션이 종료되지 않은
   상태)이라면 해당 트랜잭션이 종료되기를 기다려야 하며 enq: TX - row lock contention 이벤트를 대기한다.
   
7. 커밋이 수행되면, 트랜잭션에 SCN을 할당한다. 커밋 정보는 리두 버퍼에 저장된다.

8. 언두 세그먼트 헤더의 트랜잭션 테이블에 커밋이 이루어졌음을 저장하고, 락을 포함한 모든 리소스에 대한 점유를
   해제한다.
   
9. 리두 버퍼의 내용이 리두 로그 파일에 기록된다. 변경된 블록들은 이후 DBWR에 의해 데이터 파일로 기록된다.

출처 - http://support.dbworks.co.kr/index.php?document_srl=3593&mid=ora_tb

트랜잭션 내부작업 진행 9단계

1.  해당 트랜잭션에 대해 언두 세그먼트를 할당.

2. 언두 세그먼트에 트랜잭션 테이블 슬롯을 생성.

3. TXID(transaction ID) 생성

SQL> delete scott.emp;

SQL> select xidusn, xidslot, xidsqn from v$transaction;

4. 블록헤더의 ITL에 트랜잭션 엔트리를 등록, ITL에 공간이 없다면 enq:TX – allocate ITL entry 이벤트 대기

5. 변경정보는 PGA에 체인지 벡터라는 이름으로 저장된다. 언두헤더블록, 언두블록,데이터블록 프로세스는 PGA의 체인지 벡터들을 리두 레코드라는 이름으로 리두버퍼에 복사한다.

6. 이전 이미지에 대한 정보를 언두 블록에 기록하고, 변경된 데이터 블록에 대한 CR블록이 버퍼캐시에 생성된다. 만일 다른 트랜잭션에 의해 변경 중이라면 종료될 때까지 enq:TX – row lock contention 이벤트 대기

7. 커밋이 수행되면, 트랜잭션에 SCN을 할당, 커밋 정보는 리두버퍼에 저장

8. 언두 세그먼트헤더의 트랜잭션 테이블에 커밋정보를 저장, 락을 포함한 리소스에 대한 점유 해제

9.  리두버퍼의 내용이 리두 로그파일에 기록된다

출처 - http://salme.tistory.com/1

1)SELECT 명령어 처리

(PARSING LEVEL) 

1.서버 프로세스 구문분석 요청

  사용자가 SQL 명령어들을 입력하면 SQL명령어는 text string으로 서버로 전송하게 된다.

2.소프트 파싱과 하드 파싱

  SGA의 라이크러리 캐쉬에서 동일문장을 실행했던 실행계획을 검색 동일 실행계획을 존재하면 DB버퍼캐쉬에서 해당결과를 찾아 바로 유저에서 Fetch 작업을 함, 동일문장이 존재하지 많으면 딕셔너리 캐쉬에서 오브젝트를 참조하여 하드파싱한다.

3. 문장검사

parsing과정이 많기 때문에 오라클의 처리 속도를 올리기 위해서는 동일한 SQL문을 사용하여 library cache에서 바로 실행을 할 수 있게 해주는 것이 기본이 된다.

4. 데이터베이스 분석

  딕셔너리 캐쉬에서 티이블 및 갈럼 존재 유무를 확인한다.

5. 쿼리 단순화

  옵티마이져가 좀 더 좋은 실행계획을 생성하기 위해 내부적으로 SQL을 변경한다.

6. 권한확인

  시스템 테이블 스페이스에 저장된 DBA_SYS_PRIVS, DBA_TAB_PRIVS 뷰를 이용해 권한 확인한 후 딕셔너리 캐쉬에 저장한다.

7. 락 수행

   USER가 DML를 던지면 변경되는 ROW에 대한 ROW LOCK과 TABLE에 대한 TABLE LOCK이 발생.

 ROW LOCK (TX)

SQL 문장에서 WHERE 조건에 해당되는 ROW에 대하여 다른 유저들이 변경할 수 없도록  EXCLUSIVE LOCK 이 생긴다.  TX LOCK이 걸린 ROW는 DML 문장을 실행한 유저가 COMMIT이나 ROLLBACK을 할때 까지 걸리므로 다른 유저들이 변경할 수 없다.

 TABLE LOCK (TM)

   TX LOCK이 걸린 ROW가 저장된 TABLE에 대한 LOCK 이다.
DML SQL 문장을 수행하는 중에, 해당 테이블이 ALTER 나 DROP 되는 것을 방지하기 위해서 TM LOCK을 사용한다.
 같은 테이블에서 실행할 수 있는 SQL 문장과 실행할 수 없는 SQL 문장을 구분하기 위해서다. 
TM LOCK에는 RS(ROW SHARE), RX(ROW EXCLUSIVE), S(SHARE), SRX(SHARE ROW EXCLUSIVE), X(EXCLUSIVE) 가 있다.
 

8. Excute Plan 및 Tree 생성

9. 결과물이 SGA에 저장

(EXCUTE LEVEL)

  실행계획을 가지고 DB버퍼 캐쉬에서 해당 ROW를 검색 후 존재하면 결과값을 우저에서 전홍 한다.

 존재하지 않으면 데이터 파일에서 해당값을 검색하여 DB버퍼 캐쉬로 읽어 올린다.

(FETCH LEVEL) 

 유저에서 해당 결과값을 화면으로 출력해준다.

2) DML 구문 처리

(PARSING LEVEL)

1. 서버프로세스 구문분석요청

2. SGA의 라이브러리 캐쉬에서 동일문장 검색 .........-> 소프트 파싱 or 하드 파싱

3. 문장검사 

4. 데이터 베이스 분석 ... 딕셔너리 캐쉬에서 데이블 및 칼럼 존재 유무 확인

5. 옵티 마이저가 좀더 좋은 실행계획을 생성하기위한 쿼리 단순화

6. 권한확인

7. 락수행

8. Excute Plan 및 Patse Tree 생성

9. 결과물이 SGA에 저장

(EXCUTE LEVEL)

1. 실행 계획을 가지고 데이터파일의 해당 값을 검색하여 DB 버퍼 캐쉬로 읽어 올린다.

2. 서버프로세스는 언두 세그 먼트를 확보한다.

3. 변경된 내용을 리두 로그버퍼에 저장한다.

4. 변경 이전 이미지를 언두 세그먼트에 저장한다.

5. DB버퍼 캐쉬에 변경된 내용을 적용한다.

6. 유저에게 1row update라는 결과를 전송한다.

7. commit 명령어를 수행하면 리두 로그버퍼에 있는 변경된 내용을 리두 로그 파일에 기록한다.

   단 시점은 사용자에 의한 commit 명령이 발생 했을 경우

       리두로그 버퍼가 1/3이상 사용되었을 경우

       1MB 이상의 리두가 생성되었을 경우

       3초마다 리두 로그 파일에 내려 쓰여 진다.

출처 - http://mes2good.egloos.com/761982

Part1 오라클서버

1. 오라클 구성요소의 개요

- 오라클 주요 구성요소 : 서버, 인스턴스, 데이터베이스

* 인스턴스 :  오라클 인스턴스는 백그라운드 프로세스와 메모리 구조로 구성됩니다. 
                      인스턴스는 사용자가 데이터베이스의 데이터에 접근하기 위해서 반드시

                      시작되어 있어야 합니다

          인스턴스가 시작할 때 System Global Area(SGA)가 할당되고 오라클 
          백그라운드 프로세스들이 시작됩니다.

* 데이타베이스 : 오라클 데이터베이스는 데이터베이스 정보를 위한 실제 물리적인 저장을 
                           제공하는 운영체제 파일들로 구성됩니다 데이터베이스 파일들은 데이터가 
                           일관되게 유지되고 인스턴스 실패 시에 복구될 수 있도록 하는데 사용됩니다

1) 오라클 서버

- 데이터베이스 서버는 정보 관리에 아주 중요한 부분입니다. 일반적으로 많은 사용자가 동일한 데이터를 동시에 접근하는 환경에서 서버는 상당한 양의 데이터를 관리합니다. 또한 데이터베이스 서버는 권한이 없는 접근을 금지해야 하며 장애 시에 효과적인 복구를 제공해야 합니다

- 오라클 서버는 오픈되고 포괄적이고 통합된 접근을 제공하는 데이터베이스 관리 시스템

- 오라클 서버는 오라클 인스턴스와 오라클 데이터베이스로 구성

2) 오라클 인스턴스

- 오라클 인스턴스는 아래 그림과 같이 System Global Area(SGA) 메모리 구조와 데이터베이스 관리 에 필요한 백그라운드 프로세스들로 구성

  - 하나의 인스턴스는 각각의 운영체제에서 지정하는 방법에 따라 확인되며, 한번에 하나의 데이터베이스에 대해서 오픈되고 사용

- 오라클 인스턴스는 오라클 데이터베이스에 접근할 수 있는 방법

- 오라클 인스턴스는 하나의 데이터베이스에만 오픈

- 오라클 인스턴스는 메모리와 백그라운드 프로세스들로 구성

3) 접속과 세션

- 사용자는 오라클 데이터베이스에서 SQL 문장을 수행하기 전에 인스턴스에 접속해야만 합니다

- 인스턴스에 접속하는 과정

  . 사용자가 SQL*Plus를 시작하면 사용자 프로세스가 시작됩니다.

  . 사용자가 오라클 서버에 로그온 하면 서버에는 서버 프로세스가 시작됩니다

  . 서버 프로세스는 사용자 프로세스를 대신하여 인스턴스와 통신합니다

-  접속 : 접속은 사용자 프로세스와 서버 프로세스간의 통신 수단입니다. 데이터베이스 사용자는

             다음의 세가지 방법 중에 하나로 오라클 서버에 접속합니다

  . 오라클 인스턴스가 수행되고 있는 시스템에 로그온하여 SQL*Plus를 수행

  . 오라클 인스턴스가 수행되고 있는 시스템과 네트워크로 연결된 컴퓨터에서 프로그램을 수행

  . 사용자 컴퓨터는 오라클 인스턴스와 네트워크로 연결되어 있는 응용프로그램 서버나 네트워크

    서버에 연결되어 있음

- 세션 : 세션은 사용자가 오라클 서버에 접속할 때 시작하여 로그아웃 할 때 끝납니다

※ Dedicated Server 환경에서는 한 개의 사용자 프로세스와 한 개의 서버 프로세스가 통신합니다

※ Shared Server 환경에서는 여러 사용자 프로세스가 한 개의 서버 프로세스를 공유합니다

4) 오라클 데이타베이스

- 물리적 구조

  . 물리적인 구조는 운영체제 파일들로서 데이터 파일, 리두 로그 파일, 컨트롤 파일로 구성되어 있음

  . 리두로그파일: 에러 시에 데이터들을 복구하기 위해 데이터베이스에서 만들어진 변경 정보들을

                           갖고 있음

  . 데이터파일 : 실제데이터를 갖고 있음

  . 컨트롤파일 : 데이터베이스의 무결성을 보장하기 위해 필요한 정보들을 갖고 있음

  . 오라클 서버는 데이터베이스를 구성하는 파일들은 아니지만 다른 파일들도 사용합니다

     @ 파라미터 파일 : 오라클 인스턴스의 특징을 정의하는 파라미터들을 갖고 있음

     @ 패스워드 파일 : 오라클 인스턴스를 시작하고 종료할 수 있는 권한이 있는 사용자를 인증

     @ 아카이브 파일 : 복구할 때 필요한 리두 로그 파일을 복사한 파일

- 물리적 구조

  . 논리적인 구조는 테이블스페이스, 세그먼트, 익스텐트, 블럭으로 구성되어 있으며 데이터베이스의

    물리적인 공간이 어떻게 사용되어 지는지를 나타냅니다

  . 테이블 스페이스 : 오라클 데이터베이스는 한 개 이상의 테이블 스페이스를 갖고 있음 

                               한 개의 테이블 스페이스는 한 개 이상의 세그먼트를 갖고 있음

  . 세그먼트 : 한 개의 세그먼트는 익스텐트들로 만들어짐

  . 익스텐트 : 한 개의 익스텐트는 논리적인 블럭들로 만들어 짐

  . 블럭 : 한 개의 블럭은 읽고 쓰기 위한 가장 작은 단위

2. 메모리 구조

- 오라클 메모리 구조는 System Global Area(SGA)와 Program Global Area(PGA)로

   구성되어 있습니다. SGA는 인스턴스가 시작할 때 할당되며 오라클 인스턴스의

   기본 구성요소입니다. PGA는 서버 프로세스가 시작할 때 할당됩니다 

1) System Global Area

- SGA는 Shared Global Area라고도 부릅니다. SGA에는 데이터베이스 프로세스들에 의해

   공유되는  데이터베이스 정보와 오라클 서버를 위한 데이터와 제어 정보가 저장되며, 오라클이

   설치된 컴퓨터의 가상 메모리에 할당됩니다

- SGA의 종류

  . Shared Pool

  . Database Buffer Cache

  . Redo Log Buffer

  . Large Pool

  . Java Pool

- 동적SGA

  . 오라클 9i부터, 동적 SGA는 인스턴스를 종료하지 않고 SGA 형태를 변경할 수 있는 기본조직을

    이행하므로, 인스턴스를 종료하지 않고 Database Buffer Cache와 Shared Pool의 크기를 변경할

    수 있습니다. Database Buffer Cache와 Shared Pool의 크기는 처음에는 작게 구성되었다가

    그들의 작업에 따라 SGA_MAX_SIZE의 최대 크기까지 성장 또는 축소될 수 있습니다

- SGA 크기

  . DB_CACHE_SIZE : 기본 블럭들의 Cache 크기 / UNIX의 기본은 48MB, NT의 기본은 52MB임

  . LOG_BUFFER : 리두 로그 버퍼에 할당될 바이트 수

  . SHARED_POOL_SIZE : 공유풀에 할당될 바이트 수 /기본은 16MB, 64bit에서는 64MB임

  . LARGE_POOL_SIZE : 대형풀의 크기 / PARALLEL_AUTOMATIC_TUNING=true로 설정되지

                                      않으면 기본은 0임

  . JAVE_POOL_SIZE : 자바풀의 크기, 기본은 24MB임

- SGA 크기 : SGA_MAX_SIZE - DB_CACHE_SIZE - LOG_BUFFER - SHARED_POOL_SIZE -

                      LARGE_POOL - JAVA_POOL

- 할당 단위 : Granule은 연속된 가상 메모리 할당 단위입니다. Granule의 크기는 SGA_MAX_SIZE

                      파라미터 값에 의해 계산된 SGA 전체 크기에 의존합니다

  . 계산된 SGA 크기가 128MB보다 적을 때 Granule 크기는 4MB

  . 계산된 SGA 크기가 128MB보다 클 때 Granule 크기는 16MB

  . Database Buffer Cache와 Shared Pool은 Granule 경계에 따라 확장되고 축소될 수 있습니다.  

    인스턴스가 시작할 때 오라클 서버는 각각의 구성요소에 한 개의 Granule을 할당합니다.

    데이터베이스가 계속 사용되면서 그들이 요구하는 것에 따라 더 많은 Granule을 할당합니다

  . SGA의 최소 구성은 다음과 같이 3개의 Granule입니다

    Redo Buffer를 포함한 Fixed SGA에 1개를 할당

    Database Buffer Cache에 1개를 할당

    Shared Pool에 1개를 할당

2) Shared Pool

- Shared Pool은 가장 최근에 실행된 SQL 문장과 가장 최근에 사용된 Dictionary를 저장하기 위해

   사용되며 아래 그림과 같이 Library Cache와 Data Dictionary Cache로 구성됩니다

-  Shared Pool 의 크기

  . Shared Pool은 다시 사용될 SQL Execution plan과 PL/SQL package, procedure, function과

    Cursor 정보 들을 공유하기 위해 사용됩니다

  . Shared Pool의 크기는 초기 파라미터 SHARED_POOL_SIZE에 의해 결정됩니다.

    또한 ALTER SYSTEM SET 명령을 사용하여 동적으로 조정할 수 있습니다. 그렇지만

    전체 SGA 크기는 SGA_MAX_SIZE를 초과 할 수 없습니다

- 초기 파라미터 SHARED_POOL_SIZE로 크기를 결정합니다

- ALTER SYSTEM SET SHARED_POOL_SIZE = 64M

- 전체 SGA 크기는 SGA_MAX_SIZE를 초과 할 수 없습니다

- Library Cache

  . Library Cache 크기는 Shared Pool의 크기에 의존하며 가장 최근에 사용된 SQL과 PL/SQL 문장

    에 관한 정보가 저장됩니다. 그러므로 Shared Pool의 크기가 너무 작으면, 이들 문장이 계속해서

    Library Cache에 올라오게 되어 성능에 영향을 미치게 됩니다

  . Library Cache는 LRU 알고리즘이 사용되므로 Cache가 꽉 차면 최근에 적게 사용된 Execution

    Plan과 Parse Tree를 제거하여 새로운 문장을 위한 공간을 만듭니다

  . Shared SQL : 다시 수행될 SQL문장을 위해 Execution Plan과 Parse Tree를 저장하며 동일한

                          SQL 문장이 다시 수행되면 Shared SQL에서 Parse 정보를 가져옴

                          동일한 문장이 되려면 글자와 스키마와 변수가 같아야 함

  . Shared PL/SQL : 가장 최근에 사용된 PL/SQL 문장을 저장

- Data Dictionary Cache

  . Data Dictionary Cache는 Row Cache 라고도 부릅니다. 오라클 서버에 의해 Dictionary 정보가

    필요하면 Dictionary Table로부터 정보를 읽어 Data Dictionary Cache에 저장합니다. Data

    Dictionary의 크기는 Shared Pool에 의존하므로, 만약 Data Dictionary의 크기가 너무

    작으면 서버에 의해 필요한 정보를 반복적으로 Dictionary Table로부터 읽게 됩니다. 그러므로

    Dictionary Cache로부터 읽는 것보다 속도가 느리게 됩니다

  . Data Dictionary Cache의 기능

    가장 최근에 사용된 Database 정보를 저장함

    파일, 테이블, 인덱스, 사용자, 권한, 기타 다른 객체 정보들이 저장됨

    Parse 단계에서 서버 프로세스가 Dictionary 정보를 찾음

3) Database Buffer Cache

- Query문을 수행하면 오라클 서버는 Database Buffer Cache에서 원하는 블럭들을

   찾습니다. 해당 블럭을 Buffer Cache에서 찾지 못하면 데이터 파일에서 블럭을 읽어

   Database Buffer Cache에 저장해 놓으므로 같은 블럭에 대한 요구가 있으면 메모리에서 그

   블럭을 찾을 수 있어 Physical Read를 하지 않아도 됩니다. 오라클 서버는 Database Buffer

   Cache에서 새로운 블럭에 대한 공간을 만들기 위해 최근에 사용이 안된 블럭들을 쫓아내는 LRU

   알고리즘을 사용합니다 

- Database Buffer Cache 크기

  . Database Buffer Cache안에 있는 각 버퍼의 크기는 DB_BLOCK_SIZE 파라미터에 의해 결정되는

    오라클 블럭 크기와 같습니다. Database Buffer Cache는 독립적인 sub-cache들로 구성되는데,

    DB_BLOCK_SIZE 파라미터는 기본 블럭 크기를 결정하며 SYSTEM 테이블스페이스에 사용됩니다

  . Database Buffer Cache 크기를 결정하는 파라메타

    DB_CACHE_SIZE : 기본 Buffer Cache 크기를 결정,반드시 지정하여야 하며 0으로 설정할 수

                                 없음

   DB_KEEP_CACHE_SIZE : 다시 사용되므로 메모리에 머무르게 하고 싶은 블럭을 위한 버퍼

                                           크기를 지정함

    DB_RECYCLE_CACHE_SIZE : 다시 사용되지 않으므로 메모리에서 제거하고 싶은 블럭을 위한

                                                 버퍼 크기를 지정함

- Buffer Cache Advisory

  . Buffer Cache Advisory는 다른 Cache 크기를 가졌을 때의 행동을 예견하기 위한 통계를 모으는

    작업을 활성화 혹은 비활성화 할 수 있다는 특징을 가지고 있습니다. 이 통계에 의해 제공되는

    정보는 주어진 작업에 따라 Database Buffer Cache 크기를 적당하게 조절할 수 있도록 합니다.

    Buffer Cache Advisory 정보는 V$DB_CACHE_ADVICE에 저장되며, DB_CACHE_ADVICE 초기

    파라미터로 활성화 할 수 있습니다

  . OFF : Advisory를 위한 메모리를 할당하지 않음

  . ON : CPU와 메모리의 과부하를 초래 / OFF 상태에서 ON으로 변경하면 ORA-4031 에러가 발생함

            / READY 상태에서 ON으로 변경하면 메모리가 할당되어 있어 에러가 발생하지 않음

  . READY : Advisory는 OFF되어 있지만 메모리는 할당되어 있음

4) Redo Log Buffer

- Redo Log Buffer는 데이터 파일 블럭들에 만들어진 변경을 포함하고 있는 순환 buffer입니다 

- 이 정보는 리두 엔트리 안에 저장됩니다 /

  . 리두엔트리 : INSERT, UPDATE, DELETE, CREATE, ALTER, DROP 명령에 의해 만들어진 변경전

                       의 데이타를 다시 만들기 위해 필요한 정보를 갖고 있음 

- Redo Log Buffer 크기 : 초기 파라미터 LOG_BUFFER에 의해 결정됩니다

5) Large Pool

- Shared Server, Oracle XA, Parallel Query Buffers에서 세션 메모리를 Large Pool에

   할당하므로 오라클은 공유하는 SQL 문장을 저장하기 위해 Shared Pool을 사용할 수 있습니다.

   따라서 Shared Pool 안의 영역에서 짐을 덜 수 있습니다. Shared Pool은 Shared Session 정보,

   I/O, Backup, Recover 프로세스들을 위하여 SQL Parse Tree를 메모리에서 포기할 필요가

  없습니다. 그러므로 Shared SQL을 확장하고 축소하며 발생하는 과부하를 줄여 성능이 좋아집니다

- Backup and Restore

  . BACKUP_DISK_IO=n, BACKUP_TAPE_IO_SLAVE=true 파라미터가 정의되었으면 Recovery

     Manager (RMAN)는 Large Pool을 사용합니다. 만약 Large Pool이 충분히 크지 않으면 Large

     Pool에 메모리 할당은 실패합니다. RMAN은 에러 메세지를 Alert! Log File에 기록하고 Backup이

    나 Restore를 위하여 I/O slaves를 사용하지 않습니다

- Parallel execution

  . PARALLEL_AUTOMATIC_TUNING=true 파라미터가 정의되었으면 Large Pool을 사용하고 그렇지

    않으면 Shared Pool을 사용합니다

- Large Pool 크기

  . LARGE_POOL_SIZE 파라미터에 의해 결정되며 이 파라미터는 동적이 아닙니다

- Large Pool 과 LRU list

  . Large Pool은 LRU list를 사용하지 않습니다. LRU list를 사용하는 Shared Pool안의 예약된

     공간과 다릅니다

6) Java Pool

- Java Pool은 선택적이지만 JAVA를 설치하거나 사용하려면 필요합니다. 크기는 JAVA_POOL_SIZE

   파라미터에 의해 결정되며, 기본 크기는 24MB입니다

7) Program Global Area

- Program Global Area 혹은 Process Global Area (PGA)는 단일 서버 프로세서나

  단일 백그라운드 프로세서를 위한 데이터와 제어정보를 갖고 있습니다. PGA는 프로세스가 시작할

  때 할당되고 프로세스가 종료되면 해제됩니다. 여러 개의 프로세스들에 의해 공유되는 SGA에 반해

  PGA는 단지 한 개의 프로세스에 의해 사용되는 영역입니다

- PGA 의 내용

  . PGA의 내용은 인스턴스가 Dedicated Server 혹은 Shared Server에서 운영되느냐에 따라 달라

     집니다. 일반적으로 PGA는 다음과 같은 정보를 포함

     Private SQL Area : bind 정보와 실행 메모리 구조 같은 데이터를 포함

     Session 메모리 : 세션 변수와 세션과 관련된 다른 정보를 포함

     SQL Work Area : Sort, Hash-join, Bitmap merge, Bitmap 생성시 사용

3. 프로세스 구조

오라클은 여러 가지 종류의 프로세스들을 갖고 있습니다. 사용자가 오라클 서버에
접속했을 때 시작하는 사용자 프로세스, 사용자가 세션을 만들었을 때 시작하여
오라클 인스턴스와 접속하는 서버 프로세스, 오라클 인스턴스가 시작했을 때
시작하는 백그라운드 프로세스가 그것입니다

1) 사용자 프로세스

- 데이터베이스의 정보를 요구하는 사용자는 먼저 오라클 서버와 접속을 해야 합니다. SQL*Plus

   같은 Tool을 사용하여 접속하면 사용자 프로세스가 시작됩니다. 사용자 프로세스는 오라클 서버와

   직접 작용하지 않는 대신 세션을 만들고 서버 프로세스를 시작시키는 User Program Interface

   (UPI)를 통해 접속합니다

2) 서버 프로세스

- 사용자가 접속하면 사용자의 요구를 처리하기 위해 서버 프로세스가 시작됩니다.

   서버 프로세스는 Dedicated Server process 혹은 Shared Server process가 될 수 있습니다.

   Dedicated Server 환경에서, 서버 프로세스는 한 개의 사용자 프로세스 요구를 처리하며 사용자

   프로세스가 종료하면 서버 프로세스도 종료합니다. 반면 Shared Server 환경에서, 서버

   프로세스는 여러 개의 사용자 프로세스 요구를 처리합니다. 서버 프로세스는 Oracle Program

   Interface(OPI)를 사용하여 오라클 서버와 통신합니다 

3) 백그라운드 프로세스

- 오라클은 뒤에서 설명할 다섯 개의 필수적인 백그라운드 프로세스와 옵션이 사용됐을 때

   시작하는 선택적인 백그라운드 프로세스가 있습니다

  . RECO : Recover

  . QMNn : Advanced Queuing

  . ARCn : Archiver

  . LCKn : Rac Lock Manager - Instance Locks

  . LMON : RAC DLM Monitor - Global Locks

  . LMDn : RAC DLM Monitor - Remote Locks

  . CJQ0 : Coordinator Job Queue background process

  . Dnnn : Dispatcher

  . Snnn : Shared Server

  . Pnnn : Parallel Query Slaves

- Database Writer (DBWn)

. 서버 프로세스는 변경을 Database Buffer Cache 안의 언두 블럭과 데이터 블럭에 기록합니다.

  DBWn은 Database Buffer Cache 안의 Dirty Buffer들을 데이터 파일에 기록합니다. 이렇게

  함으로써 Database Buffer Cache 안에 사용할 수 있는 많은 수의 Free Buffer를 보장할 수

  있습니다. 또한 서버 프로세스는 Database Buffer Cache 안에서만 변경을 하므로 데이터베이스의

  성능이 향상됩니다

. DBWn은 다음과 같은 경우가 될 때까지 데이터 파일에 기록을 지연합니다

  Checkpoint가 발생했을 때

  Dirty Buffer의 수가 한계에 도달했을 때

  서버 프로세스가 지정된 수의 블럭을 읽는 동안 Free Buffer를 찾지 못했을 때

  시간이 경과했을 때

  Real Application Clusters (RAC) 환경에서 ping을 요구했을 때

  테이블스페이스를 OFFLINE 시킬 때

  테이블스페이스를 READ ONLY로 변경시킬 때

  테이블을 DROP 하거나 TRUNCATE 시킬 때

  테이블스페이스를 BEGIN BACKUP 했을 때

- Log Writer (LGWR)

  . LGWR는 순차적으로 Redo Log Buffer를 리두 로그 파일에 기록합니다. 리두는 복구에 사용되므로

    LGWR는 리두가 디스크에 쓰여진 후에 COMMIT 명령을 확인합니다. LGWR는 데이터 파일에 기록

    하기 위해 DBWn을 부를 수도 있습니다 

  . LGWR는 다음과 같은 경우에 발생합니다

    COMMIT 명령이 수행됐을 때

    Redo Log Buffer가 1/3 이상 찼을 때

    Redo Log Buffer 안의 변경이 1MB를 초과했을 때

    DBWn이 Database Buffer Cache의 변경된 블럭을 데이터 파일에 기록하기 전 매 3초 마다

- System Monitor (SMON)

  . 오라클 인스턴스가 실패하면, 디스크에 기록되지 않은 SGA 안의 정보는 잃어버립니다.

    인스턴스를 잃은 후에 데이터베이스를 다시 시작하면 SMON이 자동적으로 인스턴스

    복구를 수행합니다 

  . 다음과 같은 순서로 인스턴스가 복구

- Process Monitor (PMON) 

. PMON은 실패한 프로세스를 다음과 같이 정리

  사용자의 현재 트랜잭션을 취소

  현재 걸려 있는 테이블 잠금과 로우 잠금을 해제

  사용자에 의해 유지되고 있는 다른 자원을 해제

  죽은 Dispatcher를 다시 시작함

- Checkpoint (CKPT)

. 매 3초마다 CKPT 프로세스는 리두로그 파일에서 복구가 시작될 위치를 확인하기 위해 컨트롤 파일

  안에 데이터를 저장합니다. 이것을 Checkpoint라고 부릅니다 

  Checkpoint의 목적은 한 시점 전에 Database Buffer Cache에서 수정된 모든 버퍼들이 데이터

  파일에 기록된 것을 보장하는 것입니다. 이 시점이 인스턴스 실패 시에 복구를 시작할 위치입니다.

  DBWn는 그 시점 이전에 Database Buffer Cache에서 변경된 모든 버퍼들을 기록합니다

  로그 스위치가 발생할 때 CKPT는 데이터 파일의 헤더에 Checkpoint 정보를 기록합니다

. Checkpoint는 다음과 같은 이유로 발생

  1. 메모리에서 수정된 데이터 블럭들이 주기적으로 디스크에 쓰여져 시스템 실패시에 데이터가

     손실되지 않도록 하기 위해

  2. 인스턴스 복구에 필요한 시간을 줄이기 위해, Checkpoint 이후의 리두 로그 엔트리만이 복구 필요

  3. 모든 COMMIT 된 데이터들이 데이터베이스 종료시에 데이터 파일에 기록된 것을 보장하기 위해

- Archiver (ARCn)

  . ARCn은 데이터베이스의 구성에 따라 선택이지만 디스크 손실 후에 데이터베이스를 복구하기 위해

    매우 중요합니다. 
    리두 로그 파일이 꽉 차면 오라클 서버는 다음 리두 로그 파일에 쓰기를 시작합니다. 한 개의 리두

    로그 파일에서 다음 리두 로그 파일로 옮겨 쓰는 것을 로그 스위치라고 부릅니다. 
    ARCn 프로세스는 로그 스위치가 발생하면 꽉 찬 리두 로그 파일의 백업을 시작합니다. 이렇게

    리두 로그 파일이 다시 사용되기 전에 자동적으로 백업되어 데이터베이스에서 만들어진 모든

    변경은 보관됩니다. DBA는 디스크가 깨진 경우 그 시점까지 데이터베이스를 복구할 수 있습니다 

. NOARCHIVELOG 혹은 ARCHIVELOG 모드로 운영

  NOARCHIVELOG : 리두 로그 파일은 로그 스위치가 발생할 때 겹쳐 쓰여 집니다

                              LGWR는 그 그룹에 대한 Checkpoint가 완료될 때까지 리두 로그 그룹을

                              겹쳐 쓸 수 없습니다. 이것은 COMMIT 된 데이터들이 인스턴스 실패 시에

                              복구될 수 있음을 보장합니다

  ARCHIVELOG  : 리두 로그 그룹은 다시 사용되기 전에 반드시 기록되어야 합니다

                           데이터베이스에서 만들어진 변경은 리두 로그 파일에 기록되어 있으므로 DBA는

                           데이터 파일의 물리적인 백업과 아카이브 파일을 사용하여 COMMIT 된 데이터의

                           손실 없이 데이터베이스를 복구할 수 있습니다

4. SQL 문장처리

사용자가 SQL*Plus를 사용하여 오라클 서버에 접속하면 사용자 프로세스가 시작하여
세션을 만들고 서버 프로세스를 시작시킵니다.
사용자 프로세스에서 수행시킨 SQL 문장을 서버 프로세스에서 처리할 때 사용되는 
구성요소는 SQL 문장의 종류에 따라 다릅니다. 어떤 구성요소는 SQL 문장 처리에
사용되지 않기도 합니다

- QUERY 문 처리

  . Parse (구문분석)

    1. 동일한 문장을 Library Cache에서 찾음

    2. 문법을 체크

    3. 객체명과 권한을 체크

    4. Parse 과정에서 사용되는 객체에 잠금을 함

    5. Execution plan을 생성하여 Library Cache에 저장함

  . Bind : 변수들에 값을 지정합니다

  . Execute : 문장을 처리합니다

  . Fetch : 사용자 프로세스에 데이터를 보냅니다

- DML 문 처리

  . Parse (구문분석)

  . Bind

  . Execute

    1. 데이터 블럭과 undo 블럭을 Buffer Cache에서 찾음

    2. 없으면 데이터 파일에서 읽어서 Buffer Cache에 저장함

    3. 변경될 데이터에 잠금을 함

    4. Redo Log Buffer에 변경 전 데이터와 변경 후 데이터를 기록

    5. 변경 전 데이터를 undo 블럭에 기록하고 데이터 블럭을 변경함

    6. Buffer Cache 안의 변경된 블럭은 Dirty Buffer로 기록됨

  . DELETE와 INSERT 문의 처리과정도 이와 유사합니다. DELETE 문의 변경 전 데이터는 삭제된

    로우의 전체 칼럼 값이며, INSERT 문의 변경 전 데이터는 로우의 위치 정보입니다

- DDL 문 처리

  . DDL 문의 실행은 DML 문이나 QUERY 문의 실행과 다릅니다.  왜냐하면 DDL 문의 성공은

    Dictionary에 쓰기를 요구합니다. 실제 Parsing은 Parsing과 Dictionary 검색과 Execution을

   포함합니다. Transaction Management, Session Management, System Management

   SQL 문이 Parse와 Execute 단계를 사용하여 처리됩니다

출처 - http://mes2good.egloos.com/763061#763061_1

http://www.gurubee.net/

http://dbnit.net/dashboard.action

http://wiki.gurubee.net/display/SWDEV/02.Oracle

의존 라이브러리 설치

아래의 명령을 이용하여 오라클 설치시 필요한 의존 라이브러를 설치합니다.

pdksh 설치파일은 yum 으로 설치가 되지 않아 직접 rpm 파일을 다운로드 받아 설치합니다.

Kernel Parameter 설정

아래의 명령으로 Kernel Parameter 설정 파일을 편집합니다.

아래의 내용으로 수정합니다.

아래의 명령을 이용하여 변경된 Kernel Parameter 을 적용합니다.

정상적으로 적용시 아래와 같은 메시지가 나타납니다.

사용자 자원 제한 설정

아래의 명령으로 limits.conf 파일을 편집합니다.

아래의 내용을 추가합니다.

사용자 인증 보안 설정

아래의 명령으로 해당 설정파일을 편집합니다.

session    required     pam_namespace.so 다음 라인에 아래의 내용을 추가합니다.

SELINUX 설정 해제

아래의 명령으로 해당 설정파일을 편집합니다.

아래와 같이 SELINUX 설정을 disabled 로 설정합니다.

hostname 설정

아래의 명령을 실행하여 hostname 을 확인합니다.

아래와 같이 hostname 이 나타납니다.

재부팅 없이 호스트명 변경

영구적 호스트명 변경

아래와 같이 HOSTNAME 의 속성을 변경합니다.

hosts 파일에 host 명을 추가 시켜줍니다.

아래와 같이 hostname 을 추가시킨후 저장합니다.

사용자 계정 생성

아래의 명령을 이용하여 사용자 그룹과 계정을 생성합니다.

아래의 명령을 이용하여 oracle 설치 디렉토리를 생성한 후 권한을 부여합니다.

환경변수 설정

oracle 사용자의 환경 변수를 편집합니다.

아래의 내용을 입력합니다.

Oracle 설치

아래의 명령을 이용하여 오라클 사용자로 권한을 변경합니다.

설치파일 압축해제

Oracle 설치파일의 압축을 해제합니다.

압축을 해제한 후 설치 디렉토리로 이동합니다.

Oracle Universal Installer 실행

아래의 명령을 이용하여 Oracle Universal Installer 를 실행합니다.

정상적으로 오라클 인스톨러가 실행되면 아래와 같은 메시지가 출력된 후, 설치 화면이 나타납니다.

아래와 같은 설치 화면이 나타나면 (1) 번 항목의 체크를 해제한 후 [Next >] 버튼을 클릭합니다.

이메일 주소를 입력하지 않을 경우 아래와 같이 Email Address Not Specified 팝업이 나타나면 계속 진행을 위해 [Yes] 버튼을 클릭합니다.

Create and configure a database 항목을 선택한 후 [Next >] 버튼을 클릭합니다.

Server Class 항목을 선택한 후 [Next >] 버튼을 클릭합니다.

Single instance database installation 항목을 선택한 후 [Next >] 버튼을 클릭합니다.

Advanced install 항목을 선택한 후 [Next >] 버튼을 클릭합니다.

왼쪽의 Available Languages 선택 상자에서 Korean 을 선택한 후  [Next >] 버튼을 클릭합니다.

Enterprise Edition (4.29GB) 항목을 선택한 후 [Next >] 버튼을 클릭합니다.

Oracle 의 설치디렉토를 확인한후  [Next >] 버튼을 클릭합니다.

General Purpose / Transaction Processing 항목을 선택한 후  [Next >] 버튼을 클릭합니다.

Global database name 과 Oracle Service Identifier (SID) 항목을 각 환경에 맞게 입력한 후  [Next >] 버튼을 클릭합니다.

Memory 탭의 설정을 확인합니다. Enable Automatic Memory Management 항목은 기본은 체크하도록 합니다.

Character sets 탭 에서는 다국어 지원을 위하여 Use Unicode (AL32UTF8) 항목을 선택합니다.

Security 탭의 설정을 확인합니다.

Sample Schemas 탭에서는 Oracle 설치시 샘플 데이터베이스를 생성하고자 할 경우 Create database with sample schemas 항목에 체크를 합니다.

[Next >] 버튼을 클릭합니다.

[Next >] 버튼을 클릭합니다.

[Next >] 버튼을 클릭합니다.

오라클 계정의 패스워드를 설정하는 화면입니다. 관리 계정은 모두 동일한 패스워드를 사용하기 위하여 Use the same password for all accounts 항목을 선택한 후 패스워드를 입력합니다.

패스워드는 하나 이상의 영문 대소문자와 숫자를 포함한 8글자 이상으로 만들어주셔야 합니다. 해당 조건을 충족시키지 못할시 경고 메시지가 나타납니다.

Database Administrator (OSDBA) Group 와 Database Operator (OSOPER) Group 의 usergroup 을 dba 로 설정한 후 [Next >] 버튼을 클릭합니다.

Install 시 필요한 라이브러리를 확인하며, 버전이 맞지 않을 경우에도 나타날수 있습니다. 의존 라이브러리가 설치가 되어있다면, (1) 번 Ignore All 항목을 체크한 후 [Next >] 버튼을 클릭합니다.

Oracle 을 설치 옵션에 대한 최종확인을 합니다. 각 옵션 항목을 확인한 후 [Finish] 버튼을 클릭합니다.

설치가 시작되면 아래의 화면과 같이 진행 상태가 나타납니다.

설치중에 Database 설치 팝업이 나타납니다.

설치가 완료되면 아래와 같이 Database Configuration Assistant 팝업이 나타납니다. [Password Management] 버튼을 클릭합니다.

샘플 데이터베이스의 SCOTT 사용자에 대한 Lock Account 항목의 체크를 해제한 후 [OK] 버튼을 클릭합니다.

아래 화면과 같은 Execute Configuration Scripts 팝업창이 나타나며, 터미널 창을 띄어 (1) 항목에 있는 스크립트를 root 권한으로 실행합니다.

아래의 명령으로 root 권한으로 변경합니다.

orainstRoot.sh 명령을 실행합니다.

정상적으로 실행시 아래와 같은 메시지가 나타납니다.

root.sh 명령을 실행합니다.

정상적으로 실행시 아래와 같은 메시지가 출력됩니다.

스크립트를 모두 실행한 후, Execute Configuration Scripts 팝업창에서 [OK] 버튼을 클릭하면, 오라클의 모든 설치가 완료됩니다. [Close] 버튼을 클릭하여 설치화면을 종료합니다.

설치 확인

Web Admin (EM)

브라우저의 주소창에 https://localhost:1158/em 을 접속하면, 아래와 같이 로그인창이 나타납니다. 각 항목에 로그인 정보를 입력한 후 [Login] 버튼을 클릭합니다.

• User Name : SYS
• Password : 설치시 설정한 패스워드를 입력합니다.
• Connect As : SYSDBA

로그인 성공시 아래와 같은 화면이 나타납니다.

Console

오라클 사용자로 변경합니다.

아래의 설치 위치로 이동합니다.

아래와 같이 sqlplus 명령을 실행합니다.

정상적으로 실행이 되면 아래와 같이 Oracle Console 메시지가 출력됩니다.

또는 아래와 같이 실행이 가능합니다.

Enter user-name: 프롬프트가 나타나면 “/ as sysdba” 를 입력하여 콘솔에 접근 가능합니다.

아래의 명령을 이용하여 instance 를 확인합니다.

정상적으로 실행시 아래와 같이 SID 명이 출력됩니다.

아래의 명령을 이용하여 datafile 위치를 확인합니다.

정상적으로 실행시 아래와 같이 datafile 의 위치가 출력됩니다.

Service 등록

root 권한으로 변경합니다.

아래의 파일을 편집합니다. oratab 파일은 Oracle 설치시 자동으로 생성되는 파일입니다.